Échecs des négociations TLS : résoudre de manière fiable les chaînes de certificats, le SNI et le renouvellement automatique via ACME

TLS est souvent « invisible » en exploitation – jusqu’au moment où les handshakes TLS échouent et que des logiciels métiers, portails, API ou intégrations ne peuvent plus établir de connexions. Les symptômes se ressemblent souvent (« Handshake failure », « unknown ca », « certificate verify failed »), mais les causes diffèrent : une chaîne de certificats incomplète, un problème de SNI (Server Name Indication, c’est‑à‑dire la sélection du certificat approprié selon le nom d’hôte), un certificat expiré ou mal renouvelé via ACME (Automated Certificate Management Environment, p. ex. Let’s Encrypt) ou un proxy qui remplace un certificat « en transit ».

Cet article est conçu comme un runbook pour administrateurs, ingénieurs systèmes, opérateurs et prestataires IT techniques : avec une séquence de vérification claire, des contrôles concrets, les pièges typiques, une stratégie de mise en œuvre et de retour en arrière. L’objectif n’est pas seulement de « revenir au vert », mais d’obtenir un état stable et vérifiable – incluant automatisation et supervision – afin que le problème ne se reproduise pas dans quatre semaines.

Ce qui se passe réellement lors du handshake TLS (et où il échoue typiquement)

Un handshake TLS est la négociation du chiffrement et de l’identité entre le client et le serveur. Simplifié : le client se connecte, indique (dans le cas HTTPS) via SNI le nom d’hôte souhaité, le serveur fournit un certificat (et idéalement les certificats intermédiaires), les deux négocient la version du protocole et la suite de chiffrement, et le client vérifie la chaîne de confiance (Chain of Trust) jusqu’à une Root-CA dans le trust store.

Points de rupture en pratique :

• Chaîne de certificats incomplète : le serveur ne fournit que le certificat final (leaf), le certificat intermédiaire est absent. Certains clients ne peuvent pas le « recharger » (selon la plateforme/politique/hors ligne).
• La SNI ne prend pas effet : le serveur sert un certificat par défaut qui ne correspond pas à l’hôte (mismatch CN/SAN). Fréquent avec plusieurs vHosts sur une même IP ou avec des load balancers.
• Renouvellement/déploiement ACME défaillant : le certificat a été renouvelé, mais le service utilise encore le fichier / le binding / le keystore ancien.
• Politique de protocole/cipher incompatible : des clients legacy ne supportent pas TLS 1.3, ou le serveur bloque TLS 1.2 ; l’ALPN (Application-Layer Protocol Negotiation) négocie mal HTTP/2.
• mTLS (Mutual TLS) / certificats client : le serveur attend un certificat client ; le client n’en fournit pas ou fournit une CA incorrecte.
• Temps/CRL/OCSP : horloge système incorrecte, OCSP/CRL inaccessibles ou configurations « Must-Staple ».

Première évaluation : déterminer la classe de symptôme avant de « toucher au certificat »

Avant de remplacer des certificats : catégorisez l’erreur. Cela fait gagner du temps et évite des effets secondaires, par exemple si un proxy est à l’origine du problème et que vous modifiez le backend.

Contrôle 1 : est‑ce que cela concerne tous les clients ou seulement certains ?

• Tous les clients affectés : plutôt certificat expiré, mauvais certificat déployé, SNI/certificat par défaut, endpoint incorrect (DNS/load balancer).
• Uniquement certaines plateformes : souvent des problèmes de chaîne (intermédiaire), trust store, anciennes politiques Java ou Windows, interopérabilité TLS 1.3/1.2.
• Uniquement les clients internes : proxy/inspection (TLS‑interception), distribution CA interne, split‑DNS.

Contrôle 2 : Où se termine réellement le TLS ? (identifier le point de terminaison)

