Certificat SSL ou de sécurité invalide : réparer l'erreur

Le cadenas est cassé, et ton visiteur voit une page rouge

Un visiteur arrive sur ton site et Chrome lui affiche un avertissement en plein écran : “Votre connexion n’est pas privée”. Le message technique commence par NET::ERR_CERT_ suivi d’un code, COMMON_NAME_INVALID, AUTHORITY_INVALID, WEAK_SIGNATURE_ALGORITHM… Peu importe le libellé exact, l’effet est le même : plus personne ne clique “continuer quand même”, et ton trafic s’effondre en quelques heures.

Deux situations se cachent derrière le même écran, et elles ne se règlent pas au même endroit. Tu es visiteur et le message dit « Problème avec le certificat de sécurité de ce site » ou « Votre connexion n’est pas privée » : le défaut est sur le site que tu visites, pas chez toi, sauf si l’heure de ton appareil est fausse ou si tu es sur un Wi-Fi public qui intercepte les connexions. Tu es propriétaire du site : le certificat est absent, expiré, émis pour un autre nom, ou sa chaîne est incomplète, et les sections qui suivent règlent chaque cas. Un troisième cas fréquent est l’état « SSL en attente » affiché par l’hébergeur juste après une commande ou un changement de DNS : Let’s Encrypt doit d’abord vérifier que le domaine pointe bien vers le serveur, ce qui prend de quelques minutes à quelques heures selon la propagation.

Bonne nouvelle : ces erreurs sont presque toujours mécaniques, pas mystérieuses. Un certificat SSL répond à des règles précises (nom exact, chaîne de confiance complète, date de validité) et dès qu’une de ces règles casse, le navigateur bloque tout par sécurité. Ce n’est pas un bug aléatoire, c’est un contrôle qui fait exactement son travail.

Si le message précis est NET::ERR_CERT_DATE_INVALID, ton certificat est expiré et on a un guide dédié pour ça. Si c’est plutôt ERR_SSL_PROTOCOL_ERROR, le problème vient souvent de la configuration du protocole côté serveur, traité ici. Cet article couvre les autres cas : mauvais nom de domaine, chaîne incomplète, contenu mixte, redirection mal réglée et wildcard.

Pourquoi ça arrive : les causes les plus fréquentes

• Mauvais nom (SAN) : le certificat a été émis pour exemple.com mais le visiteur arrive sur www.exemple.com, ou un sous-domaine n’est pas couvert.
• Chaîne de certification incomplète : le certificat intermédiaire (entre ton certificat et l’autorité racine) n’a pas été installé côté serveur.
• Contenu mixte (mixed content) : la page est en HTTPS mais charge des images, scripts ou styles en HTTP.
• Redirection HTTP → HTTPS mal configurée : boucle, redirection partielle, ou absence totale de redirection.
• Certificat wildcard mal émis ou mal renouvelé : un seul sous-domaine change, mais tous tombent en même temps.
• Certificat auto-signé ou de test oublié en production après une mise en ligne rapide.
• Migration d’hébergeur ou de DNS récente qui n’a pas transféré le certificat au bon endroit.

1. Identifier le message exact avant de toucher à quoi que ce soit

Le TLS (Transport Layer Security) désigne le protocole qui chiffre l’échange entre le navigateur et le serveur, et que l’usage appelle encore « SSL » (source : MDN, glossaire TLS). Chaque code après NET::ERR_CERT_ pointe vers un problème précis. Clique sur “Avancé” dans le message d’erreur du navigateur pour lire le détail :

L’ANSSI publie le référentiel français sur les versions de TLS et les suites cryptographiques à retenir, utile pour trancher un WEAK_SIGNATURE_ALGORITHM (source : ANSSI, Recommandations de sécurité relatives à TLS). Ne saute jamais cette étape : réémettre un certificat entier pour un simple souci de mixed content, c’est perdre du temps sur le mauvais chantier.

2. Corriger un nom invalide (COMMON_NAME_INVALID)

Le SAN (Subject Alternative Name) désigne l’extension du certificat X.509 qui énumère les noms de domaine réellement couverts, et c’est elle que les navigateurs contrôlent en priorité (source : RFC 5280, IETF, 2008). Si ton certificat ne couvre que exemple.com et que ton site répond aussi sur www.exemple.com, le navigateur refuse la connexion sur la version non couverte.

Comment vérifier : dans le navigateur, clique sur le cadenas (ou son absence) → “Certificat” → onglet “Détails” → cherche le champ “Autre nom de l’objet”. Compare avec l’URL exacte tapée par tes visiteurs.

Comment réparer :

• Si tu utilises Let’s Encrypt via ton hébergeur (o2switch, Infomaniak, IONOS, Hostinger…), régénère le certificat en cochant explicitement www et tous les sous-domaines utilisés.
• Si le certificat vient de Cloudflare, vérifie le mode SSL/TLS et la couverture du certificat “Universal” dans le tableau de bord, voir aussi notre guide pour configurer les DNS sur Cloudflare si le domaine a été ajouté récemment.
• Si tu gères plusieurs environnements (staging, préprod), assure-toi qu’ils n’utilisent pas par erreur le certificat de production.

