Erreur 525 Cloudflare : ce que ça veut dire
L’erreur 525 Cloudflare signifie que la négociation du chiffrement (handshake SSL/TLS) entre Cloudflare et votre serveur d’origine a échoué. Le visiteur atteint bien Cloudflare, mais Cloudflare ne parvient pas à ouvrir une connexion HTTPS avec votre hébergeur : certificat absent ou expiré, port 443 fermé, SNI manquant ou versions TLS incompatibles.
Le handshake TLS désigne l’échange initial où deux machines choisissent une version de TLS et une suite de chiffrement, puis vérifient un certificat, avant de s’envoyer la moindre donnée. C’est cet échange qui casse ici, sur le tronçon Cloudflare vers origine. La documentation Cloudflare sur l’erreur 525 le confirme : le 525 se règle côté serveur d’origine, pas dans le site.
Prenons un cas typique (illustratif) : vous changez d’hébergeur, vous faites pointer Cloudflare vers la nouvelle IP, le mode SSL reste sur Full (strict), et le nouveau serveur n’a pas encore émis son certificat. Résultat : un 525 sur tout le site. C’est gérable, et la correction est méthodique.
Ne confondez pas avec les autres erreurs de la série : le 521 signale un serveur qui refuse la connexion, le 523 une origine injoignable, le 524 un délai dépassé, le 520 une réponse inconnue. Parmi eux, le 525 est celui où la connexion s’établit mais où la négociation du chiffrement échoue. Son voisin, le 526, signale un certificat d’origine que Cloudflare refuse (voir la FAQ).
Pourquoi ça arrive
- Aucun certificat valide installé sur l’origine, ou certificat expiré (renouvellement automatique en échec).
- Chaîne de certificats incomplète ou obsolète : le certificat du domaine semble valide, mais un certificat intermédiaire ou racine ne l’est plus. Un témoignage sur le forum Cloudflare décrit ce cas (anecdotique, mais courant).
- Port 443 fermé ou filtré par un pare-feu (ou l’autre port sécurisé que vous utilisez).
- SNI absent ou mal configuré sur le serveur.
- Versions TLS ou suites de chiffrement incompatibles entre Cloudflare et l’origine.
- Mode SSL Full ou Strict sur une origine qui ne sert pas de HTTPS fonctionnel.
1. Vérifier le certificat côté hébergeur
C’est la cause la plus fréquente, donc le premier test.
- Ouvrez le panel de l’hébergeur : cPanel > SSL/TLS Status (AutoSSL), Plesk > Let’s Encrypt, ou l’espace SSL de votre hébergeur.
- Vérifiez que le domaine exact (avec et sans www) a un certificat actif et non expiré.
- Relancez l’émission ou le renouvellement si le statut est en erreur.
- Contrôlez la chaîne : installez le fichier « fullchain » (certificat plus intermédiaires), pas seulement le certificat seul.
Pour tester depuis votre poste, en remplaçant IP_ORIGINE et exemple.fr :
openssl s_client -connect IP_ORIGINE:443 -servername exemple.frUne ligne Verify return code: 0 (ok) indique une chaîne valide. Autre option : le test en ligne SSL Labs. Si le certificat est invalide, passez à l’étape 5 pour en installer un.
2. Vérifier que le port 443 est ouvert
Un pare-feu qui bloque le 443 produit le même symptôme qu’un certificat absent.
- Pare-feu de l’hébergeur : autorisez le port 443 entrant.
- Serveur géré par vous :
sudo ufw statusousudo iptables -L, puissudo ufw allow 443/tcp. - Vérifiez que le serveur web (Apache, Nginx) écoute bien en HTTPS :
sudo ss -tlnp | grep 443.
3. Corriger le SNI et le virtual host
Le SNI (Server Name Indication) est une extension de TLS qui permet au visiteur d’indiquer le nom de domaine voulu avant la présentation du certificat. Elle existe parce que TLS seul ne permet pas au client de désigner le serveur contacté sur une adresse partagée source : IETF, RFC 6066, 2011.
Sur un serveur qui héberge plusieurs sites, un SNI absent ou un bloc server mal rattaché fait présenter le mauvais certificat, ou aucun. Vérifiez que votre domaine a son propre virtual host HTTPS (listen 443 ssl et server_name sous Nginx, VirtualHost *:443 et ServerName sous Apache), avec le bon certificat. Si l’origine est un très vieux serveur sans support SNI, la documentation Cloudflare le liste parmi les causes du 525.
4. Aligner les versions TLS et les suites de chiffrement
Cloudflare propose ses suites de chiffrement à l’origine, et l’origine en choisit une. Elle doit donc en supporter au moins une en commun avec Cloudflare source : Cloudflare, 2026. Les suites TLS 1.3 sont distinctes de celles de TLS 1.2 source : IETF, RFC 8446, 2018.
Sous Nginx, une base saine :
ssl_protocols TLSv1.2 TLSv1.3;Un serveur limité à TLS 1.0 ou 1.1, ou à des chiffrements anciens, est la cause typique d’un 525 sur une vieille machine. Mettez à jour OpenSSL et le serveur web plutôt que de rouvrir les anciens protocoles. TLS 1.2 est aussi le minimum de PCI DSS v4.0 d’après Cloudflare, 2026.
5. Installer un certificat d’origine, puis choisir le bon mode SSL
Sans certificat valide, deux options :
- Un certificat d’une autorité publique (Let’s Encrypt via votre hébergeur).
- Un certificat Cloudflare Origin CA, gratuit et valable jusqu’à 15 ans source : Cloudflare, 2026.
Un certificat Origin CA est un certificat émis par Cloudflare, reconnu uniquement par Cloudflare : si vous passez le DNS en « nuage gris » (proxy désactivé), les navigateurs afficheront une erreur de certificat.
Ensuite, réglez le mode dans Cloudflare > SSL/TLS > Vue d’ensemble :
| Mode | Comportement vers l’origine | Quand l’utiliser |
|---|---|---|
| Full | HTTPS, certificat non validé | Dépannage temporaire |
| Full (strict) | HTTPS, certificat validé | Mode cible en production |
| Strict (SSL-Only Origin Pull) | Toujours HTTPS, certificat validé | Offre Enterprise uniquement |
Source : Cloudflare, modes de chiffrement. Le mode Full (strict) correspond à une connexion HTTPS dont Cloudflare vérifie le certificat d’origine (autorité publique ou Origin CA). Visez-le, c’est la recommandation de Cloudflare. Sachez aussi que si le certificat expire, Cloudflare ne repasse pas tout seul de Full (strict) à Full.
Ne passez surtout pas en Flexible pour faire disparaître l’erreur : le trafic cesse d’être chiffré entre Cloudflare et l’origine, et vous risquez une boucle de redirection ou du contenu mixte. Le certificat doit être corrigé, pas contourné.
6. Lire les journaux d’erreurs pour les 525 intermittents
Un 525 qui apparaît par moments pointe vers une charge, un renouvellement partiel ou un pare-feu qui limite Cloudflare. Consultez les journaux de l’origine : /var/log/nginx/error.log ou le journal Apache (la doc Cloudflare conseille de configurer la journalisation de mod_ssl). Cherchez les lignes « handshake », « no shared cipher » ou « unknown protocol ». Si votre hébergeur change souvent l’IP d’origine, mettez à jour l’enregistrement dans la zone DNS Cloudflare.
Tableau récapitulatif : cause → solution
| Symptôme / cause | Test | Solution |
|---|---|---|
| Certificat absent ou expiré | openssl s_client | Réémettre (AutoSSL, Let’s Encrypt) ou Origin CA |
| Chaîne incomplète | SSL Labs | Installer le fullchain |
| Port 443 fermé | ss -tlnp | Ouvrir le port dans le pare-feu |
| SNI absent | Mauvais certificat présenté | Virtual host dédié par domaine |
| TLS ou suites incompatibles | Journaux no shared cipher | TLSv1.2 TLSv1.3, mise à jour serveur |
| Mode inadapté | Réglage Cloudflare | Full (strict) avec certificat valide |
FAQ
Quelle différence entre l'erreur 525 et l'erreur 526 ?
Le 525 signale que la négociation TLS n’a pas abouti. Le 526 apparaît quand la connexion s’établit mais que Cloudflare, en mode Full (strict), rejette le certificat d’origine (expiré, auto-signé, nom incorrect). Les deux se corrigent en installant un certificat valide à l’origine.
Le 525 peut-il venir de Cloudflare et non de mon hébergeur ?
C’est rare. La documentation Cloudflare place les causes côté origine : certificat, port, SNI. Vérifiez d’abord votre serveur avant d’ouvrir un ticket.
Puis-je passer en mode Full pour me dépanner ?
Oui, temporairement : Full ne valide pas le certificat et accepte les certificats auto-signés. Mais l’origine doit quand même répondre en HTTPS. Revenez à Full (strict) dès que le certificat est valide.
Mon certificat est valide mais le 525 persiste, que faire ?
Contrôlez la chaîne complète (intermédiaires, racine), la version TLS minimale du serveur et les suites de chiffrement. Un certificat feuille valide ne suffit pas si un maillon de la chaîne est périmé.
Quand passer la main à un pro
Passez la main si vous n’avez pas d’accès SSH ou au panel du serveur, si l’hébergeur ne répond pas, ou si le 525 revient après chaque renouvellement de certificat. Un 525 qui réapparaît est souvent un renouvellement automatique mal configuré, et une maintenance suivie surveille précisément les dates d’expiration. Pour un certificat côté navigateur, voyez aussi l’erreur de certificat SSL. Action immédiate : testez votre origine avec openssl s_client, puis installez un certificat valide et passez en Full (strict).
Ce problème, Peechy s'en occupe
Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout, hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.
Confier mon site à Peechy
