Erreur de certificat SSL : comprendre et corriger les codes NET::ERR_CERT

TL;DR« Votre connexion n'est pas privée » : derrière ce message, le navigateur indique toujours un code précis. Nous avons testé cinq certificats défectueux pour montrer ce que chaque code signifie, comment le diagnostiquer en deux commandes et comment le corriger.

⚠️ Une erreur de certificat SSL, c'est quoi exactement ?#

Quand vous ouvrez une adresse en https://, le serveur présente un certificat : une pièce d'identité numérique qui prouve que vous parlez bien au site demandé. Avant d'afficher la page, le navigateur vérifie trois choses : que le certificat est dans sa période de validité, qu'il couvre le nom de domaine saisi, et qu'il a été émis par une autorité de certification qu'il reconnaît.

Si l'un de ces contrôles échoue, le navigateur bloque la page et affiche « Votre connexion n'est pas privée » (Chrome, Edge), « Attention : risque probable de sécurité » (Firefox) ou « Cette connexion n'est pas privée » (Safari). Le code affiché en petit sous le message dit lequel des trois contrôles a échoué. C'est lui qu'il faut lire en premier.

Ces erreurs sont différentes de ERR_SSL_PROTOCOL_ERROR et de ERR_SSL_VERSION_OR_CIPHER_MISMATCH : dans ces deux cas, la négociation du chiffrement échoue avant même que le certificat soit examiné. Ici, la connexion chiffrée s'établit, mais le navigateur refuse de faire confiance à l'identité présentée.

⚠️ Les codes d'erreur de certificat et leur signification#

🛠️ Notre test : cinq certificats défectueux, deux outils#

Pour vérifier ce que renvoie réellement chaque panne, nous avons interrogé le 13 octobre 2026 les serveurs de démonstration de badssl.com, un site public qui expose volontairement des certificats défectueux. Les commandes ont été lancées depuis l'un de nos serveurs (OpenSSL 3.5.7, curl 8.14.1). Voici les messages obtenus, tels quels.

Deux enseignements pratiques ressortent de ce test.

• openssl s_client ne vérifie pas le nom de domaine par défaut. Sur le certificat émis pour un autre domaine, il a répondu « ok ». Un diagnostic fait uniquement avec cette commande peut donc conclure à tort que tout va bien. Ajoutez l'option -verify_hostname, ou contrôlez avec curl.
• Trois pannes différentes donnent le même code dans le navigateur. Auto-signé, racine inconnue et chaîne incomplète affichent tous ERR_CERT_AUTHORITY_INVALID. Seule la ligne de commande permet de les distinguer, et la correction n'est pas la même.

📌 Diagnostiquer son propre site en deux commandes#

La première commande affiche l'émetteur, les dates de validité et les noms couverts par le certificat que sert réellement votre serveur :

openssl s_client -connect exemple.fr:443 -servername exemple.fr </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates -ext subjectAltName

La seconde vérifie la chaîne complète et le nom de domaine, et renvoie un message explicite en cas d'échec :

curl -sS -o /dev/null https://exemple.fr/ && echo "certificat accepté"

Lancée sur notre propre site, la première commande montre par exemple un certificat valable du 11 octobre 2026 au 9 janvier 2027, couvrant websource.fr et *.websource.fr. La ligne subjectAltName est celle qui compte pour l'erreur de nom : les navigateurs ne lisent plus le champ « Common Name », seulement cette liste.

🌐 Corriger chaque erreur côté serveur#

📌 NET::ERR_CERT_DATE_INVALID : le certificat a expiré#

Les certificats gratuits Let's Encrypt sont valables 90 jours. Ils ne posent aucun problème tant que le renouvellement automatique fonctionne, et expirent sans prévenir le jour où il casse : nom de domaine qui ne pointe plus vers le serveur, port 80 fermé, tâche planifiée désactivée après une migration.

certbot certificates        # liste les certificats et les jours restants
certbot renew --dry-run     # simule un renouvellement sans rien modifier

Sur le serveur qui héberge ce site, 33 certificats sont gérés de cette façon. Le jour du test, il leur restait entre 35 et 87 jours de validité : c'est le signe d'un renouvellement sain, puisque Certbot renouvelle par défaut quand il reste moins de 30 jours. Un certificat qui passe sous ce seuil sans être renouvelé est une alerte à traiter avant l'échéance, pas après.

📌 NET::ERR_CERT_COMMON_NAME_INVALID : le nom ne correspond pas#

Le cas le plus courant est le certificat émis pour exemple.fr alors que le visiteur arrive sur www.exemple.fr, ou l'inverse. Viennent ensuite le sous-domaine oublié, et le site servi par le mauvais hôte virtuel : le serveur ne trouve pas de configuration pour le nom demandé et présente le certificat d'un autre site. La correction consiste à réémettre le certificat avec tous les noms réellement utilisés, puis à vérifier que l'hôte virtuel HTTPS déclare bien ces noms.

📌 NET::ERR_CERT_AUTHORITY_INVALID : la chaîne de confiance est rompue#

