ERR_CERT_AUTHORITY_INVALID : solutions Chrome, Edge, Android

Qu'est-ce que NET::ERR_CERT_AUTHORITY_INVALID ?

NET::ERR_CERT_AUTHORITY_INVALID signifie que votre navigateur ne fait pas confiance à l'émetteur du certificat du site. Chrome affiche « Votre connexion n'est pas privée » et, sous Paramètres avancés, indique : « Impossible de vérifier que ce serveur est bien example.com », car son certificat de sécurité n'est pas approuvé, ce qui « peut être dû à une mauvaise configuration ou à l'interception de votre connexion par un pirate informatique ». Chromium la répertorie comme l'erreur -202 (net_error_list.h).

La connexion a été établie, le serveur a envoyé son certificat, et le navigateur n'a pas pu le relier à une autorité de certification (AC) de confiance. Les notes de Chromium donnent trois raisons : un attaquant a substitué le certificat, le site utilise une AC que le navigateur ne connaît pas, ou le certificat est auto-signé.

Si un certificat cumule plusieurs problèmes, Chrome n'affiche que le plus grave, et un émetteur non approuvé l'emporte sur un nom erroné ou une date expirée. Un certificat auto-signé qui est aussi expiré affiche donc ce code, et non ERR_CERT_DATE_INVALID.

À quoi ressemble ERR_CERT_AUTHORITY_INVALID dans chaque navigateur

Chaque navigateur le formule à sa façon. Repérez ceci :

Comment fonctionne la chaîne de confiance SSL

Chaque certificat dépend d'une chaîne de confiance qui se termine par une autorité de certification racine déjà approuvée par le navigateur.

Lors de la connexion, le serveur envoie son propre certificat et un ou plusieurs certificats intermédiaires. Le navigateur vérifie que le certificat du site a été signé par l'intermédiaire, et celui-ci par une racine de sa liste. Chrome n'utilise plus la liste de votre système d'exploitation pour cela : il embarque la sienne, la Chrome Root Store, sous Windows et macOS depuis Chrome 108 et sous Android depuis Chrome 115 (pas sur iPhone ni iPad, où la liste d'Apple est obligatoire). Cette liste compte environ 100 racines et se met à jour en arrière-plan (Chrome Root Store). Sous Windows et macOS, Edge embarque la liste de Microsoft, Firefox celle de Mozilla, et tous font aussi confiance aux racines que vous ou votre entreprise ajoutez à l'ordinateur.

Si un maillon manque ou est inconnu, vous obtenez cette erreur (plus de détails dans qu'est-ce qu'une chaîne de certificats SSL). La chaîne comporte quatre parties :

• AC racine — auto-signée et intégrée à la liste de racines du navigateur
• AC intermédiaire — signée par la racine ; le serveur doit l'envoyer. Chrome télécharge un intermédiaire manquant à l'adresse indiquée dans le certificat, mais curl, les applications et beaucoup d'autres clients ne le peuvent pas
• Certificat du site — signé par l'intermédiaire, pour les noms de sa liste Subject Alternative Name
• Validation — le navigateur remonte du certificat du site jusqu'à une racine approuvée ; chaque signature doit être valide

Quelles sont les causes de NET::ERR_CERT_AUTHORITY_INVALID ?

L'endroit où vous la voyez réduit les causes possibles : un seul site signifie que le problème vient presque toujours du certificat de ce site. Tous les sites HTTPS signifie que c'est votre appareil ou votre réseau.

Solutions pour les visiteurs (côté client)

Si vous voyez l'erreur sur un site qui n'est pas le vôtre, essayez ces solutions dans l'ordre. Ne saisissez jamais de mot de passe ni de numéro de carte sur une page qui affiche cet avertissement.

Solution 1 : se connecter au Wi-Fi ou essayer un autre réseau

Les Wi-Fi d'hôtels, d'aéroports et de cafés détournent souvent vos premières connexions pour afficher une page de connexion, et un site HTTPS reçoit alors le certificat du réseau au lieu du sien. L'aide de Chrome indique que ces réseaux demandent de se connecter et que visiter une page en http:// ouvre la page de connexion ; Chrome peut aussi afficher une page pour se connecter au Wi-Fi à la place de cette erreur. Acceptez la connexion, puis rechargez.

Les réseaux d'entreprise et scolaires peuvent aussi inspecter le HTTPS avec leur propre certificat. Si l'erreur disparaît en données mobiles, demandez à l'équipe informatique du réseau : les appareils qu'elle gère ont normalement sa racine installée, le vôtre peut-être pas.

Solution 2 : vérifier l'analyse HTTPS de l'antivirus

Des antivirus comme Kaspersky, Avast, ESET et Bitdefender peuvent analyser le HTTPS en le déchiffrant avec leur propre certificat, puis en le rechiffrant. Si leur certificat racine n'est pas approuvé par votre navigateur, ou si la fonction se détraque après une mise à jour, tous les sites HTTPS affichent cette erreur d'un coup.

