Comment corriger l’erreur NET::ERR_CERT_AUTHORITY_INVALID

NET::ERR_CERT_AUTHORITY_INVALID est une erreur de handshake TLS au niveau du navigateur qui se produit lorsque le certificat présenté par un serveur web ne peut pas être retracé jusqu’à une autorité de certification (CA) racine approuvée par le magasin de confiance intégré du navigateur. Le navigateur met fin à la connexion avant tout échange de données, affichant cette erreur pour prévenir l’exposition aux attaques de type man-in-the-middle (MITM), l’interception de données ou le trafic provenant d’un serveur usurpé.

Il ne s’agit pas d’un simple avertissement cosmétique. C’est un échec de vérification cryptographique critique. Le navigateur a inspecté la chaîne de certificats, tenté de valider chaque maillon jusqu’à une racine de confiance, et a constaté que la chaîne était brisée, absente ou cryptographiquement invalide. Comprendre exactement où cette chaîne se rompt fait la différence entre une correction en cinq minutes et des heures de mauvais diagnostic.

Ce qui déclenche réellement cette erreur

La plupart des documentations listent des causes superficielles. La réalité est plus nuancée, et chaque cause racine nécessite un chemin de remédiation différent.

Certificats auto-signés

Un certificat auto-signé est un certificat dans lequel l’émetteur et le sujet sont identiques — le serveur a signé son propre certificat plutôt que de faire appel à une CA de confiance. Ils sont standard dans les environnements de développement local, les serveurs de staging internes et les infrastructures privées. Aucun magasin de confiance de navigateur public ne les reconnaît, donc la validation de la chaîne échoue immédiatement.

Nuance importante : Même si vous ajoutez un certificat auto-signé au magasin de confiance de votre OS, certains navigateurs (notamment Chrome sur certaines plateformes) utilisent leur propre magasin de certificats et le rejetteront quand même, sauf configuration explicite.

Certificat SSL/TLS expiré

Chaque certificat contient un champ `notBefore` et `notAfter` encodé dans sa structure X.509. Une fois que l’horloge système dépasse le timestamp `notAfter`, le certificat est cryptographiquement invalide, quelle que soit la manière dont il a été émis. Les navigateurs appliquent cette règle strictement.

Cas particulier : Si l’horloge de votre serveur dérive significativement en avance, un certificat techniquement encore valide peut sembler expiré au serveur lui-même lors de la négociation du handshake TLS, provoquant cette erreur côté serveur plutôt que côté client.

Chaîne de certificats incomplète (CA intermédiaire manquante)

C’est la cause la plus fréquemment mal diagnostiquée dans les environnements de production. Une CA racine de confiance ne signe pas directement les certificats d’entité finale. Elle signe des CA intermédiaires, qui signent ensuite votre certificat. Lorsque vous installez un certificat SSL sur un serveur, vous devez installer la chaîne complète : votre certificat d’entité finale plus tous les certificats intermédiaires concaténés dans l’ordre.

Si l’intermédiaire est absent de la réponse TLS du serveur, la plupart des navigateurs ne peuvent pas compléter le parcours de la chaîne jusqu’à une racine de confiance. Firefox est un peu plus indulgent à cet égard car il met en cache les intermédiaires des sessions précédentes (récupération AIA), mais Chrome et Edge échoueront catégoriquement.

Comment vérifier : Exécutez `openssl s_client -connect yourdomain.com:443 -showcerts` et vérifiez si la chaîne complète est retournée.

Nom commun ou SAN du certificat non concordant

Si un certificat a été émis pour `www.example.com` mais que l’utilisateur accède à `example.com` (ou un sous-domaine non couvert par un wildcard), le navigateur générera une erreur connexe mais distincte. Cependant, dans certaines configurations, cela se manifeste comme une erreur d’autorité invalide plutôt qu’une erreur de non-concordance de nom, notamment avec les anciens formats de certificats dépourvus de Subject Alternative Names (SANs).

Décalage d’horloge côté client

Les certificats TLS sont limités dans le temps. Si l’horloge de la machine cliente est réglée sur une date antérieure au champ `notBefore` du certificat ou postérieure à son champ `notAfter`, le navigateur le rejettera. Cela est extrêmement courant sur les machines virtuelles, les serveurs nouvellement provisionnés ou les machines qui ont été éteintes pendant de longues périodes sans synchronisation NTP.

