Créer et gérer des chaînes de certificats

Une CA racine est un certificat auto-signé qui sert d’ancrage de confiance ultime. La clé privée de la CA racine doit rester hors ligne, sur un système isolé du réseau ou dans un HSM, car sa compromission met en péril toute la PKI. "openssl req -x509 -new -nodes -key root_key.pem -sha256 -days 3650 -out root_cert.pem" génère un certificat racine auto-signé valide pendant 10 ans.

Les CA intermédiaires sont signées par la CA racine et utilisées pour l’émission quotidienne de certificats. Tout d’abord, générez la clé intermédiaire et le CSR : "openssl req -new -key intermediate_key.pem -out intermediate.csr". Ensuite, la CA racine le signe : "openssl x509 -req -in intermediate.csr -CA root_cert.pem -CAkey root_key.pem -CAcreateserial -days 1825 -out intermediate_cert.pem".

Les certificats d’entité finale, ou certificats feuilles, sont signés par la CA intermédiaire pour des serveurs ou des clients spécifiques. Générez la clé et le CSR du serveur avec des noms alternatifs du sujet (SAN), puis signez-le avec l’intermédiaire : "openssl x509 -req -in server.csr -CA intermediate_cert.pem -CAkey intermediate_key.pem -CAcreateserial -extensions v3_req -days 365 -out server_cert.pem".

La clé privée de la CA racine reste hors ligne et n’est utilisée que pour signer un petit nombre de certificats de CA intermédiaires. L’émission quotidienne de certificats est assurée par des CA intermédiaires en ligne. Si une CA intermédiaire est compromise, elle peut être révoquée et remplacée sans compromettre la racine. La clé racine reste protégée puisqu’elle n’a jamais été exposée en ligne.

La commande "openssl ca" fournit un flux de travail de CA plus complet que "openssl x509 -req". Elle gère une base de données de certificats (index.txt), attribue des numéros de série à partir d’un fichier de série et prend en charge la génération de CRL. Elle nécessite un fichier de configuration openssl.cnf correctement configuré, avec des sections propres à la CA qui définissent la politique de certificats et les contraintes de longueur de chemin.

Un fichier de chaîne de certificats complet pour un serveur web contient le certificat d’entité finale, suivi des certificats de CA intermédiaires dans l’ordre, jusqu’à juste avant la racine. Les certificats racines ne sont pas inclus, car les navigateurs disposent de magasins racines préinstallés. Ordre de concaténation : "cat server_cert.pem intermediate_cert.pem > chain.pem". Un ordre incorrect provoque des échecs de négociation TLS.

"openssl verify -CAfile root_cert.pem -untrusted intermediate_cert.pem server_cert.pem" vérifie la chaîne complète. L’option "-untrusted" fournit les certificats intermédiaires qui font partie de la chaîne, mais qui ne sont pas encore approuvés. Si la vérification réussit, la sortie est "server_cert.pem: OK". Les erreurs courantes signalent l’absence de certificats intermédiaires ou la présence de certificats expirés.

Les problèmes fréquents de chaîne de certificats comprennent les certificats intermédiaires manquants, lorsque le serveur n’envoie que le certificat feuille, un mauvais ordre de concaténation, lorsque la feuille doit venir en premier, un certificat intermédiaire expiré, qui passe facilement inaperçu puisque l’expiration de la feuille est surveillée, des certificats auto-signés absents du magasin de confiance et une discordance de nom, lorsque le SAN du certificat ne correspond pas au nom d’hôte. Tous ces problèmes peuvent être diagnostiqués avec "openssl s_client -showcerts".

PKCS#12 (.pfx ou .p12) est un format de conteneur qui regroupe la clé privée, le certificat d’entité finale et les certificats intermédiaires dans un seul fichier chiffré. Création : "openssl pkcs12 -export -out bundle.pfx -inkey server_key.pem -in server_cert.pem -certfile intermediate_cert.pem". Ce format est requis par IIS, .NET, les magasins de clés Java et de nombreuses applications d’entreprise.

PEM est de l’ASCII encodé en base64, lisible par l’humain, qui prend en charge plusieurs objets dans un même fichier et qui est utilisé par Apache, nginx et les outils OpenSSL. DER est binaire, avec un objet par fichier, et est utilisé par Java (pour les imports JKS), Android et certains outils d’entreprise. PKCS#12/PFX est un conteneur binaire chiffré pour plusieurs objets, utilisé par Windows et IIS. Prenez connaissance du format attendu par votre système cible avant le déploiement.

Les CA modernes doivent journaliser tous les certificats émis dans des journaux de transparence des certificats (CT) avant leur remise. Lors de la création d’une CA privée pour un usage interne, la journalisation CT n’est pas requise. Cependant, les certificats accessibles au public doivent contenir des horodatages de certificat signés (SCT) pour être approuvés par Chrome. Les CA privées peuvent appliquer leurs propres politiques sans exigences liées à CT.

Lorsque vous assemblez un fichier de chaîne de certificats TLS pour un serveur nginx, quel est l’ordre correct de concaténation ?

Les CA racines sont auto-signées, conservées hors ligne et ne signent que des CA intermédiaires. Les CA intermédiaires gèrent l’émission quotidienne. Les fichiers de chaîne contiennent d’abord la feuille, puis les intermédiaires, la racine étant omise. Vérifiez avec "openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem". Les paquets PKCS#12 regroupent la clé et les certificats pour Windows et Java. Un mauvais ordre de chaîne est une cause courante d’échec du déploiement, que la commande s_client -showcerts permet de diagnostiquer.