ERR_SSL_PROTOCOL_ERROR

Ce que signifie cette erreur et comment la reconnaître

• Chrome ou Edge affiche « Ce site ne peut pas fournir une connexion sécurisée » avec ERR_SSL_PROTOCOL_ERROR.
• L’échec peut concerner l’ensemble du site, un sous-domaine ou un seul nom d’hôte derrière un proxy ou un load balancer.
• HTTP en clair sur le port 80 peut fonctionner alors que HTTPS échoue, ce qui indique un problème sur le chemin TLS plutôt que nécessairement dans l’application.
• L’erreur peut apparaître après le renouvellement d’un certificat, une migration de serveur, une modification de la configuration du serveur web, un changement de CDN ou une modification du service à l’écoute sur le port 443.
• Un test direct de l’origine et un test du nom d’hôte public peuvent produire des résultats différents lorsqu’un CDN, un reverse proxy ou un load balancer intervient.

Causes principales, classées par probabilité

1. Le port 443 sert du HTTP en clair ou un autre protocole non-TLS. Le listener HTTPS peut être absent ou le mauvais service peut s’être attaché au port 443. Le navigateur reçoit alors des données qui ne correspondent pas à un handshake TLS.
2. Le virtual host HTTPS ou le server block est incorrect. Le serveur peut écouter sur la mauvaise adresse, sélectionner le mauvais nom d’hôte ou ne pas disposer des directives TLS requises par le serveur web.
3. Un CDN, un reverse proxy ou un load balancer présente une incompatibilité avec l’origine. Le proxy peut utiliser HTTP alors que l’origine attend HTTPS, ou se connecter au mauvais port ou au mauvais backend.
4. La configuration TLS est incompatible ou mal formée. Des versions de protocole non prises en charge, des paramètres de chiffrement trop restrictifs, des problèmes de routage SNI ou un équipement qui termine TLS mal configuré peuvent interrompre le handshake avant la validation du certificat.
5. Le certificat ou la chaîne est inutilisable. Un certificat expiré, un certificat intermédiaire manquant ou un certificat qui ne couvre pas le nom d’hôte demandé peut empêcher une connexion sécurisée. Certains navigateurs et chemins de connexion affichent à la place un avertissement plus précis concernant le certificat.
6. Un certificat renouvelé n’a pas été chargé par le service. La mise à jour des fichiers de certificat sur le disque ne modifie pas le certificat présenté par un serveur web en cours d’exécution tant que sa configuration n’a pas été rechargée ou redémarrée conformément à la procédure documentée du service.

Comment corriger le problème

1. Déterminer si l’échec est public, spécifique à l’origine ou local

Essayez le nom d’hôte exact qui échoue depuis un second réseau ou appareil. Si un seul ordinateur échoue, vérifiez les logiciels de sécurité locaux, les proxies d’interception et l’heure système. Si tous les clients échouent, poursuivez l’analyse du serveur, du proxy, du CDN ou du load balancer.

Si HTTP fonctionne mais pas HTTPS, concentrez-vous sur le listener TLS, le port 443, la sélection du certificat et tout proxy situé entre le client et l’origine. Ne supposez pas que le succès de HTTP prouve que la configuration HTTPS est correcte.

2. Tester le handshake TLS sans modifier l’état du serveur

Depuis un terminal d’administration disposant d’un accès réseau à l’endpoint, exécutez :

openssl s_client -connect [your-hostname]:443 -servername [your-hostname] -showcerts

L’option -servername est importante lorsque SNI sélectionne les certificats ou les virtual hosts. Notez si le handshake démarre, quel certificat est renvoyé, sa date d’expiration, les noms d’hôte du Subject Alternative Name et la présence éventuelle de certificats intermédiaires.

• Si la connexion renvoie du HTTP en clair ou échoue avant l’apparition d’un certificat, examinez le listener du port 443 et le routage du proxy.
• Si un certificat est renvoyé, comparez-le au nom d’hôte demandé et vérifiez ses dates de validité ainsi que sa chaîne.
• Si un test direct de l’origine fonctionne mais que le nom d’hôte public échoue, examinez le CDN, le reverse proxy, le load balancer ou le chemin DNS plutôt que de modifier l’application.

3. Vérifier le listener HTTPS et le routage des noms d’hôte

Avec les accès serveur et l’autorisation appropriés, examinez la configuration active du serveur web et confirmez que :

