Diagnostic TLS : déboguer les erreurs SSL avec openssl

Un curl: (60) SSL certificate problem ou un certificat qui « marche dans le navigateur mais pas en ligne de commande » ? La réponse tient en une commande : openssl s_client -connect host:443 -servername host. Elle révèle la version TLS négociée, la chaîne de certificats et un code de vérification qui pointe la cause exacte. Ce guide vous apprend à lire cette sortie, à reconnaître les erreurs les plus fréquentes (chaîne incomplète, certificat expiré, mauvais SNI, hostname qui ne correspond pas) et à les reproduire dans un lab avec badssl.com.

Ce que vous allez apprendre

• Lire la sortie d'openssl s_client : version TLS, suite de chiffrement, code de vérification.
• Comprendre la chaîne de certificats et les codes verify (0, 10, 18, 19, 20, 21).
• Diagnostiquer le piège n°1 : la chaîne incomplète qui « marche dans Chrome mais pas avec curl ».
• Maîtriser le SNI (et son successeur chiffré ECH) pour obtenir le bon certificat.
• Éviter le faux positif du hostname : openssl ne vérifie pas le nom d'hôte par défaut.
• Surveiller l'expiration et tester les versions TLS acceptées par un serveur.

Prérequis

• Connaissances de base sur HTTPS et TLS (voir le guide HTTP et HTTPS).
• Un terminal Linux, macOS ou WSL avec openssl et curl installés.
• Une connexion Internet pour atteindre les serveurs de test badssl.com.

openssl s_client : voir un certificat en une commande

openssl s_client ouvre une connexion TLS vers un serveur et affiche tout ce qui s'y passe. C'est l'outil de diagnostic de référence :

echo | openssl s_client -connect exemple.com:443 -servername exemple.com

Deux options structurent la commande :

• -connect host:443 : la cible (hôte et port).
• -servername host : fixe le SNI. OpenSSL l'envoie déjà de lui-même quand -connect porte un nom DNS, mais il devient indispensable dès que vous visez une adresse IP (voir plus bas).

Le echo | ferme l'entrée standard pour que la commande ne reste pas bloquée après le handshake.

Options utiles à connaître

• -showcerts : affiche toute la chaîne envoyée par le serveur (essentiel pour repérer un intermédiaire manquant).
• -tls1_3, -tls1_2, -tls1_1 : force une version unique de protocole.
• -status : demande l'agrafage OCSP (OCSP stapling).
• -verify_return_error : fait échouer la commande dès la première erreur de vérification (pratique en CI).

Lire la sortie : version, cipher, code de vérification

Trois lignes résument l'état de la connexion. Voici la sortie réelle pour un site sain :

Protocol  : TLSv1.3
Cipher    : TLS_AES_256_GCM_SHA384
Verify return code: 0 (ok)

• Protocol : la version TLS réellement négociée (ici TLS 1.3).
• Cipher : la suite de chiffrement retenue.
• Verify return code : le résultat de la validation de la chaîne. 0 (ok) = tout va bien ; tout code différent de 0 signale un problème.

Ce code de retour est le cœur du diagnostic. Apprenez à le lire et vous identifiez la cause en quelques secondes.

La chaîne de certificats et les codes verify

Un certificat n'est jamais seul. Il s'inscrit dans une chaîne de confiance :

Certificat serveur (feuille)  ->  Intermédiaire(s)  ->  CA racine

Le serveur doit envoyer la feuille et les intermédiaires ; la racine est déjà dans le magasin de confiance du système. Si un maillon manque ou n'est pas fiable, la validation échoue avec un code précis :

Code	Message exact	Cause
0	ok	chaîne complète et valide
10	certificate has expired	date notAfter dépassée
18	self-signed certificate	certificat auto-signé (feuille)
19	self-signed certificate in certificate chain	racine non fiable (CA inconnue)
20	unable to get local issuer certificate	émetteur introuvable (intermédiaire ou CA absente)
21	unable to verify the first certificate	chaîne incomplète (intermédiaire manquant)

Glissez pour voir

