ERR_SSL_PROTOCOL_ERROR : diagnostic et correction

Étape 0 : le problème vient-il de vous ou du serveur ?

La question à trancher en premier, car elle divise le travail par deux. Ouvrez le site depuis un autre réseau (données mobiles plutôt que Wi-Fi) ou utilisez un service de test en ligne qui interroge le serveur depuis l'extérieur. Si le site répond correctement ailleurs, la cause est locale : votre navigateur, votre antivirus, votre réseau d'entreprise.

Si l'échec est identique depuis toutes les origines, la cause est côté serveur — et c'est là qu'il faut agir si le site est le vôtre. Un scan externe est le moyen le plus rapide de trancher : il vous dira quelles versions de TLS le serveur accepte réellement, si le certificat est servi correctement et si le port 443 répond bien en TLS.

Causes côté visiteur (le site marche pour les autres)

Le trio classique : antivirus, extensions, cache. Les suites de sécurité qui inspectent le trafic chiffré s'intercalent dans la négociation TLS et la cassent parfois, notamment après une mise à jour du navigateur. Désactivez temporairement l'option d'analyse HTTPS pour tester. Côté navigateur, effacez l'état SSL et les données de navigation, puis testez en navigation privée avec les extensions désactivées : un VPN ou un bloqueur mal configuré produit exactement ce symptôme.

Vérifiez ensuite que votre navigateur n'est pas resté sur une version ancienne : les navigateurs modernes ont retiré le support de TLS 1.0 et 1.1, et à l'inverse un navigateur trop ancien ne connaît pas TLS 1.3. Sur un réseau d'entreprise ou d'école, un proxy d'inspection peut également bloquer certaines négociations — testez depuis une connexion personnelle pour le confirmer.

Cas particulier de Windows : une horloge fausse, une pile TLS désactivée dans les options Internet (TLS 1.2 décoché) ou un système obsolète empêchent la négociation. Réactivez TLS 1.2 dans les options Internet, onglet Avancé.

Causes côté serveur : les cinq classiques

Cause 1, aucune version de TLS commune. Un serveur durci qui n'accepte plus que TLS 1.3 face à un client ancien, ou à l'inverse un serveur bloqué sur TLS 1.0/1.1 face à un navigateur moderne qui a retiré ces protocoles : dans les deux cas, aucune version commune, donc échec. La configuration recommandée aujourd'hui accepte TLS 1.2 et 1.3, et rien en dessous.

Cause 2, aucune suite de chiffrement commune. Même logique, un cran plus bas : le serveur n'accepte que des suites que le client refuse (ou l'inverse). Cela arrive après un durcissement trop agressif copié depuis un article de blog. Repartez d'une configuration de référence maintenue plutôt que d'une liste artisanale.

Cause 3, le serveur répond en clair sur le port 443. Erreur de configuration fréquente sur nginx quand la directive ssl manque dans le bloc listen : le navigateur envoie une poignée de main TLS et reçoit du HTTP en clair, ce qui produit exactement cette erreur.

Cause 4, un problème de SNI ou de certificat mal chargé sur un serveur qui héberge plusieurs sites : le vhost par défaut répond à la place du bon. Cause 5, plus rare, une taille de clé ou un paramètre Diffie-Hellman refusé par le navigateur (clé RSA inférieure à 2048 bits, paramètres DH faibles).

openssl s_client -connect exemple.com:443 -tls1_2 </dev/null
openssl s_client -connect exemple.com:443 -tls1_3 </dev/null
# « no protocols available » ou « handshake failure » = version refusée

server {
    listen 443 ssl;
    http2 on;
    server_name exemple.com;

    ssl_certificate     /etc/letsencrypt/live/exemple.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/exemple.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
}

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLHonorCipherOrder off

sudo nginx -t && sudo systemctl reload nginx
# ou
sudo apachectl configtest && sudo systemctl reload apache2

Vérifier la correction

Rechargez toujours le service après modification, puis retestez depuis un appareil qui n'a jamais visité le site — le cache TLS du navigateur masque volontiers un correctif partiel. Testez également les variantes avec et sans www, ainsi que les sous-domaines, chacun pouvant avoir sa propre configuration.

Un audit externe confirme l'ensemble en une passe : versions de TLS acceptées, robustesse de la clé du certificat, redirection HTTP vers HTTPS et présence des en-têtes de sécurité. C'est aussi la meilleure façon de vérifier que le durcissement n'a pas laissé de trou ailleurs, car ces erreurs surviennent souvent au milieu d'un chantier de configuration.