3. Réparer une chaîne de certification incomplète (AUTHORITY_INVALID)

Un certificat SSL n’est jamais seul : il s’appuie sur un ou plusieurs certificats intermédiaires qui font le lien avec l’autorité racine reconnue par les navigateurs. Valider un certificat consiste précisément à reconstruire ce chemin de certification jusqu’à une racine de confiance, chaque maillon signant le suivant (source : RFC 5280, IETF, 2008). Si seul le certificat final est installé sur le serveur, sans la chaîne intermédiaire, certains navigateurs ou anciens appareils mobiles refusent la connexion, même si le certificat lui-même est valide.

Symptôme typique : le site fonctionne sur ton ordinateur (le navigateur a mis le certificat intermédiaire en cache) mais casse pour une partie de tes visiteurs.

Comment réparer :

1. Récupère le fichier “certificat complet” (full chain) fourni par ton autorité de certification, pas seulement le certificat individuel.
2. Installe cette chaîne complète dans le panneau SSL de ton hébergeur, ou dans le fichier de configuration Nginx/Apache (ssl_certificate doit pointer vers le fichier concaténé, pas vers le certificat seul).
3. Teste avec un outil de vérification SSL en ligne, il signale explicitement une chaîne incomplète, contrairement au navigateur qui reste parfois silencieux.

Si tu viens de migrer d’hébergeur, ce point mérite une vérification systématique : notre checklist post-migration couvre ce cas précis.

4. Éliminer le contenu mixte (mixed content)

Le HTTPS protège toute la page, mais si une image, un script ou une feuille de style se charge encore en http://, le navigateur affiche un cadenas barré ou un avertissement partiel, même si le certificat lui-même est parfaitement valide.

Le contenu mixte désigne une page servie en HTTPS qui charge encore une partie de ses ressources en HTTP : les navigateurs bloquent aujourd’hui d’office les scripts et feuilles de style concernés (source : MDN, contenu mixte). Comment vérifier : ouvre la console développeur (F12) → onglet “Console” → cherche les lignes “Mixed Content” qui listent précisément les ressources fautives.

Comment réparer :

• Remplace les URLs en dur http:// par des URLs relatives ou en https:// dans le contenu, les widgets et le thème.
• Sur WordPress, une recherche-remplacement en base de données (via un plugin dédié ou en ligne de commande) règle souvent 90 % des cas d’un coup.
• Un guide complet existe pour ce point précis : corriger le contenu mixte sur WordPress.

5. Vérifier la redirection HTTP → HTTPS

Une redirection mal configurée peut créer deux symptômes opposés : soit le site reste accessible en HTTP (donc jamais sécurisé), soit il entre en boucle infinie entre HTTP et HTTPS (ERR_TOO_MANY_REDIRECTS).

Comment réparer :

• Vérifie la règle de redirection dans le .htaccess (Apache) ou la configuration serveur (Nginx) : elle doit rediriger une seule fois, sans repasser par une règle concurrente au niveau du CDN. Une redirection définitive se signale par un code 301, que le navigateur met en cache et rejoue ensuite sans redemander au serveur (source : MDN, 301 Moved Permanently).
• Si tu utilises Cloudflare, vérifie que le mode SSL/TLS n’est pas en conflit avec une redirection déjà en place côté serveur d’origine, c’est la cause la plus fréquente de boucle. Notre guide sur les redirections en boucle détaille la marche à suivre.
• Teste toujours en navigation privée pour éviter un cache de redirection périmé côté navigateur.

6. Gérer un certificat wildcard pour les sous-domaines

Un certificat wildcard (*.exemple.com) couvre tous les sous-domaines de premier niveau en un seul certificat, pratique si tu as boutique.exemple.com, blog.exemple.com, app.exemple.com. Mais il ne couvre pas les sous-domaines de second niveau (api.blog.exemple.com) et son renouvellement doit être synchronisé partout où il est utilisé.

Piège fréquent : un wildcard expiré ou mal renouvelé casse simultanément tous les sous-domaines, ce qui donne l’impression d’une panne générale alors qu’un seul fichier est en cause.

Recommandation : si tu gères peu de sous-domaines, des certificats individuels (souvent gratuits via Let’s Encrypt) sont plus simples à diagnostiquer un par un. Le wildcard devient pertinent à partir de 4-5 sous-domaines actifs, avec un process de renouvellement centralisé et documenté.

Tableau récapitulatif

FAQ

Quand passer la main à un pro

Diagnostiquer un mauvais SAN ou du contenu mixte se fait en quinze minutes avec les bons outils. Mais dès que le problème touche une chaîne de certification personnalisée, un wildcard partagé entre plusieurs environnements, ou une configuration Nginx/Apache que tu ne maîtrises pas, une mauvaise manipulation peut couper l’accès au site plusieurs heures. Si le certificat casse en pleine période de forte affluence, ou si tu ne comprends pas d’où vient l’erreur après avoir suivi ces étapes, fais réparer proprement plutôt que d’empiler des correctifs qui reviendront te hanter au prochain renouvellement.