Erreurs SSL : ce qu’elles sont et comment les corriger

Une erreur SSL est ce qu’affiche un navigateur lorsqu’il ne parvient pas à établir une connexion chiffrée de confiance vers un site web. Au lieu de la page demandée, vous obtenez un écran d’avertissement et un code court en petites majuscules, quelque chose comme NET::ERR_CERT_AUTHORITY_INVALID ou SSL_ERROR_NO_CYPHER_OVERLAP.

Ce code est la partie utile, et la plupart des guides passent à côté. « Erreur SSL » n’est pas un terme technique, et aucune norme n’en définit un. C’est le nom courant d’une famille entière de défaillances différentes, ce qui explique pourquoi un conseil générique comme vider votre cache en résout certaines et ne fait absolument rien pour les autres.

Ce qu’est réellement une erreur SSL

Lorsque vous chargez une adresse commençant par https://, votre navigateur et le serveur mènent une courte négociation appelée handshake TLS avant que le contenu de la page ne soit transmis. Le handshake convient d’une version de protocole et d’un ensemble d’algorithmes de chiffrement, et le serveur prouve son identité avec un certificat. Si une partie de ce processus échoue, le navigateur refuse de continuer et affiche une erreur plutôt que la page.

SSL et TLS méritent d’être distingués ici, car cette nomenclature crée une réelle confusion. SSL est le protocole d’origine, et chacune de ses versions est obsolète depuis des années. Ce que votre navigateur parle réellement, c’est TLS. Le mot « SSL » survit dans les noms de produits, dans les directives de configuration et dans les codes d’erreur, ce qui explique pourquoi on le voit encore partout. Lorsqu’une page ou un navigateur dit SSL, cela signifie presque toujours TLS.

C’est important pour le dépannage, car la définition populaire d’une erreur SSL est trop restrictive. Vous lirez souvent qu’une erreur SSL signifie que le navigateur n’a pas pu vérifier le certificat du site. C’est vrai pour un groupe de ces erreurs et faux pour le reste. Un serveur qui répond sur le port HTTPS en texte brut non chiffré produit une erreur SSL et n’envoie jamais aucun certificat. Deux machines qui ne parviennent pas à s’entendre sur une suite de chiffrement en produisent une avant même que le certificat ne soit examiné. Partir du certificat alors que le certificat n’a jamais été le problème est la raison la plus courante pour laquelle on passe des heures sur une correction de cinq minutes.

Quelle étape de la connexion a échoué

Chaque connexion HTTPS suit la même séquence, et une erreur SSL est simplement le point où cette séquence s’est arrêtée. Déterminer l’étape restreint immédiatement la cause, car chaque étape possède un ensemble d’explications complètement différent.

1. La connexion n’est jamais devenue TLS. Votre navigateur a ouvert une connexion et ce qui est revenu n’était pas du TLS, ou l’autre extrémité a fermé la connexion avant la fin du handshake. Aucun certificat n’est en cause, et aucun certificat n’a besoin d’être remplacé.
2. Le handshake a échoué pendant la négociation. Les deux côtés parlaient TLS mais n’ont pas pu s’entendre sur une version de protocole, une suite de chiffrement, ou sur le site demandé. Le handshake s’arrête avant que le certificat ne soit validé, et souvent même avant qu’il ne soit envoyé.
3. Le certificat a été reçu et rejeté. C’est le groupe auquel les gens font référence lorsqu’ils disent « erreur SSL ». Expiration, couverture du nom d’hôte, chaîne de confiance, révocation et robustesse de la signature se retrouvent tous ici.
4. Le handshake a réussi et quelque chose après lui a échoué. La connexion chiffrée a été établie correctement, puis une couche ultérieure a échoué. Le certificat est confirmé valide à ce stade, donc le remplacer ne change rien.

Vous n’avez pas besoin de deviner à quelle étape vous vous trouvez. Le code d’erreur vous le dit, et la section suivante associe chaque code à son étape.

