Dépannage des certificats TLS avec exemples pratiques

Introduction

Les certificats TLS sont le fondement des communications sécurisées sur Internet. Lorsqu'ils échouent, les applications cessent de fonctionner, les utilisateurs voient des avertissements et des incidents de production surviennent. Le dépannage des problèmes de certificats TLS implique souvent plusieurs couches : validité du certificat, chaîne de confiance, correspondance du nom d'hôte, versions de protocole, suites de chiffrement et configuration des serveurs web ou des proxys inverses. Ce guide propose une approche pratique, étape par étape, destinée aux développeurs et aux ingénieurs DevOps pour diagnostiquer et résoudre les problèmes courants de certificats TLS. Il inclut des commandes concrètes, des extraits de configuration et les sorties attendues, couvrant les prérequis, une mise en œuvre sécurisée, la vérification, les modes de défaillance, la récupération et une liste de contrôle opérationnelle.

Inventaire de la version et de l'environnement

Avant de commencer le dépannage, établissez l'environnement exact. Déterminez le système d'exploitation, le logiciel serveur web ou proxy, les versions des bibliothèques TLS et les détails du certificat. Ces informations aident à réduire les causes potentielles et à garantir une reproduction cohérente.

Exemples de commandes pour recueillir les informations d'environnement :

# Vérifier la version du système d'exploitation
cat /etc/os-release

# Vérifier la version de Nginx et le support TLS
nginx -V 2>&1 | grep -o 'with-http_ssl_module'
nginx -V 2>&1 | grep -o 'built with OpenSSL [^ ]*'

# Vérifier la version d'OpenSSL
openssl version -a

# Vérifier les détails du certificat (en supposant que vous ayez le fichier du certificat)
sudo openssl x509 -in /etc/nginx/ssl/example.com.crt -noout -subject -issuer -dates

Sortie attendue pour les détails du certificat :

subject= /CN=example.com
issuer= /C=US/O=Let's Encrypt/CN=R3
dates: notBefore=Jan 1 00:00:00 2024 GMT
notAfter=Mar 31 23:59:59 2025 GMT

Pour les situations impliquant un proxy inverse comme Nginx, notez le backend en amont et si la terminaison TLS a lieu au niveau du proxy ou du backend. Cela affecte l'endroit où les vérifications de certificat sont effectuées. Documentez la topologie, y compris les équilibreurs de charge, les CDN et les services internes.

Chemin de configuration sécurisé

Lors de la modification de la configuration TLS, travaillez toujours sur un chemin contrôlé : testez les changements dans un environnement de préproduction ou une instance locale d'abord, puis appliquez-les en production avec des options de retour en arrière. Pour Nginx, utilisez nginx -t pour tester la syntaxe de la configuration avant de recharger.

Exemple de flux de travail de configuration sécurisé :

• Sauvegarder la configuration existante :

sudo cp /etc/nginx/sites-available/example.com.conf /etc/nginx/sites-available/example.com.conf.bak

• Apporter des modifications ciblées (par exemple, mettre à jour les chemins des certificats ou les protocoles) :

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
}

• Tester la configuration :

sudo nginx -t

Sortie attendue en cas de succès :

nginx: configuration file /etc/nginx/nginx.conf test is successful

• Recharger Nginx en douceur :

sudo systemctl reload nginx

• Vérifier le changement avec une requête locale avant de faire confiance à la production :

curl -vI --resolve example.com:443:127.0.0.1 https://example.com

Cela garantit que le changement est limité dans sa portée et réduit les risques.

Vérification et diagnostics

Utilisez une combinaison d'outils en ligne de commande pour vérifier les certificats, la chaîne de confiance et les négociations de protocole. Outils clés : openssl, curl, echo | openssl s_client et les journaux du serveur web.

Vérification de la chaîne de certificats

openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt /etc/nginx/ssl/example.com.crt

Sortie attendue si valide :

/etc/nginx/ssl/example.com.crt: OK

Si la chaîne est brisée, la sortie peut afficher :

error 20 at 0 depth lookup: unable to get local issuer certificate

Inspection du certificat du serveur distant

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

Vérifiez que le Subject Alternative Name (SAN) inclut le nom d'hôte.

Test avec curl

La sortie verbeuse révèle les erreurs TLS :

curl -v https://example.com 2>&1 | grep -E 'SSL|TLS|certificate|handshake'

Messages d'erreur courants :

