OpenSSL : clés et certificats en 12 étapes [2026]

OpenSSL équipe la quasi-totalité des serveurs web, des conteneurs et des objets connectés de la planète. C’est l’outil qui génère vos clés, fabrique vos certificats TLS, chiffre vos fichiers et teste la sécurité d’un serveur distant. Pourtant, sa ligne de commande intimide. Des dizaines de sous-commandes, des centaines d’options, une documentation dense : beaucoup d’administrateurs copient-collent des incantations trouvées en ligne sans les comprendre, et reproduisent des réglages obsolètes (RSA 1024 bits, SHA-1, chiffrement sans dérivation de clé).

Ce tutoriel corrige le tir. En 12 étapes et environ 30 minutes, vous allez générer des clés RSA et à courbe elliptique solides, créer des certificats auto-signés et des demandes de signature (CSR), inspecter et vérifier des certificats, chiffrer des fichiers avec AES-256, et construire une mini-autorité de certification complète. Toutes les commandes sont à jour pour OpenSSL 3.5 LTS, la version publiée le 8 avril 2025 qui ajoute la cryptographie post-quantique. Chaque étape montre la sortie attendue, et une section dépannage règle les huit erreurs les plus courantes.

OpenSSL en 2026 : pourquoi cet outil reste incontournable

OpenSSL est une bibliothèque cryptographique open source et un utilitaire en ligne de commande nés en 1998. Vingt-huit ans plus tard, il reste le socle de la sécurité du transport sur Internet. Apache, Nginx, Node.js, Python, la plupart des distributions Linux et d’innombrables appareils embarqués s’appuient sur sa bibliothèque libcrypto ou sur le binaire openssl. Maîtriser ses commandes, c’est tenir entre ses mains le couteau suisse de la cryptographie appliquée.

L’année 2025 a marqué un tournant. Avec la sortie d’OpenSSL 3.5, support à long terme (LTS) jusqu’au 8 avril 2030, le projet intègre nativement les algorithmes post-quantiques normalisés par le NIST : ML-KEM (FIPS 203) pour l’échange de clés, ML-DSA (FIPS 204) et SLH-DSA (FIPS 205) pour les signatures. Concrètement, les certificats et tunnels TLS que vous fabriquez aujourd’hui peuvent déjà résister à un futur ordinateur quantique. C’est une raison de plus de remettre à plat ses pratiques OpenSSL en 2026.

Au-delà de TLS, OpenSSL sert de boîte à outils universelle : chiffrer une archive avant de l’envoyer, calculer une empreinte SHA-256, générer 32 octets aléatoires pour une clé symétrique, convertir un certificat du format PEM vers PKCS#12 pour Windows, ou diagnostiquer pourquoi un navigateur refuse un site. Ce tutoriel couvre tous ces cas d’usage avec des commandes vérifiées.

Prérequis et versions d’OpenSSL en 2026

Avant de commencer, assurez-vous de disposer des éléments suivants. Ce tutoriel suppose une connaissance de base du terminal (naviguer dans les dossiers, lancer une commande), mais aucune compétence préalable en cryptographie.

OpenSSL 3.5 LTS (recommandé) ou toute version 3.x encore maintenue. La 3.0 LTS reste acceptable pour les commandes classiques mais ne gère pas le post-quantique.
Un système Linux, macOS ou Windows. Sous Linux, OpenSSL est presque toujours préinstallé. Sous Windows, installez-le via les binaires de la communauté ou le gestionnaire winget.
Un terminal (Bash, Zsh, PowerShell ou l’invite de commandes Windows).
Environ 50 Mo d’espace disque et les droits d’écriture dans un dossier de travail.
Une connexion Internet uniquement pour l’étape de test d’un serveur distant.

Le choix de version a son importance. Le tableau ci-dessous résume l’état du support des principales branches d’OpenSSL au 15 juin 2026. Évitez à tout prix OpenSSL 1.1.1 et 1.0.2, en fin de vie, ainsi que toute branche 1.x pour de nouveaux déploiements.

