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
Format | Encodage / Conteneur | Extensions usuelles | Contenu possible | Clé privée incluse ? | Usages courants | Conversion OpenSSL |
---|---|---|---|---|---|---|
PEM (Privacy-Enhanced Mail) |
ASCII Base64 avec en-têtes -----BEGIN ... |
.pem , .crt , .cer , .key |
Certificat, chaîne, clé privée/publique | Oui | Serveurs Apache/Nginx, scripts | openssl x509 -in cert.der -inform der -out cert.pem |
DER (binaire ASN.1) |
Binaire | .der , .cer |
Certificat ou clé publique | Non | Java, Windows, mobiles | openssl x509 -in cert.pem -outform der -out cert.der |
PKCS #7 (P7B) |
ASN.1 (binaire ou Base64) | .p7b , .p7c |
Chaîne de certificats | Non | Windows, Java TrustStores | openssl crl2pkcs7 -nocrl -certfile chain.pem -out chain.p7b |
PKCS #12 (PFX) |
Conteneur binaire chiffré | .p12 , .pfx |
Certificats + clé privée | Oui | Windows, navigateurs, appliances | openssl pkcs12 -export -inkey key.pem -in cert.pem -out bundle.p12 |
JKS (Java KeyStore) |
Conteneur Java binaire | .jks |
Clé + certs ou trustedCert | Oui (si keypair) | Java, Tomcat, Spring | keytool -importkeystore -srckeystore bundle.p12 -destkeystore store.jks -srcstoretype PKCS12 |
CER / CRT | PEM ou DER (selon contexte) | .cer , .crt |
Certificat seul | Non | Usage général Windows/Linux | Varie selon le contenu |
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.