• SSL certificate problem: unable to get local issuer certificate (intermédiaire manquant)
• SSL: no alternative certificate subject name matches target host name (non-correspondance du nom d'hôte)

Vérification de l'expiration

openssl x509 -enddate -noout -in /etc/nginx/ssl/example.com.crt

Sortie attendue :

notAfter=Mar 31 23:59:59 2025 GMT

Analyse des journaux

Les journaux Nginx peuvent montrer des erreurs TLS. Exemple dans /var/log/nginx/error.log :

SSL_do_handshake() failed (SSL: error:14094416:SSL routines: ssl3_read_bytes: sslv3 alert certificate unknown: SSL alert number 46)

Cela indique que le client a rejeté le certificat du serveur, souvent en raison d'un intermédiaire manquant ou de problèmes de confiance.

Modes de défaillance et récupération

Les modes de défaillance courants incluent les certificats expirés, la non-correspondance du nom d'hôte, les protocoles faibles, l'émetteur non approuvé et une chaîne mal configurée. Chacun nécessite une approche de récupération spécifique.

Certificat expiré

Renouvelez immédiatement. Pour Let's Encrypt, utilisez certbot :

sudo certbot renew --dry-run
sudo certbot renew

Puis rechargez le serveur web. Vérifiez la nouvelle date d'expiration.

Non-correspondance du nom d'hôte

Assurez-vous que le SAN du certificat inclut le nom d'hôte exact (y compris les jokers si applicable). Sinon, obtenez un nouveau certificat.

Intermédiaire manquant

Concaténez le certificat intermédiaire avec le certificat du serveur dans le bon ordre :

cat example.com.crt intermediate.crt > fullchain.crt

Mettez à jour la configuration Nginx pour utiliser fullchain.crt comme ssl_certificate.

Problèmes de protocole ou de chiffrement

Ajustez ssl_protocols et ssl_ciphers pour prendre en charge les clients modernes (par exemple, activez TLSv1.2/1.3). Testez avec :

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

ou utilisez testssl.sh.

Récupération par retour en arrière

Gardez toujours une sauvegarde de la configuration et des certificats précédents qui fonctionnaient. Si un changement provoque une défaillance, revenez en arrière :

sudo cp /etc/nginx/sites-available/example.com.conf.bak /etc/nginx/sites-available/example.com.conf
sudo systemctl reload nginx

Surveillance automatisée

Mettez en place des vérifications pour alerter en cas d'expiration. Exemple d'entrée cron :

0 9 * * * /usr/local/bin/check_cert.sh example.com

Où check_cert.sh se termine avec un code non nul si le certificat expire dans les 14 jours.

Pièges courants et comment les éviter

De nombreuses défaillances TLS proviennent d'erreurs récurrentes. Voici les pièges les plus fréquents, pourquoi ils surviennent et comment les éviter ou s'en remettre.

1. Oublier d'inclure les certificats intermédiaires

Pourquoi cela arrive : Le certificat du serveur seul n'est pas approuvé par les clients à moins qu'ils ne puissent construire une chaîne jusqu'à une autorité de certification racine. Si l'intermédiaire manque, le client ne peut pas vérifier la chaîne.

Comment éviter : Installez toujours la chaîne complète (certificat du serveur plus intermédiaires) telle que fournie par l'autorité de certification. Pour Let's Encrypt, utilisez fullchain.pem.

Comment récupérer : Combinez le certificat du serveur et les intermédiaires dans l'ordre :

cat server.crt intermediate.crt > fullchain.crt

Puis configurez votre serveur web pour utiliser fullchain.crt.

2. Ne pas vérifier la date d'expiration du certificat

Pourquoi cela arrive : Les certificats expirent silencieusement. Sans surveillance, un certificat peut expirer et provoquer une panne.

Comment éviter : Mettez en place une surveillance automatisée avec des outils comme certbot renew --dry-run dans cron, ou utilisez un service de surveillance externe qui vérifie l'expiration.

Comment récupérer : Renouvelez le certificat immédiatement, puis rechargez le serveur web.

3. Non-correspondance du nom d'hôte en raison d'un SAN manquant

Pourquoi cela arrive : Les anciens certificats peuvent n'utiliser que le champ Common Name (CN). Les navigateurs modernes exigent que le nom d'hôte figure dans l'extension Subject Alternative Name (SAN). Si le SAN ne comprend pas le nom d'hôte exact, le navigateur rejette le certificat.

Comment éviter : Lors de la génération d'une CSR, incluez tous les SAN nécessaires (par exemple, example.com, www.example.com).

Comment récupérer : Obtenez un nouveau certificat avec les SAN corrects.

4. Utiliser des protocoles TLS obsolètes ou des chiffrements faibles

Pourquoi cela arrive : Les anciennes configurations peuvent encore activer TLSv1.0 ou SSLv3 pour la compatibilité, mais ceux-ci sont désormais considérés comme non sécurisés et peuvent être bloqués par les navigateurs ou les analyses de sécurité.

Comment éviter : Désactivez les protocoles obsolètes et les chiffrements faibles. Utilisez uniquement TLSv1.2 et TLSv1.3, et préférez des suites de chiffrement fortes.

Comment récupérer : Mettez à jour la configuration de votre serveur web :

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;

Puis testez avec nmap --script ssl-enum-ciphers ou testssl.sh.

5. Mauvaise configuration dans les configurations de proxy inverse

Pourquoi cela arrive : Dans les topologies complexes avec équilibreurs de charge et proxys inverses, les certificats peuvent être installés sur le proxy mais pas sur le backend, ou vice versa. Les clients peuvent voir des erreurs si le proxy transmet le TLS de manière incorrecte.

Comment éviter : Documentez clairement où la terminaison TLS a lieu. Vérifiez chaque saut avec openssl s_client.

Comment récupérer : Tracez le chemin de la requête et assurez-vous que les certificats sont correctement installés au point de terminaison.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle pour les opérations TLS régulières et les revues de dépannage. Attribuez un responsable unique pour chaque élément et révisez au moins une fois par mois.

Examinez régulièrement les journaux pour détecter les erreurs TLS et ajustez les configurations si nécessaire.

Conclusion

Le dépannage des certificats TLS exige une approche systématique : recueillir les détails de l'environnement, modifier la configuration en toute sécurité, vérifier avec des outils de diagnostic et planifier la récupération en cas de défaillances courantes. En utilisant les commandes et les procédures décrites, les praticiens peuvent rapidement identifier et résoudre des problèmes tels que les certificats expirés, les problèmes de chaîne et les non-correspondances de nom d'hôte. Mettez en œuvre la liste de contrôle opérationnelle pour maintenir la santé des certificats et prévenir les incidents futurs. Commencez par un changement pilote étroit et mesurable pour valider votre processus avant un déploiement plus large.