Pour tester, suspendez uniquement l'analyse HTTPS ou web et rechargez. Si l'erreur disparaît, réparez ou mettez à jour l'antivirus pour qu'il réinstalle son certificat, ou laissez l'analyse HTTPS désactivée.

Solution 3 : mettre à jour le navigateur et le système d'exploitation

Les navigateurs et les systèmes d'exploitation mettent régulièrement à jour leurs listes de racines (Chrome par des mises à jour de composants en arrière-plan), et les anciens systèmes ignorent les racines récentes. Les versions d'Android antérieures à 7.1.1, par exemple, n'approuvent pas ISRG Root X1 : les sites Let's Encrypt y échouent dans les navigateurs et applications qui s'appuient sur la liste du système.

Mettez d'abord le navigateur à jour : Chrome et Edge embarquent leurs propres listes de racines sous Windows et macOS, et Chrome le fait aussi sous Android depuis la version 115. Mettez ensuite à jour le système d'exploitation.

Solution 4 : vérifier la date et l'heure

Une horloge qui retarde ou avance de plusieurs mois ou années fait paraître les certificats pas encore valides ou expirés. Chrome affiche en général un avertissement distinct pour cela (« Votre horloge est en retard » ou ERR_CERT_DATE_INVALID), mais une horloge très fausse après une pile CMOS à plat ou une machine virtuelle restaurée peut aussi perturber la vérification de confiance. L'écarter prend dix secondes.

Windows : Paramètres → Heure et langue → Date et heure → activez Régler l'heure automatiquement. macOS : Réglages Système → Général → Date et heure → Régler la date et l'heure automatiquement. Android : Paramètres → Système → Date et heure → Définir l'heure automatiquement (Date et heure automatiques sur Android 16).

Solution 5 : essayer la navigation privée, puis redémarrer le navigateur

Une fenêtre de navigation privée (Ctrl+Maj+N dans Chrome et Edge, Ctrl+Maj+P pour une fenêtre privée dans Firefox) s'exécute sans vos extensions, sauf si vous les avez autorisées. Les extensions VPN et proxy peuvent faire passer votre trafic par un serveur qui présente son propre certificat ; si le site fonctionne en navigation privée, désactivez les extensions dans chrome://extensions et réactivez-les une par une.

Si le site vient de corriger son certificat, fermez toutes les fenêtres du navigateur et rouvrez-le, afin qu'il vérifie le nouveau certificat à zéro.

Solution 6 : sous Android

Android ajoute quelques vérifications propres :

• Réglez la date et l'heure automatiquement : Paramètres → Système → Date et heure.
• Mettez à jour Chrome et Android System WebView depuis le Play Store. Les applications qui affichent des pages web via WebView vérifient les certificats avec la liste de racines d'Android lui-même ; une ancienne version d'Android peut donc encore y échouer.
• Désactivez les applications de VPN, de blocage de publicités ou de « navigation sécurisée » qui filtrent le HTTPS ; elles affichent une clé ou une icône VPN dans la barre d'état.
• Connectez-vous au Wi-Fi : les réseaux publics affichent l'erreur tant que vous n'avez pas accepté leur page de connexion.
• Sous Android antérieur à 7.1.1, la racine de Let's Encrypt n'est pas dans la liste du système, donc les applications et navigateurs qui s'y fient ne peuvent pas vérifier ces sites. Un navigateur qui embarque sa propre liste de racines est le seul contournement.

Solutions pour les propriétaires de sites (côté serveur)

Si des visiteurs signalent NET::ERR_CERT_AUTHORITY_INVALID sur votre site, le certificat que vous servez ne remonte généralement pas à une racine publique. Vérifiez-le d'abord avec le SSL Checker, puis corrigez ce qu'il trouve. S'il affiche un autre certificat que celui que vous avez installé, confirmez avec le DNS Lookup que le domaine pointe vers le serveur attendu, et avec le HTTP Header Checker quel serveur répond.

Solution 1 : installer un certificat d'une autorité de certification reconnue

Un certificat auto-signé, ou issu de votre propre AC, ne sera jamais approuvé par les navigateurs des visiteurs : le signataire ne figure sur aucune liste de racines publique.

Installez plutôt un certificat d'une AC publiquement approuvée. Let's Encrypt délivre des certificats gratuits et automatisés approuvés par tous les grands navigateurs ; DigiCert, Sectigo et GlobalSign vendent des certificats avec validation de l'organisation et assistance.

# Install Let's Encrypt certificate with Certbot (Nginx)
sudo certbot --nginx -d example.com -d www.example.com

# Install Let's Encrypt certificate with Certbot (Apache)
sudo certbot --apache -d example.com -d www.example.com

# Verify the installed certificate
sudo certbot certificates

Solution 2 : envoyer la chaîne de certificats complète