Ces six codes couvrent la quasi-totalité des incidents TLS du quotidien. Les codes 20 et 21 pointent tous deux un problème de chaîne. Le 20 apparaît quand l'émetteur manque dans le magasin local, par exemple une CA interne pas encore installée sur le client ; le 21 est le code final d'une chaîne incomplète côté serveur, détaillée ci-dessous.

Le piège n°1 : la chaîne incomplète

C'est l'erreur la plus fréquente en production, et la plus déroutante : le site fonctionne dans le navigateur mais échoue avec curl ou openssl.

La raison : un navigateur sait compléter la chaîne tout seul (cache, récupération de l'intermédiaire via le champ AIA du certificat, Authority Information Access, l'URL où télécharger l'intermédiaire). curl et openssl, eux, ne le font pas : si le serveur n'envoie pas l'intermédiaire, ils ne peuvent pas remonter jusqu'à la racine.

Comptez les certificats envoyés avec -showcerts :

# Serveur sain : plusieurs certificats (feuille + intermédiaires)
echo | openssl s_client -connect exemple.com:443 -servername exemple.com -showcerts 2>/dev/null \
  | grep -c "BEGIN CERTIFICATE"
# 4

# Chaîne incomplète : un seul certificat
echo | openssl s_client -connect incomplete-chain.badssl.com:443 \
  -servername incomplete-chain.badssl.com -showcerts 2>/dev/null \
  | grep -c "BEGIN CERTIFICATE"
# 1

Le serveur défaillant n'envoie qu'un seul certificat et openssl rend :

Verify return code: 21 (unable to verify the first certificate)

Correctif côté serveur : servir le fullchain (feuille + intermédiaires), pas seulement le certificat feuille. C'est exactement ce que recommandent les guides Nginx (ssl_certificate pointant sur le fullchain.pem) et Traefik avec Let's Encrypt, qui produisent une chaîne complète automatiquement.

SNI : obtenir le bon certificat

Le SNI (Server Name Indication) est le nom d'hôte envoyé dans le premier message du handshake pour que le serveur sache quel certificat présenter quand plusieurs sites partagent une IP (mutualisé, CDN, reverse proxy).

Depuis OpenSSL 1.1.1, s_client remplit le SNI tout seul avec le nom passé à -connect, à condition que ce soit un nom DNS : la page de manuel d'OpenSSL 3.0 le dit, et la mesure ci-dessous le confirme. Il n'envoie en revanche aucun SNI pour une adresse IP, ni pour un nom sans point comme localhost, et -noservername le supprime volontairement. Dans ces cas, le serveur répond avec son certificat par défaut, souvent celui d'un autre domaine, et vous diagnostiquez un faux « mauvais certificat ».

Mesuré avec OpenSSL 3.0.13, contre un openssl s_server qui présente un second certificat, de CN certificat-sni-localhost (le CN est un nom de lab, sans lien avec localhost), quand le SNI vaut whoami.local.test, et son certificat par défaut sinon. Seules les lignes Peer certificate sont reproduites :

$ openssl s_client -connect whoami.local.test:4443 -brief
Peer certificate: CN = certificat-sni-localhost
$ openssl s_client -connect whoami.local.test:4443 -noservername -brief
Peer certificate: CN = certificat-par-defaut
$ openssl s_client -connect 127.0.0.1:4443 -brief
Peer certificate: CN = certificat-par-defaut
$ openssl s_client -connect 127.0.0.1:4443 -servername whoami.local.test -brief
Peer certificate: CN = certificat-sni-localhost

Le cas qui piège en production est le test d'un backend ou d'un load balancer précis par son adresse IP : sans -servername, vous lisez le certificat par défaut de la machine, pas celui du site. Écrire -servername à chaque fois ne coûte rien et rend la commande juste quelle que soit la forme de -connect :

# Explicite : le SNI demande le bon site, quelle que soit la cible de -connect
echo | openssl s_client -connect exemple.com:443 -servername exemple.com 2>/dev/null \
  | openssl x509 -noout -subject

ECH, le SNI chiffré (2026)

Le SNI circule en clair : il révèle le domaine visité à tout intermédiaire. ECH (Encrypted Client Hello, RFC 9849, publiée en 2026) chiffre ce premier message et n'expose qu'un nom de couverture. En 2026, les navigateurs (Firefox, Chrome) et les grands CDN le déploient ; côté serveur auto-hébergé, le support arrive (Nginx 1.29.4, OpenSSL annoncé). C'est la suite logique du SNI, encore peu répandue côté origine.

Le faux positif du hostname

Piège subtil et important : openssl ne vérifie pas le nom d'hôte par défaut. Il valide la chaîne, pas la correspondance entre le domaine demandé et le certificat.

Démonstration avec wrong.host.badssl.com, dont le certificat n'est valide que pour *.badssl.com :

echo | openssl s_client -connect wrong.host.badssl.com:443 \
  -servername wrong.host.badssl.com 2>/dev/null | grep "Verify return code"
# Verify return code: 0 (ok)   <- la chaîne est valide... mais le hostname ne correspond pas !

Le code 0 ici est trompeur : la chaîne est bonne, mais le certificat ne couvre pas ce nom. Deux façons de détecter le hostname mismatch :

# 1. Demander explicitement la vérification du nom à openssl
echo | openssl s_client -connect wrong.host.badssl.com:443 \
  -servername wrong.host.badssl.com -verify_hostname wrong.host.badssl.com 2>/dev/null \
  | grep "Verify return code"

# 2. Utiliser curl, qui vérifie le hostname par défaut
curl -Iv https://wrong.host.badssl.com
# curl: (60) SSL: no alternative certificate subject name matches target host name

Retenez : pour valider qu'un certificat couvre bien un domaine, fiez-vous à curl ou ajoutez -verify_hostname à openssl. Le nom doit figurer dans le CN ou, surtout, dans les SAN (Subject Alternative Names).

La ligne de commande accepte un certificat sans SAN, pas les navigateurs

Attention à une règle souvent énoncée trop largement : « un certificat sans SAN est refusé par les clients modernes ». C'est vrai des navigateurs, qui ont cessé de regarder le CN depuis longtemps. Ce n'est pas vrai de la ligne de commande.

Mesuré avec OpenSSL 3.5.5 et curl 8.12.1 sur un certificat dépourvu de SAN, dont le CN correspond au nom demandé :

openssl verify -CAfile ca.crt -verify_hostname serveur.exemple.test srv.crt

srv.crt: OK

curl l'accepte de la même façon et rend un HTTP 200. Les deux outils retombent sur le CN quand le SAN est absent, et ne protestent qu'avec un autre nom :

error 62 at 0 depth lookup: hostname mismatch
curl: (60) SSL: certificate subject name 'serveur.exemple.test' does not match
target host name 'autre.exemple.test'

Le piège pratique est là : vous validez votre certificat avec openssl, tout paraît bon, et il casse dans Firefox. Ajoutez toujours un SAN, même quand openssl ne s'en plaint pas, et vérifiez sa présence explicitement :

openssl x509 -in srv.crt -noout -ext subjectAltName

Vérifier l'expiration

Un certificat expiré rend le code 10. Pour surveiller l'échéance, deux commandes :

# Dates de validité (notBefore / notAfter)
echo | openssl s_client -connect exemple.com:443 -servername exemple.com 2>/dev/null \
  | openssl x509 -noout -dates
# notBefore=May 31 21:39:12 2026 GMT
# notAfter=Aug 29 21:41:26 2026 GMT

# Expire-t-il dans les 24h ? code de sortie 0 = encore valide, 1 = expire sous 24h ou déjà expiré
echo | openssl s_client -connect exemple.com:443 -servername exemple.com 2>/dev/null \
  | openssl x509 -noout -checkend 86400 && echo "valide > 24h"

-checkend N renvoie un code de sortie exploitable : c'est l'outil idéal d'un script de supervision qui alerte avant l'expiration. Avec l'arrivée des certificats à durée de vie courte (Let's Encrypt descend vers 6 à 45 jours), cette surveillance devient indispensable. Pour automatiser l'émission et la rotation, voir Vault PKI.

