Une erreur SSL signifie que le navigateur refuse la connexion chiffrée avec le site. Le code affiché désigne la cause : autorité inconnue, nom non couvert, protocole ou chiffrement incompatible. Le visiteur vérifie son horloge, son réseau et son antivirus ; le propriétaire examine le certificat avec openssl et corrige la configuration du serveur web.
Chrome affiche « Votre connexion n’est pas privée » et, sous le texte, un code accessible via « Avancé ». Ce code est le seul indice fiable : deux sites qui montrent la même page d’alerte peuvent avoir des causes sans rapport. Les plus fréquentes sont un certificat qui ne couvre pas le nom demandé, une chaîne de certificats incomplète, un certificat autosigné, un port 443 qui ne répond pas en TLS ou une configuration qui n’autorise plus que des protocoles obsolètes.
Deux étapes s’adressent au visiteur, les six suivantes au propriétaire ou à l’administrateur du serveur. Un certificat périmé relève de la page certificat SSL expiré, et l’avertissement « Non sécurisé » sur un site en HTTPS de la page site non sécurisé : elles ne sont pas reprises ici.
Éliminer une cause locale : horloge, réseau et navigateur
Si vous visitez un site. Ouvrez l’adresse depuis un autre réseau, par exemple le partage de connexion d’un téléphone, puis depuis un autre appareil. Si l’erreur disparaît, la cause est locale : réseau d’entreprise, Wi-Fi public avec portail d’accès ou mauvaise date. Corrigez la date et l’heure en activant le réglage automatique, puis testez en navigation privée pour écarter une extension. Si l’alerte persiste partout, le défaut vient du site : prévenez son éditeur en joignant le code exact.
Repérer un antivirus ou un proxy qui intercepte HTTPS
Si vous visitez un site. Certains antivirus, pare-feu d’entreprise et proxys déchiffrent le trafic HTTPS pour l’inspecter, en présentant leur propre certificat. Le navigateur le rejette s’il ne connaît pas leur autorité, d’où NET::ERR_CERT_AUTHORITY_INVALID sur presque tous les sites. Cliquez sur le cadenas, ouvrez le détail du certificat et lisez l’émetteur : un nom d’éditeur de sécurité ou d’entreprise au lieu d’une autorité publique confirme l’interception. Désactivez l’option d’analyse HTTPS ou SSL de l’antivirus, ou demandez à l’administrateur du réseau d’installer son autorité de confiance.
Examiner ce que le serveur présente réellement
Si c’est votre site. Depuis un poste de travail, lancez openssl s_client -connect exemple.fr:443 -servername exemple.fr, en remplaçant le nom par le vôtre. Lisez trois éléments. La section « Certificate chain » doit lister le certificat du site puis un ou plusieurs intermédiaires. La ligne Verify return code doit indiquer 0 (ok) ; un code 20 ou 21 signale une chaîne incomplète, un code 18 un certificat autosigné. Pour lire les noms couverts, reliez la sortie à openssl x509 -noout -subject -ext subjectAltName par un tube. Si la commande échoue avant toute poignée de main, le problème est plus bas : voir l’étape 6.
Corriger NET::ERR_CERT_AUTHORITY_INVALID
Si c’est votre site. Ce code veut dire que le navigateur ne peut pas remonter du certificat jusqu’à une autorité qu’il connaît. Deux causes dominent. Un certificat autosigné, généré avec openssl req -x509 ou par un panneau d’administration, n’est reconnu par aucun navigateur : remplacez-le par un certificat d’une autorité publique, par exemple Let’s Encrypt via Certbot. Une chaîne intermédiaire absente : le serveur envoie le seul certificat du site. Avec Certbot, faites pointer ssl_certificate (nginx) ou SSLCertificateFile (Apache) vers fullchain.pem et non vers cert.pem. Avec un certificat acheté, concaténez le certificat et le fichier de chaîne fourni par l’autorité, dans cet ordre. Testez avec nginx -t ou apachectl configtest, puis rechargez le serveur.
Corriger NET::ERR_CERT_COMMON_NAME_INVALID
Si c’est votre site. Le certificat est valide, mais il ne couvre pas le nom tapé dans la barre d’adresse. Le cas typique : un certificat émis pour exemple.fr seul, alors que les visiteurs arrivent sur www.exemple.fr ou sur un sous-domaine créé plus tard. Relevez les noms listés dans « Subject Alternative Name » avec la commande de l’étape 3, puis réémettez le certificat avec tous les noms utilisés, par exemple avec plusieurs options -d de Certbot. Vérifiez aussi que le bon bloc server répond : un nom sans bloc dédié tombe sur le serveur par défaut, qui présente le certificat d’un autre site.
Corriger ERR_SSL_PROTOCOL_ERROR
Si c’est votre site. Chrome n’a pas obtenu de réponse TLS valable. Vérifiez d’abord que le port 443 sert bien du TLS : en nginx, la directive doit être listen 443 ssl; et non listen 443;, et en Apache le module doit être chargé avec un VirtualHost *:443 contenant SSLEngine on. Cherchez ensuite un service qui répond en clair sur ce port, par exemple un conteneur ou un équipement en amont. Contrôlez que le certificat et sa clé privée correspondent et que les fichiers sont lisibles par le serveur, puis consultez le journal d’erreurs, journalctl -u nginx ou celui d’Apache. Après toute correction, nginx -t puis systemctl reload nginx.
Corriger ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Si c’est votre site. Le navigateur et le serveur n’ont aucun protocole ou chiffrement en commun. Cela arrive quand la configuration n’autorise que des versions obsolètes, ou qu’un jeu de chiffrements trop restreint exclut ceux des navigateurs actuels. Dans nginx, la directive ssl_protocols doit inclure TLSv1.2 TLSv1.3 ; dans Apache, SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1. Ne réintroduisez pas SSLv3 ni TLS 1.0 pour contenter un vieux client. Retirez une liste de chiffrements personnalisée ancienne plutôt que de la compléter : les valeurs par défaut des versions récentes sont adaptées. Testez ensuite et rechargez.
Valider la correction depuis l’extérieur
Si c’est votre site. Relancez la commande de l’étape 3 : Verify return code: 0 (ok), une chaîne complète et tous vos noms dans subjectAltName. Contrôlez ensuite chaque nom utilisé, avec et sans www, depuis un autre réseau et en navigation privée, car Chrome met en cache certaines décisions. Si le défaut reste visible chez certains visiteurs seulement, ancien système, antivirus ou proxy sont à reconsidérer, comme aux étapes 1 et 2.
Questions fréquentes
Pourquoi l’erreur SSL n’apparaît-elle que sur mon ordinateur ?
Quand un seul appareil ou un seul réseau est touché, le site est rarement en cause. Les coupables habituels sont une horloge décalée, un antivirus qui inspecte le trafic HTTPS, un proxy d’entreprise ou un portail de Wi-Fi public. Testez depuis un autre réseau avant de modifier quoi que ce soit.
Peut-on cliquer sur « Continuer vers le site » en toute sécurité ?
Seulement si vous maîtrisez le site, par exemple un serveur de test interne. Sur un site public, l’alerte peut signaler une interception de la connexion : n’y saisissez ni mot de passe ni numéro de carte. Le vrai remède consiste à corriger le certificat côté serveur.
Quelle différence entre NET::ERR_CERT_AUTHORITY_INVALID et NET::ERR_CERT_COMMON_NAME_INVALID ?
Le premier concerne la confiance : l’émetteur du certificat n’est pas reconnu ou sa chaîne est incomplète. Le second concerne le nom : le certificat est fiable, mais il n’a pas été établi pour l’adresse saisie. Le premier se règle avec une autorité publique et le fichier fullchain.pem, le second en réémettant le certificat avec le nom manquant.
Un certificat autosigné est-il utilisable en production ?
Non, pas sur un site visité par le public : aucun navigateur ne le reconnaît, et chaque visiteur voit l’alerte. Il convient pour un test interne ou une communication entre vos propres machines, à condition d’y installer l’autorité correspondante. Un certificat Let’s Encrypt remplace avantageusement l’autosigné.
Faut-il redémarrer le serveur après avoir modifié la configuration TLS ?
Non. Après nginx -t ou apachectl configtest, un simple rechargement du service suffit à appliquer les nouveaux fichiers et directives. Le test préalable évite de recharger une configuration invalide et de couper le site. Un redémarrage complet n’est utile que si le rechargement échoue.
Sources
- Configuring HTTPS servers — nginx
- Apache module mod_ssl — Apache HTTP Server
- Chaîne de certificats — Let’s Encrypt