Trouvez votre erreur

Lisez le code affiché sous le message d’avertissement. Dans Chrome et Edge, il se trouve en petites majuscules sous « Votre connexion n’est pas privée ». Dans Firefox, vous devrez peut-être ouvrir les détails avancés sur la page d’avertissement. Puis trouvez-le ci-dessous.

Étape 1 : la connexion n’est jamais devenue TLS

• SSL_ERROR_RX_RECORD_TOO_LONG dans Firefox signifie que le serveur a répondu à une requête HTTPS avec quelque chose qui n’est pas du TLS, presque toujours du HTTP en clair servi sur le port 443. C’est un problème de configuration serveur.
• PR_END_OF_FILE_ERROR dans Firefox signifie que l’autre extrémité a fermé la connexion avant la fin du handshake. La cause se situe souvent entre vous et le serveur plutôt qu’à l’une des deux extrémités.

Étape 2 : le handshake a échoué pendant la négociation

• ERR_SSL_PROTOCOL_ERROR est le code générique de Chrome pour un handshake ayant échoué pour une raison qu’il n’a pas pu identifier précisément. Commencez ici si c’est votre code, car la première tâche consiste à affiner le diagnostic.
• SSL_ERROR_NO_CYPHER_OVERLAP est l’équivalent de Firefox, et tout aussi large : il apparaît pour toute défaillance fatale du handshake signalée par le serveur, quelle qu’en soit la véritable raison.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH est le code Chrome pour la même classe de défaillance, déclenché pour une liste courte et précise de conditions de négociation.
• ERR_SSL_UNRECOGNIZED_NAME_ALERT signifie que le serveur a mis fin au handshake volontairement car le nom d’hôte demandé ne correspond à aucun site configuré sur lui. Aucun certificat n’est envoyé, donc le certificat n’est pas en cause.
• ERR_BAD_SSL_CLIENT_AUTH_CERT fonctionne dans le sens inverse de toutes les autres erreurs ici : le site a demandé un certificat à votre navigateur et a rejeté celui qu’il a reçu, ou n’en a reçu aucun. Celle-ci se corrige réellement sur votre machine.
• L’erreur Cloudflare 525 est un échec de handshake sur une autre partie du trajet : entre Cloudflare et le serveur d’origine derrière lui, pas entre votre navigateur et Cloudflare. Les visiteurs ne peuvent rien y faire.

Étape 3 : le certificat a été reçu et rejeté

Votre connexion n’est pas privée est l’écran d’avertissement de Chrome pour tout ce groupe plutôt qu’une cause en soi, donc si c’est tout ce que vous avez, lisez d’abord le code affiché en dessous.

La chaîne de confiance n’a pas pu être établie. Le navigateur n’a pas pu relier le certificat du site à une racine de confiance, généralement parce que le serveur envoie son propre certificat et omet le certificat intermédiaire au-dessus de lui.

• NET::ERR_CERT_AUTHORITY_INVALID dans Chrome et Edge.
• SEC_ERROR_UNKNOWN_ISSUER dans Firefox, la même condition sous un nom différent.
• Un certificat intermédiaire expiré, où la chaîne existe mais un maillon au-dessus de vous est arrivé à échéance.
• MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT, où il n’y a pas de chaîne car le certificat s’est signé lui-même.

Les dates ou le nom ne correspondent pas. Le certificat est de confiance mais ne s’applique pas à ce moment ou à ce nom d’hôte.

• NET::ERR_CERT_DATE_INVALID, où le certificat a expiré ou n’est pas encore valide. Il convient de savoir qu’une horloge incorrecte sur votre propre appareil produit également cette erreur.
• NET::ERR_CERT_COMMON_NAME_INVALID, où le nom d’hôte ne figure pas dans le certificat.
• DLG_FLAGS_SEC_CERT_CN_INVALID, le même problème de nom d’hôte signalé par des logiciels construits sur l’ancienne pile web de Windows, principalement le mode Internet Explorer d’Edge et les applications métier.

