Problème de certificat de sécurité d'un site web : solutions

Un message « problème avec le certificat de sécurité de ce site » veut dire que ton navigateur n’a pas pu vérifier l’identité du site : certificat expiré, émis pour un autre nom, chaîne de confiance incomplète ou connexion interceptée en route. Si tu es simple visiteur, ne saisis aucune donnée et fais les trois vérifications de la première partie (heure de l’appareil, réseau, antivirus). Si le site est le tien, le défaut est presque toujours sur le serveur ou chez l’hébergeur, et la suite de l’article le règle cas par cas, y compris l’état « SSL en attente ».

Deux publics tombent sur le même écran, et ils n’ont pas la même chose à faire. Le visiteur vérifie que le problème ne vient pas de chez lui, puis s’arrête là. Le propriétaire, lui, doit lire le code d’erreur exact et corriger le certificat, le DNS ou la configuration du serveur.

Les messages exacts selon le navigateur

Avant d’agir, relève le message mot pour mot. Voici ceux que les éditeurs documentent eux-mêmes :

• Chrome affiche « Votre connexion n’est pas privée », souvent accompagné d’un code comme NET::ERR_CERT_AUTHORITY_INVALID, ERR_CERT_COMMON_NAME_INVALID, NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM ou ERR_CERTIFICATE_TRANSPARENCY_REQUIRED, ou encore « Erreur de certificat SSL » (source : aide Google Chrome, messages d’erreur courants).
• Quand l’horloge de l’appareil est fausse, Chrome affiche plutôt « Votre horloge est en retard. », « Votre horloge est en avance. » ou NET::ERR_CERT_DATE_INVALID (même source).
• Microsoft documente l’avertissement « Il y a un problème au niveau du certificat de sécurité de ce site web », suivi de « Le certificat de sécurité présenté par ce site web ne provient pas d’une autorité de certification approuvée » (source : Microsoft Learn, échec de la validation du certificat de sécurité). C’est la formulation que beaucoup de gens tapent sous la forme « le certificat de sécurité de ce site web présente un problème ».

Le certificat SSL désigne le fichier qu’un site présente au navigateur pour prouver son identité et chiffrer l’échange. Le TLS (Transport Layer Security) désigne le protocole qui chiffre cet échange entre le navigateur et le serveur, et que l’usage appelle encore « SSL » (source : MDN, glossaire TLS).

Tu es visiteur : « certificat de sécurité invalide », que faire ?

Le défaut vient le plus souvent du site. Mais l’aide de Chrome liste plusieurs causes situées chez le visiteur, à écarter avant d’accuser le site (source : aide Google Chrome) :

1. L’heure de ton appareil. Si la date ou l’heure est fausse, le certificat paraît expiré ou pas encore valide. Corrige l’horloge, puis recharge la page.
2. Un Wi-Fi public (café, gare, aéroport). Ces réseaux demandent souvent de se connecter sur une page d’accueil. Chrome conseille d’ouvrir une adresse en http://, par exemple http://example.com, pour faire apparaître cette page.
3. Une extension du navigateur. Ouvre la page en navigation privée. Si elle s’affiche, désactive tes extensions une par une.
4. Le système. Mets à jour Windows ou macOS.
5. L’antivirus. Un antivirus qui fait de la « protection HTTPS » ou de l’« analyse HTTPS » peut provoquer l’erreur. Google propose de désactiver cette fonction pour tester, puis de la réactiver.
6. Un ordinateur de travail. Un proxy d’entreprise qui inspecte le trafic HTTPS déclenche NET::ERR_CERT_AUTHORITY_INVALID si son certificat manque sur le poste. C’est à l’administrateur informatique de régler ça.

Google déconseille d’installer soi-même un certificat pour faire disparaître l’alerte, et renvoie vers le propriétaire du site si l’erreur persiste (même source). En pratique : si le même site s’ouvre sans erreur sur ton téléphone en données mobiles, le problème est local. Sinon, il est sur le site, et seul son propriétaire peut le corriger. Dans ce cas, ne saisis ni mot de passe ni numéro de carte.

Tu es propriétaire : « SSL en attente » chez l’hébergeur

« SSL en attente » n’est pas une erreur du navigateur. C’est un état affiché dans l’interface de l’hébergeur ou de la plateforme : le certificat est demandé mais pas encore émis.

Chez Shopify par exemple, une fois le domaine connecté, l’émission du certificat TLS peut prendre jusqu’à 48 heures, et un statut « SSL pending » s’affiche pendant ce temps (source : aide Shopify, dépannage des domaines). La même page indique que toute modification DNS peut mettre jusqu’à 48 heures à se propager. Chez Cloudflare, un nouveau certificat passe par les états « Initializing », « Pending Validation », « Pending Issuance », « Pending Deployment », puis « Active » (source : Cloudflare, statuts des certificats).