Inspection SSL par des logiciels de sécurité

Les pare-feux d’entreprise, les suites de sécurité des terminaux et certains antivirus effectuent une inspection SSL/TLS (également appelée interception HTTPS). Ils terminent la connexion TLS au niveau de l’appliance de sécurité, inspectent le texte en clair, puis le rechiffrent à l’aide d’un certificat généré dynamiquement signé par la propre CA de l’appliance. Si cette CA d’appliance n’est pas dans le magasin de confiance du navigateur, chaque site HTTPS déclenchera cette erreur.

Magasin de certificats racine obsolète

Sur les anciens systèmes d’exploitation (Windows 7 sans mises à jour, distributions Linux héritées), le bundle CA racine du système peut ne pas inclure les nouveaux certificats racine. L’ISRG Root X1 de Let’s Encrypt, par exemple, a provoqué des erreurs généralisées sur Android 7 et versions antérieures et sur les systèmes Windows non patchés lorsque la signature croisée DST Root CA X3 a expiré en septembre 2021.

Comparaison des causes racines

Corrections étape par étape

Étape 1 : Synchroniser la date et l’heure système

C’est la correction la plus rapide lorsque l’erreur apparaît soudainement sur une machine qui fonctionnait auparavant.

Windows :

1. Ouvrez Paramètres > Heure et langue > Date et heure.
2. Activez Définir l’heure automatiquement et Définir le fuseau horaire automatiquement.
3. Cliquez sur Synchroniser maintenant sous « Synchroniser votre horloge ».
4. Si la synchronisation automatique échoue, ouvrez l’Invite de commandes en tant qu’Administrateur et exécutez : `w32tm /resync /force`

macOS :

1. Ouvrez Réglages système > Général > Date et heure.
2. Activez Régler la date et l’heure automatiquement et sélectionnez un serveur NTP proche (ex. `time.apple.com`).
3. Si le problème persiste, exécutez dans le Terminal : `sudo sntp -sS time.apple.com`

Linux (serveur ou bureau) :

“`bash

sudo timedatectl set-ntp true

sudo systemctl restart systemd-timesyncd

timedatectl status

“`

Après la synchronisation, redémarrez le navigateur et réessayez.

Étape 2 : Vider le cache, les cookies et les certificats mis en cache du navigateur

Les navigateurs mettent en cache les politiques HSTS (HTTP Strict Transport Security) et les données de certificats. Une entrée de cache obsolète peut perpétuer une erreur même après la résolution du problème sous-jacent.

Google Chrome :

1. Accédez à `chrome://settings/clearBrowserData`.
2. Définissez la plage de temps sur Toute la période.
3. Cochez Cookies et autres données des sites et Images et fichiers en cache.
4. Cliquez sur Effacer les données.

Pour vider le cache HSTS spécifiquement dans Chrome, accédez à `chrome://net-internals/#hsts`, saisissez le domaine sous « Supprimer les politiques de sécurité du domaine » et cliquez sur Supprimer.

Mozilla Firefox :

1. Ouvrez Paramètres > Vie privée et sécurité.
2. Sous Cookies et données de sites, cliquez sur Effacer les données.
3. Effacez également le Contenu web en cache.

Microsoft Edge :

1. Accédez à `edge://settings/clearBrowserData`.
2. Sélectionnez Toute la période et effacez les données en cache et les cookies.

Étape 3 : Identifier et désactiver l’inspection SSL

Si vous êtes sur un réseau d’entreprise ou utilisez un produit de sécurité des terminaux, l’inspection SSL est le principal suspect.

1. Cliquez sur l’icône de cadenas (ou l’icône d’avertissement) dans la barre d’adresse du navigateur.
2. Inspectez les détails du certificat. Si l’émetteur est votre fournisseur d’antivirus (ex. « Avast Root », « Kaspersky Anti-Virus », « ESET SSL Filter CA ») plutôt qu’une CA publique comme DigiCert, Let’s Encrypt ou Sectigo, l’inspection SSL est active.
3. Dans les paramètres de votre antivirus ou pare-feu, localisez Analyse HTTPS, Filtrage SSL ou Web Shield et désactivez-le.
4. Vous pouvez également ajouter le certificat CA racine de l’appliance au magasin de confiance de votre navigateur.