Dans les architectures modernes, TLS ne se termine souvent pas au niveau du serveur d’application lui‑même, mais au reverse proxy (Nginx/Apache), au load balancer, à une WAF ou à une API‑Gateway. « TLS‑Termination » signifie : c’est là que la connexion TLS est déchiffrée, et derrière circule HTTP ou TLS à nouveau (Re‑Encryption).

Conséquence pour le dépannage : vous devez tester le point de terminaison, pas « le serveur ». Si un load balancer effectue la terminaison, le certificat côté backend est sans importance pour le client externe.

Étapes de vérification avec OpenSSL et consignation systématique des preuves

La vérification la plus fiable et la plus rapide s’obtient généralement avec openssl s_client. Important : testez toujours avec le nom d’hôte attendu (SNI), sinon vous pouvez voir le certificat par défaut.

Vérifier SNI et la chaîne de certificats en une seule étape

# SNI explizit setzen, Zertifikatskette anzeigen, OCSP-Informationen anfordern
openssl s_client 
  -connect example.com:443 
  -servername example.com 
  -showcerts 
  -status 
  </dev/null

À quoi prêter attention dans la sortie :

• subject / SAN : le nom d’hôte figure‑t‑il dans les Subject Alternative Names (SAN) ? Le CN seul n’est plus suffisant pour les clients modernes.
• issuer : qui a signé ? CA/intermédiaire attendu ?
• Verify return code : « 0 (ok) » est bon ; des codes comme « unable to get local issuer certificate » indiquent des problèmes de chaîne.
• Certificate chain : le certificat leaf et les intermédiaires sont‑ils fournis ? La racine n’a généralement pas besoin d’être envoyée.
• OCSP response : si le stapling est utilisé, une réponse devrait être présente ; en cas d’erreurs vous observez souvent des timeouts ou « no response ».

Tester ALPN et la version du protocole (TLS 1.2 vs TLS 1.3)

# TLS 1.2 erzwingen
openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null

# TLS 1.3 erzwingen
openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null

# ALPN-Angebot simulieren (z. B. HTTP/2 und HTTP/1.1)
openssl s_client -connect example.com:443 -servername example.com -alpn "h2,http/1.1" </dev/null

Pourquoi cela aide : certains problèmes n’apparaissent que pour certains chemins de négociation, par ex. lorsqu’un proxy annonce HTTP/2 (h2) mais effectue un mapping incorrect en interne, ou lorsque des appliances plus anciennes ne prennent pas en charge TLS 1.3 correctement.

Cause fréquente 1 : chaîne de certificats incomplète (intermédiaire manquant)

Une chaîne de certificats se compose du certificat Leaf (pour votre hôte), d’un ou de plusieurs certificats intermédiaires et d’une Root-CA présente dans le trust store du client. Si le serveur n’envoie pas les certificats intermédiaires, certains clients ne peuvent pas reconstituer la chaîne — en particulier dans des environnements RESTreints sans accès aux URL AIA ou avec blocage par proxy.

Symptômes typiques

• Un navigateur A fonctionne, mais le navigateur B ou un client Java-/Windows échoue.
• Messages d’erreur : „unable to get local issuer certificate“, „unknown ca“, „self signed certificate in certificate chain“ (trompeur, souvent un problème de chaîne).
• Seules certaines Middleboxes/MTLS-Clients sont concernées.

Comment vérifier correctement la chaîne

En complément de s_client, effectuez une seconde vérification : extrayez les certificats et vérifiez si la chaîne se termine par une racine connue.

# Zertifikate aus der s_client-Ausgabe in Dateien schreiben (manuell oder via Skript)
# Danach: Prüfen, ob Leaf gegen eine angegebene Chain verifizierbar ist
openssl verify -CAfile root-and-intermediate.pem leaf.pem

En pratique, la solution est généralement banale mais cruciale : au point de terminaison TLS, une Fullchain doit être configurée (Leaf + Intermediate), et pas seulement le certificat Leaf. Pour les clients ACME, le fichier s’appelle souvent fullchain.pem (et non cert.pem).

Pièges en production

