Erreurs SSL et de sécurité

À propos de cette catégorie d’erreurs

# Erreurs SSL et de sécurité

Les erreurs SSL et de sécurité surviennent lorsqu’un navigateur ne parvient pas à établir ou à valider une connexion HTTPS sécurisée et fiable. L’échec peut se produire pendant le handshake TLS, lorsque le serveur présente son certificat, ou lorsque le certificat ne correspond pas au hostname visité.

Un même site web peut produire des résultats différents pour son domaine racine, un sous-domaine ou sa variante www. Un CDN public ou un reverse proxy peut également présenter un certificat différent de celui du serveur d’origine. Commencez par noter le hostname exact et l’erreur du navigateur au lieu de considérer tous les avertissements SSL comme un seul et même problème.

Symptômes courants

Vous pouvez voir :

• Un avertissement indiquant que la connexion n’est pas privée ou sécurisée
• Une incompatibilité entre le nom du certificat et le hostname
• Une connexion qui échoue avant le chargement de la page
• ERR_SSL_PROTOCOL_ERROR ou un autre message lié au protocole TLS
• Des résultats différents pour le domaine racine, un sous-domaine ou le hostname www
• Un site qui fonctionne via un CDN ou un proxy, mais échoue lors d’une connexion directe à son serveur d’origine

Diagnostiquer l’échec par couche

1. Notez le hostname et l’erreur exacts

Vérifiez le hostname complet dans la barre d’adresse, y compris son sous-domaine. Comparez le hostname concerné avec les versions www et sans www si les deux sont utilisées. Notez également le message d’erreur complet du navigateur, car une incompatibilité de certificat et un échec de négociation TLS nécessitent des vérifications différentes.

Pour une incompatibilité de hostname, consultez [NET::ERR_CERT_COMMON_NAME_INVALID](/errors/err-cert-common-name-invalid). Cela signifie généralement que le serveur a présenté un certificat qui ne couvre pas le hostname affiché dans la barre d’adresse.

2. Examinez le certificat présenté au navigateur

Ouvrez les détails du certificat dans le navigateur et vérifiez :

• Les Subject Alternative Names du certificat, qui indiquent les hostnames couverts
• Les dates de validité
• L’émetteur et l’état de confiance
• La chaîne de certificats
• Si le serveur présente bien le certificat attendu, plutôt que le certificat par défaut d’un hébergeur

Un certificat pour le domaine racine n’est pas automatiquement valide pour tous les sous-domaines. Le hostname concerné doit être couvert par les noms du certificat ou par un nom wildcard applicable.

Si le certificat est correct dans un environnement mais pas dans un autre, examinez le DNS, le SNI, le routage du reverse proxy et la configuration du CDN. Différents endpoints TLS peuvent servir des certificats différents pour un même site en apparence.

3. Distinguez la validation du certificat d’un échec du handshake TLS

Un avertissement concernant le hostname ou la confiance signifie généralement que le navigateur a atteint l’étape où il peut examiner un certificat. Une erreur de protocole peut indiquer que la négociation TLS a échoué plus tôt. Vérifiez si :

• Le port 443 sert bien HTTPS et TLS, et non du HTTP en clair
• Le virtual host HTTPS prévu est sélectionné pour le hostname demandé
• La configuration TLS du serveur est activée et valide en interne
• Le certificat et la clé privée correspondent
• La chaîne complète de certificats est installée à l’emplacement attendu par le serveur
• Un proxy, un load balancer, un pare-feu ou un CDN interrompt le handshake

Pour le cas spécifique lié au protocole, consultez [ERR_SSL_PROTOCOL_ERROR](/errors/err-ssl-protocol-error).

4. Comparez les chemins de connexion public et d’origine

Déterminez si l’erreur se produit uniquement sur le hostname public, uniquement sur le hostname d’origine ou sur les deux. Un CDN ou un reverse proxy peut terminer HTTPS sur l’edge public et utiliser une connexion TLS distincte vers l’origine. Son certificat et ses paramètres TLS ne correspondent pas nécessairement à la configuration du serveur d’origine.

Vérifiez également que le DNS dirige le hostname vers le service prévu. Une ancienne adresse, un serveur de staging ou un endpoint d’hébergement mutualisé peut renvoyer un certificat sans rapport avec le site que vous vouliez visiter.

5. Testez à nouveau le hostname qui échoue

Après avoir corrigé une association de certificat, un mapping de hostname ou une couche TLS, testez à nouveau le même hostname. Si plusieurs hostnames sont concernés, testez-les séparément. Vous pourrez ainsi déterminer si le problème est limité à un endpoint ou s’il révèle un problème plus large de configuration DNS, de proxy ou de serveur.

Évitez de contourner un avertissement du navigateur comme méthode de dépannage. Cela ne corrige pas la configuration du serveur et peut exposer la connexion à des risques. Identifiez d’abord si le problème vient d’une incompatibilité de hostname, d’une chaîne de certificats non fiable ou incomplète, ou d’un échec de négociation TLS.

Quand utiliser les guides associés

• Utilisez [ERR_SSL_PROTOCOL_ERROR](/errors/err-ssl-protocol-error) lorsque le navigateur indique que le protocole SSL ou TLS n’a pas pu être établi.
• Utilisez [NET::ERR_CERT_COMMON_NAME_INVALID](/errors/err-cert-common-name-invalid) lorsque le certificat présenté ne correspond pas au hostname affiché dans la barre d’adresse.

Le message exact du navigateur, le hostname, les détails du certificat, la destination DNS et le chemin de connexion sont plus utiles que le libellé général « erreur SSL ». Collectez ces informations avant de remplacer des certificats ou de modifier les paramètres du serveur.

Autres domaines de référence

Pour les détails propres à l’implémentation, consultez la documentation du navigateur concerné, du serveur web, de l’autorité de certification, du CDN ou du reverse proxy, ainsi que de la plateforme d’hébergement. Les sections pertinentes s’intitulent généralement installation du certificat, chaînes de certificats, SNI ou virtual hosts, configuration TLS et paramètres HTTPS de l’origine.