Dépannage réseau des certificats TLS : guide pratique avec commandes

Introduction

Les certificats TLS sont les ancres de confiance des services réseau modernes, mais ils sont aussi une source fréquente d’incidents en production. Un certificat qui expire silencieusement, une chaîne mal configurée après un renouvellement ou un nom d’hôte incompatible sur un nouveau point d’accès peut interrompre la connectivité sans aucun changement du code applicatif. Le dépannage réseau des certificats TLS exige une approche disciplinée : observer avant de modifier, enregistrer l’état actuel, isoler la défaillance à une couche précise (DNS, TCP, poignée de main TLS, validation du certificat ou application) et vérifier chaque correction à l’aide de commandes claires et de sorties attendues.

Ce guide s’adresse aux développeurs, aux ingénieurs DevOps et aux équipes techniques de startups qui exploitent des services derrière TLS. Il met l’accent sur le diagnostic pratique avec OpenSSL, l’outil en ligne de commande de facto pour l’inspection et le test des certificats. Vous apprendrez à inspecter des fichiers de certificats sans les modifier, à tester des points d’accès distants pour détecter les problèmes de poignée de main et de chaîne, à valider des chaînes de certificats hors ligne et à planifier des procédures de récupération qui minimisent les temps d’arrêt. Les exemples utilisent de vraies commandes avec des espaces réservés, pour que vous puissiez les adapter immédiatement à votre environnement.

Nous couvrirons les principaux aspects du réseau des certificats TLS : la résolution DNS (à quel point d’accès parlons-nous), la connectivité des ports (pouvons-nous joindre le port TLS), la validité du certificat (dates, sujet, émetteur, chaîne de confiance) et le comportement du protocole (versions et suites de chiffrement négociées). Tout au long, l’accent est mis sur la sécurité opérationnelle : saisir l’état actuel avant tout changement, limiter les modifications à un élément ciblé, protéger les clés privées et les secrets, et définir des étapes de retour en arrière avant d’agir.

Inventaire des versions et de l’environnement

Avant d’exécuter tout diagnostic, établissez un inventaire clair des composants impliqués dans la fourniture ou la validation des certificats TLS. Cet inventaire réduit le risque de corriger le mauvais serveur, d’appliquer une commande avec une version différente d’OpenSSL ou de manquer un prérequis comme l’accès root ou un magasin de confiance spécifique.

Pour chaque hôte ou service inspecté, notez :

Nom et rôle du composant : par exemple, reverse proxy nginx, équilibreur de charge haproxy, contrôleur d’entrée Kubernetes ou serveur d’application dorsal.
Version d’OpenSSL prise en charge : exécutez openssl version et notez la sortie exacte. Les différentes versions d’OpenSSL prennent en charge différents niveaux de sécurité par défaut et différentes suites de chiffrement. Exemple de sortie : OpenSSL 3.0.7 1 Nov 2022 (Library: OpenSSL 3.0.7 1 Nov 2022).
Privilèges requis : certaines commandes, comme la liaison au port 443 ou la lecture de clés privées, nécessitent root ou une appartenance à un groupe spécifique. Notez le compte que vous utilisez.
Emplacement du magasin de confiance : sur les systèmes Linux, le magasin de confiance système est souvent /etc/ssl/certs/ca-certificates.crt (Debian/Ubuntu) ou /etc/pki/tls/certs/ca-bundle.crt (RHEL/CentOS). Pour les autorités de certification personnalisées, notez le chemin du fichier.

Une fois l’inventaire en place, effectuez une observation en lecture seule du certificat concerné. La commande suivante inspecte un fichier de certificat au format PEM sans le modifier :

openssl x509 -in <certificat.pem> -noout -subject -issuer -serial -dates -fingerprint -sha256

La sortie attendue comprend des lignes comme :