Tester les versions TLS acceptées

En 2026, TLS 1.3 est la cible et TLS 1.2 reste accepté. TLS 1.0 et 1.1 sont dépréciés (RFC 8996, 2021). Un serveur correctement durci doit refuser les vieilles versions. Vérifiez-le en forçant chaque version :

# Doit RÉUSSIR
echo | openssl s_client -connect exemple.com:443 -servername exemple.com -tls1_3 2>/dev/null | grep Protocol
# Protocol  : TLSv1.3
echo | openssl s_client -connect exemple.com:443 -servername exemple.com -tls1_2 2>/dev/null | grep Protocol
# Protocol  : TLSv1.2

# Doit ÉCHOUER (serveur ou client qui n'accepte plus TLS 1.1)
echo | openssl s_client -connect exemple.com:443 -tls1_1 2>&1 | grep -iE "no protocol|alert"
# ...:no protocols available

Un échec sur -tls1_1 est donc le résultat attendu, pas un bug. Le message no protocols available vient du client : votre OpenSSL refuse lui-même la version, par son niveau de sécurité par défaut (SECLEVEL 2 sur Debian et Ubuntu) ou un MinProtocol dans openssl.cnf ; un serveur distant qui la refuse renvoie plutôt une alerte tlsv1 alert protocol version.

