SSL Handshake Failed : comment corriger l’erreur 525 et les problèmes TLS ?

L’erreur SSL Handshake Failed signifie que votre navigateur, Cloudflare, une application ou un serveur n’a pas réussi à établir une connexion HTTPS sécurisée. Autrement dit, le client et le serveur n’arrivent pas à se mettre d’accord sur les paramètres de sécurité nécessaires : certificat SSL/TLS, version du protocole, suite de chiffrement, nom de domaine, SNI ou configuration du serveur.

Cette erreur peut apparaître sous plusieurs formes : SSL Handshake Failed, Error 525 SSL Handshake Failed, ERR_SSL_HANDSHAKE_FAILURE_ALERT, TLS handshake failed, ou encore SSL certificate problem selon le navigateur, le CDN, l’application ou l’outil utilisé.

Dans la plupart des cas, le problème vient soit d’un certificat SSL expiré ou mal installé, soit d’une configuration TLS incompatible, soit d’un serveur d’origine inaccessible en HTTPS, notamment lorsque le site passe par Cloudflare. Cloudflare explique par exemple que l’erreur 525 apparaît lorsque le handshake SSL échoue entre Cloudflare et le serveur d’origine, généralement avec le mode SSL Full ou Full Strict activé.

La bonne nouvelle, c’est que cette erreur se corrige souvent avec une méthode simple : identifier si le problème vient de votre appareil, du navigateur, du certificat, du serveur web ou de Cloudflare. Ce guide vous accompagne étape par étape pour comprendre l’origine du blocage et appliquer la bonne solution.

Que signifie SSL Handshake Failed ?

SSL Handshake Failed signifie qu’une connexion HTTPS n’a pas pu être établie entre un client et un serveur. Le navigateur ou le service distant tente de négocier une connexion chiffrée, mais le processus échoue à cause d’un certificat invalide, d’une incompatibilité TLS, d’un mauvais chiffrement, d’un problème SNI, d’un pare-feu ou d’une mauvaise configuration Cloudflare.

Quand vous ouvrez une page en HTTPS, votre navigateur ne charge pas immédiatement le contenu. Il commence par vérifier si le serveur peut créer une connexion sécurisée. Cette phase s’appelle le handshake SSL/TLS.

Pendant ce handshake, plusieurs choses se passent en quelques millisecondes :

1. le navigateur contacte le serveur ;
2. le serveur présente son certificat SSL/TLS ;
3. les deux parties choisissent une version du protocole TLS ;
4. elles sélectionnent une suite de chiffrement compatible ;
5. le navigateur vérifie si le certificat est valide ;
6. une clé de session est créée pour chiffrer les échanges.

Si l’une de ces étapes échoue, la connexion HTTPS est interrompue. C’est là que vous pouvez voir une erreur comme SSL Handshake Failed.

Google Apigee décrit ce type d’échec comme une situation où le client et le serveur ne parviennent pas à établir une communication avec le protocole TLS/SSL. Les causes possibles incluent un décalage de protocole, une suite de chiffrement incompatible, un certificat incorrect, une chaîne de certificats invalide ou un problème lié au SNI.

En pratique, cette erreur peut donc venir de deux côtés :

Avant d’appliquer une solution, il faut donc savoir dans quelle situation vous êtes.

Diagnostic rapide : quelle solution appliquer selon votre cas ?

Si l’erreur SSL Handshake Failed apparaît sur un seul site et plusieurs appareils, le problème vient probablement du site. Si elle apparaît partout sur votre appareil, vérifiez la date, le navigateur, l’antivirus, le VPN ou le proxy. Si vous utilisez Cloudflare, l’erreur 525 indique surtout un problème SSL/TLS entre Cloudflare et le serveur d’origine.

Voici le diagnostic le plus rapide :

Si votre erreur concerne spécifiquement Citrix, un certificat racine non reconnu ou un message du type “SSL Error 61”, consultez aussi notre guide dédié : comment réparer une erreur SSL 61. Cette erreur est différente de “SSL Handshake Failed”, mais elle appartient au même groupe de problèmes liés aux certificats SSL/TLS et à la chaîne de confiance.

Le plus important est de ne pas appliquer les solutions dans le désordre. Par exemple, vider le cache du navigateur ne réparera pas un certificat expiré sur le serveur. À l’inverse, modifier la configuration Nginx ne servira à rien si le problème vient simplement de l’horloge de votre ordinateur.

La bonne méthode consiste à commencer par les vérifications simples, puis à passer aux tests serveur.

Qu’est-ce qu’un handshake SSL/TLS ?

Un handshake SSL/TLS est la négociation de sécurité qui précède une connexion HTTPS. Le client et le serveur s’échangent des informations pour choisir une version TLS, vérifier le certificat, sélectionner un algorithme de chiffrement et créer une clé de session. Si cette négociation échoue, la connexion sécurisée est annulée.

Même si l’expression “SSL Handshake” reste très utilisée, le protocole moderne réellement utilisé aujourd’hui est TLS, successeur de SSL. Dans le langage courant, beaucoup d’utilisateurs et d’outils parlent encore de “SSL”, mais les connexions HTTPS actuelles reposent sur TLS.

Le rôle du handshake est simple : permettre à deux machines qui ne se connaissent pas encore de créer une connexion sécurisée. Pour y parvenir, elles doivent répondre à plusieurs questions :

• le serveur est-il bien celui qu’il prétend être ?
• le certificat présenté correspond-il au nom de domaine ?
• le certificat est-il encore valide ?
• l’autorité de certification est-elle reconnue ?
• le navigateur et le serveur supportent-ils la même version de TLS ?
• les deux parties acceptent-elles une suite de chiffrement commune ?
• le serveur sait-il quel certificat présenter si plusieurs sites partagent la même adresse IP ?

