PKI et certificats X.509 : comprendre et manipuler avec OpenSSL

Dans un monde de plus en plus connecté, la sécurité des communications est essentielle. L’infrastructure à clé publique (PKI) et les certificats X.509 constituent la base de la confiance sur Internet : HTTPS, S/MIME, authentification mutual TLS (mTLS), signatures applicatives, etc.

Qu’est‑ce qu’un certificat X.509 ?

Un certificat X.509 est un fichier normalisé contenant :

• Une clé publique d’un sujet (serveur, utilisateur, appareil…) et des informations sur le détenteur. En plus de ces informations on va retrouver
• Un Distinguished Name (DN) décrivant ce sujet (CN, O, C, etc.)
• La signature d’une Autorité de Certification (CA) qui atteste de l’authenticité du couple « clé publique ↔ identité »
• Des extensions (période de validité, usages permis, numéros de série, empreintes…)

Le principe : si je fais confiance à la CA qui a signé le certificat, je peux faire confiance à la clé publique qu’il contient.

Un certificat permet de dialoguer de manière sécurisée (communication chiffrée).

---

1. Générer une clé privée RSA

Pourquoi ? La clé privée est la base même de toute PKI : elle permet de signer (prouver l’identité) et de déchiffrer les messages destinés au sujet. Elle doit rester secrète. On commence donc toujours par la générer le certificat.

openssl genrsa -out ma_cle_privee.key 2048

• 2048 bits : sécurité correcte pour un certificat d’usage courant (4096 recommandés pour une racine).
• Le fichier ma_cle_privee.key est au format PEM et doit être protégé (permissions 600, coffre-fort, HSM…).

---

2. Créer un certificat X.509 auto‑signé (ex. : Root CA)

Pourquoi ? Quand on n’a aucune autorité au‑dessus de soi, on doit s’auto‑signer : c’est le cas d’une Autorité de Certification racine. Ce certificat deviendra la racine de confiance importée dans les magasins de certificats des systèmes ou équipements.

openssl req -x509 -new -key ma_cle_privee.key -sha256 -days 3650 -out mon_certificat_root.crt

• -x509 : mode « auto‑signature ».
• Période de 10 ans (-days 3650) souvent choisie pour une racine.
• Les informations DN saisies identifieront la CA.

---

3. Générer une CSR (Certificate Signing Request)

Pourquoi ? Une CSR est la « demande officielle » qu’on adresse à une CA. Elle contient la clé publique du futur certificat, le DN souhaité et une signature faite avec la clé privée, prouvant la possession de celle‑ci.

openssl req -new -key ma_cle_privee.key -out ma_requete.csr

La CSR est ensuite envoyée à la CA (publique ou interne) qui, après validation, émet le certificat signé.

---

4. Signer une CSR pour émettre un certificat intermédiaire

Pourquoi ? Dans une bonne PKI, la racine reste hors‑ligne. On crée donc une CA intermédiaire (signée par la racine) : elle signera les certificats serveur ou utilisateur. Cela limite l’exposition de la clé privée racine.

a) Générer la clé privée de l’intermédiaire

openssl genrsa -out intermediaire.key 4096

b) Générer la CSR de l’intermédiaire

openssl req -new -key intermediaire.key -out intermediaire.csr

c) Signer la CSR avec la racine

openssl x509 -req -in intermediaire.csr -CA mon_certificat_root.crt -CAkey ma_cle_privee.key -CAcreateserial -out intermediaire.crt -days 1825 -sha256

• -CAcreateserial crée/met à jour le fichier de numéro de série.
• Validité de 5 ans pour l’intermédiaire (-days 1825).

---

5. Lire et analyser un certificat

Pourquoi ? Vérifier un certificat permet d’auditer son contenu, dépanner des erreurs de chaîne ou contrôler ses extensions (Key Usage, SAN…).

a) Afficher le certificat complet

openssl x509 -in mon_certificat_root.crt -noout -text

b) Vérifier le sujet

openssl x509 -in mon_certificat_root.crt -noout -subject

c) Vérifier l’émetteur

openssl x509 -in mon_certificat_root.crt -noout -issuer

d) Empreinte SHA‑256

openssl x509 -in mon_certificat_root.crt -noout -fingerprint -sha256

---

6. Vérifier la chaîne de confiance d’un certificat

Pourquoi ? Avant de déployer ou de diagnostiquer un problème TLS, il est judicieux de vérifier localement que le certificat client ou serveur se valide correctement contre la chaîne CA.

# Regroupe l’intermédiaire et la racine dans un fichier
cat intermediaire.crt mon_certificat_root.crt > chaine.pem

# Vérifie la validité de certificat_client.crt contre la chaîne
openssl verify -CAfile chaine.pem certificat_client.crt

---

Détails des options

Option	Rôle
openssl	Appelle la boîte à outils OpenSSL.
req	Lance la sous-commande « request » pour gérer des CSR (Certificate Signing Request), mais utilisée ici pour générer un certificat X.509 directement.
-x509	Demande à OpenSSL de produire un certificat X.509 auto-signé au lieu d’une CSR.
-new	Indique qu’on veut créer une nouvelle requête/certificat (même en mode -x509).
-nodes	(Sans le « passphrase ») Signifie “no DES” → on ne chiffre pas la clé privée si elle est générée avec la commande. ❗️ Attention : dans cette commande, on fournit déjà une clé (-key), donc -nodes est inutile ici — il ne fait rien.
-key ma_cle_privee.key	Spécifie le fichier contenant la clé privée qui sera utilisée pour signer le certificat.
-sha256	Définit l’algorithme de hachage pour la signature du certificat : SHA-256 (fortement recommandé aujourd’hui).
-days 3650	Durée de validité du certificat : ici 10 ans (3650 jours).
-out mon_certificat_root.crt	Fichier de sortie : contiendra le certificat auto-signé au format PEM.

Formats de certificats X.509

Conclusion

La manipulation de certificats X.509 est un socle indispensable pour sécuriser ses applications. Comprendre pourquoi chaque étape est nécessaire (clé privée, auto‑signature, CSR, intermédiaire, lecture et validation) permet d’anticiper les problèmes et d’opérer une PKI robuste, que ce soit en DevOps, en intégration de partenaires ou en déploiement de mTLS.