OpenSSL est le couteau suisse de la gestion des certificats SSL/TLS. Qu’il s’agisse de générer une clé privée, d’inspecter un certificat sur le point d’expirer, de créer une Autorité de Certification pour des services internes ou de déboguer un échec de handshake TLS, le CLI openssl gère tout. Ce guide couvre toutes les opérations essentielles liées aux certificats — de la génération de clés à la validation de la chaîne — avec des commandes pratiques exécutables immédiatement sur n’importe quel serveur Linux.

Prérequis

  • OpenSSL installé (version 1.1.x ou 3.x — vérifiez avec openssl version)
  • Familiarité de base avec la ligne de commande Linux
  • Accès root ou sudo pour installer des certificats au niveau système
  • Compréhension des certificats SSL/TLS (paires clé publique/privée, CA, chaînes de confiance)

Génération de Clés et de Demandes de Signature de Certificat

Chaque cycle de vie de certificat commence par une clé privée. OpenSSL prend en charge RSA, ECDSA et Ed25519. RSA 4096 bits et ECDSA P-256 sont les choix les plus courants pour la production.

Générer une clé privée RSA :

openssl genrsa -out key.pem 4096

Générer une clé ECDSA (plus rapide, plus petite, aussi sécurisée) :

openssl ecparam -genkey -name prime256v1 | openssl ec -out ec-key.pem

Créer une Demande de Signature de Certificat (CSR) :

openssl req -new -key key.pem -out request.csr

Vous serez invité à renseigner les champs du Distinguished Name (DN). Le champ le plus critique est Common Name (CN) — il doit correspondre à votre nom de domaine. Pour TLS moderne, les Subject Alternative Names (SANs) sont obligatoires. Utilisez un fichier de configuration pour les définir :

cat > san.conf <<EOF
[req]
req_extensions = v3_req
distinguished_name = dn
[dn]
[v3_req]
subjectAltName = @alt_names
[alt_names]
DNS.1 = example.com
DNS.2 = www.example.com
EOF

openssl req -new -key key.pem -out request.csr -config san.conf

Inspecter le CSR avant de le soumettre :

openssl req -text -noout -in request.csr

Création de Certificats Auto-signés

Les certificats auto-signés sont idéaux pour les services internes, les environnements de développement et les API privées où une CA publique n’est pas nécessaire.

Créer un certificat auto-signé en une seule commande :

openssl req -x509 -newkey rsa:4096 \
  -keyout key.pem -out cert.pem \
  -sha256 -days 365 -nodes \
  -subj "/CN=example.com/O=MyOrg/C=US"

L’indicateur -nodes ignore le chiffrement par mot de passe de la clé privée. Retirez-le pour les clés stockées hors ligne.

Auto-signé avec SANs (requis par les navigateurs modernes) :

openssl req -x509 -newkey rsa:4096 \
  -keyout key.pem -out cert.pem \
  -sha256 -days 365 -nodes \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

Création d’une Autorité de Certification Interne

Une CA interne vous permet d’émettre des certificats de confiance pour tous les services de votre organisation sans dépendre d’une CA publique.

Créer la clé CA et le certificat racine auto-signé :

openssl genrsa -aes256 -out ca-key.pem 4096
openssl req -new -x509 -days 3650 \
  -key ca-key.pem -out ca-cert.pem \
  -subj "/CN=My Internal CA/O=MyOrg/C=US"

Signer un CSR serveur avec votre CA :

openssl x509 -req -days 365 \
  -in request.csr \
  -CA ca-cert.pem -CAkey ca-key.pem \
  -CAcreateserial -out server-cert.pem \
  -extfile san.conf -extensions v3_req

Inspection et Validation des Certificats

Lire un certificat local :

openssl x509 -text -noout -in cert.pem

Vérifier uniquement la date d’expiration :

openssl x509 -enddate -noout -in cert.pem

Inspecter le certificat d’un serveur distant :

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -text -noout

Vérifier que le certificat correspond à la clé privée :

openssl rsa  -noout -modulus -in key.pem  | md5sum
openssl x509 -noout -modulus -in cert.pem | md5sum