Cette dernière question est importante pour le SNI, ou Server Name Indication. Le SNI permet au client d’indiquer le nom de domaine qu’il souhaite joindre pendant la négociation TLS. Sans SNI, un serveur qui héberge plusieurs sites peut présenter le mauvais certificat ou ne pas savoir quel certificat utiliser.

C’est pour cette raison que certains vieux navigateurs, vieux systèmes d’exploitation, proxys d’entreprise ou clients techniques peuvent déclencher des erreurs de handshake même si le certificat du site semble valide.

SSL, TLS et HTTPS : quelle différence ?

SSL est l’ancien nom historique du protocole de chiffrement, TLS est son remplaçant moderne, et HTTPS est l’utilisation de HTTP au-dessus de TLS. Quand un navigateur affiche un cadenas HTTPS, cela signifie qu’une connexion TLS a été établie correctement entre le navigateur et le serveur.

Ces trois termes sont souvent confondus :

Dans la pratique, quand on parle de “certificat SSL”, on parle presque toujours d’un certificat utilisé avec TLS. Cette expression reste populaire parce qu’elle est plus connue du grand public, des hébergeurs et des interfaces d’administration.

Pour un propriétaire de site, la nuance importante est la suivante : installer un certificat ne suffit pas toujours. Il faut aussi que le serveur soit correctement configuré pour utiliser TLS, présenter la bonne chaîne de certificats et accepter des versions de protocole compatibles avec les navigateurs modernes.

Mozilla maintient d’ailleurs un générateur de configuration SSL/TLS permettant de produire des configurations adaptées à plusieurs serveurs comme Apache, Nginx, HAProxy, Caddy ou Lighttpd.

Pourquoi l’erreur SSL Handshake Failed apparaît-elle ?

L’erreur SSL Handshake Failed apparaît lorsque le client et le serveur ne trouvent pas de configuration de sécurité compatible. Le blocage peut venir d’un certificat expiré, d’un mauvais nom de domaine, d’une chaîne incomplète, d’un protocole TLS non supporté, d’une suite de chiffrement incompatible, d’un problème SNI, d’un pare-feu ou d’un mauvais réglage Cloudflare.

L’erreur peut sembler identique pour l’utilisateur, mais ses causes sont nombreuses. C’est ce qui rend le diagnostic parfois difficile. Le navigateur ne dit pas toujours “le certificat est expiré” ou “le serveur ne supporte pas TLS 1.2”. Il affiche parfois un message générique.

Voici les causes les plus fréquentes.

1. Le certificat SSL/TLS est expiré

Un certificat SSL/TLS possède une période de validité. Lorsqu’il expire, le navigateur ou le client ne peut plus lui faire confiance. Résultat : le handshake peut échouer ou déboucher sur une erreur de certificat.

Depuis mars 2026, les exigences du CA/Browser Forum indiquent une validité maximale de 200 jours pour les certificats serveur publics, avec une réduction prévue à 100 jours en 2027 puis 47 jours en 2029.

Cela signifie que la surveillance et l’automatisation du renouvellement deviennent de plus en plus importantes. Un site qui dépend encore d’un renouvellement manuel risque davantage de subir une interruption HTTPS.

Symptômes possibles :

• le navigateur affiche une erreur de certificat ;
• Cloudflare affiche une erreur 525 ;
• les outils SSL indiquent “certificate expired” ;
• le site fonctionnait avant puis tombe soudainement en erreur.

Solution habituelle : renouveler le certificat, vérifier son installation, puis redémarrer ou recharger le serveur web.

2. Le certificat ne correspond pas au nom de domaine

Un certificat doit couvrir exactement le domaine visité. Par exemple, un certificat prévu pour example.com ne couvre pas forcément www.example.com, sauf si ce nom est inclus dans le certificat.

Le problème peut aussi apparaître après une migration, un changement de sous-domaine ou une mauvaise configuration multi-sites.

Exemples :

• le certificat couvre domaine.fr, mais pas www.domaine.fr ;
• le certificat couvre un ancien nom de domaine ;
• le serveur présente le certificat d’un autre site ;
• le wildcard *.domaine.fr ne couvre pas toujours le domaine racine domaine.fr.

Solution habituelle : réémettre le certificat avec tous les noms nécessaires, souvent via les champs SAN, puis vérifier que le serveur présente le bon certificat.

3. La chaîne de certificats est incomplète

Un certificat SSL/TLS ne fonctionne pas seul. Il s’appuie sur une chaîne de confiance composée du certificat du site, d’un ou plusieurs certificats intermédiaires et d’une autorité racine reconnue.

Si le serveur n’envoie pas les bons certificats intermédiaires, certains navigateurs peuvent réussir à charger le site grâce à leur cache, tandis que d’autres clients échouent. C’est fréquent avec des applications, des clients API, des environnements Linux, Citrix, Java ou de vieux appareils.

Symptômes possibles :

• le site fonctionne dans Chrome mais pas dans une application ;
• curl affiche une erreur de certificat ;
• SSL Labs signale une chaîne incomplète ;
• l’erreur apparaît surtout sur certains systèmes.

Solution habituelle : installer le fichier “fullchain” ou “bundle” fourni par l’autorité de certification, et non uniquement le certificat du domaine.

4. Le serveur utilise une version TLS obsolète

Les anciens protocoles SSL et les vieilles versions TLS ne sont plus acceptés par les navigateurs modernes. Si un serveur n’accepte que des protocoles obsolètes, le client peut refuser la connexion.

Aujourd’hui, une configuration saine doit généralement supporter TLS 1.2 et TLS 1.3. Le détail dépend du serveur, du public cible et des contraintes de compatibilité, mais les anciennes versions doivent être évitées.

Symptômes possibles :

• erreur sur les navigateurs récents ;
• erreur après mise à jour du navigateur ;
• message du type ERR_SSL_VERSION_OR_CIPHER_MISMATCH ;
• échec de handshake dans les outils de diagnostic.