Version	Type	Date de sortie	Fin de support	Post-quantique
OpenSSL 3.5	LTS	8 avril 2025	8 avril 2030	Oui (ML-KEM, ML-DSA, SLH-DSA)
OpenSSL 3.4	Standard	22 octobre 2024	22 octobre 2026	Non
OpenSSL 3.3	Standard	9 avril 2024	9 avril 2026	Non
OpenSSL 3.0	LTS	7 septembre 2021	7 septembre 2026	Non
OpenSSL 1.1.1	Fin de vie	11 septembre 2018	Terminé (11 sept. 2023)	Non

Sources : politique de versions et calendrier de support du projet OpenSSL.

Depuis la version 3.0.0, OpenSSL suit un schéma de numérotation MAJEUR.MINEUR.CORRECTIF, avec une compatibilité d’API et d’ABI garantie au sein d’une même version majeure. Autrement dit, une bibliothèque compilée pour la 3.0 fonctionne sans recompilation avec la 3.5. Pour ce tutoriel, n’importe quelle 3.x conviendra, sauf mention explicite du post-quantique réservé à la 3.5.

Étapes 1 et 2 : installer et vérifier OpenSSL

Commencez par vérifier la version installée. Ouvrez un terminal et lancez la commande suivante.

# Étape 1 : vérifier la version installée
openssl version -a

Vous devriez obtenir une sortie comparable à celle-ci, qui confirme la version, la date de compilation et le dossier des certificats racine du système :

OpenSSL 3.5.0 8 Apr 2025 (Library: OpenSSL 3.5.0 8 Apr 2025)
built on: Tue Apr  8 13:14:00 2025 UTC
platform: linux-x86_64
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-3"
MODULESDIR: "/usr/lib/x86_64-linux-gnu/ossl-modules"

Si la commande renvoie une version 1.x, ou « command not found », passez à l’installation. Voici les commandes pour les trois grands environnements.

# Étape 2 : installer OpenSSL selon votre système

# Debian / Ubuntu
sudo apt update && sudo apt install openssl

# Fedora / RHEL / Rocky
sudo dnf install openssl

# macOS (via Homebrew, version plus récente que celle d'Apple)
brew install openssl@3

# Windows (via winget)
winget install ShiningLight.OpenSSL.Light

Sous macOS, attention : Apple livre sa propre variante (LibreSSL) sous le nom openssl. Après installation via Homebrew, ajoutez le binaire au PATH ou appelez-le par son chemin complet (par exemple /opt/homebrew/opt/openssl@3/bin/openssl) pour bénéficier de la vraie version 3.5. Créez maintenant un dossier de travail dédié, vous y stockerez toutes les clés et certificats du tutoriel.

mkdir -p ~/tuto-openssl && cd ~/tuto-openssl

Étape 3 : générer une clé privée RSA solide

La clé privée est le secret fondamental de toute la chaîne. Si elle fuit, l’attaquant peut usurper votre identité ou déchiffrer vos communications. En 2026, la commande moderne pour générer une clé RSA est genpkey, qui remplace l’ancienne genrsa. Visez 3072 bits au minimum, 4096 bits pour une marge à long terme.

# Clé RSA 3072 bits (équilibre sécurité / performance)
openssl genpkey -algorithm RSA \
  -pkeyopt rsa_keygen_bits:3072 \
  -out serveur.key

# Variante chiffrée par mot de passe (recommandé pour une clé sensible)
openssl genpkey -algorithm RSA \
  -pkeyopt rsa_keygen_bits:3072 \
  -aes-256-cbc \
  -out serveur-protegee.key

La seconde commande demande une phrase de passe et chiffre la clé sur le disque avec AES-256. Sans cette protection, n’importe qui ayant accès au fichier détient votre clé en clair. Restreignez aussi les permissions du fichier sous Linux et macOS :

chmod 600 serveur.key
# Vérifier le contenu et la taille de la clé
openssl pkey -in serveur.key -text -noout | head -3

La sortie commence par Private-Key: (3072 bit, 2 primes), confirmant la taille demandée. Pourquoi 3072 et non 2048 ? Le NIST classe RSA 2048 dans une catégorie de sécurité d’environ 112 bits, suffisante jusqu’à 2030 mais sans marge. RSA 3072 atteint 128 bits, le seuil retenu par l’ANSSI et le NIST pour les usages durables. Au-delà de 4096 bits, le gain de sécurité devient marginal alors que le coût de calcul explose : mieux vaut alors basculer sur les courbes elliptiques.