subject=CN = example.com
issuer=CN = Let's Encrypt R3
serial=04F0B5A2C1D3E4F5A6B7C8D9E0F1A2B3C4D5
notBefore=Jun  1 00:00:00 2024 GMT
notAfter=Aug 30 00:00:00 2024 GMT
SHA256 Fingerprint=AB:CD:EF:01:23:45:67:89:AB:CD:EF:01:23:45:67:89:AB:CD:EF:01:23:45:67:89:AB:CD:EF:01

Enregistrez le sujet attendu, l’émetteur, la fenêtre de validité et l’empreinte SHA-256 avant le déploiement. Cette empreinte constitue un contrôle d’intégrité rapide après la copie de fichiers entre hôtes. Si l’empreinte change de manière inattendue, le mauvais certificat a peut-être été installé.

Ensuite, testez la poignée de main TLS du point d’accès distant sans envoyer de données applicatives. L’option -connect utilise le port HTTPS par défaut 443 ; si votre service écoute sur un autre port, ajustez en conséquence :

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Sorties clés à vérifier :

Les lignes subject et issuer correspondent au certificat attendu.
Verify return code: 0 (ok) indique que le client a vérifié la chaîne avec succès par rapport à son magasin de confiance par défaut. Tout code non nul indique un problème.
La chaîne de certificats est affichée ; assurez-vous que les certificats intermédiaires sont envoyés. Un intermédiaire manquant est une cause fréquente d’erreurs « unable to verify » chez certains clients.
Le protocole et la suite de chiffrement négociés apparaissent en haut (par exemple, Protocol : TLSv1.3, Cipher : TLS_AES_256_GCM_SHA384). Cela permet de détecter des problèmes comme un serveur n’offrant que des versions obsolètes de TLS.

Une connexion TCP réussie au port 443 ne prouve pas la validité du certificat. Utilisez s_client pour confirmer que la couche TLS est saine.

Enfin, validez une chaîne de certificats hors ligne, sans contacter de serveur distant. C’est utile après un renouvellement ou lors de la préparation d’un nouveau déploiement :

openssl verify -CAfile <ca-de-confiance.pem> -untrusted <intermediaire.pem> <feuille.pem>

Si la chaîne est valide, la sortie sera :

<feuille.pem>: OK

En cas de problème, vous verrez des détails d’erreur comme unable to get local issuer certificate (autorité de certification racine manquante) ou certificate has expired. Testez toujours les procédures de renouvellement et de retour en arrière avant que la fenêtre d’expiration ne devienne urgente.

Chemin de configuration sécuritaire

Les modifications de configuration des services TLS sont à haut risque, car une erreur peut instantanément rompre toutes les connexions sécurisées. Suivez un chemin de configuration sûr qui minimise le rayon d’impact et garantit la restauration d’un état connu comme bon.

Séparez l’observation de l’intervention. Ne mélangez jamais les diagnostics en lecture seule avec les modifications. Utilisez des sessions shell ou des terminaux séparés si nécessaire. Avant toute modification, saisissez la configuration et l’état du certificat actuels. Par exemple, enregistrez la sortie de :

   openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -serial -dates -fingerprint -sha256

Cela donne une empreinte et une fenêtre de validité de référence pour le certificat actuellement en ligne.

Faites un changement ciblé à la fois. Si vous devez mettre à jour à la fois un fichier de configuration Nginx et un lien symbolique de certificat, modifiez un seul élément, testez-le, puis passez au suivant. Cela permet d’identifier clairement la cause d’une défaillance.

Utilisez le contrôle de version ou une sauvegarde pour les fichiers de configuration. Avant de modifier /etc/nginx/sites-available/default, copiez-le dans une sauvegarde horodatée :

   cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bak.$(date +%Y%m%d%H%M%S)

Sinon, si la configuration est gérée par un outil comme Ansible ou Puppet, utilisez le mécanisme de contrôle des modifications de cet outil.

Validez la syntaxe de la configuration avant de recharger ou de redémarrer. Pour Nginx :

   nginx -t

