« Secure connection failed ». C’est le message que voit un visiteur qui tente d’ouvrir un site WordPress un mardi après-midi, juste après qu’un développeur a renouvelé « à la main » un certificat TLS censé expirer le lendemain. Firefox affiche l’erreur en clair ; Chrome parle d’un certificat invalide. Dans les deux cas, impossible de charger la moindre page en HTTPS.
Le renouvellement manuel d’un certificat reste courant sur les configurations qui n’utilisent pas encore Certbot en mode automatique, notamment sur des serveurs mutualisés gérés à la main ou des VPS configurés il y a longtemps. C’est justement ce terrain qui laisse le plus de place à une erreur de manipulation.
Le symptôme observé
Le certificat affiché par le navigateur ne correspondait tout simplement pas au nom de domaine attendu, avec une alerte de type SSL_ERROR_BAD_CERT_DOMAIN selon les navigateurs, ou un blocage pur et simple de la connexion sécurisée. Le port 80 en HTTP restait fonctionnel, ce qui a permis d’écarter d’emblée une panne réseau ou serveur plus large.
- Le HTTP simple sur le port 80 fonctionne normalement
- Le HTTPS échoue systématiquement, quel que soit le navigateur testé
- Le certificat renvoyé ne correspond pas au domaine attendu
Diagnostic : la clé privée ne correspondait plus au certificat
La commande openssl permet de comparer l’empreinte du certificat et celle de la clé privée censée lui correspondre. En cas de mismatch, les deux valeurs diffèrent :
openssl x509 -noout -modulus -in certificat.crt | openssl md5
openssl rsa -noout -modulus -in cle-privee.key | openssl md5Sur ce dossier, les deux empreintes ne correspondaient pas. En reconstituant la chronologie, l’explication est apparue : lors d’une précédente demande de certificat, une nouvelle paire clé publique / clé privée avait été générée, mais l’ancienne clé privée avait été laissée en place dans le bloc serveur Nginx par erreur de copier-coller de chemin de fichier.
Le correctif appliqué
La correction elle-même est rapide une fois la cause identifiée : il s’agit de vérifier que le bloc server Nginx référence bien la clé privée générée en même temps que le certificat en cours d’installation, puis de recharger la configuration.
server {
listen 443 ssl;
server_name exemple-site.fr;
ssl_certificate /etc/ssl/exemple-site.fr/fullchain.pem;
ssl_certificate_key /etc/ssl/exemple-site.fr/privkey.pem;
}Après correction du chemin et test de la configuration avec nginx -t, un rechargement du service (systemctl reload nginx) a suffi à rétablir l’accès HTTPS, sans coupure supplémentaire du service HTTP.
Toujours vérifier une paire clé/certificat avant de recharger le service. Une simple comparaison d’empreintes coûte dix secondes ; un certificat mal apparié coûte souvent une heure de diagnostic, et parfois la confiance d’un client qui a vu une alerte de sécurité s’afficher sur son propre site.
Pourquoi ce genre d’erreur reste fréquent en gestion manuelle
La génération d’un certificat TLS via Certbot en mode manuel crée systématiquement une nouvelle clé privée, sauf si l’on précise explicitement le contraire. Sur un serveur où plusieurs domaines et plusieurs générations de certificats cohabitent, il devient facile de mélanger les fichiers, en particulier si les noms ne sont pas rigoureusement normalisés dans l’arborescence /etc/letsencrypt/.
Prévenir plutôt que corriger dans l’urgence
Ce dossier a conduit à deux décisions. D’abord, la bascule vers un renouvellement automatique via le service intégré de Certbot, qui gère lui-même la correspondance entre certificat et clé sans intervention manuelle. Ensuite, l’ajout d’une vérification de type test de connexion HTTPS programmée toutes les nuits, qui aurait détecté l’incident en quelques minutes plutôt qu’en attendant un signalement d’un visiteur.
Pour ne pas reproduire cette erreur
Un renouvellement TLS manuel n’est pas fautif en soi, mais il exige une discipline stricte : vérifier systématiquement la correspondance clé/certificat avant de recharger le serveur, et tester la configuration avec les outils prévus à cet effet plutôt que de faire confiance à un chemin de fichier recopié à la main. Ce sont ces deux réflexes, plus qu’un outil particulier, qui évitent la panne.