Comparaison

FonctionnalitéOpenSSL CLIcfssleasy-rsacertbot
Certificats auto-signésOuiOuiOuiNon
CA interneOuiOuiOuiNon
Intégration CA publiqueNonNonNonOui (Let’s Encrypt)
Support SANOui (fichier config)OuiOuiOui
Export PKCS#12OuiPartielNonOui
Courbe d’apprentissageMoyenneFaibleFaibleTrès faible

Scénario Réel

Vous avez un serveur Nginx de production qui génère des erreurs de handshake SSL. Les utilisateurs signalent “NET::ERR_CERT_COMMON_NAME_INVALID” dans Chrome. Voici le flux de diagnostic :

# Étape 1 : vérifier quel certificat le serveur délivre
echo | openssl s_client -connect myserver.com:443 -servername myserver.com 2>/dev/null \
  | openssl x509 -text -noout | grep -A3 "Subject Alternative Name"

# Étape 2 : si aucun SAN n'est listé, régénérer avec l'approche san.conf

# Étape 3 : vérifier la correspondance clé/certificat après régénération
openssl rsa  -noout -modulus -in /etc/nginx/ssl/key.pem  | md5sum
openssl x509 -noout -modulus -in /etc/nginx/ssl/cert.pem | md5sum

# Étape 4 : tester le handshake complet
openssl s_client -connect myserver.com:443 -servername myserver.com

Pièges et Cas Particuliers

Les SANs sont obligatoires depuis 2017. Chrome 58 a abandonné le support des certificats avec CN uniquement. Incluez toujours subjectAltName même pour les certificats mono-domaine.

Les permissions du fichier de clé sont importantes. La clé privée doit être lisible uniquement par le processus qui en a besoin : chmod 600 key.pem. Nginx et Apache refuseront de démarrer si la clé est lisible par tous.

Les clés protégées par mot de passe bloquent les redémarrages automatisés. Utilisez -nodes lors de la génération de clés pour les serveurs web.

L’ordre de la chaîne de certificats est important. Nginx et Apache attendent le certificat serveur en premier, suivi des certificats intermédiaires, dans le même fichier PEM.

Le décalage horaire casse la validation. Si l’horloge du serveur est décalée de plus de quelques minutes, openssl verify échouera avec “certificate not yet valid”.

Exporter au format PKCS#12 pour Windows/Java :

openssl pkcs12 -export \
  -out bundle.p12 \
  -inkey key.pem \
  -in cert.pem \
  -certfile ca-cert.pem

Résolution de Problèmes

“verify error:num=20:unable to get local issuer certificate” — Le certificat CA n’est pas dans votre magasin de confiance. Passez-le explicitement : openssl verify -CAfile ca-cert.pem cert.pem.

“private key does not match the certificate public key” — Les hachages du modulus diffèrent. Vous avez régénéré la clé sans régénérer le certificat, ou mélangé les fichiers.

“no shared cipher” — Le client et le serveur ne peuvent pas s’accorder sur une suite de chiffrement. Vérifiez la configuration SSL du serveur.

“certificate has expired” — Vérifiez avec openssl x509 -enddate -noout -in cert.pem et renouvelez avec le même CSR.

Résumé

  • Générez des clés RSA 4096 ou ECDSA P-256 avec openssl genrsa ou openssl ecparam
  • Incluez toujours des Subject Alternative Names — les certificats CN-only sont rejetés par les navigateurs modernes
  • Utilisez un fichier de configuration avec la section [alt_names] pour ajouter des SANs aux CSR et certificats auto-signés
  • Inspectez tout certificat avec openssl x509 -text -noout -in cert.pem
  • Vérifiez la correspondance clé/certificat en comparant les hachages MD5 du modulus
  • Créez une CA interne pour Kubernetes, VPN et microservices sans dépendances externes
  • Exportez au format PKCS#12 pour les keystores Java et les magasins de certificats Windows
  • Conservez les clés privées CA chiffrées, hors ligne et avec des sauvegardes séparées

Articles Connexes