Sortie attendue : nginx: configuration file /etc/nginx/nginx.conf test is successful. Pour HAProxy :

   haproxy -c -f /etc/haproxy/haproxy.cfg

La sortie attendue comprend Configuration file is valid.

Rechargez plutôt que de redémarrer si possible. Un rechargement applique les changements sans interrompre les connexions existantes. Pour Nginx :

   systemctl reload nginx

Vérifiez toujours que le service est toujours actif après le rechargement :

   systemctl is-active nginx

Sortie attendue : active.

Testez la nouvelle configuration avec une vérification en lecture seule. Exécutez à nouveau openssl s_client et comparez l’empreinte à la nouvelle valeur attendue. Si l’empreinte est inchangée, le nouveau certificat n’a peut-être pas été chargé.

Définissez et testez le retour en arrière. Avant d’appliquer un changement, sachez comment le rétablir. Si vous avez remplacé un lien symbolique de certificat, conservez l’ancien fichier de certificat et soyez prêt à repointrer le lien. Si vous avez modifié Nginx, gardez le fichier de sauvegarde et connaissez la commande pour le restaurer.

Pour les contrôleurs d’entrée Kubernetes, le chemin de configuration diffère. Les certificats sont souvent stockés sous forme de Secrets. Pour inspecter un secret TLS sans exposer les clés privées, utilisez :

kubectl get secret <nom-du-secret-tls> -n <espace-de-noms> -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -subject -issuer -dates -fingerprint -sha256

Pour mettre à jour le certificat, vous créeriez un nouveau Secret et mettrez à jour la ressource Ingress pour le référencer. Vérifiez toujours les journaux du contrôleur pour les événements de rechargement du certificat après la mise à jour.

Vérification et diagnostics

Une vérification systématique est essentielle pour résoudre rapidement les problèmes TLS. Utilisez une approche par couches qui vérifie chaque dépendance dans l’ordre : résolution DNS, connectivité TCP, poignée de main TLS, validation de la chaîne de certificats et enfin comportement au niveau applicatif.

Étape 1 : Résolution DNS

Assurez-vous que le nom d’hôte se résout vers l’adresse IP attendue. Utilisez dig ou host :

dig +short example.com

La sortie attendue est une ou plusieurs adresses IP. Si l’adresse IP diffère de ce que votre équilibreur de charge ou votre serveur attend, le trafic peut atteindre un mauvais point d’accès. Pour le débogage, vous pouvez aussi forcer la résolution dans openssl s_client en utilisant l’adresse IP avec -connect et le nom d’hôte avec -servername, mais cela contourne le DNS et ne convient qu’au dépannage avancé.

Étape 2 : Connectivité TCP

Confirmez que le port TLS est joignable. Utilisez nc ou telnet :

nc -zvw3 example.com 443

La sortie attendue comprend Connection to example.com 443 port [tcp/https] succeeded!. Si la connexion expire, vérifiez les règles de pare-feu, les groupes de sécurité et si le service écoute sur l’interface attendue. Sur le serveur lui-même, vérifiez avec :

ss -tlnp | grep ':443'

La sortie attendue montre un écouteur, par exemple LISTEN 0 128 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=1234,fd=6)).

Étape 3 : Poignée de main TLS et inspection du certificat

Utilisez openssl s_client avec des options détaillées pour capturer plus d’informations :

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts -tlsextdebug -state 2>&1 | tee /tmp/tls-handshake.log

L’option -state affiche la progression de la poignée de main TLS. L’option -tlsextdebug montre l’indication de nom de serveur (SNI) et d’autres extensions. Recherchez :

Le certificat du serveur présenté et les éventuels intermédiaires.
Le Verify return code à la fin.
Toute alerte comme alert handshake failure ou alert certificate expired.