Solution habituelle : activer TLS 1.2 et TLS 1.3 dans Apache, Nginx, HAProxy, Caddy ou le panneau d’hébergement.

5. Les suites de chiffrement sont incompatibles

Une suite de chiffrement définit les algorithmes utilisés pour sécuriser la connexion. Si le client et le serveur n’ont aucune suite compatible en commun, le handshake échoue.

Google Apigee cite le cipher suite mismatch comme l’une des causes possibles d’un échec TLS/SSL : le client utilise une suite de chiffrement que le serveur ne prend pas en charge.

Ce problème est plus fréquent sur :

• vieux serveurs ;
• appliances réseau ;
• reverse proxies ;
• applications Java anciennes ;
• configurations SSL durcies trop agressivement ;
• environnements d’entreprise avec interception TLS.

Solution habituelle : utiliser une configuration TLS moderne mais compatible, par exemple via le générateur de configuration Mozilla ou les recommandations de votre hébergeur.

6. Le serveur ne gère pas correctement SNI

Le SNI permet à un serveur de savoir quel certificat présenter lorsque plusieurs sites HTTPS sont hébergés sur la même adresse IP. Sans SNI, le serveur peut envoyer un certificat incorrect ou fermer la connexion.

Ce problème peut toucher :

• de vieux clients ;
• certains bots ;
• des bibliothèques obsolètes ;
• des proxys ;
• des configurations multi-domaines ;
• des serveurs mal configurés après migration.

Solution habituelle : vérifier que le serveur présente le bon certificat pour le bon nom de domaine avec une commande incluant -servername.

Exemple :

openssl s_client -connect domaine.com:443 -servername domaine.com

Cette commande est plus fiable qu’un simple test sans SNI, car elle indique explicitement au serveur le domaine demandé.

7. Un pare-feu, un antivirus ou un proxy intercepte la connexion

Un pare-feu, un antivirus, un VPN ou un proxy d’entreprise peut provoquer une erreur SSL Handshake Failed lorsqu’il intercepte, filtre ou modifie la connexion HTTPS. Dans ce cas, le navigateur ne dialogue plus directement avec le serveur, ce qui peut créer un conflit de certificat, de protocole TLS ou de suite de chiffrement.

Même si le certificat du site est parfaitement valide, l’erreur peut venir de votre environnement local. Certains antivirus inspectent les connexions HTTPS pour analyser le trafic sécurisé. Des proxys d’entreprise peuvent aussi remplacer le certificat du site par un certificat interne, afin de filtrer ou journaliser les connexions.

Ce fonctionnement peut bloquer le handshake dans plusieurs cas :

• le certificat du proxy n’est pas reconnu par votre appareil ;
• l’antivirus utilise une méthode d’inspection HTTPS obsolète ;
• le VPN force un tunnel incompatible avec certains sites ;
• le proxy de l’entreprise bloque TLS 1.3 ou certaines suites de chiffrement ;
• une extension de navigateur modifie les requêtes HTTPS ;
• un pare-feu coupe la connexion avant la fin de la négociation TLS.

C’est une cause fréquente lorsque l’erreur n’apparaît que sur un ordinateur, un réseau Wi-Fi, un navigateur ou un environnement professionnel précis. Si le même site fonctionne sur votre téléphone en 4G/5G mais pas sur le réseau de l’entreprise, le problème vient probablement du réseau, du proxy, du VPN ou de la politique de sécurité locale.

Pour confirmer, testez le site :

1. sur un autre navigateur ;
2. en navigation privée ;
3. sans VPN ;
4. sans extension ;
5. depuis un autre réseau ;
6. depuis un autre appareil.

Si le site fonctionne ailleurs, inutile de modifier le certificat du serveur. Il faut d’abord corriger l’environnement local.

8. Le port 443 est fermé ou le serveur HTTPS ne répond pas

Le port 443 est le port standard utilisé par HTTPS. Si ce port est fermé, filtré ou mal redirigé, le navigateur ou Cloudflare peut ne pas atteindre correctement le serveur en HTTPS. Résultat : le handshake SSL/TLS ne peut pas se terminer, même si le certificat existe et semble valide dans le panneau d’hébergement.

Un certificat SSL installé ne suffit pas. Le serveur doit aussi accepter les connexions HTTPS sur le bon port. Le port standard est 443. Si ce port est bloqué par le pare-feu, fermé sur le VPS, mal redirigé par un reverse proxy ou non écouté par Apache/Nginx, le handshake échoue avant même que le contenu de la page soit servi.

Ce cas est fréquent après :

• une migration d’hébergement ;
• un changement de VPS ;
• l’installation d’un pare-feu ;
• une mauvaise règle UFW, iptables ou security group ;
• un changement DNS ;
• une activation Cloudflare ;
• une configuration Docker ou reverse proxy incomplète.

Cloudflare cite notamment les problèmes côté serveur d’origine comme cause de l’erreur 525, avec une vérification nécessaire du certificat, du port 443, du SNI et des suites de chiffrement côté origin.

Pour tester rapidement si le port HTTPS répond, utilisez :

curl -Iv https://votredomaine.com

Si la connexion échoue immédiatement, si elle reste bloquée ou si aucun certificat n’est présenté, il faut inspecter la configuration serveur. Sur un VPS Linux, vous pouvez aussi vérifier les ports ouverts avec :

curl -Iv https://votredomaine.com

Si rien n’écoute sur le port 443, Apache, Nginx, Caddy ou votre reverse proxy n’est pas correctement configuré pour HTTPS.

Comment corriger SSL Handshake Failed côté visiteur ?

Si vous êtes simple visiteur, commencez par vérifier la date et l’heure de votre appareil, puis testez un autre navigateur, désactivez temporairement VPN, proxy, antivirus et extensions, videz le cache SSL/DNS et essayez un autre réseau. Si l’erreur persiste sur plusieurs appareils, le problème vient probablement du site.

