# « Secure connection failed » après un renouvellement TLS manuel raté > Un renouvellement de certificat effectué à la main casse l'accès HTTPS d'un site pendant l'après-midi. Retour sur l'erreur commise et sur le correctif. - Auteur : WordPress Développement - Publié le : 2020-03-02 - Mis à jour le : 2020-03-02 - Catégorie : Hébergement & serveurs - URL : https://www.wpmoderne.fr/hebergement/secure-connection-failed-renouvellement-tls-manuel-rate/ ## L’essentiel - Un certificat et sa clé privée doivent correspondre exactement - openssl permet de vérifier la correspondance en trente secondes - Automatiser évite l'erreur humaine sur ce type de manipulation « 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 md5 ``` Sur 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. > L'essentiel à retenir : Un certificat et sa clé privée doivent correspondre exactement ; openssl permet de vérifier la correspondance en trente secondes ; Automatiser évite l'erreur humaine sur ce type de manipulation ## 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.