Certificat SSL valide mais le navigateur affiche une erreur : cinq causes et comment vérifier chacune

Mis à jour le oct. 2026 · 12 min de lecture

Quand la date d'expiration est bonne et que les visiteurs voient quand même une alerte, le problème vient presque toujours de ce que le serveur envoie, pas du certificat acheté.

En bref. Un navigateur ne vérifie pas que la date d'expiration. Il vérifie aussi que le certificat remonte jusqu'à une autorité de confiance et qu'il couvre exactement le nom de la barre d'adresse. Un certificat encore valable peut échouer si le serveur n'envoie pas le certificat intermédiaire (chaîne incomplète), si le nom n'est pas dans le certificat (www, un sous-domaine, le domaine nu), si le serveur présente un autre certificat que celui installé, si un CDN sert son propre certificat alors que l'origine en a un que les navigateurs ne reconnaissent pas, ou si l'un des serveurs ou l'une des adresses IP derrière le nom sert encore un ancien certificat. Testez de l'extérieur avec openssl s_client -servername, puis refaites le test pour chaque adresse IP.

« Le certificat est valable jusqu'à l'an prochain » : c'est souvent vrai, et souvent hors sujet. Le fichier du certificat sur le serveur peut être parfait alors que les visiteurs reçoivent autre chose : une chaîne à laquelle il manque un maillon, un certificat par défaut, ou le certificat d'un serveur oublié. Ce guide passe en revue cinq causes courantes, avec la commande qui confirme chacune.

Ce que le navigateur vérifie vraiment

Quand un visiteur ouvre https://www.example.com, le navigateur reçoit un ou plusieurs certificats du serveur et vérifie notamment que :

1La chaîne mène à une racine de confiance. Le certificat du site est signé par une autorité intermédiaire, elle-même rattachée à une racine que le navigateur reconnaît. C'est au serveur d'envoyer les intermédiaires.
2Le nom correspond. www.example.com doit figurer dans la liste Subject Alternative Name (SAN) du certificat, tel quel ou via un wildcard.
3Les dates sont valables, selon l'horloge du visiteur.

Chrome signale ces échecs avec des codes distincts, définis dans le code source de Chromium : NET::ERR_CERT_AUTHORITY_INVALID quand il ne peut pas construire une chaîne de confiance, NET::ERR_CERT_COMMON_NAME_INVALID quand le nom ne correspond pas, et NET::ERR_CERT_DATE_INVALID pour les dates. Seul le dernier concerne l'expiration. Le code affiché sur la page d'alerte est votre premier indice.

Commencez chaque diagnostic par le certificat que le serveur envoie pour le nom, vu de l'extérieur :

host=www.example.com
openssl s_client -connect "$host:443" -servername "$host" -showcerts </dev/null 2>/dev/null \
  | grep -E '^ *[0-9]+ s:|^ *i:|Verify return code'
echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

La première commande liste les certificats envoyés et se termine par Verify return code: 0 (ok) quand la chaîne est bonne. La seconde affiche les dates et les noms couverts (OpenSSL 1.1.1 ou plus récent).

1. La chaîne est incomplète

Le serveur envoie le certificat du site mais pas le certificat intermédiaire qui le rattache à la racine. La documentation de nginx décrit exactement ce cas : le certificat du serveur doit être suivi des intermédiaires dans le même fichier. Avec Certbot, la documentation de Certbot indique d'utiliser fullchain.pem (le certificat du serveur d'abord, puis les intermédiaires) pour le ssl_certificate de nginx, pas cert.pem.

Pourquoi c'est trompeur : souvent, ça marche sur votre poste. nginx rappelle que les navigateurs gardent les certificats intermédiaires déjà reçus, si bien qu'un navigateur qui visite beaucoup de sites peut ne rien signaler. Firefox va plus loin et précharge les certificats intermédiaires connus de Mozilla, tandis que d'autres logiciels vont chercher l'intermédiaire manquant à l'adresse indiquée dans le certificat. Un téléphone neuf, un client d'API, le webhook d'un prestataire de paiement ou un outil de supervision peuvent ne rien faire de tout cela, et échouer.

Pour confirmer. Dans la sortie de la première commande, regardez ce qui est listé et la dernière ligne. Un seul certificat (0 s: uniquement) avec une erreur de vérification comme unable to verify the first certificate ou unable to get local issuer certificate signifie en général que l'intermédiaire manque.

Correction. Installez la chaîne complète fournie par l'autorité, certificat du site en premier, puis rechargez le serveur.

2. Le nom n'est pas couvert par le certificat

Le certificat est valable, mais pour un autre nom. Les cas fréquents :