Avant de penser à un problème serveur, commencez par les corrections simples. Elles prennent quelques minutes et permettent d’écarter les causes locales.

1. Vérifier la date et l’heure de l’appareil

Une date incorrecte peut empêcher le navigateur de valider un certificat SSL/TLS. Les certificats possèdent une date de début et une date d’expiration. Si votre ordinateur pense être dans le passé ou dans le futur, il peut considérer un certificat comme invalide alors qu’il est correct.

À faire :

• activez le réglage automatique de la date et de l’heure ;
• vérifiez le fuseau horaire ;
• redémarrez le navigateur ;
• rechargez le site.

Cette vérification est particulièrement utile après une réinstallation système, un changement de batterie, un dual boot ou une machine virtuelle.

2. Tester un autre navigateur

Si l’erreur apparaît dans Chrome, testez Firefox, Edge ou Safari. Si le site fonctionne dans un autre navigateur, le problème vient probablement du cache, d’une extension, d’un profil corrompu ou d’un réglage spécifique au navigateur.

À faire :

1. ouvrez le site dans un autre navigateur ;
2. testez en navigation privée ;
3. désactivez les extensions ;
4. mettez le navigateur à jour ;
5. redémarrez l’ordinateur.

Si l’erreur disparaît en navigation privée, une extension est probablement responsable. Les extensions de sécurité, VPN, proxy, blocage publicitaire ou analyse de trafic peuvent parfois modifier les connexions HTTPS.

3. Désactiver temporairement VPN, proxy ou antivirus

Un VPN, un proxy ou un antivirus peut intercepter les connexions HTTPS. Cette interception peut provoquer une erreur de handshake si le certificat injecté par l’outil n’est pas reconnu ou si l’outil ne supporte pas correctement la configuration TLS du site.

À tester temporairement :

• couper le VPN ;
• désactiver le proxy système ;
• désactiver l’analyse HTTPS de l’antivirus ;
• changer de réseau ;
• tester depuis un partage de connexion mobile.

Ne laissez pas l’antivirus désactivé durablement. L’objectif est seulement de confirmer ou d’écarter la cause. Si l’erreur disparaît après désactivation, réactivez la protection puis cherchez le réglage précis lié à l’inspection HTTPS.

4. Vider le cache DNS et le cache du navigateur

Après une migration, un renouvellement SSL ou un changement Cloudflare, votre appareil peut conserver d’anciennes informations DNS ou SSL. Cela peut créer un décalage entre l’ancien serveur et le nouveau.

Sur Windows, vous pouvez vider le cache DNS avec :

ipconfig /flushdns

Sur macOS, la commande dépend de la version du système, mais vous pouvez déjà commencer par redémarrer le navigateur et l’ordinateur. Dans Chrome, vous pouvez aussi supprimer les données de navigation, puis relancer le test.

À faire :

• vider le cache du navigateur ;
• vider le cache DNS ;
• redémarrer le navigateur ;
• tester à nouveau le site ;
• essayer un autre réseau.

Cette méthode est surtout utile si l’erreur est apparue juste après un changement DNS, une migration ou une activation HTTPS.

5. Tester depuis un autre appareil ou un autre réseau

Le test le plus simple reste souvent le plus fiable : ouvrez le même site depuis un téléphone en données mobiles. Si le site fonctionne sur mobile mais pas sur votre ordinateur, le problème vient de votre appareil ou de votre réseau.

Si le site échoue partout, le problème vient probablement du site, de son certificat, de son serveur ou de Cloudflare.

Comment corriger SSL Handshake Failed côté site web ?

Si vous gérez le site, commencez par tester le certificat SSL, vérifier sa date d’expiration, son nom de domaine, sa chaîne intermédiaire et le port 443. Ensuite, contrôlez la configuration Apache, Nginx ou Cloudflare, puis inspectez les logs serveur pour identifier une incompatibilité TLS, SNI ou cipher suite.

Lorsque vous êtes propriétaire du site, vous avez plus de leviers. Le diagnostic doit être méthodique : certificat, domaine, chaîne, port, serveur web, TLS, logs.

1. Tester le certificat SSL avec un outil externe

La première étape consiste à vérifier ce que voit un utilisateur externe. Un outil de test SSL permet de détecter rapidement :

• certificat expiré ;
• nom de domaine non couvert ;
• chaîne intermédiaire incomplète ;
• protocole TLS obsolète ;
• cipher suites faibles ou incompatibles ;
• problèmes SNI ;
• configuration HTTPS incomplète.

Utilisez un outil comme SSL Labs Server Test ou l’outil proposé par votre hébergeur. Ne vous contentez pas du panneau WordPress ou du tableau de bord de l’hébergeur : ils peuvent indiquer qu’un certificat est “actif” alors que le serveur présente une mauvaise chaîne ou un mauvais certificat sur le domaine public.

Après le test, vérifiez surtout :

Si le test signale une chaîne incomplète, réinstallez le certificat avec le fichier complet fourni par l’autorité de certification. Sur Let’s Encrypt, cela correspond généralement au fichier fullchain.pem.

2. Renouveler ou réinstaller le certificat SSL

Si le certificat est expiré, corrompu ou mal installé, la solution est de le renouveler ou de le réinstaller. Sur beaucoup d’hébergements mutualisés, cette opération se fait depuis le panneau de contrôle : cPanel, Plesk, hPanel, Site Tools ou interface propriétaire.

Sur un VPS, Certbot est souvent utilisé pour installer HTTPS et continuer à renouveler les certificats automatiquement. La documentation officielle indique que Certbot sert à passer un site HTTP en HTTPS puis à renouveler ses certificats lorsque nécessaire.

Exemple de renouvellement manuel :