• le service prévu écoute sur le port 443 ;
• le server block ou virtual host HTTPS est activé ;
• le nom d’hôte demandé figure dans les paramètres server_name ou ServerName/ServerAlias pertinents ;
• TLS est activé pour ce listener ; et
• les chemins du certificat et de la clé privée pointent vers les fichiers prévus.

Pour Nginx, vérifiez le server block activé et sa configuration listen 443 ssl. Pour Apache, vérifiez la configuration <VirtualHost *:443> et SSLEngine on. Ne copiez pas de directives d’un produit à l’autre sans vérifier la syntaxe et la version prises en charge par le serveur installé.

4. Valider le certificat et la chaîne

Confirmez que le certificat présenté :

• n’est pas expiré et n’est pas encore invalide ;
• couvre le nom d’hôte exact dans ses entrées Subject Alternative Name ;
• correspond à la clé privée associée ; et
• est accompagné de la chaîne de certificats intermédiaires requise.

Un certificat pour le domaine racine ne couvre pas automatiquement tous les sous-domaines. Le sous-domaine doit être listé explicitement ou couvert par un certificat wildcard approprié. Si le serveur ne présente que le certificat leaf, installez le fichier de chaîne fourni par l’autorité de certification dans le format requis par le serveur web.

5. Vérifier le renouvellement et le chargement du certificat

Pour un déploiement géré par Certbot, un administrateur peut exécuter certbot renew --dry-run afin de tester le processus de renouvellement sans émettre de certificat de production. Examinez la sortie, la configuration du renouvellement, les permissions et le hook de reload du service.

Si le renouvellement a réussi mais que les clients reçoivent toujours l’ancien certificat, confirmez que le serveur web ou le proxy qui termine TLS a chargé les nouveaux fichiers. Un reload ou un redémarrage modifie l’état du service et doit être effectué uniquement pendant une fenêtre de maintenance approuvée, avec un plan de retour arrière et conformément à la procédure documentée du produit. Gardez cette opération distincte des diagnostics en lecture seule.

6. Examiner les paramètres TLS du CDN, du proxy et du load balancer

Identifiez l’endroit où TLS se termine : CDN, proxy edge, load balancer ou serveur d’origine. Vérifiez que le protocole et le port d’origine configurés correspondent à ce que l’origine sert réellement.

Si un CDN propose des modes tels que Flexible, Full ou Full (strict), sélectionnez le mode qui correspond à la configuration réelle de l’origine et à la validité de son certificat. Un mode moins strict peut masquer le problème sous-jacent ou créer un échec différent ; il ne remplace pas durablement un certificat d’origine valide. N’effectuez des modifications de configuration qu’avec l’autorisation nécessaire, puis testez à nouveau le nom d’hôte public et le chemin vers l’origine lorsque cela est possible.

7. Vérifier les interférences liées au protocole, à SNI ou aux équipements réseau

Si l’endpoint présente un certificat valide correspondant au nom d’hôte mais que le handshake échoue toujours, comparez les résultats depuis différents réseaux et avec différents clients TLS. Examinez les paramètres du firewall, du load balancer, du web application firewall et de l’inspection TLS pour détecter des versions de protocole bloquées, des politiques de chiffrement non prises en charge, un routage SNI incorrect ou une modification du trafic. Conservez la sortie du handshake et les journaux serveur pertinents pour le fournisseur d’hébergement ou l’administrateur réseau.

Prévention et vérification du correctif

• Surveillez l’expiration des certificats indépendamment du mécanisme de renouvellement et déclenchez des alertes avant leur expiration.
• Testez le renouvellement dans un environnement hors production ou avec un dry-run, et vérifiez que le hook de reload du service présente effectivement le nouveau certificat.
• Tenez à jour un inventaire documenté de chaque nom d’hôte, point de terminaison TLS, certificat, clé privée et chaîne intermédiaire.
• Après toute modification des certificats, proxies, load balancers ou mappages de ports, testez le nom d’hôte public et chaque sous-domaine important.
• Vérifiez la compatibilité SNI, des versions de protocole, des paramètres de chiffrement et du port d’origine avant de déployer des modifications de configuration TLS.
• Conservez les informations récentes sur le serveur, le proxy et les certificats afin de pouvoir comparer un handshake échoué à la dernière configuration connue comme fonctionnelle.

Questions fréquentes