Si le certificat est auto-signé, il faut le remplacer par un certificat émis par une autorité reconnue. Si la chaîne est incomplète, le certificat est bon mais le serveur n'envoie pas le certificat intermédiaire qui le relie à l'autorité. Avec Certbot, cela vient presque toujours du mauvais fichier dans la configuration :

# Apache
SSLCertificateFile    /etc/letsencrypt/live/exemple.fr/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/exemple.fr/privkey.pem

# nginx
ssl_certificate     /etc/letsencrypt/live/exemple.fr/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/exemple.fr/privkey.pem;

Le fichier à utiliser est fullchain.pem, qui contient le certificat et son intermédiaire, et non cert.pem, qui ne contient que le certificat. Cette panne est trompeuse : certains navigateurs savent retrouver seuls l'intermédiaire manquant et affichent le site normalement, alors que d'autres clients (applications mobiles, outils en ligne de commande, robots) échouent. Un site « qui marche chez moi » peut donc être cassé pour une partie des visiteurs.

Bon à savoir. Derrière un proxy comme Cloudflare, il y a deux certificats : celui que le proxy présente aux visiteurs, et celui de votre serveur d'origine. Notre site est dans ce cas, avec un certificat Google Trust Services côté visiteurs et un certificat Let's Encrypt sur le serveur. Si le second expire alors que le proxy est réglé en vérification stricte, le visiteur ne voit pas une erreur de certificat mais une erreur 526. Pensez à contrôler les deux.

⚠️ Et si l'erreur vient de l'appareil du visiteur ?#

Quand l'erreur apparaît sur de nombreux sites à la fois, ou sur un seul appareil, le serveur n'est pas en cause. Quatre vérifications suffisent en général.

1. La date et l'heure de l'appareil. Une horloge déréglée, souvent après une pile de carte mère vide, rend tous les certificats « expirés » ou « pas encore valides ».
2. Le réseau Wi-Fi public. Un portail de connexion (hôtel, gare, train) intercepte les pages tant que vous ne vous êtes pas identifié.
3. L'antivirus ou le proxy d'entreprise. Certains analysent le trafic HTTPS en présentant leur propre certificat, que le navigateur ne reconnaît pas toujours.
4. Un système trop ancien. Un appareil qui ne reçoit plus de mises à jour ne connaît pas les autorités récentes et finit par refuser des certificats parfaitement valides.

Le bouton « Continuer vers le site » ne doit servir que sur un site que vous administrez vous-même, en test. Ailleurs, l'avertissement signifie que personne ne peut garantir à qui vous envoyez vos données. Sur les sites qui activent la règle HSTS, le navigateur retire d'ailleurs ce bouton : il n'y a alors aucun contournement possible, et c'est voulu.

📌 Ce que nous faisons pour les sites que nous hébergeons#

Websource héberge un grand nombre de sites, et la gestion des certificats fait partie de ce que nous ne laissons pas à la charge du client. Sur nos offres d'hébergement web, le certificat SSL est inclus, installé dès que le nom de domaine pointe vers l'hébergement, puis renouvelé automatiquement. Nous accompagnons nos clients dès la commande : nous indiquons quoi modifier chez le gestionnaire du nom de domaine, et si le site est déjà en ligne ailleurs, sa migration est offerte avec les offres Premium et Advanced, et réalisée sur devis avec l'offre Standard.

Si votre site affiche pour la première fois l'avertissement « non sécurisé » parce qu'il n'a pas encore de certificat, le guide passer son site en HTTPS reprend la mise en place depuis le début.

❓ Questions fréquentes#

📌 Que signifie NET::ERR_CERT_DATE_INVALID ?#

Le certificat du site n'est pas dans sa période de validité : il a expiré, il n'est pas encore valide, ou l'horloge de votre appareil est fausse. Si l'erreur apparaît sur de nombreux sites, vérifiez d'abord la date et l'heure de l'appareil.

📌 Pourquoi mon site fonctionne-t-il dans mon navigateur mais pas sur d'autres appareils ?#

C'est le symptôme typique d'une chaîne de certificats incomplète. Certains navigateurs retrouvent seuls le certificat intermédiaire manquant, d'autres clients non. Faites servir par le serveur le fichier contenant la chaîne complète (fullchain.pem avec Certbot).

📌 Peut-on ignorer l'avertissement et continuer vers le site ?#

Seulement sur un site que vous administrez vous-même, en test. Ailleurs, l'avertissement signifie que l'identité du serveur n'est pas garantie. Les sites qui activent HSTS ne proposent d'ailleurs aucun contournement.

📌 Combien de temps un certificat Let's Encrypt est-il valable ?#

90 jours. Le renouvellement est prévu pour être automatique : Certbot renouvelle par défaut quand il reste moins de 30 jours de validité.

📌 Quelle différence avec ERR_SSL_PROTOCOL_ERROR ?#

ERR_SSL_PROTOCOL_ERROR survient pendant la négociation du chiffrement, avant l'examen du certificat. Les erreurs NET::ERR_CERT apparaissent ensuite : la connexion chiffrée s'établit, mais le certificat présenté est refusé.

Article publié le 18/10/2026 sous la signature de Jonathan Gutierrez, rédigé à partir des sources citées ci-dessus, puis relu avant publication. Une information vous semble inexacte ou datée ? Signalez-le nous, nous corrigeons.