sudo certbot renew

Après renouvellement, rechargez le serveur web :

sudo systemctl reload nginx

ou :

sudo systemctl reload apache2

Puis testez à nouveau :

curl -Iv https://votredomaine.com

À ne pas oublier : un certificat renouvelé mais non rechargé par le serveur peut continuer à poser problème. Il faut vérifier que Nginx, Apache, Caddy ou le reverse proxy utilise bien le nouveau certificat.

3. Vérifier que le certificat couvre toutes les variantes du domaine

Une erreur fréquente consiste à installer un certificat pour une seule variante du domaine.

Exemple :

• certificat valide pour critiqueplus.com ;
• mais pas pour www.critiqueplus.com.

Ou inversement.

Pour éviter cela, le certificat doit couvrir toutes les variantes réellement utilisées :

• domaine racine ;
• version www ;
• sous-domaines importants ;
• domaine temporaire si nécessaire ;
• alias ou domaines redirigés.

Un certificat wildcard comme *.domaine.com couvre généralement les sous-domaines de premier niveau, comme blog.domaine.com, mais pas forcément le domaine racine domaine.com. Il faut donc vérifier les SAN du certificat plutôt que supposer que tout est couvert.

4. Installer la chaîne complète de certificats

Une chaîne incomplète peut provoquer des erreurs difficiles à reproduire. Certains navigateurs corrigent automatiquement le problème grâce à leur cache, mais des clients plus stricts échouent.

C’est souvent le cas avec :

• applications mobiles ;
• API ;
• Java ;
• Citrix ;
• vieux systèmes ;
• environnements Linux minimalistes ;
• outils en ligne de commande.

Si vous rencontrez une erreur liée à la chaîne de confiance, vous pouvez également consulter notre guide dédié à l’erreur SSL 61, car ce problème est souvent lié à un certificat racine ou intermédiaire non reconnu.

Sur Nginx, vérifiez que vous utilisez le fichier complet :

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

Sur Apache, la configuration peut varier selon la version, mais l’idée reste la même : le serveur doit envoyer la chaîne complète au client.

5. Activer TLS 1.2 et TLS 1.3

Un serveur qui n’accepte que de vieilles versions TLS peut être rejeté par les navigateurs modernes. À l’inverse, une configuration trop restrictive peut bloquer de vieux clients encore nécessaires dans certains environnements professionnels.

Une configuration moderne doit généralement privilégier TLS 1.2 et TLS 1.3. Mozilla propose un générateur de configuration SSL/TLS pour plusieurs serveurs, dont Apache, Nginx, HAProxy, Caddy, Postfix, Tomcat et d’autres logiciels.

Exemple Nginx :

ssl_protocols TLSv1.2 TLSv1.3;

Exemple Apache :

SSLProtocol -all +TLSv1.2 +TLSv1.3

Après modification, rechargez le serveur web et testez à nouveau. Une erreur SSL Handshake Failed peut disparaître simplement parce que le client et le serveur retrouvent enfin un protocole commun.

6. Corriger les suites de chiffrement incompatibles

Si le serveur et le client ne partagent aucune suite de chiffrement compatible, la négociation TLS échoue. Google Apigee cite le mismatch de protocole, le mismatch de cipher suite, les certificats incorrects, les chaînes invalides ou expirées et les problèmes SNI parmi les causes possibles d’échec TLS/SSL.

Ce problème peut arriver après une tentative de “durcissement” de la sécurité. Par exemple, un administrateur peut supprimer trop de suites de chiffrement pour obtenir une meilleure note dans un outil de test, mais bloquer certains clients légitimes.

La bonne approche consiste à :

1. partir d’une configuration recommandée ;
2. garder TLS 1.2 et TLS 1.3 ;
3. éviter les protocoles obsolètes ;
4. tester avec plusieurs navigateurs ;
5. tester avec curl et openssl ;
6. surveiller les logs.

Sur Nginx, la configuration des cipher suites dépend du profil choisi et de la compatibilité souhaitée. Pour éviter les erreurs, utilisez une configuration générée par un outil reconnu, puis testez avant de déployer en production.

Comment corriger l’erreur sur WordPress ?

Sur WordPress, SSL Handshake Failed vient rarement du CMS lui-même. Le problème se situe généralement au niveau du certificat, de l’hébergeur, de Cloudflare, du domaine www/non-www, d’une redirection HTTPS incorrecte ou d’un plugin SSL mal configuré. Il faut donc vérifier le serveur avant de modifier WordPress.

WordPress affiche parfois des erreurs HTTPS, mais le handshake se produit avant même que WordPress ne génère la page. Cela signifie que le cœur du problème se trouve souvent plus bas : DNS, serveur, certificat, hébergeur, CDN ou reverse proxy.

1. Vérifier les URL WordPress

Dans WordPress, allez dans :

Réglages → Général

Vérifiez que les deux champs suivants utilisent bien HTTPS :

• Adresse web de WordPress ;
• Adresse web du site.

Exemple correct :

https://votredomaine.com

Évitez de mélanger http://, https://, www et non-www sans stratégie claire. Une mauvaise cohérence peut provoquer des redirections en boucle ou des erreurs HTTPS après migration.

2. Contrôler les redirections HTTPS

Un site WordPress peut forcer HTTPS via :

• le fichier .htaccess ;
• Nginx ;
• un plugin SSL ;
• Cloudflare ;
• l’hébergeur ;
• un CDN ;
• une règle dans wp-config.php.

Le problème apparaît quand plusieurs couches forcent HTTPS de façon contradictoire. Par exemple, Cloudflare force HTTPS, WordPress force HTTPS, et le serveur renvoie vers HTTP ou vers une mauvaise variante du domaine.

À vérifier :

• une seule version canonique du domaine ;
• redirection HTTP → HTTPS ;
• redirection www → non-www, ou inversement ;
• absence de boucle ;
• cohérence avec le certificat installé.