Pour vérifier si le serveur envoie la chaîne complète, extrayez les certificats de la sortie et comptez-les. Une sortie typique pour un serveur correctement configuré comprend le certificat feuille et un ou deux intermédiaires. Si seule la feuille est envoyée, certains clients (surtout mobiles) peuvent échouer à vérifier.

Étape 4 : Validation hors ligne de la chaîne

Si vous disposez des fichiers de certificats localement (feuille, intermédiaire, racine), validez la chaîne hors ligne comme décrit précédemment. De plus, vérifiez l’usage et les contraintes du certificat :

openssl x509 -in <feuille.pem> -noout -purpose

La sortie comprend des lignes comme SSL client : Yes et SSL server : Yes, indiquant que le certificat est valide pour l’usage prévu. Si le certificat sert uniquement à l’authentification du client, il ne fonctionnera pas pour un serveur.

Étape 5 : Diagnostic du protocole et des suites de chiffrement

Parfois, le problème ne vient pas du certificat mais du protocole ou de la suite de chiffrement négociés. Utilisez openssl s_client avec des versions spécifiques pour tester la compatibilité :

echo | openssl s_client -connect example.com:443 -servername example.com -tls1_2

Si le serveur prend en charge TLS 1.2, la poignée de main réussira. En cas d’échec, vous verrez peut-être no protocols available ou un échec de poignée de main. Cela aide à identifier si les clients utilisant des versions plus anciennes sont bloqués.

Pour lister les suites de chiffrement offertes par le serveur, utilisez nmap avec le script ssl-enum-ciphers (si disponible) :

nmap --script ssl-enum-ciphers -p 443 example.com

Cela fournit une liste détaillée des suites de chiffrement prises en charge et de leur robustesse. Notez que certaines organisations interdisent l’utilisation de nmap ; vérifiez d’abord la politique.

Étape 6 : Vérification du nom d’hôte

Même si la chaîne est valide, le certificat doit correspondre au nom d’hôte utilisé par le client. Vérifiez l’extension Subject Alternative Name (SAN) :

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

La sortie attendue comprend DNS:example.com et éventuellement des entrées génériques comme DNS:*.example.com. Si le nom d’hôte est absent ou incompatible, les clients rejetteront la connexion avec des erreurs telles que SSL: no alternative certificate subject name matches target host name.

Étape 7 : Surveillance de l’expiration des certificats

Surveillez de manière proactive l’expiration des certificats pour éviter les surprises. Utilisez un script simple qui vérifie la date notAfter et alerte s’il reste moins de N jours :

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

Le format de sortie est notAfter=Aug 30 00:00:00 2024 GMT. Analysez cette date et comparez-la à la date actuelle. De nombreux outils automatisent cela, mais une simple tâche cron avec un script shell peut suffire pour de petits environnements.

Modes de défaillance et récupération

Les défaillances des certificats TLS se répartissent en catégories prévisibles. Comprendre le mode de défaillance accélère la récupération et aide à préparer des mesures préventives.

Certificat expiré

Symptôme : Les clients signalent certificate has expired, et openssl s_client affiche Verify return code: 10 (certificate has expired).

Récupération immédiate : Remplacez le certificat par un certificat valide dès que possible. Si vous utilisez un émetteur automatisé comme Let's Encrypt, exécutez la commande de renouvellement. Pour les processus manuels, installez le nouveau certificat et rechargez le service. Vérifiez avec :

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

Assurez-vous que notAfter est dans le futur et que l’empreinte correspond au nouveau certificat attendu.

Prévention : Mettez en place une surveillance qui vérifie quotidiennement les dates d’expiration et alerte à 30, 14 et 7 jours avant l’expiration. Automatisez le renouvellement lorsque c’est possible.

Chaîne de confiance rompue

Symptôme : Certains clients fonctionnent, d’autres non. Erreur courante : unable to get local issuer certificate ou unable to verify the first certificate. openssl s_client peut afficher Verify return code: 21 (unable to verify the first certificate).