Ne désactivez pas définitivement votre logiciel de sécurité. Réactivez-le après les tests, ou configurez-le pour exclure des domaines de confiance spécifiques.

Étape 4 : Vérifier et réparer la chaîne de certificats côté serveur (Administrateurs de serveur)

C’est la correction appropriée pour les sites web en production où les visiteurs voient l’erreur.

Diagnostiquer la chaîne :

“`bash

openssl s_client -connect yourdomain.com:443 -showcerts 2>/dev/null | openssl x509 -noout -text | grep -E "Issuer:|Subject:"

“`

Ou utilisez l’inspection complète de la chaîne :

“`bash

openssl s_client -connect yourdomain.com:443 -showcerts

“`

Comptez les certificats retournés. Vous devriez en voir au moins deux (entité finale + intermédiaire). Si un seul apparaît, l’intermédiaire est manquant.

Correction dans Apache (`httpd.conf` ou fichier d’hôte virtuel) :

“`apache

SSLCertificateFile /etc/ssl/certs/yourdomain.crt

SSLCertificateKeyFile /etc/ssl/private/yourdomain.key

SSLCertificateChainFile /etc/ssl/certs/intermediate.crt

“`

Correction dans Nginx (`nginx.conf` ou bloc serveur) :

Nginx nécessite que la chaîne complète soit concaténée dans un seul fichier :

“`bash

cat yourdomain.crt intermediate.crt > fullchain.pem

“`

Puis référencez-le :

“`nginx

ssl_certificate /etc/ssl/certs/fullchain.pem;

ssl_certificate_key /etc/ssl/private/yourdomain.key;

“`

Après modification, testez toujours la configuration avant de redémarrer :

“`bash

Apache

apachectl configtest

Nginx

nginx -t

“`

Puis rechargez le service :

“`bash

sudo systemctl reload apache2

or

sudo systemctl reload nginx

“`

Si vous utilisez un environnement géré, un VPS avec cPanel fournit une interface graphique sous SSL/TLS Manager où vous pouvez coller le certificat, la clé privée et le bundle CA directement sans toucher manuellement aux fichiers de configuration.

Étape 5 : Renouveler ou remplacer un certificat expiré

Si le certificat a expiré, il n’existe aucune solution de contournement côté client. Le serveur doit présenter un certificat valide.

Pour Let’s Encrypt (Certbot) :

“`bash

sudo certbot renew –dry-run

sudo certbot renew

sudo systemctl reload nginx # or apache2

“`

Pour les certificats gérés manuellement : Obtenez un nouveau certificat auprès de votre CA, téléchargez-le via votre panneau de contrôle et assurez-vous que la chaîne du nouveau certificat est complète. Si vous avez besoin d’un certificat de confiance pour un domaine en production, les Certificats SSL d’une CA reconnue éliminent entièrement le problème des certificats auto-signés.

Automatiser les renouvellements : Les certificats Let’s Encrypt expirent tous les 90 jours. Ajoutez une tâche cron ou utilisez des timers systemd pour automatiser le renouvellement :

“`bash

0 3 * * * /usr/bin/certbot renew –quiet –post-hook "systemctl reload nginx"

“`

Étape 6 : Approuver un certificat auto-signé pour un usage interne

Si vous exploitez des outils internes, un serveur de développement ou un service de réseau privé où le remplacement du certificat n’est pas faisable, vous pouvez ajouter le certificat auto-signé au magasin de confiance de l’OS.

Windows :

1. Exportez le certificat depuis le navigateur (cliquez sur l’avertissement > Certificat > Détails > Copier dans un fichier).
2. Ouvrez `certmgr.msc`.
3. Accédez à Autorités de certification racines de confiance > Certificats.
4. Clic droit > Toutes les tâches > Importer et importez le certificat.

macOS :

“`bash

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /path/to/cert.crt

“`

Linux (Debian/Ubuntu) :

“`bash

sudo cp cert.crt /usr/local/share/ca-certificates/

sudo update-ca-certificates

“`

Important : Chrome sur Linux et Windows utilise le magasin de confiance de l’OS pour la plupart des usages, mais maintient également sa propre base de données NSS. Si Chrome rejette toujours le certificat après la mise à jour du magasin OS, importez-le directement via `chrome://settings/certificates`.