Lab : reproduire chaque erreur avec badssl.com

Le service badssl.com expose des sous-domaines conçus pour déclencher chaque erreur. Reproduisez-les pour ancrer les codes :

1. Préparez la commande de test

   verif() { echo | openssl s_client -connect "$1":443 -servername "$1" 2>/dev/null | grep "Verify return code"; }

2. Déclenchez chaque erreur

   verif expired.badssl.com          # 10 (certificate has expired)
   verif self-signed.badssl.com      # 18 (self-signed certificate)
   verif untrusted-root.badssl.com   # 19 (self-signed certificate in certificate chain)
   verif incomplete-chain.badssl.com # 21 (unable to verify the first certificate)

3. Observez le faux positif du hostname

   verif wrong.host.badssl.com       # 0 (ok) -> piège : chaîne valide, hostname faux

Sous-domaine badssl.com	Code verify	Erreur démontrée
expired	10	certificat expiré
self-signed	18	auto-signé (feuille)
untrusted-root	19	racine non fiable
incomplete-chain	21	chaîne incomplète
wrong.host	0	hostname non vérifié par openssl

Glissez pour voir

badssl.com peut être indisponible

badssl.com est un service bénévole, parfois en panne ou lui-même temporairement expiré. Pour un lab reproductible hors-ligne, générez vos propres certificats de test avec openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 1.

Outils d'audit complets

openssl s_client est parfait pour un diagnostic ciblé. Pour un audit complet d'un serveur (protocoles, suites, vulnérabilités), des outils dédiés vont plus loin :

Outil	Usage
testssl.sh	audit TLS de référence : script Bash autonome, teste versions, suites, vulnérabilités, chaîne, OCSP
sslscan	énumère rapidement protocoles et suites supportés
nmap --script ssl-enum-ciphers	note chaque suite de A à F, lisible pour un rapport
curl -v / --cert-status	voir le handshake et vérifier l'OCSP pendant une requête réelle

Glissez pour voir

# Audit complet d'un serveur
testssl.sh exemple.com

# Énumération rapide des suites avec notation
nmap --script ssl-enum-ciphers -p 443 exemple.com

testssl.sh est l'outil à connaître pour un audit reproductible : aucune dépendance lourde, sortie détaillée, et il détecte les vulnérabilités historiques (Heartbleed, ROBOT) en plus de la configuration.

Mettre en pratique

Une sortie openssl se lit d'autant mieux qu'on l'a décortiquée soi-même : ce lab vous fait inspecter un certificat TLS réel, sa chaîne et ses dates de validité, directement dans un shell jetable.

Lab guidé Pratique

Apprendre à faire

Inspecter un certificat TLS avec openssl

$ dsoxlab run l1-ssl-certificates

Environnement : Shell·Durée : ~25 min

Vérification : la sortie produite est comparée au résultat attendu.

Première fois ? Qu'est-ce que DSOXLab et comment l'installer