3. Désactiver temporairement les plugins SSL en cas de conflit

Des plugins comme Really Simple SSL peuvent être utiles, mais ils ne remplacent pas une configuration serveur correcte. Si le certificat est expiré ou si Cloudflare ne peut pas joindre l’origine en HTTPS, aucun plugin WordPress ne réparera le handshake.

En cas de doute :

1. vérifiez le certificat avec un outil externe ;
2. désactivez temporairement le plugin SSL ;
3. testez le site ;
4. vérifiez les redirections serveur ;
5. réactivez le plugin seulement si la configuration HTTPS est saine.

Le plugin doit accompagner la configuration, pas masquer un problème serveur.

4. Demander à l’hébergeur de vérifier le serveur d’origine

Sur un hébergement mutualisé, vous n’avez pas toujours accès aux logs Apache/Nginx ni à la configuration TLS. Dans ce cas, contactez l’hébergeur avec des informations précises :

• domaine concerné ;
• message exact ;
• heure du test ;
• capture d’écran ;
• résultat SSL Labs ;
• présence ou non de Cloudflare ;
• test depuis plusieurs réseaux ;
• mention éventuelle de l’erreur 525.

Plus votre demande est précise, plus l’hébergeur pourra vérifier rapidement le certificat, le port 443, le vhost, SNI, la chaîne intermédiaire et les logs.

Comment corriger Cloudflare Error 525 SSL Handshake Failed ?

Cloudflare Error 525 signifie que Cloudflare a réussi à joindre le serveur d’origine, mais n’a pas pu terminer le handshake SSL/TLS avec lui. Cette erreur apparaît généralement lorsque Cloudflare est en mode Full ou Full Strict et que le certificat, le port 443, le SNI ou les suites de chiffrement du serveur d’origine posent problème.

L’erreur 525 est l’un des cas les plus fréquents de SSL Handshake Failed sur les sites qui utilisent Cloudflare. Elle ne signifie pas forcément que Cloudflare est en panne. Elle indique surtout que la connexion HTTPS entre Cloudflare et votre hébergement ne fonctionne pas correctement.

Pour comprendre le problème, il faut visualiser le trajet :

Visiteur → Cloudflare → Serveur d’origine

Le visiteur ne se connecte pas directement à votre serveur. Il passe d’abord par Cloudflare. Si Cloudflare ne parvient pas à établir une connexion HTTPS valide avec votre serveur d’origine, il affiche une erreur 525.

1. Vérifier le mode SSL/TLS dans Cloudflare

Dans Cloudflare, allez dans :

SSL/TLS → Overview

Vérifiez le mode actif :

Pour un site sérieux, le mode recommandé est généralement Full Strict, mais seulement si le serveur d’origine possède un certificat valide et correctement installé.

Si vous activez Full Strict alors que le certificat du serveur d’origine est expiré, mal installé, auto-signé sans configuration adaptée ou absent, Cloudflare peut afficher une erreur 525.

2. Vérifier le certificat du serveur d’origine

Une erreur fréquente consiste à croire que le certificat visible côté Cloudflare suffit. Ce n’est pas le cas. Cloudflare peut avoir un certificat valide côté visiteur, mais le serveur d’origine doit lui aussi répondre correctement en HTTPS.

À vérifier côté hébergement :

• certificat installé sur le serveur ;
• certificat non expiré ;
• domaine et version www couverts ;
• chaîne intermédiaire complète ;
• serveur accessible en HTTPS ;
• port 443 ouvert ;
• certificat présenté avec SNI.

Testez votre serveur avec :

openssl s_client 
-connect votredomaine.com:443 
-servername votredomaine.com

Si la commande renvoie un certificat expiré, un certificat d’un autre domaine ou une erreur de chaîne, le problème vient probablement de l’origine.

3. Désactiver temporairement le proxy Cloudflare pour tester l’origine

Dans l’interface DNS de Cloudflare, vous pouvez passer temporairement l’enregistrement du domaine ou du sous-domaine en DNS only au lieu de Proxied. Le nuage devient gris.

Ce test permet de voir si le serveur fonctionne correctement sans Cloudflare.

À faire avec prudence :

1. noter l’état actuel de la configuration ;
2. passer le domaine en DNS only ;
3. attendre la propagation courte ;
4. tester https://votredomaine.com ;
5. remettre le proxy Cloudflare après le test.

Si le site ne fonctionne pas sans Cloudflare, le problème vient du serveur d’origine. Si le site fonctionne sans Cloudflare mais échoue avec Cloudflare, vérifiez le mode SSL/TLS, le certificat origin, SNI, les règles Cloudflare et les paramètres de sécurité.

4. Vérifier le port 443 et le pare-feu

Cloudflare doit pouvoir joindre votre serveur sur le port HTTPS. Si le port 443 est fermé ou filtré, le handshake ne peut pas se terminer.

Sur un VPS, vérifiez que le serveur écoute bien :

sudo ss -tlnp | grep ':443'

Vérifiez aussi votre pare-feu :

sudo ufw status

Si le port 443 est bloqué, autorisez HTTPS :

sudo ufw allow 443/tcp

Dans certains cas, l’hébergeur ou le fournisseur cloud ajoute aussi des règles réseau externes : security groups, firewall manager, protection anti-DDoS, filtrage CDN ou règles d’accès IP. Il faut alors autoriser les plages IP Cloudflare si l’origine bloque les connexions entrantes.

5. Vérifier SNI sur le serveur d’origine

Cloudflare peut échouer si le serveur d’origine ne présente pas le bon certificat avec SNI. Le SNI est particulièrement important lorsque plusieurs sites partagent la même adresse IP.

Testez avec :

openssl s_client -connect votredomaine.com:443 -servername votredomaine.com

