Le site s’ouvre sur exemple.com et le navigateur bloque www.exemple.com. Le certificat est valide. Il est simplement délivré pour un nom, et le visiteur a tapé l’autre. HTTPS compare le nom demandé à la liste écrite dans le certificat, avant même d’afficher la page.
Ce que le navigateur compare
Le certificat a un nom commun et, surtout, des noms alternatifs (SAN). Si la liste contient exemple.com et pas www.exemple.com, la seconde adresse produit une erreur du type « le nom du certificat ne correspond pas ». Le cadenas de la première adresse ne s’étend pas à l’autre. Ce sont deux hôtes.
Le même symptôme apparaît avec un sous-domaine oublié : cdn.exemple.com, app.exemple.com. Chaque nom servi en HTTPS doit être dans le certificat, ou avoir le sien.
Corriger dans l’ordre
- Décider du nom canonique. Un seul doit rester dans la barre d’adresse, par exemple
exemple.com. - Émettre un certificat qui contient les deux noms, le temps que les anciens liens en
wwwfonctionnent. - Faire pointer le DNS des deux noms vers le même service. Un CNAME
wwwvers le sommet, ou deux enregistrements A identiques. - Rediriger en 301 le nom secondaire vers le canonique, une fois le certificat en place. La redirection HTTP ne peut pas s’exécuter tant que le navigateur refuse le TLS.
Inverser l’ordre — rediriger avant d’avoir le nom dans le certificat — laisse les visiteurs sur l’avertissement. Ils ne voient jamais la redirection.
Après le changement
On ouvre les deux URL. Le nom canonique affiche le site. L’autre bascule vers lui sans avertissement. On vérifie aussi les liens absolus dans les cartes du site, les e-mails et les balises Open Graph : un www resté dans une image de partage recommence l’erreur pour quiconque clique depuis un réseau social.
Chez Let’s Encrypt, le plus simple est d’ajouter les deux noms à la même demande. Chez Cloudflare ou Bunny, le certificat du nom proxifié doit lister les hôtes réellement publiés. Le détail du proxy est dans les articles Cloudflare et Bunny.net.