• Fichier incorrect lié : Nginx/Apache pointe vers cert.pem au lieu de fullchain.pem.
• Load balancer « avale » l’intermédiaire : selon le produit, la chaîne doit être importée séparément ou n’est pas correctement prise en compte lors du téléversement.
• Formats de keystore : Java (JKS/PKCS12) et Windows (magasin de certificats) exigent souvent l’import incluant la chaîne, sinon le Leaf est „孤“.

Cause fréquente 2 : mauvaise configuration SNI et certificats par défaut

SNI (Server Name Indication) est une extension TLS qui permet au client d’indiquer le nom d’hôte dès l’établissement de la connexion. Le serveur peut alors sélectionner le certificat approprié lorsque plusieurs domaines utilisent la même combinaison IP/port.

Symptômes typiques

• L’appel par IP ne fonctionne pas ou renvoie un certificat incorrect (attendu), mais l’appel via DNS renvoie aussi un certificat « incorrect ».
• Un hôte sur la même IP fonctionne, un autre non.
• Seuls des clients anciens échouent (sans prise en charge de SNI), p. ex. de très vieux systèmes embarqués.

Vérifier que le bon certificat est bien délivré

# Ohne SNI testen: Server wird Default-Zertifikat liefern
openssl s_client -connect example.com:443 -showcerts </dev/null

# Mit SNI testen: korrektes vHost-Zertifikat erwartet
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Si un autre certificat est présenté « sans SNI », c’est normal. Si, malgré le SNI, le mauvais certificat est présenté, la cause se situe au point de terminaison : vHost-Mapping, affectation du Listener, binding incorrect ou un équipement en amont qui a déjà terminé le handshake TLS.

Risque : Legacy-Clients sans SNI

Si vous avez encore des clients sans SNI sur le terrain, vous avez besoin d’une stratégie : IP/port dédié pour ce domaine, ou un endpoint legacy séparé. Dans les environnements B2B, cela apparaît par exemple sur de vieilles appliances, des gateways d’impression/scan ou des gateways embarqués en production.

Cause fréquente 3 : Renouvellement automatique via ACME – le certificat est renouvelé mais pas actif

ACME automatise la demande et le renouvellement. Le risque opérationnel réel se situe souvent non pas dans le renouvellement, mais dans le déploiement : le certificat est renouvelé sur le disque, mais le service utilise encore l’ancien certificat parce qu’un reload/redémarrage fait défaut ou qu’un mauvais chemin est lié.

Comprendre la validation ACME : HTTP-01, DNS-01, TLS-ALPN-01

• HTTP-01 : le serveur ACME récupère un fichier token via HTTP (port 80). Échec en cas de politiques de redirection, règles WAF ou absence d’ouverture entrante.
• DNS-01 : token sous forme d’enregistrement DNS-TXT. Adapté aux certificats wildcard et quand le port 80 n’est pas possible, mais dépend de l’automatisation DNS/propagation.
• TLS-ALPN-01 : validation via le port 443 et ALPN. Pratique si le port 80 est fermé, mais peut entrer en conflit avec certains proxies ou points de terminaison TLS.

Vérifier si le nouveau certificat est réellement actif

Comparez la date NotAfter (expiration) et idéalement aussi l’empreinte (Fingerprint) du certificat en production avec l’artefact attendu.

# Live-Zertifikat holen und Ablaufdatum anzeigen
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -dates -subject -issuer -fingerprint -sha256

Si le certificat en production est ancien alors que les fichiers ACME sont récents, il s’agit d’un problème de déploiement/reload.

Écueils typiques d’ACME en exploitation

• Reload fehlt : le service lit les certificats uniquement au démarrage. Solution : reload planifié après un renouvellement réussi.
• Mehrere Instanzen : le certificat est renouvelé sur le nœud A, mais le trafic passe par le nœud B. Solution : stockage central, gestion de configuration, ou distribution via hook.
• Container/Immutable Deployments : le certificat se trouve sur l’hôte, le conteneur ne le voit pas (volume manquant) ou l’Ingress-Controller le gère séparément.
• Permissions de fichiers/SELinux/AppArmor : le renouvellement écrit un nouveau fichier, le service ne peut pas le lire ensuite.
• Clock Skew : les décalages d’heure provoquent des erreurs « not yet valid » ou des vérifications OCSP fragiles.