Le certificat est de confiance et à jour mais refusé pour une autre raison.

• NET::ERR_CERT_REVOKED, où l’autorité de certification l’a annulé avant sa date d’expiration.
• NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED, où le certificat n’est pas arrivé avec suffisamment de preuve publique d’émission.
• NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM, où quelque chose dans la chaîne est signé avec SHA-1. Le Chrome actuel peut signaler le même certificat sous un code différent, mais la condition et la correction restent inchangées.
• SEC_ERROR_REUSED_ISSUER_AND_SERIAL, une collision au sein du propre magasin de certificats de Firefox plutôt qu’un défaut de la connexion.
• NET::ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN, qui s’applique à un très petit ensemble de domaines intégrés au navigateur, ce qui fait qu’un site web ordinaire ne peut pas la produire.

Le fichier de certificat lui-même est erroné. Ces deux erreurs se rencontrent sur le serveur plutôt que dans un navigateur, et elles empêchent généralement complètement un site de servir en HTTPS.

• ERR_SSL_SERVER_CERT_BAD_FORMAT, où le navigateur n’a pas pu décoder le certificat envoyé par le serveur.
• Une non-correspondance de module, où le certificat installé n’appartient pas à la clé privée installée.

Étape 4 : le handshake a réussi et quelque chose après lui a échoué

Celles-ci sont classées parmi les erreurs SSL par habitude. Dans chaque cas, la connexion chiffrée fonctionnait déjà, donc le certificat a été validé avec succès et le réémettre ne servira à rien.

• ERR_SSL_BAD_RECORD_MAC_ALERT signifie que le serveur a reçu des données chiffrées qu’il n’a pas pu vérifier, ce qui se produit après le handshake, sous les clés de session. Quelque chose sur le trajet corrompt ou réécrit le trafic.
• ERR_QUIC_PROTOCOL_ERROR est une défaillance de QUIC, le transport sous-jacent à HTTP/3. Ce n’est pas un problème de certificat, et la cause habituelle est un pare-feu ou un VPN filtrant l’UDP.
• ERR_SPDY_PROTOCOL_ERROR est une défaillance au niveau de la couche HTTP/2, qui se situe au-dessus d’un handshake TLS achevé.
• Le contenu mixte est le cas particulier : la page s’est chargée parfaitement en HTTPS, puis a demandé une ressource en HTTP en clair. Cela ne produit aucune page d’erreur, juste un cadenas dégradé et des scripts ou des images manquants.

Erreurs nommées d’après un appareil plutôt qu’une étape

Deux plateformes produisent suffisamment de particularités propres pour être traitées séparément, car la même condition sous-jacente s’y comporte différemment.

• Erreurs SSL sur iPhone et iPad, notamment le message « Une erreur SSL s’est produite et une connexion sécurisée au serveur ne peut pas être établie ». Le réglage de la date et de l’heure est la première chose à vérifier.
• Erreurs de connexion SSL sur Android, où Chrome et d’autres applications consultent des magasins de confiance différents, et où un certificat intermédiaire manquant cause plus de problèmes que sur un ordinateur de bureau.

Codes qui n’apparaissent plus

Trois codes sont encore largement documentés mais ont été retirés des navigateurs qui les produisaient, donc si vous lisez des conseils à propos de l’un d’eux, vérifiez la date de la publication. Les conditions derrière deux d’entre eux existent encore sous d’autres noms.

• NET::ERR_CERT_SYMANTEC_LEGACY a été supprimé dans Chrome 136, publié en avril 2025.
• ERR_SSL_VERSION_INTERFERENCE a été supprimé dans Chrome 76 en 2019, bien que l’interférence qu’il décrivait se produise encore et se manifeste désormais différemment.
• ERR_SPDY_PROTOCOL_ERROR a été renommé ERR_HTTP2_PROTOCOL_ERROR dans Chrome 77, également en 2019. La défaillance qu’il décrit est toujours d’actualité, ce qui explique qu’elle figure dans l’étape quatre ci-dessus.