Puis comparez avec :

openssl s_client -connect votredomaine.com:443

Si le certificat présenté change ou si la commande sans -servername échoue, il peut y avoir un problème de configuration multi-sites. Google Apigee cite d’ailleurs les problèmes SNI parmi les causes possibles d’échecs TLS, notamment quand aucun certificat par défaut n’est présenté au client.

6. Contacter l’hébergeur avec les bons éléments

Si vous êtes sur un hébergement mutualisé, vous n’aurez pas toujours accès aux logs ni à la configuration TLS. Dans ce cas, envoyez une demande précise à l’hébergeur.

Message type :

Bonjour,

Mon site affiche une erreur Cloudflare 525 SSL Handshake Failed.

Domaine concerné : votredomaine.com
Mode Cloudflare : Full / Full Strict
Erreur observée : Error 525
Heure du test : [date + heure]
Tests effectués :
- certificat SSL vérifié ;
- port 443 testé ;
- erreur reproduite sur plusieurs appareils ;
- proxy Cloudflare activé.

Pouvez-vous vérifier le certificat SSL du serveur d’origine, la chaîne intermédiaire, SNI, le port 443, la configuration TLS et les logs Apache/Nginx ?

Merci.

Cette demande est plus efficace qu’un simple “mon site ne marche pas”, car elle oriente directement le support vers les causes probables.

Commandes utiles pour diagnostiquer SSL Handshake Failed

Les commandes les plus utiles sont openssl s_client pour inspecter le certificat et le handshake, curl -Iv pour tester la réponse HTTPS, ss pour vérifier le port 443, et les logs Apache/Nginx pour identifier les erreurs serveur. Elles permettent de distinguer certificat expiré, SNI absent, port fermé et incompatibilité TLS.

Tester le certificat avec OpenSSL

Commande principale :

openssl s_client -connect votredomaine.com:443 -servername votredomaine.com

À regarder dans le résultat :

• le certificat présenté ;
• la date d’expiration ;
• le nom de domaine ;
• l’autorité de certification ;
• la chaîne de certificats ;
• les messages verify error;
• la version TLS utilisée ;
• la cipher suite choisie.

Si vous voyez une erreur de vérification, un certificat expiré ou un certificat qui ne correspond pas au domaine, vous avez probablement trouvé la cause.

Tester HTTPS avec curl

Commande simple :

curl -Iv https://votredomaine.com

Cette commande affiche les en-têtes HTTP et les informations de connexion. Elle permet de voir si le serveur répond bien en HTTPS, s’il redirige correctement et si la négociation TLS aboutit.

Si curl échoue avec une erreur SSL, comparez le résultat avec un navigateur. Si les deux échouent, le problème est probablement côté serveur. Si seul curl échoue, cela peut venir d’une chaîne de certificats incomplète ou d’un environnement local différent.

Vérifier Apache

Sur un serveur Apache, les logs se trouvent souvent ici :

sudo tail -f /var/log/apache2/error.log

ou :

sudo tail -f /var/log/httpd/error_log

Selon la distribution Linux, le chemin peut changer. Cherchez des messages liés à SSL, TLS, certificate, handshake, SNI ou vhost.

Après modification de configuration, testez Apache :

sudo apachectl configtest

Puis rechargez :

sudo systemctl reload apache2

Vérifier Nginx

Sur Nginx, commencez par tester la configuration :

sudo nginx -t

Puis consultez les logs :

sudo tail -f /var/log/nginx/error.log

Rechargez ensuite Nginx :

sudo systemctl reload nginx

Les erreurs fréquentes concernent un mauvais chemin vers fullchain.pem, un certificat supprimé, une clé privée incorrecte, un vhost mal configuré ou une directive TLS incompatible.

Tester le port 443

Pour vérifier que le serveur écoute sur HTTPS :

sudo ss -tlnp | grep ':443'

Si rien n’apparaît, votre serveur web ne répond pas sur le port HTTPS. Il faut vérifier le vhost, le pare-feu, le reverse proxy ou le service web.

Comment éviter que l’erreur SSL Handshake Failed revienne ?

Pour éviter que SSL Handshake Failed revienne, automatisez le renouvellement des certificats, surveillez leur expiration, gardez TLS 1.2 et TLS 1.3 actifs, utilisez une configuration serveur recommandée, documentez vos réglages Cloudflare et testez HTTPS après chaque migration, changement DNS ou modification d’hébergement.

Corriger l’erreur une fois ne suffit pas. Un site peut retomber en erreur après un renouvellement raté, une migration, une mise à jour serveur ou une modification Cloudflare.

1. Automatiser le renouvellement des certificats

Le renouvellement manuel devient de plus en plus risqué. Le CA/Browser Forum a adopté une réduction progressive de la durée maximale des certificats TLS publics, avec une trajectoire vers 47 jours à partir de 2029.

Cela signifie qu’un site doit idéalement automatiser ses certificats via l’hébergeur, Let’s Encrypt, ACME ou une solution de gestion centralisée des certificats.

À vérifier :

• renouvellement automatique actif ;
• e-mail d’alerte fonctionnel ;
• certificat renouvelé avant expiration ;
• serveur rechargé après renouvellement ;
• test HTTPS après chaque renouvellement.

2. Surveiller l’expiration SSL

Ajoutez une surveillance externe. Beaucoup d’outils peuvent envoyer une alerte avant expiration du certificat. L’objectif est d’éviter de découvrir le problème lorsque les visiteurs ne peuvent déjà plus accéder au site.

À surveiller :

• domaine principal ;
• version www ;
• sous-domaines ;
• certificats API ;
• domaines de staging publics ;
• certificats utilisés par les reverse proxies ;
• certificats du serveur d’origine derrière Cloudflare.

3. Utiliser une configuration TLS moderne

