09. X.509, chaîne et contraintes

Comprendre le mécanisme

Un certificat X.509 lie une clé publique et des informations selon une signature d’émetteur. Une chaîne doit atteindre une ancre admise et respecter périodes de validité, contraintes et usages applicables. Posséder un fichier de certificat public ne donne pas le secret correspondant. Une chaîne syntaxiquement complète n’est pas forcément une chaîne de confiance pour le client qui la reçoit.

Raisonner et vérifier

Séparez magasin de confiance du client, certificat serveur, intermédiaires et clé privée. Un intermédiaire manquant peut provoquer un échec selon la construction de chaîne disponible ; télécharger n’importe quel certificat ne doit pas devenir une nouvelle ancre de confiance. Le renouvellement doit conserver la bonne association clé/certificat et les permissions d’accès. L’état de révocation dépend aussi des politiques et capacités du client.

Certificat public

Un certificat porte une clé publique et des informations signées. Le secret correspondant est séparé. Un certificat associe une clé publique et des informations signées. Il peut être partagé ; la clé privée correspondante reste un objet distinct qui doit être protégé contre lecture et export non autorisés.

Ancre de confiance

Une chaîne doit atteindre une ancre admise. La confiance dépend du magasin et de la politique du client. Le client construit une chaîne vers une ancre qu’il admet déjà selon sa politique. Recevoir une racine dans la réponse du serveur ne doit pas rendre cette racine automatiquement digne de confiance.

Validité temporelle

Les périodes de validité doivent être vérifiées. La validation de chemin comporte plusieurs exigences. Vérifiez notBefore et notAfter avec une horloge correcte. Une signature mathématiquement valide peut appartenir à un certificat expiré ou pas encore valable ; ce sont des conditions supplémentaires de validation.

Contraintes

Les contraintes d’usage comptent. Les extensions peuvent limiter les usages. Usages de clé, extended key usage et contraintes d’autorité limitent le rôle des certificats. La présence d’une signature ne suffit pas si un intermédiaire n’est pas admis à signer le certificat présenté.

Intermédiaires

Des intermédiaires manquants peuvent empêcher la validation. Les capacités de construction et données disponibles diffèrent. Un serveur doit fournir les éléments intermédiaires nécessaires au chemin attendu. Le succès sur un navigateur qui dispose d’un cache ne prouve pas que tous les clients construiront la même chaîne.

Représentation PEM

PEM décrit une représentation. Le format de représentation ne fixe pas le type de contenu. PEM est une enveloppe textuelle qui peut contenir différents objets selon son en-tête. Inspectez le type réel et les permissions ; un nom de fichier en .pem ne dit pas qu’il s’agit seulement d’un certificat public.

Magasin client

Le magasin client doit être identifié. Les ancres de confiance varient selon les clients. Navigateur, PHP et Java peuvent utiliser des magasins différents. Identifiez celui du client en échec avant d’importer une autorité ; une confiance ajoutée à un outil ne s’étend pas automatiquement aux autres.

Identité de service

Le nom du service demande aussi une vérification. L’identité de destination reste distincte de la validité du chemin. Après la chaîne, comparez l’identité de référence aux identifiants du certificat selon les règles du client. Une chaîne valide pour api-a ne protège pas une connexion attendue vers api-b.

Révocation

La révocation dépend des politiques et capacités du client. Le comportement doit être décrit et testé. Les mécanismes disponibles et la politique en cas d’indisponibilité varient selon le client. Documentez ce qui est réellement vérifié et le délai de retrait attendu, plutôt que supposer une consultation universelle immédiate.

Clé privée hors public

La clé privée doit être protégée hors du répertoire public. La fuite donne des capacités sensibles. Le document root ne doit jamais permettre de télécharger une clé privée ou sa sauvegarde. Protégez permissions, export, copies temporaires et accès d’exploitation séparément du certificat distribué aux clients.

Atelier guidé : lire, expliquer et vérifier le code

openssl x509 -in lab-server.crt -noout -subject -issuer -dates
# subject=CN=api.example.test
# issuer=CN=Lab CA

La commande affiche sujet, émetteur et dates du certificat. Elle ne démontre ni la possession de la clé privée par un client ni la validation complète de la chaîne. Complétez le diagnostic avec un magasin de confiance identifié et un test du nom de destination attendu.

Le certificat et la clé privée sont des objets distincts. issuer décrit l’émetteur. Le nom n’est pas un secret de signature. Cette commande n’a pas cet objet ni ces paramètres.

Travail pratique : Créez une autorité locale de laboratoire puis testez client avec et sans cette ancre. Retirez un intermédiaire.

Critères de correction : Comparez les erreurs de construction et de confiance, sans désactiver les contrôles. Documentez précisément le magasin utilisé et la portée du laboratoire. Gardez la clé privée hors du répertoire public.