Étape 4 : générer une clé à courbe elliptique (ECC et Ed25519)

Les courbes elliptiques offrent une sécurité équivalente à RSA pour des clés bien plus petites et des calculs plus rapides. Une clé P-256 (256 bits) procure une robustesse comparable à RSA 3072 (3072 bits). C’est le choix par défaut des déploiements modernes, des navigateurs aux passerelles d’API.

# Clé P-256 (courbe prime256v1, la plus répandue pour TLS)
openssl ecparam -name prime256v1 -genkey -noout -out ec-p256.key

# Méthode équivalente avec genpkey
openssl genpkey -algorithm EC \
  -pkeyopt ec_paramgen_curve:P-256 \
  -out ec-p256-bis.key

# Clé Ed25519 (signatures modernes, rapides et compactes)
openssl genpkey -algorithm ED25519 -out ed25519.key

Ed25519 mérite une mention spéciale. Cet algorithme de signature, conçu par Daniel J. Bernstein, est immunisé contre plusieurs classes d’erreurs d’implémentation qui ont historiquement affaibli ECDSA, comme la réutilisation de nonce. Il est désormais accepté par OpenSSH, TLS 1.3 et la plupart des écosystèmes. Pour une nouvelle paire de clés de signature, c’est un excellent défaut. Le tableau suivant récapitule les recommandations d’algorithmes en 2026.

Usage	À éviter	Acceptable	Recommandé 2026
Clé asymétrique RSA	1024 / 2048 bits	3072 bits	4096 bits
Courbe elliptique	secp192r1	P-256	P-384 / Ed25519
Empreinte (hachage)	MD5 / SHA-1	SHA-256	SHA-384 / SHA-512
Chiffrement symétrique	DES / RC4 / AES-CBC seul	AES-256-CBC + PBKDF2	AES-256-GCM
Protocole de transport	SSLv3 / TLS 1.0 / 1.1	TLS 1.2	TLS 1.3

Recommandations d’algorithmes cryptographiques pour OpenSSL en 2026.

Étape 5 : créer un certificat auto-signé

Un certificat auto-signé associe votre clé publique à une identité (un nom de domaine) sans passer par une autorité externe. Parfait pour le développement, les tests internes ou un service interne, mais rejeté par les navigateurs pour un site public. La commande req -x509 génère le certificat en une seule passe.

# Certificat auto-signé valable 365 jours, signé en SHA-256
openssl req -x509 -new -key serveur.key \
  -sha256 -days 365 \
  -subj "/C=FR/ST=Ile-de-France/L=Paris/O=Mon Entreprise/CN=exemple.local" \
  -out serveur.crt

Le champ -subj évite les questions interactives en renseignant directement le pays (C), la région (ST), la ville (L), l’organisation (O) et surtout le nom commun (CN), c’est-à-dire le domaine. Problème : les navigateurs modernes ignorent le CN et exigent l’extension Subject Alternative Name (SAN). Pour un certificat réellement utilisable, ajoutez les SAN via un paramètre dédié.

# Certificat auto-signé AVEC Subject Alternative Names (SAN)
openssl req -x509 -new -key serveur.key -sha256 -days 365 \
  -subj "/C=FR/O=Mon Entreprise/CN=exemple.local" \
  -addext "subjectAltName=DNS:exemple.local,DNS:www.exemple.local,IP:127.0.0.1" \
  -out serveur-san.crt

L’option -addext, disponible depuis OpenSSL 1.1.1, injecte les SAN sans fichier de configuration externe. C’est la méthode la plus simple pour obtenir un certificat que Chrome ou Firefox accepteront (après ajout manuel à la liste de confiance, puisqu’il reste auto-signé).

Étape 6 : générer une CSR pour une autorité de certification

Pour un site public, vous ne signez pas vous-même : vous envoyez une demande de signature de certificat (CSR, Certificate Signing Request) à une autorité de certification comme Let’s Encrypt ou une CA d’entreprise. La CSR contient votre clé publique et votre identité, signées par votre clé privée. L’autorité renvoie alors un certificat signé.