Cause : Le serveur n’envoie pas les certificats intermédiaires nécessaires, ou le client ne fait pas confiance à l’autorité de certification racine.

Récupération : Configurez le serveur pour inclure la chaîne complète. Pour Nginx, définissez ssl_certificate sur un fichier contenant la feuille suivie des intermédiaires (et éventuellement la racine, bien qu’elle soit généralement omise). Par exemple, un fichier combiné fullchain.pem serait référencé ainsi :

ssl_certificate /etc/nginx/ssl/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/privkey.pem;

Après le rechargement, testez à nouveau. Si le problème persiste sur des clients spécifiques, assurez-vous que ces clients ont l’autorité de certification racine dans leur magasin de confiance.

Incompatibilité de nom d’hôte

Symptôme : Les clients signalent SSL: no alternative certificate subject name matches target host name. Le certificat est valide pour d’autres noms mais pas pour celui auquel on accède.

Récupération : Obtenez un certificat qui inclut le ou les bons noms d’hôte dans l’extension SAN. Si un caractère générique est attendu, vérifiez le motif. Par exemple, *.example.com ne correspond pas à example.com ni à sub.sub.example.com.

Contournement temporaire : Si le service doit rester disponible pendant l’émission d’un nouveau certificat, certains clients permettent de désactiver la vérification du nom d’hôte, mais cela est non sécuritaire et ne doit jamais être utilisé en production.

Discordance de clé privée

Symptôme : Le service ne démarre pas ou ne se recharge pas, avec des erreurs comme key values mismatch ou des problèmes SSL_CTX_use_PrivateKey_file.

Cause : Le fichier de clé privée ne correspond pas au certificat feuille. Cela peut arriver après la génération d’une nouvelle clé sans l’associer au certificat, ou lors d’une copie incorrecte des fichiers.

Récupération : Vérifiez que le module de la clé et du certificat correspondent.

openssl x509 -in <certificat.pem> -noout -modulus | openssl md5
openssl rsa -in <cle-privee.key> -noout -modulus | openssl md5

Les deux commandes doivent produire le même hachage MD5. S’ils diffèrent, vous devez associer la bonne clé au certificat. Si vous avez perdu la clé d’origine, vous devrez générer une nouvelle clé et un nouveau certificat (ou le faire réémettre par l’autorité de certification).

Incompatibilité de version TLS ou de suite de chiffrement

Symptôme : Les anciens clients ne parviennent pas à se connecter, tandis que les clients modernes réussissent. Les erreurs peuvent inclure no protocols available ou des échecs de poignée de main.

Cause : Le serveur a été durci pour n’autoriser que TLS 1.3 ou un ensemble restreint de suites de chiffrement que les anciens clients ne prennent pas en charge.

Récupération : Ajustez la configuration TLS du serveur pour prendre en charge une plus large gamme de versions (par exemple, TLS 1.2 et 1.3) et une suite de chiffrement raisonnable. Pour Nginx :

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';

Testez avec openssl s_client -tls1_2 et -tls1_3 pour confirmer que les deux versions fonctionnent.

Certificat révoqué

Symptôme : Les clients signalent certificate revoked. openssl s_client peut afficher Verify return code: 23 (certificate revoked).

Cause : Le certificat a été ajouté à une liste de révocation de certificats (CRL) ou signalé via OCSP.

Récupération : Obtenez un nouveau certificat auprès de l’autorité de certification. Ne contournez pas les vérifications de révocation. Jusqu’à la mise en place du nouveau certificat, envisagez d’utiliser un certificat de secours s’il est disponible, mais comprenez les implications de sécurité.

Liste de contrôle des opérations

Utilisez la liste de contrôle suivante pour dépanner les problèmes de réseau de certificats TLS. Elle est conçue pour être exécutée dans l’ordre, avec vérification à chaque étape.

