NET::ERR_CERT_AUTHORITY_INVALID : signification et solutions

err_cert_authority_invalid signifie que votre navigateur ne parvient pas à construire une chaîne valide entre le certificat du site web et une autorité de certification racine à laquelle il fait confiance. Le message net::err_cert_authority_invalid signale un échec de confiance, et non la preuve que le site est malveillant.

Commencez par vérifier si un seul site échoue ou si plusieurs sites sans rapport échouent. Suivez ensuite la piste correspondante ci-dessous : les visiteurs doivent isoler l’appareil ou le réseau, les propriétaires doivent inspecter la chaîne de certificats déployée, et les développeurs doivent configurer une confiance explicite pour leur autorité de certification locale ou interne.

L’essentiel

• err_cert_authority_invalid signifie que le client ne peut pas établir de chaîne de certificats jusqu’à une autorité de confiance.
• Un certificat intermédiaire manquant peut empêcher la validation de la chaîne de certificats.
• Une expiration ou une incohérence de nom d’hôte est un problème distinct d’une autorité de certification non fiable.
• Un échec qui n’apparaît que derrière un proxy ne prouve pas, à lui seul, une interception TLS.
• Installer une autorité de certification de développement ne configure pas le serveur de développement pour qu’il utilise son certificat.
• Désactiver la vérification des certificats supprime un contrôle essentiel de l’identité du serveur.

Que signifie err_cert_authority_invalid ?

Le navigateur a reçu un certificat mais n’a pas pu établir la confiance envers l’autorité qui l’a émis. Le chiffrement seul ne peut pas établir que le serveur est bien la destination voulue.

Une chaîne typique va du certificat feuille du site web à une racine de confiance, en passant par des certificats intermédiaires. Le serveur fournit la feuille et les intermédiaires nécessaires ; le client a besoin d’une ancre de confiance acceptable. Une feuille autosignée non fiable, un intermédiaire indisponible ou une autorité de certification privée inconnue peuvent faire échouer ce processus.

Chromium distingue les échecs liés à l’autorité, à la date et au nom d’hôte dans ses définitions des erreurs réseau. Diagnostiquez le code exact avant de modifier des paramètres.

Quelles sont les causes de err_cert_authority_invalid ?

Vérifiez l’ancre de confiance, la chaîne envoyée par le serveur et une éventuelle substitution de certificat. Utilisez cette vérification de la confiance en 3 étapes pour distinguer ces causes.

• La racine est-elle de confiance ? Une autorité de certification privée ou un certificat de développement autosigné peut être inconnu de ce client.
• Le serveur fournit-il les intermédiaires nécessaires ? Une feuille valide seule peut être insuffisante. La documentation de DigiCert sur les chaînes explique le rôle de l’intermédiaire.
• Quelque chose re-signe-t-il le trafic ? Un service d’inspection autorisé ou un outil de sécurité local peut présenter un certificat de remplacement dont l’autorité de certification est absente de la configuration de confiance du client.

L’interception est une modification de la connexion, et non un maillon supplémentaire de la chaîne de certificats. Ces erreurs voisines demandent des correctifs différents, d’après les définitions de Chromium :

Comment corriger l’erreur en tant que visiteur ?

Comparez la connexion avant de modifier les paramètres de confiance. Si un site échoue sur des appareils et des réseaux indépendants, signalez-le à son propriétaire.

• Vérifiez quand même l’horloge. Corrigez la date, l’heure et le fuseau horaire, mais les problèmes d’horloge relèvent généralement de DATE_INVALID.
• Essayez un autre réseau de confiance. Comparez une connexion haut débit domestique et les données mobiles. Sur un Wi-Fi public, terminez la procédure de connexion prévue par le réseau.
• Essayez une fenêtre de navigation privée. Si le résultat change, examinez les extensions et la configuration du navigateur.
• Mettez à jour le navigateur et le système d’exploitation. Redémarrez et réessayez après les mises à jour prises en charge.
• Examinez l’analyse HTTPS. Sur un appareil que vous gérez vous-même, testez temporairement avec cette fonction désactivée, puis réactivez-la. Cherchez une réparation prise en charge si elle a causé l’échec.

Ces étapes d’isolation sont conformes aux recommandations de Google sur les erreurs de certificat. Sur du matériel géré, demandez l’avis du service informatique avant de modifier un logiciel de sécurité.

Ne poursuivez pas vers des pages bancaires, de connexion ou de paiement tant qu’un avertissement de certificat reste non résolu. Pour l’avertissement plus général, consultez notre guide sur l’avertissement de connexion non privée.

Pourquoi l’erreur apparaît-elle sur TOUS les sites ?

Des échecs sur des sites sans rapport entre eux orientent vers un problème partagé d’appareil, de magasin de confiance ou de réseau. Ils sont moins cohérents avec l’hypothèse que chaque site déploie indépendamment un certificat défectueux.