Si vous visitez le site

La plupart des erreurs SSL sont à corriger par le site web, et aucun effort sur votre propre appareil ne les changera. Il existe une courte liste d’exceptions réelles, qu’il convient de parcourir avant de conclure que le site est défaillant.

• Vérifiez votre horloge. La validation du certificat compare les dates du certificat à l’heure de votre propre appareil. Une horloge décalée de plusieurs mois ou années fait paraître invalide chaque certificat, et c’est de loin la cause la plus fréquente du côté visiteur.
• Essayez un second réseau. Passer du Wi-Fi aux données mobiles, ou l’inverse, vous indique en quelques secondes si quelque chose sur le réseau intercepte le trafic. Le Wi-Fi public et celui des hôtels sont des coupables fréquents.
• Désactivez temporairement l’analyse HTTPS. Les antivirus et les proxys d’entreprise inspectent le trafic chiffré en substituant leurs propres certificats. Lorsqu’ils le font mal, vous obtenez une erreur SSL sur des sites qui fonctionnent parfaitement ailleurs.
• Essayez une fenêtre privée et un autre navigateur. Si l’erreur apparaît dans un navigateur mais pas dans un autre, la cause est généralement locale, dans une extension ou dans des données stockées. Si elle apparaît dans tous les navigateurs, c’est le site.

Si rien de tout cela n’aide, le problème se situe sur le serveur, et la réponse honnête est que vous ne pouvez pas le corriger. C’est entièrement le cas pour l’erreur Cloudflare 525, où la défaillance se produit sur une connexion dont votre navigateur ne fait pas partie.

Les navigateurs offrent effectivement un moyen de passer outre la plupart des avertissements de certificat, et il convient d’être clair sur ce que cela coûte. Poursuivre indique au navigateur d’accepter une connexion dont il n’a pas pu vérifier l’identité, ce qui signifie que vous n’avez aucune garantie de parler au site que vous avez saisi plutôt qu’à quelque chose entre les deux. C’est un compromis acceptable sur un serveur de test que vous contrôlez. Ce n’est pas acceptable sur quoi que ce soit où vous saisirez un mot de passe ou des informations de paiement. Certaines erreurs n’offrent aucun moyen de passer outre, et c’est délibéré plutôt qu’un défaut.

Si vous gérez le site web

Diagnostiquez avant de modifier quoi que ce soit. Réinstaller un certificat qui n’a jamais été le problème est la manière habituelle par laquelle une heure se transforme en après-midi.

Commencez par une vérification externe

Passez le domaine dans notre SSL Checker. Il indique ce que le serveur envoie réellement vers l’extérieur, ce qui ne correspond fréquemment pas à ce qui se trouve dans le fichier de configuration. Une chaîne qui semble complète sur le disque mais qui arrive incomplète au navigateur est le constat le plus fréquent, et c’est la cause derrière NET::ERR_CERT_AUTHORITY_INVALID et SEC_ERROR_UNKNOWN_ISSUER.

Vous pouvez constater la même chose depuis la ligne de commande. Ceci affiche chaque certificat proposé par le serveur, dans l’ordre où il les propose :

openssl s_client -connect example.com:443 -servername example.com -showcerts

Lisez la liste des certificats dans cette sortie, pas la ligne Verify return code en bas. Cette ligne est bien moins informative qu’elle ne le paraît : elle ne rapporte que le verdict d’OpenSSL sur la chaîne, elle ignore le nom d’hôte à moins que vous ne demandiez explicitement la vérification, et elle affiche 0 (ok) même lorsque le serveur n’a envoyé aucun certificat parce que le handshake a été interrompu. Si la sortie indique no peer certificate available plutôt que d’afficher une ligne subject=, rien n’a été vérifié et la défaillance s’est produite plus tôt.