[] Inventaire : Exécutez openssl version et notez la version. Identifiez le composant qui fournit TLS (Nginx, HAProxy, entrée Kubernetes, etc.) et notez tout magasin de confiance personnalisé.
[] DNS : Résolvez le nom d’hôte avec dig +short <nom-d-hote>. Confirmez que l’adresse IP correspond au serveur attendu.
[] TCP : Testez la connectivité du port avec nc -zvw3 <nom-d-hote> 443. Sur le serveur, vérifiez l’écouteur avec ss -tlnp | grep ':443'.
[] Poignée de main TLS : Exécutez echo | openssl s_client -connect <nom-d-hote>:443 -servername <nom-d-hote> -showcerts 2>&1 | tee /tmp/tls.log. Vérifiez Verify return code: 0 (ok), la chaîne présentée et le protocole négocié.
[] Détails du certificat : Extrayez les informations du certificat avec openssl x509 -in <cert.pem> -noout -subject -issuer -serial -dates -fingerprint -sha256. Comparez le sujet, l’émetteur, la fenêtre de validité et l’empreinte aux attentes.
[] Validation de la chaîne : Si les fichiers locaux sont disponibles, exécutez openssl verify -CAfile <racine.pem> -untrusted <intermediaire.pem> <feuille.pem>. Confirmez la sortie OK.
[] Vérification du nom d’hôte : Vérifiez les SAN avec openssl x509 -in <cert.pem> -noout -ext subjectAltName. Assurez-vous que le nom d’hôte cible est listé.
[] Correspondance de la clé privée : Si le service ne démarre pas, vérifiez que les modules de la clé et du certificat correspondent en utilisant openssl x509 -modulus | md5sum et openssl rsa -modulus | md5sum.
[] Configuration du service : Validez la configuration avec nginx -t (ou équivalent), puis rechargez. Vérifiez que le service est actif avec systemctl is-active <service>.
[] Vérification après changement : Après tout changement, réexécutez openssl s_client et confirmez Verify return code: 0 (ok) et l’empreinte attendue.
[] Plan de retour en arrière : Avant d’apporter des modifications, assurez-vous d’avoir des sauvegardes des fichiers de configuration et des certificats, et connaissez les commandes exactes pour les restaurer.
[] Surveillance : Mettez en place des contrôles automatisés pour l’expiration des certificats et la validation des chaînes. Planifiez des audits réguliers.

Conclusion

Le dépannage réseau des certificats TLS est une compétence essentielle pour quiconque exploite des services sécurisés. Les commandes et procédures de ce guide fournissent une base pour diagnostiquer les problèmes, de la résolution DNS à la validation et à la récupération des certificats. Les principes clés sont les suivants :

Observer avant de changer : Saisissez l’état actuel et enregistrez les valeurs attendues.
Isoler la couche de défaillance : Vérifiez systématiquement le DNS, le TCP, la poignée de main TLS et les détails du certificat.
Apporter des modifications minimales et réversibles : Un changement ciblé à la fois, avec un plan de retour en arrière.
Vérifier chaque correction : Utilisez openssl s_client et les commandes d’inspection de certificats pour confirmer la résolution du problème.
Protéger les secrets : N’exposez jamais les clés privées ou la configuration sensible dans les journaux ou la documentation.

Comme prochaine étape, choisissez une vérification à faible risque de la liste de contrôle et exécutez-la sur votre propre service. Par exemple, exécutez le test de poignée de main TLS et notez le Verify return code. Ensuite, examinez la date d’expiration du certificat et configurez une alerte de surveillance si vous n’en avez pas. Enfin, préparez un manuel de récupération d’une page pour votre équipe, couvrant les modes de défaillance les plus probables : certificat expiré, chaîne rompue et incompatibilité de nom d’hôte.

Un flux de travail technique fiable rend les défaillances visibles avant qu’elles ne deviennent des incidents. Avec les bonnes commandes et une approche disciplinée, vous pouvez maintenir votre infrastructure TLS saine et vos utilisateurs en sécurité.