Régénérer Let's Encrypt après un piratage : utile ou rituel

Ce que le cadenas dit, et ce qu'il ne dit pas

HTTPS prouve que le navigateur parle bien au serveur qui présente le certificat, et que le trajet est chiffré. Il ne dit pas que le HTML est le vôtre, ni que le JavaScript du checkout est légitime. Un kit d'hameçonnage a souvent un cadenas vert. Safe Browsing classe le contenu, pas le chiffrement.

Après un incident, le réflexe « on renouvelle, ça ira mieux » vient de cette confusion. Chrome affiche « site trompeur » avec un Let's Encrypt valide. Renouveler ne change pas une ligne du payload. Voir cadenas HTTPS et site dangereux et alerte site trompeur.

Le certificat reste un sujet — plus tard, et seulement si l'on a une raison de croire que la clé privée a fuité. Pas comme premier geste. Les premiers gestes commencent par constater et copier, pas par le manager SSL.

Quand régénérer a un sens

Si un attaquant a eu le panel, le FTP en écriture à la racine, ou un fichier `.env` / copie de clés, partez du principe que le matériel cryptographique du vhost a pu être lu. Dans ce cas, on révoque et on émet un nouveau certificat, après avoir tourné le reste des secrets — pas avant, pas à la place.

Même logique si vous trouvez une copie de `privkey.pem` ou un zip de « backup SSL » dans un dossier public. Les bots téléchargent ces archives. Les retirer et régénérer fait partie du nettoyage, comme pour un `.env` exposé.

Si le certificat a été remplacé par un autre, émis pour un nom voisin ou un prestataire inconnu, là aussi : on reprend la main sur le vhost, on émet le nôtre, on vérifie que plus personne d'autre n'a le jeton DNS ou le challenge HTTP.

• Panel ou racine web en écriture non contrôlée : régénérer après rotation.
• Fichier de clé ou zip SSL trouvé au public : régénérer.
• Certificat émis sans vous : reprendre le vhost, puis émettre.

Quand c'est un rituel qui retarde

Défacement, spam SEO, redirection mobile, page d'accueil remplacée : le certificat n'est pour rien. Passer l'après-midi à battre le challenge ACME pendant que `images.php` répond encore, c'est une journée offerte à l'indexation du spam.

Un certificat qui expire vraiment pendant l'incident est un autre sujet : les visiteurs voient un avertissement de date, distinct de Safe Browsing. On le renouvelle pour que le site soit joignable, pas pour « laver » quoi que ce soit. Voir certificat expiré et alerte Chrome.

Les hébergeurs proposent parfois « régénérer SSL » dans le même ticket que la suspension malware. Acceptez-le s'ils le font eux-mêmes, en une case. N'en faites pas votre chantier principal.

Clés, panel, et ce qui a pu être lu

Sur un mutualisé, la clé privée vit chez l'hébergeur. Un accès FTP classique ne la télécharge pas. Un accès panel, ou un fichier de backup du compte, si. Distinguez. Si seul wp-admin a été pris, régénérer Let's Encrypt ne ferme rien ; changer les clés AUTH et les mots de passe, si.

Sur un VPS, les chemins Let's Encrypt sont des fichiers comme les autres. Un shell root les lit. Là, la régénération (et la révocation) s'inscrit dans la rotation : mots de passe, clés SSH, secrets d'application, puis TLS.

Ne publiez pas la clé « pour que le prestataire installe le certif ». Un coffre, ou l'émission depuis le panel par le prestataire avec un compte révocable. Voir accès demandés par un prestataire.

HTTP encore ouvert, www et IPv6

Un HTTPS tout neuf sur `www` ne dit rien de `http://` ni du domaine nu. Les attaques et Googlebot visent parfois l'un, parfois l'autre. Après incident, testez les quatre combinaisons courantes (http/https, apex/www), plus IPv6 si l'hébergeur en annonce. Le détail est dans www, apex, IPv6 non nettoyés et HTTP encore ouvert.

Un renouvellement qui ne couvre que `www` alors que le vhost nu sert encore l'ancien DocumentRoot laisse une porte visuelle : « le cadenas marche » sur l'URL que vous tapez, pas sur celle du client.

Wildcard (`*.domaine.fr`) : utile si vous avez des sous-domaines légitimes. Dangereux si un wildcard DNS alimente un générateur. Ne « profitez pas » du renouvellement pour ouvrir un `*` dont vous n'avez pas besoin.

L'alerte Chrome n'est pas un certificat expiré

L'écran rouge Safe Browsing et l'écran « connexion non privée » (date, nom, autorité) n'ont pas le même bouton, pas le même délai, pas le même correctif. Confondre les deux est le rituel le plus coûteux : on s'occupe du TLS, on dépose un réexamen trop tôt, on recommence.

Le réexamen se dépose quand le contenu frauduleux a disparu, pas quand le cadenas brille. La page retrait blacklist Google fixe cet ordre.

Si les deux alertes coexistent (certificat pourri et phishing), traitez le phishing d'abord : chaque minute en 200 sur une fausse page bancaire pèse plus qu'un cadenas orange.

L'ordre : fermer, puis seulement le TLS

Copie, panel, mots de passe, coupure du générateur ou de l'URL de phishing, test visiteur. Ensuite, si l'une des raisons du second paragraphe s'applique : révoquer, émettre, vérifier la chaîne. Inverser, c'est polir la serrure d'une porte ouverte.

Un prestataire qui commence par « je m'occupe du SSL » sans ouvrir les fichiers vous vend un rituel. Relisez le devis.

Let's Encrypt est gratuit et automatique chez la plupart des hébergeurs français. Vous n'avez pas à acheter un certificat « plus sûr » pour sortir d'un piratage. Le prix ne lave pas un shell.

Après : ce qu'il faut vérifier une fois

Une fois le site propre : date d'expiration, noms couverts, redirection HTTP→HTTPS unique (pas de chaîne qui traverse un sous-domaine oublié), HSTS seulement si vous assumez les sous-domaines. Pas besoin d'en faire un projet.

Surveillez le renouvellement automatique : un cron ACME cassé se découvre le jour où les clients appellent. Ce n'est pas de la sécurité avancée, c'est de la continuité.

Si vous déléguez le dossier, dites si le panel a été pris. Nous saurons si la régénération fait partie de la clôture, ou si elle serait du théâtre.