# Générer une CSR à partir de la clé existante
openssl req -new -key serveur.key \
  -subj "/C=FR/O=Mon Entreprise/CN=www.exemple.fr" \
  -addext "subjectAltName=DNS:www.exemple.fr,DNS:exemple.fr" \
  -out exemple.csr

# Vérifier le contenu de la CSR avant envoi
openssl req -in exemple.csr -text -noout -verify

La seconde commande affiche le sujet, la clé publique, les extensions demandées et confirme Certificate request self-signature verify OK. Vérifiez toujours une CSR avant de l’envoyer : une erreur de domaine ou un SAN manquant vous obligerait à recommencer toute la procédure auprès de l’autorité. Si vous voulez générer la clé et la CSR en une seule commande, combinez les deux opérations :

# Clé EC P-256 + CSR en une seule passe
openssl req -new -newkey ec \
  -pkeyopt ec_paramgen_curve:P-256 \
  -nodes -keyout www.key \
  -subj "/C=FR/O=Mon Entreprise/CN=www.exemple.fr" \
  -out www.csr

L’option -nodes (pour « no DES ») signifie que la clé n’est pas chiffrée par mot de passe, pratique pour un serveur qui doit démarrer sans intervention humaine. Sur une machine de production, pesez ce compromis : une clé non chiffrée lue par un attaquant ayant accès au disque est immédiatement exploitable.

Étape 7 : inspecter et vérifier un certificat

Savoir lire un certificat est une compétence quotidienne en cybersécurité. La sous-commande x509 décode un certificat au format PEM en texte lisible.

# Afficher tout le certificat en clair
openssl x509 -in serveur-san.crt -text -noout

# Extraire seulement les informations clés
openssl x509 -in serveur-san.crt -noout -subject -issuer -dates -fingerprint -sha256

La seconde commande produit une sortie compacte et très utile au quotidien :

subject=C=FR, O=Mon Entreprise, CN=exemple.local
issuer=C=FR, O=Mon Entreprise, CN=exemple.local
notBefore=Jun 15 09:00:00 2026 GMT
notAfter=Jun 15 09:00:00 2027 GMT
SHA256 Fingerprint=A1:B2:C3:...:9F

Comme subject et issuer sont identiques, on confirme qu’il s’agit bien d’un certificat auto-signé. Les dates notBefore et notAfter délimitent la période de validité. L’empreinte SHA-256 sert à comparer deux certificats ou à épingler (pinning) une clé dans une application. Pour vérifier qu’une clé privée et un certificat forment bien une paire cohérente, comparez leurs empreintes de clé publique :

# Les deux empreintes doivent être identiques
openssl x509 -in serveur.crt -noout -pubkey | openssl sha256
openssl pkey -in serveur.key -pubout | openssl sha256

Étape 8 : tester un serveur distant avec s_client

OpenSSL n’est pas qu’un fabricant de clés, c’est aussi un client de diagnostic. La sous-commande s_client ouvre une connexion TLS vers un serveur et révèle tout : la chaîne de certificats, la version du protocole, la suite de chiffrement négociée et les éventuelles erreurs de validation.

# Inspecter le certificat d'un serveur HTTPS
openssl s_client -connect exemple.fr:443 -servername exemple.fr </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

# Forcer TLS 1.3 et afficher la suite de chiffrement
openssl s_client -connect exemple.fr:443 -servername exemple.fr -tls1_3 </dev/null 2>&1 \
  | grep -E "Protocol|Cipher"

L’option -servername est indispensable : elle envoie l’extension SNI (Server Name Indication), sans laquelle un serveur hébergeant plusieurs sites renverrait le mauvais certificat. La redirection </dev/null ferme l’entrée pour que la commande rende la main au lieu de rester en attente. Vous pouvez aussi vérifier la date d’expiration d’un certificat distant en une ligne, idéal pour un script de surveillance :

echo | openssl s_client -connect exemple.fr:443 -servername exemple.fr 2>/dev/null \
  | openssl x509 -noout -enddate

Pour aller plus loin sur la confiance et le rôle du cadenas, notre article HTTPS et TLS : comment votre connexion est protégée détaille la poignée de main TLS 1.3 de bout en bout.

Étape 9 : chiffrer un fichier avec AES-256