• Un site, plusieurs appareils : examinez la chaîne du site ou un chemin réseau commun.
• Plusieurs sites, un appareil : examinez la confiance locale, les logiciels de sécurité et les paramètres gérés.
• Un navigateur ou une application : comparez sa configuration de certificats avec celle d’un client qui fonctionne.
• Plusieurs appareils, un réseau : examinez la passerelle, le portail captif ou le service d’inspection.
• Fonctionne sur un autre réseau : comparez le routage, le DNS et les certificats présentés sur chaque chemin.

Synchronisez l’horloge, inspectez l’émetteur et notez quelles comparaisons ont changé le résultat. Une organisation inattendue qui apparaît comme émetteur sur des domaines sans rapport est un indice utile, mais pas une preuve suffisante d’une inspection justifiée. Transmettez au service informatique les URL concernées, les erreurs exactes et les détails de l’émetteur.

Gardez le vidage du DNS et la réinitialisation du navigateur pour la fin. Un vidage du DNS ne peut aider qu’en cas de résolution obsolète ; il ne peut pas installer une ancre de confiance manquante. Une réinitialisation ne répare pas la chaîne de certificats du serveur distant. Si la connexion échoue avant l’échange de certificats, utilisez le guide de dépannage distinct sur le proxy qui ne répond pas.

Comment les propriétaires de sites réparent-ils la chaîne de certificats ?

Servez le bon certificat feuille et les intermédiaires requis depuis chaque point de terminaison TLS. Remplacez un certificat de production autosigné non fiable par un certificat adapté à vos visiteurs.

Vérifiez séparément le nom d’hôte réel, le load balancer et l’origine. DigiCert recommande d’installer les intermédiaires manquants en cas d’erreur de chaîne incomplète.

Remplacez example.com ci-dessous par votre nom d’hôte. OpenSSL documente ces options de vérification :

openssl s_client -connect example.com:443 \
  -servername example.com -verify_hostname example.com \
  -verify_return_error -showcerts </dev/null

-showcerts affiche ce que le serveur a envoyé ; cela n’établit pas une chaîne vérifiée. -verify_return_error fait avorter la connexion en cas d’échec de vérification, tandis que les options de nom d’hôte sélectionnent et contrôlent l’hôte visé. Les résultats dépendent de la configuration de confiance locale. Consultez la documentation OpenSSL de s_client.

Pour un déploiement Let’s Encrypt existant géré avec Certbot, testez le renouvellement avec la simulation documentée :

certbot renew --dry-run

Un test de renouvellement Certbot réussi ne prouve pas que la production sert les fichiers renouvelés. Vérifiez la chaîne déployée après le renouvellement et le rechargement, et surveillez l’expiration du certificat telle que les clients la voient.

Exception Cloudflare : les certificats Origin CA ne sont pas approuvés par les navigateurs. Désactiver le proxy, mettre Cloudflare en pause ou accéder directement à l’origine peut faire apparaître cette erreur. Rétablissez la configuration de proxy prévue ou installez un certificat d’origine approuvé publiquement pour l’accès direct. Le dépannage Origin CA de Cloudflare documente cette distinction et la compatibilité avec le mode Full (strict).

Comment créer un certificat localhost de confiance ?

Créez une autorité de certification de développement, faites-lui confiance sur la machine de développement, puis configurez le serveur avec un certificat couvrant les noms que vous utilisez réellement. Faire confiance à l’autorité de certification seule ne configure pas HTTPS.

Le README de mkcert documente ces options d’installation. N’exécutez que l’option correspondant à votre système :

# macOS with Homebrew
brew install mkcert

# Windows with Chocolatey
choco install mkcert

# Debian/Ubuntu prerequisite
sudo apt install libnss3-tools
# Then install the appropriate Linux binary from mkcert's official releases.

Après l’installation, générez des fichiers explicitement nommés :

mkcert -install
mkcert -cert-file localhost.pem -key-file localhost-key.pem \
  localhost 127.0.0.1 ::1 app.test

Pour app.test, ajoutez 127.0.0.1 app.test au fichier hosts de votre système d’exploitation. Le nom d’hôte de l’URL doit correspondre à un nom alternatif du sujet (SAN) du certificat. Ne partagez jamais rootCA-key.pem ; gardez les clés privées générées hors du contrôle de version.

Pour un projet Next.js existant, la CLI de Next.js accepte un certificat et une clé de développement personnalisés :

npx next dev --experimental-https \
  --experimental-https-key ./localhost-key.pem \
  --experimental-https-cert ./localhost.pem

Pour un projet Vite existant, intégrez ceci dans vite.config.js. La configuration server.https de Vite accepte les options du serveur HTTPS :

import { defineConfig } from 'vite';
import { readFileSync } from 'node:fs';

export default defineConfig({
  server: {
    https: {
      key: readFileSync('./localhost-key.pem'),
      cert: readFileSync('./localhost.pem'),
    },
  },
});

Les clients peuvent nécessiter une configuration explicite de l’autorité de certification. Les options documentées suivantes préservent la vérification : NODE_EXTRA_CA_CERTS de Node, le paramètre verify de Requests et l’option –cacert de curl.