Pourquoi l’attente ? L’autorité de certification doit d’abord vérifier que tu contrôles bien le domaine. Avec Let’s Encrypt, la méthode la plus courante (le défi HTTP-01) consiste à lire un fichier placé sous /.well-known/acme-challenge/ sur ton domaine, et elle ne fonctionne que sur le port 80 (source : Let’s Encrypt, types de challenges). Si ton domaine ne pointe pas encore vers le bon serveur, la vérification échoue et le certificat reste en attente.

Si l’état ne bouge pas, vérifie dans cet ordre :

• Les enregistrements DNS. Le domaine et le www doivent pointer vers le serveur de l’hébergeur. Selon ton bureau d’enregistrement, nos guides DNS t’aident à le faire proprement, par exemple pour configurer les DNS sur Cloudflare.
• Un enregistrement AAAA (IPv6) oublié. Shopify cite un AAAA qui ne pointe pas vers lui parmi les causes à contrôler (source Shopify ci-dessus).
• Un enregistrement CAA. Le CAA désigne un enregistrement DNS qui indique quelles autorités ont le droit d’émettre un certificat pour ton domaine. Si tu en as un, il doit autoriser l’autorité utilisée par ton hébergeur ; pour Let’s Encrypt, l’identifiant est letsencrypt.org (source : Let’s Encrypt, CAA).
• DNSSEC ou un proxy. Shopify cite DNSSEC activé et le proxy Cloudflare parmi les causes d’un certificat impossible à émettre chez lui (source Shopify ci-dessus).

Erreur SSL ou erreur de certificat : identifier le code exact

Côté propriétaire, chaque code après NET::ERR_CERT_ pointe vers un problème précis. Ouvre ton propre site dans Chrome et relève le code affiché sous le message :

Deux autres codes concernent la configuration TLS du serveur plutôt que le certificat. Pour ERR_SSL_VERSION_OR_CIPHER_MISMATCH, l’aide de Chrome conseille au propriétaire de configurer TLS 1.3 avec TLS_AES_128_GCM_SHA256, et de garder TLS 1.2 en parallèle pour les clients plus anciens (source : aide Google Chrome). L’ANSSI publie le référentiel français sur les versions de TLS et les suites cryptographiques à retenir (source : ANSSI, Recommandations de sécurité relatives à TLS).

Si le message précis est NET::ERR_CERT_DATE_INVALID et que l’horloge de l’appareil est juste, ton certificat est expiré : 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. Ne saute jamais cette étape : réémettre un certificat entier pour un simple souci de contenu mixte, c’est perdre du temps sur le mauvais chantier.

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é : il couvre plusieurs sous-domaines, qui tombent tous 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.

Certificat invalide sur le nom de domaine (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 (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, ouvre le détail du certificat depuis la barre d’adresse et cherche la liste des noms couverts (Subject Alternative Name). 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 incluant 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 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.

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). Microsoft documente d’ailleurs un cas où le serveur envoie un chemin que le poste du visiteur ne sait pas valider : l’avertissement s’affiche alors que le certificat du site est bon (source : Microsoft Learn).

Symptôme typique : le site fonctionne sur ton ordinateur mais casse pour une partie de tes visiteurs, selon l’appareil ou le système.

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.

Cadenas barré : éliminer le contenu mixte

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 signale une page partiellement non sécurisée, 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. Selon MDN, les navigateurs passent automatiquement en HTTPS les images, vidéos et sons, et bloquent les autres ressources, dont les scripts, les feuilles de style et les iframes (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 une bonne partie des cas d’un coup.
• Un guide complet existe pour ce point précis : corriger le contenu mixte sur WordPress.

Redirection HTTP → HTTPS et boucle de redirection

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 en mode « Flexible », Cloudflare interroge ton serveur en HTTP. Si ce serveur redirige tout le HTTP vers le HTTPS, la boucle est garantie. Cloudflare propose deux sorties : retirer la redirection côté serveur, ou passer en mode « Full » ou plus strict, ce qui demande un certificat sur le serveur (source : Cloudflare, ERR_TOO_MANY_REDIRECTS). 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.

Certificat wildcard et sous-domaines

Un certificat wildcard (*.exemple.com) couvre les sous-domaines d’un seul niveau en un seul certificat, pratique si tu as boutique.exemple.com, blog.exemple.com, app.exemple.com. La RFC 6125 donne l’exemple : *.example.com correspond à foo.example.com, mais ni à bar.foo.example.com ni à example.com (source : RFC 6125, IETF, section 6.4.3). Pense donc à inclure aussi le domaine nu dans le certificat.

Chez Let’s Encrypt, un wildcard ne s’obtient qu’avec le défi DNS-01 : le défi HTTP-01 ne peut pas l’émettre (source : Let’s Encrypt, types de challenges). Un hébergeur doit donc pouvoir écrire dans ta zone DNS pour le renouveler.

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 intéressant quand les sous-domaines se multiplient, avec un renouvellement centralisé et documenté.

Tableau récapitulatif

FAQ

Quand passer la main à un pro

Diagnostiquer un mauvais SAN ou du contenu mixte se fait vite 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.