OpenSSL chiffre aussi des fichiers de façon symétrique, par mot de passe. Cas typique : protéger une sauvegarde ou une archive avant de la transférer. La sous-commande enc s’en charge, mais attention à un piège majeur : sans dérivation de clé robuste, votre mot de passe est mal protégé. Utilisez toujours l’option -pbkdf2.

# Chiffrer un fichier avec AES-256 et dérivation PBKDF2
openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt \
  -in secret.txt -out secret.enc

# Déchiffrer
openssl enc -d -aes-256-cbc -pbkdf2 -iter 600000 \
  -in secret.enc -out secret-dechiffre.txt

Décortiquons les options. -aes-256-cbc sélectionne AES 256 bits. -pbkdf2 active la fonction de dérivation de clé PBKDF2, qui transforme votre mot de passe en clé cryptographique résistante aux attaques par dictionnaire. -iter 600000 fixe le nombre d’itérations, un paramètre de coût aligné sur les recommandations OWASP 2025 pour PBKDF2 avec SHA-256. -salt ajoute un sel aléatoire, activé par défaut mais explicité ici pour la clarté. Sans -pbkdf2, OpenSSL retombe sur une dérivation héritée et dangereusement faible.

Pour un usage plus avancé, AES-256-GCM ajoute une authentification intégrée (le mode détecte toute altération du fichier chiffré). Le chiffrement par fichier reste cependant moins ergonomique avec GCM en ligne de commande ; pour le partage de fichiers chiffrés au quotidien, notre tutoriel GPG : chiffrer fichiers et emails en 12 étapes propose une alternative à clé publique souvent plus pratique.

Étape 10 : empreintes, signatures et aléa cryptographique

Trois opérations cryptographiques de base se font en une ligne avec OpenSSL : calculer une empreinte, signer un fichier et générer des octets aléatoires. Commençons par l’empreinte (hachage), qui vérifie l’intégrité d’un fichier.

# Empreinte SHA-256 d'un fichier
openssl dgst -sha256 archive.tar.gz

# Générer 32 octets aléatoires (clé AES-256) en hexadécimal
openssl rand -hex 32

# Générer 24 octets aléatoires en base64 (mot de passe fort)
openssl rand -base64 24

La commande openssl rand puise dans le générateur d’aléa cryptographique du système, bien plus sûr qu’un mot de passe choisi à la main. Pour la signature numérique, OpenSSL combine une empreinte et votre clé privée. Le destinataire vérifie avec votre clé publique.

# Signer un fichier avec la clé privée
openssl dgst -sha256 -sign serveur.key -out document.sig document.pdf

# Vérifier la signature avec la clé publique
openssl pkey -in serveur.key -pubout -out serveur.pub
openssl dgst -sha256 -verify serveur.pub -signature document.sig document.pdf

Une vérification réussie affiche Verified OK. Toute modification du fichier, même d’un seul octet, fait échouer la vérification : c’est tout l’intérêt de la signature. Pour comprendre en profondeur pourquoi le hachage est indissociable de la signature, lisez Signatures numériques : comment le hachage et les clés garantissent l’authenticité et notre explication de SHA-256.