Vérifiez les dates et le nom d’hôte

Ces deux éléments représentent une grande part des rejets de certificat. Pour lire la fenêtre de validité du certificat servi par le serveur :

openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -subject

Les navigateurs comparent le nom d’hôte à l’extension subjectAltName et ignorent entièrement le Common Name, c’est donc ce champ qu’il faut examiner sur un fichier de certificat local :

openssl x509 -noout -text -in certificate.crt | grep -A1 "Subject Alternative Name"

Pour faire appliquer par OpenSSL la même vérification du nom d’hôte qu’un navigateur, ajoutez l’option plutôt que de supposer qu’un résultat propre la couvre déjà :

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com

Sur macOS, ces commandes demandent de l’attention. Le openssl fourni avec macOS est LibreSSL, et il rejette purement et simplement -verify_hostname et rapporte un résultat sain sur certaines chaînes réellement défaillantes. Installez OpenSSL via Homebrew, puis relancez openssl version pour confirmer quel binaire vous appelez réellement. S’il rapporte toujours LibreSSL, votre PATH trouve d’abord la copie système, donc appelez /opt/homebrew/bin/openssl par son chemin complet.

Puis corrigez et vérifiez

Ce qu’il faut changer dépend de l’étape, et les guides individuels liés ci-dessus détaillent les étapes spécifiques à chaque plateforme. Trois corrections couvrent la plupart des cas :

• Servez la chaîne complète. Concaténez votre certificat et les certificats intermédiaires fournis par votre autorité de certification dans le fichier vers lequel pointe votre serveur. Ne placez pas la clé privée dans ce fichier.
• Renouvelez avant l’expiration, et automatisez cela. Les durées de vie des certificats se réduisent, donc tout ce qui est renouvelé manuellement finira par être renouvelé en retard. L’automatisation ACME élimine cette échéance.
• Couvrez chaque nom d’hôte que vous servez réellement. Un certificat pour un domaine ne couvre pas ses sous-domaines, sauf s’il s’agit d’un wildcard ou s’il les liste.

Testez toujours la configuration avant de recharger le service, et relancez le vérificateur ensuite depuis l’extérieur de votre propre réseau. Une correction confirmée uniquement dans le navigateur que vous avez utilisé pour tester n’est pas confirmée, car ce navigateur peut conserver un résultat mis en cache.

Comment prévenir les erreurs SSL

Presque toutes les erreurs SSL sur un site web fonctionnel proviennent de l’une de ces trois causes : un certificat qui a expiré, une chaîne qui n’a jamais été complète, ou une configuration qui a dérivé. Les trois sont évitables.

• Automatisez le renouvellement. Les durées de vie maximales des certificats sont réduites par étapes au cours des prochaines années, et le renouvellement manuel cesse d’être pratique bien avant la fin de cette réduction. Automatisez maintenant plutôt que lorsque cela se cassera.
• Surveillez l’expiration de manière indépendante. Un rappel dans un calendrier échoue quand la personne concernée quitte l’entreprise. Une vérification externe qui vous alerte plusieurs semaines à l’avance ne le fait pas.
• Vérifiez à nouveau après chaque changement. Les migrations de serveur, les changements de CDN et les mises à jour de panneau de contrôle réécrivent tous discrètement la configuration du certificat. Vérifiez ensuite depuis l’extérieur.
• Testez sur un téléphone, pas seulement sur un ordinateur de bureau. Les plateformes mobiles sont plus strictes concernant les chaînes incomplètes, donc un problème de chaîne se manifeste souvent sur un téléphone alors que l’ordinateur de bureau semble fonctionner correctement.
• Installez correctement dès la première fois. Nos tutoriels d’installation couvrent les étapes de chaîne et de liaison pour chaque plateforme, et la plupart des erreurs de chaîne proviennent du moment de l’installation.

Questions fréquemment posées