Ne copiez pas une vieille configuration Apache ou Nginx trouvée dans un ancien tutoriel. Les recommandations évoluent. Mozilla propose un générateur de configuration SSL/TLS pour plusieurs serveurs, ce qui permet de partir d’une base plus fiable qu’une configuration improvisée.

L’objectif est de garder un équilibre entre sécurité et compatibilité. Pour la plupart des sites, il faut éviter les vieux protocoles et conserver une configuration compatible avec les navigateurs modernes.

4. Tester HTTPS après chaque changement important

Refaites un test SSL/TLS après chaque opération sensible :

• migration d’hébergement ;
• changement DNS ;
• activation Cloudflare ;
• passage en Full Strict ;
• changement de certificat ;
• installation d’un reverse proxy ;
• mise à jour Nginx ou Apache ;
• changement de plugin SSL WordPress ;
• modification du fichier .htaccess.

Un test de deux minutes peut éviter plusieurs heures d’indisponibilité.

5. Documenter la configuration HTTPS

Gardez une note interne avec :

• hébergeur utilisé ;
• autorité de certification ;
• méthode de renouvellement ;
• emplacement des certificats ;
• mode Cloudflare ;
• domaine canonique ;
• règles de redirection ;
• commandes utiles ;
• contact support hébergeur.

Cette documentation devient précieuse si l’erreur revient ou si vous changez d’hébergeur.

FAQ

Que signifie SSL Handshake Failed ?

SSL Handshake Failed signifie que le client et le serveur n’ont pas réussi à établir une connexion HTTPS sécurisée. L’échec peut venir d’un certificat invalide, d’une chaîne incomplète, d’une version TLS incompatible, d’une suite de chiffrement non supportée, d’un problème SNI, d’un proxy ou d’une mauvaise configuration serveur.

Quelle est la différence entre SSL Handshake Failed et Cloudflare Error 525 ?

SSL Handshake Failed est un terme général. Cloudflare Error 525 est un cas spécifique : Cloudflare n’arrive pas à terminer le handshake SSL/TLS avec le serveur d’origine. Cloudflare indique que cette erreur apparaît lorsque le handshake échoue entre Cloudflare et l’origine, avec le mode Full ou Full Strict activé.

L’erreur vient-elle de mon ordinateur ou du site ?

Si l’erreur apparaît sur un seul appareil, testez la date, l’heure, le navigateur, le VPN, l’antivirus et le réseau. Si elle apparaît sur plusieurs appareils et plusieurs réseaux, le problème vient probablement du site, de son certificat, de son serveur ou de Cloudflare.

Comment corriger SSL Handshake Failed sur Chrome ?

Sur Chrome, commencez par mettre le navigateur à jour, vérifier la date et l’heure, vider le cache, désactiver les extensions, couper temporairement VPN/proxy/antivirus, puis tester un autre réseau. Si l’erreur reste visible sur plusieurs appareils, le propriétaire du site doit corriger le serveur.

Pourquoi mon certificat est valide mais l’erreur continue ?

Un certificat valide ne garantit pas que HTTPS fonctionne. Le problème peut venir d’une chaîne intermédiaire incomplète, d’un mauvais certificat présenté avec SNI, d’un port 443 fermé, d’une version TLS incompatible, d’un mauvais vhost Apache/Nginx ou d’une configuration Cloudflare incorrecte.

Comment tester SSL Handshake Failed avec OpenSSL ?

Utilisez cette commande :

openssl s_client -connect votredomaine.com:443 -servername votredomaine.com

Elle permet de voir le certificat présenté, la chaîne de confiance, la version TLS, la suite de chiffrement et les éventuelles erreurs de vérification.

Que faire si l’erreur concerne Citrix ou SSL 61 ?

Si le message parle de SSL Error 61, de certificat racine non reconnu ou de chaîne de confiance Citrix, le problème est proche mais différent. Consultez notre guide dédié pour réparer une erreur SSL 61, car cette erreur concerne souvent un certificat racine ou intermédiaire absent côté client.

Cloudflare Flexible SSL peut-il corriger l’erreur 525 ?

Le mode Flexible peut parfois masquer un problème côté origine, mais il n’est pas une vraie correction. Il chiffre la connexion entre le visiteur et Cloudflare, mais pas forcément entre Cloudflare et le serveur. Pour une configuration propre, mieux vaut installer un certificat valide sur l’origine et utiliser Full Strict.

Quand faut-il contacter l’hébergeur ?

Contactez l’hébergeur si vous n’avez pas accès aux logs, si le port 443 semble fermé, si le certificat est installé mais non servi, si Cloudflare affiche une erreur 525 ou si la configuration Apache/Nginx dépend d’un panneau d’hébergement. Fournissez toujours le domaine, l’heure du test, le message exact et les résultats SSL.

Conclusion

L’erreur SSL Handshake Failed indique un échec de négociation HTTPS. Elle peut venir d’un simple problème local, comme une mauvaise date ou un antivirus trop intrusif, mais aussi d’un problème plus sérieux côté serveur : certificat expiré, chaîne incomplète, TLS incompatible, SNI mal configuré, port 443 fermé ou erreur Cloudflare 525.

La meilleure méthode consiste à avancer dans l’ordre : vérifier l’appareil, tester le navigateur, contrôler le certificat, analyser le serveur, puis examiner Cloudflare ou les logs Apache/Nginx. Si vous gérez un site WordPress, gardez en tête que le problème se situe rarement dans WordPress lui-même : il vient plus souvent du certificat, de l’hébergement, du CDN ou de la configuration HTTPS.

Pour éviter que l’erreur revienne, automatisez les renouvellements SSL, surveillez l’expiration des certificats, utilisez une configuration TLS moderne et testez HTTPS après chaque changement important. Un site bien configuré doit pouvoir établir un handshake TLS propre, présenter le bon certificat et servir ses pages en HTTPS sans interruption.