Étape 11 : convertir les formats (PEM, DER, PKCS#12)

Les certificats existent en plusieurs encodages, et chaque plateforme a ses préférences. PEM (texte base64, en-têtes -----BEGIN-----) domine sous Linux. DER (binaire) sert dans certains contextes Java et Windows. PKCS#12 (extension .p12 ou .pfx) regroupe clé privée et certificat dans un seul fichier, format attendu par Windows, IIS et de nombreux outils d’importation.

# PEM vers DER
openssl x509 -in serveur.crt -outform DER -out serveur.der

# DER vers PEM
openssl x509 -in serveur.der -inform DER -out serveur-retour.crt

# Créer un paquet PKCS#12 (clé + certificat) pour Windows / IIS
openssl pkcs12 -export -inkey serveur.key -in serveur.crt \
  -name "Mon certificat" -out serveur.p12

# Extraire la clé et le certificat depuis un PKCS#12
openssl pkcs12 -in serveur.p12 -nodes -out tout.pem

La création d’un PKCS#12 demande un mot de passe d’export qui protège le fichier, car il contient la clé privée. Ne transmettez jamais un .p12 et son mot de passe par le même canal. Ces conversions sont le pain quotidien de l’administrateur qui jongle entre serveurs Linux, postes Windows et passerelles d’API.

Étape 12 : projet complet, construire une mini-PKI

Assemblons tout en un projet réel : une infrastructure à clés publiques (PKI) miniature avec une autorité de certification racine maison, qui signe ensuite un certificat de serveur. C’est exactement le mécanisme des CA publiques, à l’échelle de votre laboratoire ou d’un réseau interne. Trois étapes : créer la CA, générer une demande serveur, signer cette demande avec la CA.

# 1. Créer la clé et le certificat de la CA racine (valable 10 ans)
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out ca.key
openssl req -x509 -new -key ca.key -sha384 -days 3650 \
  -subj "/C=FR/O=Mon Lab/CN=Ma CA Racine" \
  -out ca.crt

# 2. Créer la clé et la CSR du serveur
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out app.key
openssl req -new -key app.key \
  -subj "/C=FR/O=Mon Lab/CN=app.interne.local" \
  -addext "subjectAltName=DNS:app.interne.local" \
  -out app.csr

La CA est créée. Reste à signer la CSR du serveur. Comme -addext ne propage pas les SAN lors de la signature, on passe par un petit fichier d’extensions, méthode robuste et explicite.

# 3. Fichier d'extensions pour le certificat serveur
cat > app.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = DNS:app.interne.local
EOF

# Signer la CSR avec la CA racine
openssl x509 -req -in app.csr \
  -CA ca.crt -CAkey ca.key -CAcreateserial \
  -days 365 -sha256 -extfile app.ext \
  -out app.crt

# Vérifier que la CA a bien signé le certificat serveur
openssl verify -CAfile ca.crt app.crt

La dernière commande doit afficher app.crt: OK. Vous disposez maintenant d’une chaîne de confiance complète : importez ca.crt dans le magasin de confiance de vos machines, et tous les certificats signés par cette CA seront automatiquement reconnus. C’est le principe exact qui fait fonctionner le HTTPS à l’échelle du web, avec des autorités racines préinstallées dans votre navigateur. Pour un site public réel sans gérer de CA, notre tutoriel Certificat SSL gratuit avec Certbot et Nginx automatise tout via Let’s Encrypt.

OpenSSL et la cryptographie post-quantique

La grande nouveauté d’OpenSSL 3.5 est le support natif des algorithmes post-quantiques normalisés par le NIST en 2024. Un ordinateur quantique suffisamment puissant casserait RSA et les courbes elliptiques via l’algorithme de Shor. La parade : des schémas reposant sur d’autres problèmes mathématiques. Le tableau ci-dessous présente les trois familles intégrées.

Algorithme	Norme NIST	Rôle	Remplace à terme
ML-KEM (Kyber)	FIPS 203	Échange de clés / encapsulation	RSA, ECDH
ML-DSA (Dilithium)	FIPS 204	Signature numérique	RSA, ECDSA
SLH-DSA (SPHINCS+)	FIPS 205	Signature à base de hachage	Signatures à long terme

Les algorithmes post-quantiques intégrés à OpenSSL 3.5.

Avec OpenSSL 3.5, vous pouvez déjà générer une clé ML-DSA, la commande suivante illustre la simplicité de l’opération :

# Clé de signature post-quantique ML-DSA (OpenSSL 3.5 uniquement)
openssl genpkey -algorithm ML-DSA-65 -out pq-signature.key

# Vérifier les algorithmes post-quantiques disponibles
openssl list -signature-algorithms | grep -i -E "ML-DSA|SLH-DSA"

La stratégie recommandée pour 2026 est l’approche hybride : combiner un algorithme classique (P-256) et un algorithme post-quantique (ML-KEM) dans le même échange TLS, afin de rester sûr même si l’un des deux venait à être affaibli. Notre dossier Cryptographie et fonctions de hachage replace ces évolutions dans le contexte plus large de la migration post-quantique des entreprises.

6 pièges courants à éviter avec OpenSSL

Ces erreurs reviennent sans cesse, y compris chez des professionnels expérimentés. Les connaître vous épargnera des heures de débogage et, surtout, des failles de sécurité.

Oublier -pbkdf2 lors du chiffrement de fichiers. Sans cette option, OpenSSL utilise une dérivation de clé héritée et faible. Un attaquant casse alors votre mot de passe bien plus vite. Ajoutez toujours -pbkdf2 -iter 600000.
Générer un certificat sans Subject Alternative Name. Les navigateurs modernes ignorent le champ CN depuis des années. Un certificat sans SAN provoque l’erreur NET::ERR_CERT_COMMON_NAME_INVALID. Utilisez -addext "subjectAltName=...".
Laisser une clé privée en lecture pour tous. Une clé serveur.key avec des permissions 644 est lisible par tout utilisateur de la machine. Appliquez systématiquement chmod 600.
Réutiliser RSA 1024 ou SHA-1. Des tutoriels anciens traînent partout. RSA 1024 et SHA-1 sont cryptographiquement obsolètes. Visez RSA 3072 minimum et SHA-256 minimum.
Confondre clé publique et clé privée lors d’un partage. Vous ne distribuez jamais le fichier .key. Seuls le certificat (.crt) ou la clé publique (.pub) se partagent.
Oublier -servername avec s_client. Sans SNI, un serveur multi-domaines renvoie le mauvais certificat et vous diagnostiquez le mauvais site pendant une heure.

Dépannage : 8 erreurs fréquentes et leurs solutions

Voici les messages d’erreur les plus courants rencontrés avec OpenSSL et la manière de les résoudre rapidement.

« unable to load Private Key ». Le fichier n’est pas une clé valide, ou son format ne correspond pas. Vérifiez l’en-tête avec head -1 fichier.key : il doit indiquer -----BEGIN PRIVATE KEY-----. Une clé chiffrée demande un mot de passe.
« error in req » ou aucune sortie. Le sujet -subj contient souvent un caractère mal échappé. Entourez la valeur de guillemets et évitez les caractères spéciaux non échappés.
« self-signed certificate in certificate chain » avec verify. Le certificat racine de la CA n’est pas fourni. Ajoutez -CAfile ca.crt pointant vers le bon certificat racine.
« NET::ERR_CERT_AUTHORITY_INVALID » dans le navigateur. Normal pour un certificat auto-signé. Pour un usage de test, importez votre ca.crt dans le magasin de confiance du système ou du navigateur.
« wrong tag » ou « nested asn1 error » lors d’une conversion. Vous mélangez les formats PEM et DER. Précisez -inform DER ou -inform PEM selon le fichier source.
« bad decrypt » au déchiffrement d’un fichier. Mauvais mot de passe, ou les options de chiffrement et de déchiffrement diffèrent. Le déchiffrement doit reprendre exactement -pbkdf2 -iter 600000 et le même algorithme.
s_client reste bloqué sans rendre la main. Il attend une saisie. Ajoutez </dev/null en fin de commande, ou tapez Q puis Entrée pour quitter.
« unknown option -addext » sous une vieille version. L’option date d’OpenSSL 1.1.1. Mettez OpenSSL à jour, ou passez par un fichier de configuration openssl.cnf avec une section [v3_req].

Astuces avancées pour aller plus loin

Une fois les bases acquises, ces techniques accélèrent votre travail quotidien et renforcent vos automatisations.

Surveiller l’expiration en masse. Bouclez sur vos domaines avec s_client et x509 -checkend 2592000 (qui renvoie un code d’erreur si le certificat expire dans moins de 30 jours) pour alerter en amont.
Tester localement avec s_server. Lancez openssl s_server -accept 4433 -cert serveur.crt -key serveur.key -www pour un serveur HTTPS de test instantané, sans installer Nginx.
Mesurer la performance. openssl speed rsa3072 ecdsap256 compare le débit des algorithmes sur votre matériel, utile pour dimensionner une passerelle.
Auditer une configuration TLS. Combinez s_client avec -cipher et différentes options -tls1_2 / -tls1_3 pour vérifier quels protocoles un serveur accepte encore.
Scripter avec des variables. Stockez le sujet et les SAN dans des variables d’environnement pour générer des dizaines de certificats de test reproductibles.

L’équipe du projet OpenSSL, dans son annonce de la version 3.5 du 8 avril 2025, présente cette branche LTS comme une étape majeure vers un Internet résistant au quantique. Adopter ces outils dès maintenant, c’est anticiper une transition que l’ANSSI comme le NIST jugent inévitable d’ici la fin de la décennie.

Foire aux questions sur OpenSSL

Quelle version d’OpenSSL utiliser en 2026 ?

OpenSSL 3.5 LTS, sortie le 8 avril 2025 et maintenue jusqu’en 2030, est le meilleur choix. Elle apporte le support post-quantique. La 3.0 LTS reste acceptable pour les commandes classiques, mais évitez absolument toute version 1.x, en fin de vie depuis septembre 2023.

Quelle différence entre un certificat auto-signé et un certificat signé par une CA ?

Un certificat auto-signé est validé par sa propre clé : pratique pour le test et l’interne, mais rejeté par les navigateurs car aucune autorité tierce ne garantit l’identité. Un certificat signé par une autorité de certification (CA) reconnue, comme Let’s Encrypt, est automatiquement accepté par les navigateurs.

RSA ou courbe elliptique : que choisir ?

Pour un nouveau déploiement, privilégiez les courbes elliptiques (P-256 ou Ed25519) : clés plus petites, calculs plus rapides, sécurité équivalente. RSA 3072 ou 4096 reste pertinent pour la compatibilité avec d’anciens systèmes. Une clé P-256 (256 bits) équivaut en robustesse à RSA 3072.

OpenSSL est-il sûr face aux ordinateurs quantiques ?

Les algorithmes classiques (RSA, courbes elliptiques) sont vulnérables à un futur ordinateur quantique. OpenSSL 3.5 intègre les algorithmes post-quantiques du NIST (ML-KEM, ML-DSA, SLH-DSA) pour anticiper cette menace. La meilleure pratique en 2026 est l’approche hybride, qui combine classique et post-quantique.

Pourquoi mon navigateur refuse-t-il mon certificat OpenSSL ?

Deux causes principales : le certificat est auto-signé (le navigateur ne connaît pas l’autorité), ou il manque l’extension Subject Alternative Name (SAN). Ajoutez toujours -addext "subjectAltName=DNS:votre-domaine", et pour un test, importez votre CA dans le magasin de confiance.

Comment chiffrer un fichier en sécurité avec OpenSSL ?

Utilisez openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt -in fichier -out fichier.enc. L’option -pbkdf2 est indispensable : sans elle, la dérivation de clé est trop faible. Pour un partage régulier de fichiers chiffrés, GPG à clé publique est souvent plus adapté.

OpenSSL fonctionne-t-il sous Windows ?

Oui. Installez-le via winget install ShiningLight.OpenSSL.Light ou les binaires de la communauté, puis lancez les mêmes commandes depuis PowerShell ou l’invite de commandes. Le format PKCS#12 (.pfx) facilite l’import des certificats dans le magasin Windows et IIS.

OpenSSL a-t-il connu des failles de sécurité récentes ?

Comme tout logiciel de cette ampleur, OpenSSL corrige régulièrement des vulnérabilités via ses mises à jour. C’est précisément pourquoi il faut rester sur une branche maintenue (3.5 LTS ou 3.0 LTS) et appliquer les correctifs dès leur publication, en suivant les avis officiels du projet.

L’essentiel à retenir sur OpenSSL

Vous savez désormais générer des clés RSA et elliptiques robustes, fabriquer des certificats avec SAN, produire et vérifier des CSR, inspecter un certificat local ou distant, chiffrer des fichiers avec AES-256 et PBKDF2, signer des documents et construire une mini-PKI complète. Ces douze étapes couvrent l’essentiel des besoins quotidiens en cryptographie appliquée.

Trois réflexes à conserver : restez sur une branche maintenue (OpenSSL 3.5 LTS de préférence), bannissez les algorithmes obsolètes (RSA 1024, SHA-1, chiffrement sans PBKDF2), et protégez toujours vos clés privées par des permissions strictes. Pour la suite, explorez la cryptographie post-quantique d’OpenSSL 3.5, l’avenir de la sécurité du transport se joue déjà aujourd’hui.

Sources et références : la documentation OpenSSL 3.5, le communiqué de sortie de la version 3.5, la politique de versions du projet, et les normes post-quantiques du NIST FIPS 203 et FIPS 204.