Étape 7 : Mettre à jour le navigateur et le système d’exploitation

Un navigateur obsolète peut manquer de nouveaux certificats CA racine ou ne pas prendre en charge les versions actuelles du protocole TLS (TLS 1.2 minimum est désormais requis ; TLS 1.3 est préféré).

Chrome : Accédez à `chrome://settings/help`. Chrome se met à jour automatiquement ; si une mise à jour est en attente, elle s’installera ici.

Firefox : Accédez à Aide > À propos de Firefox. Firefox vérifiera et appliquera les mises à jour.

Système d’exploitation : Sur Windows, assurez-vous que Windows Update est à jour. Sur les serveurs Linux, exécutez :

“`bash

sudo apt update && sudo apt upgrade ca-certificates openssl

“`

Ceci est particulièrement important pour les serveurs fonctionnant sous des distributions plus anciennes où le bundle CA (paquet `ca-certificates`) n’a pas été mis à jour pour inclure les nouvelles CA racine.

Étape 8 : Réinitialiser la pile réseau et vider le DNS

Les mauvaises configurations au niveau réseau, les caches DNS corrompus ou les entrées Winsock obsolètes peuvent parfois contribuer aux échecs de négociation TLS.

Windows (exécutez l’Invite de commandes en tant qu’Administrateur) :

“`cmd

netsh int ip reset

netsh winsock reset

ipconfig /release

ipconfig /renew

ipconfig /flushdns

“`

Redémarrez la machine après avoir exécuté ces commandes.

macOS :

“`bash

sudo dscacheutil -flushcache

sudo killall -HUP mDNSResponder

“`

Linux :

“`bash

sudo systemd-resolve –flush-caches

or for systems using nscd:

sudo service nscd restart

“`

Étape 9 : Contourner l’avertissement (Tests uniquement)

Il s’agit strictement d’un outil de diagnostic, pas d’une solution. Utilisez-le uniquement pour confirmer que l’erreur est liée au certificat et non à un problème réseau ou applicatif, ou lors de l’accès à un serveur interne connu et sûr pendant le développement.

Chrome : Cliquez sur Avancé sur la page d’erreur, puis sur Continuer vers [domaine] (non sécurisé).

Firefox : Cliquez sur Avancé, puis sur Accepter le risque et continuer.

Ne contournez jamais cet avertissement sur des sites gérant l’authentification, les paiements ou les données personnelles. L’avertissement existe parce que la connexion est véritablement non vérifiée.

Vérification de la correction

Après avoir appliqué toute modification côté serveur, validez le résultat à l’aide de ces outils avant de déclarer le problème résolu :

• SSL Labs SSL Test (`ssllabs.com/ssltest/`) : Fournit une analyse complète de la chaîne, une note de support de protocole et identifie les faiblesses de configuration spécifiques.
• `openssl s_client` : Vérification en ligne de commande qui montre exactement ce que le serveur présente lors du handshake TLS.
• `curl -vI https://yourdomain.com` : Vérification rapide qui affiche les détails du handshake TLS et le résultat de la validation du certificat.
• `whatsmychaincert.com` : Diagnostique spécifiquement les certificats intermédiaires manquants.

Choisir la bonne infrastructure d’hébergement pour prévenir les récidives

De nombreuses erreurs de certificats proviennent de limitations d’infrastructure plutôt que d’erreurs d’administrateur. Les environnements d’hébergement partagé restreignent parfois la configuration des chaînes de certificats ou limitent l’accès aux fichiers de configuration du serveur web. Si vous rencontrez régulièrement des problèmes de chaîne ou de renouvellement, migrer vers un environnement VPS Hosting vous donne un contrôle total sur votre pile TLS — y compris la possibilité de configurer Nginx ou Apache directement, d’automatiser les renouvellements Certbot et d’installer des bundles CA personnalisés.

Pour les charges de travail à fort trafic ou sensibles à la conformité où la gestion des certificats est critique, les Serveurs Dédiés éliminent les variables multi-locataires qui peuvent compliquer la configuration SSL. Si vous gérez plusieurs domaines ou sous-domaines, un Panneau de contrôle VPS simplifie le déploiement des certificats sur tous depuis une interface unique.