DSOXLab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Il faut Python 3.11 ou plus récent, uv ou pipx, et git. Le guide d'installation détaille ces prérequis ; sous Windows, ou sur un Mac sans Python, passez plutôt par l'appliance.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/linux-dsoxlab-training

Avant de lancer le lab, vérifiez :

• DSOXLab installé
• catalogue disponible
• environnement compatible (shell isolé ou VM)

Pour le vérifier, rien n'est sondé depuis cette page : lancez dsoxlab doctor. Lire le diagnostic

Lancer ce lab, puis valider votre travail :

dsoxlab run l1-ssl-certificates
dsoxlab check l1-ssl-certificates

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille le calcul du score et les pièges.

Le second lab déplace la question sur un service publié : au lieu de lire un certificat, vous vérifiez l'identité qu'un point d'entrée présente et la chaîne qu'il sert réellement, depuis un client qui ne connaît que l'autorité attendue. Il demande une machine complète, et il appartient à la formation Publier un service web, qui reprend cette leçon à son compte.

Lab guidé Pratique

Apprendre à faire

Vérifier une identité TLS et sa chaîne de confiance

$ dsoxlab run pub-socle-tls

Environnement : VM·Durée : ~45 min

Vérification : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que DSOXLab et comment l'installer

DSOXLab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Il faut Python 3.11 ou plus récent, uv ou pipx, et git. Le guide d'installation détaille ces prérequis ; sous Windows, ou sur un Mac sans Python, passez plutôt par l'appliance.

Ce lab démarre des machines virtuelles : il demande en plus ansible-playbook, un hyperviseur (KVM ou Incus), Terraform et la virtualisation matérielle (/dev/kvm), c'est-à-dire, dans une VM VirtualBox, la virtualisation imbriquée. La première fois, dsoxlab start pub-socle-tls vérifie tout cela avant de créer les machines. Préparer le poste pour les labs vm.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/publier-service-dsoxlab-training

Avant de lancer le lab, vérifiez :

• DSOXLab installé
• catalogue disponible
• environnement compatible (shell isolé ou VM)

Pour le vérifier, rien n'est sondé depuis cette page : lancez dsoxlab doctor. Lire le diagnostic

Lancer ce lab, puis valider votre travail :

dsoxlab run pub-socle-tls
dsoxlab check pub-socle-tls

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille le calcul du score et les pièges.

À retenir

• La commande de référence est openssl s_client -connect host:443 -servername host ; OpenSSL envoie le SNI seul pour un nom DNS, mais -servername est indispensable quand vous visez une adresse IP.
• Le Verify return code pointe la cause : 10 expiré, 18 auto-signé, 19 racine non fiable, 20 émetteur introuvable, 21 chaîne incomplète.
• « Marche dans le navigateur, pas avec curl » = presque toujours une chaîne incomplète : servez le fullchain.
• openssl ne vérifie pas le hostname par défaut (code 0 trompeur) : utilisez curl ou -verify_hostname.
• Surveillez l'expiration avec openssl x509 -checkend 86400 (code de sortie exploitable en supervision).
• En 2026, ciblez TLS 1.3, acceptez TLS 1.2, refusez TLS 1.0/1.1 (RFC 8996).
• Pour un audit complet, testssl.sh est l'outil de référence.

Testez vos connaissances

Huit questions sur les codes verify qui reviennent en incident, la chaîne incomplète qui passe au navigateur mais pas en ligne de commande, et ce qu'openssl s_client fait, ou ne fait pas, à votre place : envoyer le SNI et vérifier le nom d'hôte. Objectif évalué dans le parcours LFCS.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

8 questions

5 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

FAQ : questions fréquentes sur le diagnostic TLS

Les questions reviennent surtout sur la chaîne incomplète et sur l'écart entre navigateur et ligne de commande. La règle de la leçon tranche presque toujours : lisez d'abord le Verify return code, puis comptez les certificats envoyés.

Comment voir le certificat d'un site en ligne de commande ?

Pourquoi mon certificat marche dans le navigateur mais pas avec curl ?

Qu'est-ce que le SNI en TLS ?

Comment vérifier l'expiration d'un certificat TLS ?

Quelle version de TLS faut-il utiliser en 2026 ?

×

📖 Voir la documentation →