Skip to content
Learni
View all tutorials
Sécurité

Comment générer des certificats SSL avec OpenSSL en 2026

18 minINTERMEDIATE
CryptographieOpenSSLPKICertificats SSLSécurité TLS

Introduction

OpenSSL reste en 2026 l'outil de référence pour la cryptographie open-source, utilisé par 99% des serveurs web pour gérer les certificats SSL/TLS. Que vous configuriez un reverse proxy Nginx, un cluster Kubernetes ou une API Node.js, savoir générer des clés privées, des CSR (Certificate Signing Requests) et des certificats auto-signés est indispensable pour les environnements de dev, staging ou même prod isolés.

Ce tutoriel intermédiaire vous guide pas à pas : de la génération de clés RSA/ECC aux configurations personnalisées via openssl.cnf, en passant par les conversions de formats (PEM, PKCS12). Imaginez OpenSSL comme un atelier de forgeron crypto : vous forgez vos propres armes de sécurité. À la fin, vous saurez implémenter une PKI (Public Key Infrastructure) basique, valider des certificats et éviter les failles courantes comme les clés faibles ou les SAN manquants. Prêt à sécuriser vos déploiements ? (128 mots)

Prérequis

  • OpenSSL 3.0+ installé (Linux: sudo apt install openssl; macOS: brew install openssl; Windows: via Chocolatey ou WSL).
  • Terminal Unix-like (Bash/Zsh).
  • Connaissances de base en cryptographie : RSA vs ECC, PEM vs DER.
  • Espace de travail vide : mkdir openssl-tutorial && cd openssl-tutorial.

Vérifier l'installation d'OpenSSL

terminal
openssl version -a
openssl list -1 -cipher-algorithms | head -5
openssl rand -hex 32

Cette séquence vérifie la version (doit être 3.x pour les courbes ECC modernes), liste les algos disponibles et génère un hex aléatoire pour tester l'entropie. Évitez les versions <3.0 qui manquent de post-quantum readiness ; si erreur, réinstallez via gestionnaire de paquets.

Les bases : Clés et formats

Avant de plonger, comprenez les formats : PEM (texte base64, .pem/.key) pour la compatibilité universelle ; PKCS12 (binaire chiffré, .p12/.pfx) pour les stores Java/Tomcat. Une clé privée RSA 2048 bits est standard, mais passez à ECC P-384 pour la perf (comme NIST recommande en 2026). Chaque commande génère des fichiers autonomes, toujours protégés par passphrase initiale.

Générer une clé privée RSA 4096 bits

terminal
openssl genpkey -algorithm RSA -out private-rsa.key -aes256
openssl rsa -in private-rsa.key -out private-rsa-unencrypted.key -passin pass:SuperSecretPass2026

La première commande crée une clé chiffrée AES-256 (passphrase interactive ou via -passout). La seconde la dé-chiffre pour les serveurs (attention : plus vulnérable au vol). Utilisez 4096 bits min en 2026 ; piège : oubliez la passphrase ou utilisez DSA obsolète.

Générer un CSR avec Subject Alternative Names (SAN)

terminal
cat > san.cnf << EOF
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req

[req_distinguished_name]