www ou domaine nu. Un certificat pour example.com ne couvre pas www.example.com, et inversement.
Un wildcard couvre un seul niveau. La RFC 9525 précise qu'un wildcard ne peut être que l'étiquette complète la plus à gauche et ne correspond qu'à une seule étiquette : *.example.com couvre shop.example.com, ni example.com ni api.eu.example.com.
Un nom ajouté après coup. Un nouveau sous-domaine pointé vers un serveur dont le certificat a été émis avant sa création.
Le Common Name seul. Chrome n'accepte plus le Common Name en solution de repli depuis Chrome 58 (2017) : le nom doit être dans la liste SAN.

Pour confirmer. La ligne subjectAltName de la seconde commande liste tous les noms couverts. Si le nom de la barre d'adresse n'y est pas, c'est la cause. Chrome affiche NET::ERR_CERT_COMMON_NAME_INVALID.

Correction. Faites réémettre le certificat avec tous les noms sur lesquels le site répond, www et domaine nu compris si les deux servent.

3. Le serveur présente un autre certificat

Plusieurs sites partagent souvent une même adresse IP. Le navigateur annonce le nom voulu grâce au SNI (Server Name Indication) au début de la connexion TLS, et le serveur choisit le certificat correspondant. Quand aucun site ne correspond, le serveur se rabat sur son certificat par défaut. La documentation de nginx l'explique : sans correspondance, le navigateur reçoit le certificat du serveur par défaut, quel que soit le site demandé. Résultat fréquent : le certificat du domaine d'un autre client, ou un certificat auto-signé du panneau d'hébergement.

Le même symptôme apparaît après un renouvellement quand le nouveau certificat est bien sur le disque mais que le serveur web n'a jamais été rechargé : il présente encore l'ancien. Notre guide sur les échecs de renouvellement Let's Encrypt détaille ce piège.

Pour confirmer. Comparez le subject et le subjectAltName de ce que le serveur envoie avec ce que vous avez installé. Comparez aussi les dates : si le notAfter est plus ancien que votre dernier renouvellement, le serveur n'a jamais chargé le nouveau certificat.

Correction. Vérifiez que la configuration du site déclare le bon nom (par exemple server_name dans nginx) et pointe vers le bon certificat, puis rechargez. Si un nom pointe vers ce serveur par erreur, corrigez plutôt le DNS.

4. Le CDN sert un certificat, l'origine un autre

Avec un CDN ou un proxy inverse devant le site, il y a deux certificats : le certificat « edge » que les visiteurs reçoivent du CDN, et le certificat d'origine sur votre serveur, que seul le CDN voit. La documentation de Cloudflare décrit les deux. Ses certificats Origin CA ne chiffrent que le trafic entre Cloudflare et votre serveur d'origine, pas celui des navigateurs vers l'origine : si vous mettez Cloudflare en pause ou passez un enregistrement en « DNS uniquement », les visiteurs se connectent directement à l'origine et peuvent voir des erreurs de certificat non reconnu.

L'inverse arrive aussi. Le certificat edge est bon, mais le certificat d'origine expire ou ne correspond pas. En mode Full (strict) de Cloudflare, les visiteurs reçoivent alors l'erreur 526, que Cloudflare décrit comme l'impossibilité de valider le certificat de l'origine.

Pour confirmer. Testez le nom public normalement (c'est le edge), puis testez l'origine en vous connectant à son adresse IP avec le nom du site (voir la section suivante). Deux émetteurs différents dans les résultats, c'est normal ; un certificat d'origine que les navigateurs ne reconnaissent pas devient un problème le jour où le trafic contourne le CDN.

Correction. Gardez un certificat reconnu publiquement sur l'origine si l'enregistrement risque un jour de passer en « DNS uniquement », et surveillez l'expiration du certificat d'origine autant que celle du certificat edge.

5. Un ancien serveur ou une autre IP sert encore l'ancien certificat

Un nom peut pointer vers plusieurs adresses : deux IPv4 derrière un répartiteur de charge, une IPv6 configurée sur une autre machine, un serveur de secours resté dans le DNS après une migration. Chacune sert son propre certificat. Si l'une n'a pas été mise à jour, certains visiteurs voient une erreur et d'autres non, selon l'adresse qu'ils atteignent. C'est ainsi que « chez moi ça marche » et « le client voit une alerte » peuvent être vrais en même temps.

Pour confirmer. Listez les adresses, puis demandez à chacune le certificat du site :

host=www.example.com
for ip in $( (dig +short A "$host"; dig +short AAAA "$host") | grep -v '\.$' ); do
  case "$ip" in *:*) target="[$ip]:443" ;; *) target="$ip:443" ;; esac
  echo "== $ip"
  echo | openssl s_client -connect "$target" -servername "$host" 2>/dev/null \
    | openssl x509 -noout -enddate -fingerprint -sha256
done

Le grep écarte les noms CNAME que dig +short peut afficher avant les adresses. Toutes les adresses devraient renvoyer la même empreinte, ou au moins des dates valables. Avec curl, curl -v --resolve www.example.com:443:203.0.113.10 https://www.example.com/ force une adresse et affiche le certificat reçu.

