Le cadenas HTTPS est vert, Chrome dit « site dangereux »

Ce que le cadenas dit, mot pour mot

Le cadenas HTTPS est vert, Chrome dit « site dangereux » : les deux peuvent être vrais ensemble. HTTPS = le canal entre le navigateur et le serveur est chiffré, et le certificat relie (plus ou moins) le nom de domaine à une clé. Ça empêche un café wifi de lire le mot de passe en clair. Ça n’empêche pas votre serveur de servir un kit d’hameçonnage ou une redirection mobile.

Les autorités de certification ne valident pas votre moralité ni votre WordPress. Let’s Encrypt délivre un certificat à quiconque contrôle le DNS ou le vhost. L’attaquant qui a déjà le vhost obtient le cadenas aussi facilement que vous. Parfois plus vite : il lance certbot, vous, vous attendez l’agence.

Donc « on a un cadenas, on ne peut pas être piratés » est faux. « On a un cadenas, les clients peuvent saisir leur carte » est faux si le HTML du checkout est un skimmer. Le cadenas n’est pas le sujet de l’incident. Le contenu l’est.

• HTTPS : canal chiffré + identité du nom (idéalement).
• Safe Browsing : réputation / contenu vu par Google.
• Les deux listes ne se parlent pas en temps réel.

Ce que Chrome classe à côté

Safe Browsing : logiciels indésirables, hameçonnage, contenu trompeur. Listes mises à jour par crawl et signalements. L’interstitiel rouge ignore que votre certificat est valide. Il s’en moque. Voir site trompeur et retrait.

Un antivirus d’entreprise peut bloquer sans que Chrome soit rouge. Un Chrome rouge peut passer chez Firefox encore 6 heures. Trois horloges, encore. Délais.

Search Console « sécurité » n’est pas le cadenas non plus. Trois pastilles, trois traitements. Le renouvellement de certificat n’en lève aucune.

Un phishing avec cadenas : le cas d’école

Les kits bancaires modernes sont en HTTPS. Les utilisateurs ont appris « cadenas = safe ». Les kits en profitent. Si le kit est sur votre domaine, vos clients voient votre nom + un cadenas + un formulaire de carte. Le comble du légitime visuel. Coupez l’URL, pas le certificat. Phishing hébergé.

Un certificat « EV » à barre verte d’autrefois n’existe plus comme signal fort. Même les EV n’auditent pas votre `uploads/x.php`.

Expliquer ça dans la FAQ client évite le « mais enfin on a payé le SSL ». Vous avez payé un canal. Pas une police d’assurance contenu.

Certificat expiré vs alerte malware

Certificat expiré : warning NET::ERR_CERT_DATE_INVALID, cadenas barré, texte sur la confidentialité. Pas le mot « trompeur » / « dangereux » de Safe Browsing. Traitez avec un renew (ou un cron certbot cassé depuis 90 jours). Pas un cleaner.

Alerte malware : interstitiel rouge, « site dangereux », lien « détails ». Le certificat peut être parfait. Traitez le contenu, puis le réexamen. Voir aussi certificat expiré et alerte si les deux coïncident — ça arrive, ça brouille.

Un mix : site pirate + cert expiré. Deux tickets mentaux. Renew n’enlève pas le PHP. Nettoyer n’enlève pas le warning date. Faites les deux, dans n’importe quel ordre, mais sans croire qu’un règle l’autre.

Pourquoi on renouvelle Let’s Encrypt pour rien

Parce que c’est un bouton visible, et que « cadenas » et « confiance » sont collés dans la tête. On a vu des journées entières de forcer un renew, de changer de CDN pour « un meilleur SSL », pendant que `wp-core.php` servait encore. L’hébergeur, lui, scannait le PHP, pas le PEM.

Un renew peut même casser (challenge HTTP pendant une 500, DNS). Vous ajoutez une panne. Pendant une attaque, ne touchez au certificat que s’il est réellement expiré ou si vous changez d’IP après une migration propre.

Wildcard, www, apex : parfois un seul hostname a un cert valide. Ce n’est toujours pas Safe Browsing. C’est un SAN manquant. Autre ticket.

Ce qu’il faut traiter (spoiler : le HTML)

Ce que Googlebot et le visiteur anonyme téléchargent. Redirection, iframe, JS, page de login clone. Inspection Search Console, mobile, privée. Puis nettoyage, puis réexamen. Le PEM, on n’y touche pas.

HSTS, mixed content : sujets durs après coup, pas le jour de l’interstitiel. Un cadenas « attention » pour une image HTTP n’est pas « site dangereux ». Encore une confusion fréquente. Lisez le texte Chrome jusqu’au bout.

L’ordre incident : premiers gestes. Le SSL n’y figure pas, sauf expiration réelle qui empêche de travailler.

Expliquer ça à un client en une minute

« Le cadenas veut dire que le transport est chiffré, comme une enveloppe fermée. Google dit que le contenu de l’enveloppe est dangereux. On change le contenu, puis on demande à Google de relire. On ne change pas l’enveloppe. »

Évitez « le SSL est hacké » : ça n’existe presque pas dans ces dossiers. Évitez « c’est un faux positif de certificat ». Ce n’est pas le certificat.

Si le client exige un « meilleur certificat payant » : vous pouvez, après. Ça n’accélère pas Safe Browsing. Dites-le avant de vendre l’option.

HTTP encore ouvert : un autre sujet

Le site en HTTPS propre, l’attaquant qui sert encore le payload en HTTP sur le même vhost : certains visiteurs et certains bots tapent encore le port 80. Fermez ou redirigez 80→443 après nettoyage des deux. HTTP reste ouvert.

Un redirect 80→443 ne lave pas un PHP. Il unifie l’entrée. Utile en fin de chantier, pas comme unique geste le matin de l’alerte.

Vous pouvez déclarer avec une capture de l’interstitiel et du cadenas : les deux sur la même photo, c’est déjà le dossier pédagogique + technique.