Automatisation ACME robuste : Hooks, Reload et Idempotenz

Indépendamment du client ACME (certbot, acme.sh, win-acme etc.), un schéma éprouvé vaut : après un renouvellement réussi, un deploy-hook qui (1) déploie les fichiers/paquets de manière cohérente, (2) définit les permissions, (3) effectue un reload contrôlé et (4) lance un Smoke-Test.

# Beispiel: certbot mit deploy-hook (Linux)
# Der Hook läuft nur, wenn wirklich erneuert wurde.
certbot renew 
  --deploy-hook "/usr/local/sbin/tls-deploy-and-reload.sh"

Le hook lui‑même devrait être « idempotent » (exécutable plusieurs fois sans effets de bord) et renvoyer des codes de sortie clairs, afin que le monitoring/les jobs puissent alerter de manière fiable.

mTLS und Client-Zertifikate: Wenn der Server den Client ablehnt

Bei mTLS (mutual TLS) authentifiziert sich nicht nur der Server gegenüber dem Client, sondern auch der Client gegenüber dem Server mit einem Client-Zertifikat. Das ist in internen Integrationen, B2B-Partneranbindungen oder Admin-Endpunkten verbreitet.

Typische Symptome

• Handshake bricht mit „handshake failure“ oder „bad certificate“ ab.
• Server-Logs zeigen: „no required SSL certificate was sent“ oder „unknown ca“ (bezogen auf Client-CA).

Prüfpfad

• Verlangt der Endpoint wirklich mTLS (Policy/Location/Listener)?
• Ist die CA, die Client-Zertifikate ausstellt, auf dem Server als vertrauenswürdig konfiguriert?
• Passt EKU/Key Usage (Extended Key Usage: „Client Authentication“) im Client-Zertifikat?
• Wird SNI/Host korrekt auf die mTLS-Policy gemappt (nicht versehentlich auf „public“ Listener)?

Protokoll- und Cipher-Policy: Wenn Security-Härtung unerwartet Clients aussperrt

Viele TLS-Ausfälle entstehen nach Härtungsmaßnahmen: Deaktivierung von TLS 1.0/1.1 (meist richtig), RESTriktive Cipher-Listen, erzwungenes TLS 1.3 oder strikte Kurvenauswahl. Das ist kein Argument gegen Härtung – aber für eine kontrollierte Umstellung mit Messpunkten.

Praxisregel: Erst messen, dann schalten

• Welche Clients hängen dran (Browser, Java, .NET, Appliances, Partner)?
• Welche Protokolle werden tatsächlich genutzt (TLS 1.2/1.3)?
• Gibt es Compliance-Vorgaben, die ohnehin TLS 1.2+ verlangen?

In Troubleshooting-Situationen hilft eine temporäre Entschärfung, um Ursache einzugrenzen. Wichtig: nur mit Change-Fenster, dokumentiert, und mit klarer Rücknahme.

Prüfcheckliste: In 20 Minuten zur wahrscheinlichsten Ursache

Wenn Sie unter Zeitdruck sind, nutzen Sie diese Reihenfolge. Sie minimiert „Ratearbeit“ und liefert schnell verwertbare Beweise.

1. Terminierungspunkt bestimmen: DNS → Load Balancer → WAF → Reverse Proxy → App. Dort testen.
2. Live-Zertifikat ziehen (mit SNI): SAN, Issuer, NotAfter, Fingerprint.
3. Zertifikatskette prüfen: wird fullchain ausgeliefert? Verify-Code ansehen.
4. SNI-A/B-Test: mit und ohne -servername vergleichen.
5. TLS-Versionen prüfen: tls1_2 / tls1_3 erzwingen, ALPN testen.
6. mTLS klären: erwartet der Server ein Client-Zertifikat?
7. ACME-Status prüfen: Renewal-Logs, letzte erfolgreiche Erneuerung, Hook/Reload gelaufen?