[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = example.com
DNS.2 = www.example.com
IP.1 = 192.168.1.100
EOF

openssl req -new -key private-rsa-unencrypted.key -out example.csr -config san.cnf -subj "/C=FR/ST=Paris/L=Paris/O=Learni/OU=Dev/CN=example.com"

Ce script crée un san.cnf pour SAN (essentiel pour HTTPS multi-domaines), puis génère un CSR signé par la clé privée. Le -subj évite l'interactif ; vérifiez avec openssl req -text -noout -in example.csr. Piège : sans SAN, les navigateurs modernes rejettent le cert.

Créer un certificat auto-signé valide 1 an

terminal
openssl x509 -req -days 365 -in example.csr -signkey private-rsa-unencrypted.key -out example.crt -extensions v3_req -extfile san.cnf
openssl x509 -in example.crt -text -noout | grep -A5 'Subject Alternative Name'

Signe le CSR avec la clé privée pour un cert racine auto-signé (ok pour dev/staging). -days 365 pour 1 an ; la vérif affiche SAN. En prod, remplacez par CA externe comme Let's Encrypt. Piège : dates d'expiration courtes cassent les tests CI/CD.

Passer à l'ECC pour la performance

RSA est sûr mais lent ; ECC (Elliptic Curve Cryptography) offre l'équivalent sécurité avec clés 10x plus courtes. En 2026, prime256v1 ou secp384r1 sont standards pour TLS 1.3. Analogie : RSA = camion blindé, ECC = moto agile.

Générer clé ECC et certificat

terminal
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:secp384r1 -out private-ecc.key
openssl req -new -key private-ecc.key -out example-ecc.csr -subj "/C=FR/ST=Paris/L=Paris/O=Learni/OU=Dev/CN=ecc.example.com" -addext "subjectAltName=DNS:ecc.example.com"
openssl x509 -req -days 365 -in example-ecc.csr -signkey private-ecc.key -out example-ecc.crt

Génère clé ECC secp384r1 (NIST-approved), CSR avec -addext (OpenSSL 1.1.1+), puis cert. Plus rapide pour handshakes TLS. Vérifiez : openssl ec -in private-ecc.key -text -noout. Piège : courbes non-standard comme brainpool cassent l'interop Chrome.

Convertir en PKCS12 pour Java/Node

terminal
openssl pkcs12 -export -out keystore.p12 -inkey private-rsa-unencrypted.key -in example.crt -certfile ca.crt -passout pass:SuperSecretPass2026
openssl pkcs12 -in keystore.p12 -info -noout -passin pass:SuperSecretPass2026

Bundle clé + cert en .p12 chiffré (utilisable par keystores Java, NODE_EXTRA_CA_CERTS). Ajoutez -certfile pour chaines CA. La vérif liste contenus. Piège : passphrase faible exposée en clair dans scripts ; utilisez vars d'env.

Configuration OpenSSL.cnf personnalisée

openssl.cnf
[ req ]
default_bits       = 4096
prompt             = no
distinguished_name = req_distinguished_name
req_extensions     = req_ext

[ req_distinguished_name ]
C                  = FR
ST                 = Paris
L                  = Paris
O                  = Learni Group
OU                 = DevOps
CN                 = localhost

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = localhost
DNS.2 = 127.0.0.1
IP.1  = 127.0.0.1

Ce openssl.cnf complet automatise les CSR avec defaults (CN=localhost pour dev local). Utilisez avec openssl req -new -key private.key -out csr.csr -config openssl.cnf. Personnalisez pour prod. Piège : chemin absolu vers cnf manquant casse les validations.

Vérifier et révoquer un certificat

terminal
openssl verify -CAfile example.crt example-ecc.crt
openssl x509 -in example.crt -serial -noout
openssl ca -revoked example.crt -keyfile private-rsa-unencrypted.key -cert example.crt -config openssl.cnf

Vérifie chaîne (auto-signé = ok), extrait serial, simule révocation CA (pour PKI). Nécessite index/CRL setup pour vrai CA. Piège : sans -CAfile, vérif échoue sur self-signed ; toujours checker expiry avec openssl x509 -enddate -noout.

Bonnes pratiques

  • Toujours chiffrer les clés privées au repos (-aes256), dé-chiffrer only in-memory sur serveurs.
  • Utilisez ECC secp384r1 ou Ed25519 pour new setups ; RSA 4096 fallback.
  • Activez HSTS et OCSP Stapling post-cert ; testez avec openssl s_client -connect example.com:443.
  • Backup atomique : tar clé+cert+cnf ; gérez CRL pour révocations.
  • Intégrez en CI/CD : GitHub Actions avec OpenSSL Docker image.

Erreurs courantes à éviter

  • Clés trop courtes (<3072 RSA) : vulnérables à Shor's algorithm quantum (post-2030 threat).
  • Oubli SAN/DNS : ERR_CERT_COMMON_NAME_INVALID sur Chrome/Firefox.
  • Passphrase en clair dans scripts : utilisez openssl rand -base64 + secrets manager (Vault/AWS SSM).
  • Versions OpenSSL vulnérables (ex Heartbleed) : pin à openssl 3.3+ et openssl update -check.

Pour aller plus loin