Votre certificat peut être parfaitement valide alors que le serveur oublie d'envoyer l'intermédiaire. Chrome masque souvent le problème en téléchargeant lui-même l'intermédiaire manquant : le site fonctionne dans Chrome et échoue dans curl, les applications, les rappels de paiement et certains téléphones.

Passez le site dans le SSL Checker de DNS Robot : il montre la chaîne envoyée par votre serveur et si Mozilla, Chrome, Apple et Microsoft l'approuvent chacun. Ou vérifiez depuis un terminal :

# List each certificate the server sends (s: subject, i: issuer)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E ' [si]:'

# letsencrypt.org on 26 Oct 2026, a complete chain:
#  0 s:CN=letsencrypt.org
#    i:C=US, O=Let's Encrypt, CN=YE2
#  1 s:C=US, O=Let's Encrypt, CN=YE2
#    i:C=US, O=ISRG, CN=Root YE
#  2 s:C=US, O=ISRG, CN=Root YE
#    i:C=US, O=Internet Security Research Group, CN=ISRG Root X2
#  3 s:C=US, O=Internet Security Research Group, CN=ISRG Root X2
#    i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
# Only certificate 0 listed = the intermediate is missing.

# nginx: point ssl_certificate at the full chain, not the leaf alone
ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

# Apache 2.4.8+
SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

Solution 3 : renouveler un certificat expiré

Un certificat expiré d'une AC approuvée affiche ERR_CERT_DATE_INVALID, pas cette erreur. Vous ne verrez ERR_CERT_AUTHORITY_INVALID que si la chaîne n'est pas non plus approuvée, car Chrome signale le problème le plus grave. Dans les deux cas, vérifiez les dates et renouvelez :

# Check the certificate's dates
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates
# notBefore=Sep 30 12:00:00 2026 GMT
# notAfter=Dec 29 11:59:59 2026 GMT

# Renew now with Certbot, then reload the web server
sudo certbot renew --force-renewal
sudo systemctl reload nginx    # or apache2

Solution 4 : couvrir tous les noms utilisés par les visiteurs

Un certificat approuvé qui ne contient pas le nom de la barre d'adresse affiche plutôt ERR_CERT_COMMON_NAME_INVALID. Il ne devient cette erreur que si le certificat n'est pas non plus approuvé : corrigez d'abord la confiance, puis les noms.

Les navigateurs ne vérifient que la liste Subject Alternative Name, pas l'ancien Common Name. Un joker (*.example.com) couvre un niveau de sous-domaines mais pas example.com lui-même : listez donc les deux lors de la demande. Le SSL Checker montre la liste complète des noms d'un certificat.

Solution 5 : utiliser une AC privée ou d'entreprise

Les sites internes utilisent souvent une AC d'entreprise volontairement. Cela ne fonctionne que sur les appareils où le certificat racine de l'entreprise est installé, et Chrome et Edge font confiance à une racine ajoutée à Windows ou macOS (FAQ de la Chrome Root Store). Déployez-la avec une stratégie de groupe ou votre outil de gestion d'appareils, ou ajoutez-la à la main :

# Windows (Command Prompt as Administrator): trust for all users
certutil -addstore -f Root company-root.crt

# macOS: trust in the System keychain
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain company-root.crt

ERR_CERT_AUTHORITY_INVALID sur localhost (développeurs)

Un serveur HTTPS local avec un certificat auto-signé affiche cette erreur par conception. Rendez le certificat approuvé sur votre propre machine au lieu de passer outre :

• mkcert — mkcert -install crée une AC locale et l'ajoute au magasin de confiance de votre système (et à celui de Firefox, une fois certutil de NSS installé) ; ensuite mkcert localhost 127.0.0.1 ::1 produit un certificat que Chrome, Edge et Firefox approuvent
• Next.js — next dev --experimental-https crée pour vous un certificat localement approuvé avec mkcert
• Vite — @vitejs/plugin-basic-ssl produit un certificat non approuvé, vous verrez donc encore cette erreur ; pointez server.https vers les fichiers de mkcert
• Anciennes astuces qui ne marchent plus — l'option chrome://flags/#allow-insecure-localhost a expiré après Chrome 130 et n'est plus dans chrome://flags

# Install mkcert (macOS)
brew install mkcert
mkcert -install

# Generate localhost certificate
mkcert localhost 127.0.0.1 ::1
# Creates: localhost+2.pem and localhost+2-key.pem

# Use with Node.js
const https = require('https');
const fs = require('fs');
https.createServer({
  cert: fs.readFileSync('localhost+2.pem'),
  key: fs.readFileSync('localhost+2-key.pem')
}, app).listen(3000);

Erreurs SSL connexes

NET::ERR_CERT_AUTHORITY_INVALID n'est qu'une des erreurs de certificat derrière la page « Votre connexion n'est pas privée » de Chrome. Chaque code désigne une vérification différente :