Correction. Mettez à jour ou retirez le serveur oublié, et supprimez du DNS toute adresse qui n'appartient plus au site. Notre guide sur les sous-domaines orphelins traite des enregistrements DNS qui survivent aux serveurs vers lesquels ils pointent.

La checklist rapide

1Lisez le code d'erreur de la page d'alerte : autorité (chaîne), nom ou date.
2Lancez openssl s_client -servername sur le nom public et lisez Verify return code.
3Vérifiez que le nom de la barre d'adresse figure dans la liste subjectAltName.
4Comparez les dates et l'émetteur avec le certificat installé.
5Testez chaque adresse A et AAAA, et l'origine derrière le CDN.
6Corrigez, rechargez, et testez à nouveau de l'extérieur.

Comment surveiller

Les cinq causes ont un point commun : elles ne se voient que de l'extérieur, sur le certificat que le serveur envoie réellement. Un rappel fondé sur la date d'expiration notée dans un tableur n'en détecte aucune.

Lapsentry se connecte à chaque site et lit le certificat réellement servi. En plus de la date d'expiration et de l'émetteur, il signale les problèmes de chaîne et de nom, comme un intermédiaire manquant ou un certificat émis pour un autre nom, et permet de suivre www, shop, api ou n'importe quel sous-domaine séparément. Pour une origine derrière un CDN ou un serveur de secours précis, les commandes par adresse ci-dessus restent le moyen de vérifier.

Essayer gratuitement pendant 14 jours : sans carte bancaire.

Sources

nginx, Configuring HTTPS servers (chaînes de certificats, serveurs HTTPS par nom, SNI ; en anglais).
Certbot, User guide : where are my certificates? (fullchain.pem ; en anglais).
Mozilla Security Blog, Preloading Intermediate CA Certificates into Firefox, 13 novembre 2020 (en anglais).
IETF, RFC 9525 : Service Identity in TLS, section 6.3 (wildcards), et RFC 6066 (Server Name Indication).
Chrome for Developers, Deprecations and removals in Chrome 58 (correspondance sur le commonName ; en anglais).
Chromium, net_error_list.h (CERT_COMMON_NAME_INVALID, CERT_DATE_INVALID, CERT_AUTHORITY_INVALID).
Cloudflare, Cloudflare origin CA, Edge certificates et Error 526 (en anglais).

FAQ

Pourquoi le navigateur dit-il que le certificat n'est pas valide alors qu'il n'a pas expiré ?

Parce que l'expiration n'est qu'un des contrôles. Le navigateur vérifie aussi que le certificat remonte à une autorité de confiance et qu'il couvre exactement le nom de la barre d'adresse. Un certificat intermédiaire manquant ou un nom non couvert déclenchent tous deux une alerte sur un certificat encore dans ses dates.

Qu'est-ce qu'une chaîne de certificats incomplète ?

Le serveur envoie le certificat du site sans le certificat intermédiaire qui le rattache à une racine de confiance. Certains navigateurs comblent le manque grâce à un cache ou à une liste préchargée, d'autres non : c'est pourquoi l'erreur peut apparaître sur un appareil et pas sur un autre.

Un certificat wildcard couvre-t-il le domaine nu ?

Non. Un wildcard comme *.example.com correspond à une seule étiquette : il couvre shop.example.com, mais ni example.com ni api.eu.example.com. Ajoutez le domaine nu au certificat si le site l'utilise.

Pourquoi certains visiteurs voient-ils l'erreur et d'autres non ?

En général parce que le nom pointe vers plusieurs serveurs ou adresses IP et que l'un d'eux sert un certificat ancien ou erroné, ou parce que certains appareils savent compléter seuls une chaîne incomplète. Testez chaque adresse A et AAAA avec le nom du site.

Peut-on utiliser un certificat Cloudflare Origin CA sans le proxy Cloudflare ?

Pas pour les visiteurs. Cloudflare indique que les certificats Origin CA ne chiffrent que le trafic entre Cloudflare et votre origine. Si l'enregistrement passe en « DNS uniquement » ou si Cloudflare est en pause, les visiteurs peuvent voir des erreurs de certificat non reconnu.

Comment voir le certificat qu'un serveur envoie vraiment ?

Lancez openssl s_client avec l'option -servername réglée sur le nom du site, puis lisez le sujet, l'émetteur, les dates et le subjectAltName du certificat renvoyé. Recommencez pour chaque adresse IP si le nom en a plusieurs.

Que signifie NET::ERR_CERT_COMMON_NAME_INVALID ?

Que Chrome a reçu un certificat qui ne couvre pas le nom saisi. Vérifiez la liste subjectAltName du certificat : le nom exact, ou un wildcard correspondant, doit y figurer.

Autres guides