Matrice de décision : quelle correction s’applique à votre situation

Liste de contrôle des points clés pratiques

• Confirmez si l’erreur est côté client (horloge, cache, inspection SSL) ou côté serveur (certificat expiré, intermédiaire manquant) avant toute action.
• Exécutez `openssl s_client -connect domain:443 -showcerts` comme première étape de diagnostic pour toute investigation côté serveur.
• Concaténez toujours la chaîne de certificats complète (entité finale + tous les intermédiaires) dans la configuration de votre serveur web.
• Automatisez le renouvellement des certificats avec des tâches cron Certbot ou équivalent — le renouvellement manuel est une voie garantie vers de futures pannes.
• Après tout changement de certificat, validez avec SSL Labs avant de clôturer l’incident.
• Ne désactivez jamais définitivement l’analyse SSL de l’antivirus ; configurez plutôt des exclusions ou installez correctement le certificat CA du proxy.
• Sur les serveurs Linux, maintenez les paquets `ca-certificates` et `openssl` à jour pour s’assurer que le magasin racine reflète les CA de confiance actuelles.
• Utilisez `chrome://net-internals/#hsts` pour vider les entrées de cache HSTS lorsque le certificat d’un domaine a été légitimement modifié et que Chrome refuse toujours de se connecter.

Foire aux questions

Quelle est la différence entre NET::ERR_CERT_AUTHORITY_INVALID et NET::ERR_CERT_COMMON_NAME_INVALID ?

`ERR_CERT_AUTHORITY_INVALID` signifie que l’émetteur du certificat n’est pas approuvé — la chaîne ne peut pas être vérifiée. `ERR_CERT_COMMON_NAME_INVALID` signifie que le certificat provient d’une CA de confiance mais a été émis pour un domaine différent de celui auquel on accède. Ils nécessitent des corrections différentes : le premier requiert un nouveau certificat d’une CA de confiance ou une réparation de la chaîne ; le second requiert un certificat réémis avec les Subject Alternative Names corrects.

NET::ERR_CERT_AUTHORITY_INVALID peut-il apparaître même avec un certificat SSL payant et valide ?

Oui. Un certificat payant d’une CA de confiance déclenchera quand même cette erreur si le certificat intermédiaire n’est pas inclus dans la réponse TLS du serveur. Le navigateur ne peut pas toujours récupérer automatiquement les intermédiaires manquants (la récupération AIA est peu fiable), donc la chaîne doit être explicitement configurée sur le serveur.

Pourquoi cette erreur apparaît-elle uniquement dans Chrome mais pas dans Firefox ?

Firefox maintient son propre magasin de confiance de certificats et met également en cache les certificats intermédiaires des connexions réussies précédentes (un mécanisme appelé récupération AIA avec mise en cache). Chrome s’appuie plus strictement sur le magasin de confiance de l’OS et la chaîne présentée par le serveur. Un intermédiaire manquant que Firefox a mis en cache lors d’une session précédente provoquera quand même l’échec de Chrome.

Est-il sûr de cliquer sur « Continuer quand même » sur l’avertissement NET::ERR_CERT_AUTHORITY_INVALID ?

Uniquement dans des scénarios contrôlés : accès à un serveur interne connu, un environnement de développement local ou un serveur de staging que vous administrez. Sur tout site public — en particulier ceux nécessitant des identifiants de connexion, des informations de paiement ou des données personnelles — continuer est véritablement dangereux. La connexion est non chiffrée d’un point de vue de confiance, ce qui signifie que tout intercepteur sur le chemin réseau peut lire ou modifier le trafic.

Comment éviter que cette erreur ne se reproduise sur mon serveur de production ?

Automatisez le renouvellement des certificats (Certbot avec une tâche cron ou un timer systemd), surveillez l’expiration des certificats avec un outil externe (UptimeRobot, Zabbix ou `ssl-cert-check`), déployez toujours la chaîne de certificats complète et maintenez la synchronisation NTP de votre serveur active. Pour les environnements où la gestion manuelle est sujette aux erreurs, envisagez une plateforme d’hébergement avec gestion intégrée des certificats — un VPS avec cPanel gère les renouvellements AutoSSL automatiquement sur tous les domaines hébergés.