# Run in a POSIX shell; replace app.js with your Node entry point.
NODE_EXTRA_CA_CERTS="$(mkcert -CAROOT)/rootCA.pem" node app.js
curl --cacert "$(mkcert -CAROOT)/rootCA.pem" https://localhost:3000/

import subprocess
from pathlib import Path
import requests

ca_dir = subprocess.check_output(['mkcert', '-CAROOT'], text=True).strip()
response = requests.get(
    'https://localhost:3000/',
    verify=str(Path(ca_dir) / 'rootCA.pem'),
    timeout=10,
)
print(response.status_code)

Utilisez le port que votre serveur indique réellement. N’utilisez jamais verify=False en production : cela supprime l’authentification du certificat et crée un risque d’interception.

Pourquoi cette erreur apparaît-elle derrière un proxy d’entreprise ou un VPN ?

Un échec limité au proxy suggère un problème dépendant du chemin, mais ne prouve pas une interception. Le DNS, le routage et le point de terminaison de destination peuvent aussi différer.

Un tunnel HTTP CONNECT transmet les octets une fois établi, comme le spécifie la RFC 9110. Le TLS peut rester établi entre le client et la destination. Un intermédiaire qui inspecte le trafic, lui, interrompt le TLS et présente un autre certificat.

Pour une inspection autorisée, obtenez le certificat de l’autorité de certification de l’organisation par des canaux informatiques vérifiés. Demandez aux administrateurs de confirmer quel magasin l’application en échec utilise : la confiance du navigateur, les autorités de certification racines de confiance de Windows, ou un bundle d’exécution configuré séparément. Ne partez pas du principe qu’une réparation du navigateur corrige aussi un client Python ou Java.

Microsoft documente la distribution de certificats par stratégie de groupe vers le magasin de certificats Windows choisi. Le déploiement doit être géré par le service informatique ; les exclusions de proxy doivent respecter la politique de l’organisation.

Pour la configuration de la connexion, consultez l’utilisation de curl avec un proxy. Pour la différence de routage, consultez proxy ou VPN. DataImpulse fournit une infrastructure de proxies, et non un VPN, une API de scraping ni un unblocker géré.

Que montre notre propre test ?

Nous avons testé les points de terminaison de badssl.com avec cinq clients le 15 octobre 2026. Chaque type d’échec a produit sa propre chaîne d’erreur, ce qui explique l’importance du code exact. Il s’agit d’un instantané, pas d’un benchmark.

Méthode et échantillon : quatre points de terminaison badssl.com testés avec cinq clients, soit 20 résultats client-point de terminaison enregistrés, plus trois comparaisons de certificats en connexion directe et via proxy, et un échec de curl via proxy. Le tableau résume les deux points de terminaison d’erreur de confiance. Ce sont des chaînes observées, pas des garanties universelles sur les produits.

Via un proxy CONNECT DataImpulse, l’empreinte SHA-256 du certificat était identique à celle de la connexion directe pour untrusted-root.badssl.com et dataimpulse.com : le tunnel a transmis le certificat d’origine sans le modifier, et curl via le proxy a échoué avec la même erreur de racine non fiable que sans proxy.

Pour www.google.com, les empreintes différaient et les noms communs de l’émetteur sont passés de WR2 à WE2 ; les deux indiquaient Google Trust Services. Les grands CDN comme Google servent des certificats différents selon les serveurs périphériques et les régions, de sorte qu’une comparaison d’empreintes de feuille n’a de sens que sur les sites à certificat unique. Un simple libellé d’émetteur ne peut pas authentifier une connexion, et ces observations n’établissent pas de garantie universelle d’absence d’interception.

Quels paramètres de confiance de la plateforme comptent ?

Vérifiez la configuration de confiance utilisée par l’application en échec. Un certificat installé pour un client peut ne pas résoudre l’erreur d’un autre client.

Est-il sûr de continuer, et comment vérifier d’abord le certificat ?

N’envisagez une exception que pour un point de terminaison de développement maîtrisé dont vous avez vérifié l’identité de manière indépendante. Un avertissement inexpliqué sur un site public est une raison de s’arrêter.

Chrome documente le chemin DevTools, Confidentialité et sécurité, Sécurité, Vue d’ensemble, Afficher le certificat pour inspecter un certificat. Utilisez ses indications sur le panneau de sécurité pour consulter les détails disponibles du certificat. Si la page bloquée ne les expose pas, demandez au propriétaire ou au service informatique d’inspecter la connexion.

Vérifiez le nom d’hôte, la période de validité et l’émetteur, puis comparez l’empreinte du certificat ou de l’autorité de certification par un canal fiable. Reconnaître le nom d’un émetteur ne suffit pas.

Questions fréquentes

Besoin de comparer connexions via proxy et connexions directes ?

Si votre flux de travail nécessite un autre chemin réseau, découvrez les proxies residentiels DataImpulse. Gardez la vérification des certificats activée sur les deux chemins : un proxy peut aider à comparer le comportement des connexions, mais il ne peut pas réparer une chaîne de certificats défectueuse.

Dernière mise à jour : 15 octobre 2026.