Umsetzung: Saubere Betriebsmaßnahmen, damit es nicht wieder passiert

TLS-Probleme sind selten „einmalig“. Ohne Betriebsmaßnahmen kommen sie wieder: beim nächsten Intermediate-Wechsel, beim nächsten Zertifikats-Rollover, beim nächsten Load-Balancer-Update oder wenn ein Node aus dem Cluster neu aufgebaut wird.

1) Monitoring auf Ablauf und auf echten Handshake

Surveiller uniquement la date d’expiration ne suffit pas. Vous devez disposer d’au moins deux signaux :

• Expiration du certificat : NotAfter dans un seuil (p. ex. 14/7/3 jours).
• Handshake réel depuis l’extérieur : SNI correct, chaîne valide, version TLS OK. Cela couvre les problèmes liés au SNI, à la chaîne et au déploiement.

2) Plan de changement et de rollback pour les certificats

Un rollback pragmatique signifie : revenir en quelques minutes au certificat/binding précédent. Pour cela vous devez disposer de :

• Stockage versionné des artefacts de certificat (au minimum la version précédente), avec contrôle d’accès.
• Chemins/bindings documentés par service (p. ex. configuration Nginx, binding IIS, listener du load balancer).
• Un processus défini de reload/RESTart et un smoke-test (handshake + statut HTTP + éventuelle requête API).

3) Exploiter proprement ACME dans des environnements multi-nœuds

Dans les environnements HA, la répartition est décisive. Schémas robustes typiques :

• Gestion centralisée des certificats au point de terminaison : ACME s’exécute directement sur le load balancer/reverse proxy, pas « quelque part » dans le backend.
• Pull plutôt que push : les nœuds retirent périodiquement le certificat d’un store sécurisé (gestion des secrets) et procèdent à un reload contrôlé.
• Hooks avec contrôle de santé : ne « committer » le déploiement que si le nouveau handshake sur le listener cible réussit.

Stratégie de repli en cas d’incident : stabiliser, puis améliorer

Lorsque des interfaces productives tombent, l’ordre des opérations compte :

• Stabiliser : délivrer le certificat correct avec une chaîne valide, et au besoin revenir temporairement à une policy connue et fonctionnelle (autoriser TLS 1.2, baseline de ciphers propre).
• Vérifier : tester depuis plusieurs réseaux/clients (interne/externe), documenter les tests SNI, consigner les empreintes.
• Corriger la cause : déploiement ACME, fullchain incorrecte, mauvais mapping SNI, distribution dans le cluster.
• Renforcer ensuite : durcir à nouveau la security-policy, mais avec points de mesure et possibilité de rollback.

Il est important de ne pas considérer le « fix » uniquement au niveau du symptôme. Par exemple, si le renouvellement sur le nœud A fonctionne mais que le nœud B continue de servir l’ancien certificat, il ne s’agit pas d’un problème de certificat mais d’un problème de distribution et d’exploitation.

Conclusion : les handshakes TLS échouent — mais les causes sont maîtrisables avec un runbook clair

Lorsque les handshakes TLS échouent, le principal danger n’est pas la cryptographie mais la complexité opérationnelle : plusieurs points de terminaison, mappage SNI, chaînes de certificats, automatisation et mécanique de reload. Une séquence de vérification fixe (point de terminaison → certificat en production avec SNI → chaîne → protocoles/ALPN → déploiement ACME) permet d’atteindre rapidement la cause. La pérennité vient avec les mesures opérationnelles : monitoring des handshakes, artefacts de certificats versionnés, hooks contrôlés et une procédure de rollback rodée.

Pour ce sujet, les mauvaises configurations SNI et le renouvellement automatique ACME sont également importants. L’article replace ces aspects de manière compréhensible et montre ce qui compte au quotidien.