Erreurs Cloudflare 525 et 526 sur WordPress : réparer le TLS de l’origine

Comprendre quelle connexion échoue avec 525 ou 526

Une page Cloudflare annonce « SSL handshake failed » avec le code 525, ou « invalid SSL certificate » avec 526, à la place de votre site WordPress. Le trajet entre le visiteur et Cloudflare peut fonctionner alors que la liaison suivante échoue. Le serveur d’origine est la destination que Cloudflare contacte pour obtenir le site.

Le code 525 désigne un échec de négociation TLS entre Cloudflare et cette origine. Le code 526 indique un échec de validation du certificat de l’origine, notamment dans le mode Full (strict) du parcours proxy habituel. Ces codes orientent le diagnostic, sans identifier à eux seuls le fichier ou le réglage fautif.

Le but est de rétablir une liaison chiffrée avec une origine correctement identifiée. Une extension WordPress de redirection ou une purge de pages ne répare pas cette négociation, qui intervient avant le traitement normal de la requête par WordPress. Si le navigateur affiche directement un avertissement de certificat sans page Cloudflare, reprenez plutôt le diagnostic du certificat présenté au visiteur. Ce guide traite le site passant par le proxy Cloudflare, pas les politiques Gateway ni les sous-requêtes particulières de Workers.

Conserver les preuves avant de modifier le service

Relevez le code exact, le nom demandé, le chemin public concerné, l’heure avec son fuseau et le Ray ID lorsqu’il est affiché. Notez si le défaut touche tous les accès ou apparaît par intermittence. Une capture montrant une erreur ancienne ne décrit pas nécessairement l’état au moment du contrôle suivant.

Rapprochez le début de l’incident d’un changement connu : migration, renouvellement de certificat, nouvelle origine, modification de son service TLS ou changement de règles de routage. Gardez ces hypothèses séparées des faits observés. Un site qui revient seul ne permet pas de conclure que le dernier bouton utilisé a corrigé la cause.

1. Conservez une copie privée des paramètres du domaine et de l’origine avant intervention.
2. Identifiez la personne qui administre le serveur et celle qui gère Cloudflare.
3. Demandez les erreurs TLS de l’origine aux heures concernées.
4. Retirez des captures les jetons, cookies et paramètres privés.
5. Préparez une modification ciblée et le retour à sa configuration précédente, sans supprimer les certificats encore utilisables ni leurs clés.

Relever le mode SSL/TLS du domaine concerné

Dans le compte Cloudflare habituel, sélectionnez le bon domaine puis SSL/TLS et Overview, ou Vue d’ensemble selon la langue. Relevez le mode effectif et faites vérifier les règles qui peuvent modifier le comportement pour un nom ou un parcours particulier. N’appliquez pas une valeur à toute la zone pour diagnostiquer un seul hôte.

Full (strict) ajoute une vérification du certificat de l’origine. Celle-ci doit notamment présenter une validité temporelle correcte, une identité correspondant au nom visé et une chaîne de confiance admise. Le certificat public reçu par le navigateur ne prouve pas que cette seconde connexion satisfait ces critères.

Gardez le niveau de validation prévu pendant la recherche. Passer de Full (strict) à Full peut faire disparaître un refus de certificat sans réparer son identité ou sa confiance ; Flexible change encore le trajet vers l’origine. Ces changements ne constituent pas notre procédure de réparation. Conservez le mode, le nom et les éventuelles règles effectives dans le dossier transmis à l’exploitant. Si le résultat observé contredit les paramètres de la zone, vérifiez d’abord le compte et le chemin réellement utilisés.

Confirmer la bonne origine avant de renouveler son certificat

Dans les enregistrements et le routage Cloudflare, comparez la destination du nom en panne avec les informations privées de l’hébergement. Pour un nom proxifié, les adresses visibles dans la résolution publique peuvent appartenir à Cloudflare : elles ne donnent pas directement l’adresse du serveur WordPress à tester.

Une migration peut laisser une destination ancienne ou un nœud différent de celui où le certificat a été installé. Faites confirmer toutes les origines actives, leurs ports et le nom transmis pendant la connexion. En présence d’un équilibrage ou d’une réécriture d’origine, le simple enregistrement DNS ne décrit pas forcément toute la route.

1. Relevez le nom exact qui produit l’erreur, avec ou sans www.
2. Faites confirmer la destination et le port attendus par le responsable de l’hébergement.
3. Comparez cette référence au routage configuré pour ce nom.
4. Si une différence est prouvée, corrigez seulement la destination concernée après sauvegarde.
5. Contrôlez à nouveau avant d’émettre un autre certificat. Conservez les autres enregistrements, notamment ceux des courriels, et gardez l’adresse de l’origine dans les échanges privés.

Examiner le certificat réellement servi par chaque origine

Pour un refus 526, demandez au prestataire de lire le certificat présenté sur la connexion concernée, plutôt que celui simplement stocké dans son panneau. Un certificat émis peut être affecté au mauvais site ou ne pas avoir été chargé sur toutes les machines. La vérification doit conserver le nom TLS demandé, appelé SNI.

Comparez les noms couverts, les dates et l’autorité, puis faites contrôler l’état de révocation et les intermédiaires nécessaires. La chaîne permet de relier le certificat du serveur à une autorité admise. Un navigateur ayant déjà mémorisé un intermédiaire peut réussir là où un autre client échoue : sa seule réussite ne confirme pas une chaîne complète servie par l’origine.

Si l’origine présente le certificat d’un autre site, l’affectation du service HTTPS mérite d’abord une correction. Si elle présente le bon certificat expiré, examinez le renouvellement et son installation. Notez la différence précise dans le ticket. Ne réémettez pas plusieurs certificats identiques sans vérifier lequel est effectivement utilisé ; une nouvelle émission ne change pas automatiquement la sélection faite par le serveur.

Faire une lecture ciblée de l’origine avec curl

Cette vérification est facultative et réservée au propriétaire ou à l’exploitant, depuis un accès autorisé à l’origine. Si celle-ci n’accepte que Cloudflare ou exige une authentification particulière, faites exécuter le contrôle par son responsable ; un refus direct depuis votre poste peut être attendu.

Avec un certificat reconnu par le magasin de confiance de curl, l’exemple conserve le domaine dans l’URL tout en visant une adresse d’origine connue. Remplacez example.com et l’adresse documentaire 192.0.2.10 par les valeurs confirmées. --head demande les en-têtes et --max-time borne l’attente. Sous Windows, utilisez l’exécutable curl.exe si curl est un alias du shell.

Ne remplacez pas l’URL par l’adresse IP : vous changeriez le nom vérifié et potentiellement la sélection du certificat. Gardez la vérification TLS active, sans ajouter -k. Une réponse HTTP, même 403, indique une autre étape qu’un refus de certificat ; elle ne prouve pas le fonctionnement complet de WordPress. Conservez le résultat et l’heure en privé, sans publier l’origine.

curl --head --max-time 20 --resolve "example.com:443:192.0.2.10" "https://example.com/"

Lire la négociation TLS avec le nom correct

Lorsque l’exploitant dispose d’OpenSSL et d’un accès autorisé, s_client permet d’observer la connexion et les certificats envoyés. L’exemple vise la même adresse documentaire que précédemment et impose le nom SNI ainsi que le nom à vérifier. Il ne doit pas être lancé sur une origine choisie au hasard.

L’option -verify_return_error est essentielle ici : sans elle, cet outil de diagnostic peut continuer après des erreurs de vérification. -showcerts affiche les certificats envoyés par le serveur ; leur présence ne signifie pas à elle seule que leur chaîne est validée. Conservez le résultat détaillé et terminez la session après le relevé, avec Ctrl+C si elle reste ouverte.

Le magasin de confiance local peut différer de celui de Cloudflare, particulièrement pour Origin CA. Un échec local demande donc une interprétation de l’autorité utilisée, pas une suppression de la vérification. Inversement, une connexion réussie depuis votre poste ne reproduit pas tous les paramètres ni toutes les restrictions du trajet Cloudflare. Corrélez toujours le résultat aux erreurs du serveur à l’heure de la panne.

openssl s_client -connect 192.0.2.10:443 -servername example.com -verify_hostname example.com -verify_return_error -showcerts

Réparer un certificat expiré, mal affecté ou incomplet

Si la destination est correcte, utilisez d’abord le mécanisme de certificats déjà fourni par l’hébergement. Faites renouveler le certificat expiré ou émettre celui qui couvre les noms nécessaires, puis confirmez son installation sur le service HTTPS qui termine réellement la connexion. La date d’émission dans un panneau ne remplace pas cette lecture après installation.

Sur un service géré directement, l’exploitant doit associer le certificat à sa clé privée correspondante et à la chaîne requise. Par exemple, Nginx attend que le certificat du serveur précède les intermédiaires dans le fichier combiné prévu pour cet usage. Les chemins et la procédure d’application dépendent du serveur ; ne copiez pas une configuration complète d’un autre hébergement.

1. Corrigez le défaut identifié plutôt que de remplacer tous les éléments.
2. Vérifiez les noms, dates, chaîne et association à la clé dans les outils privés du prestataire.
3. Faites tester la configuration avant son application par le responsable.
4. Appliquez la modification selon la procédure du service.
5. Relisez le certificat présenté sur chaque origine active, puis contrôlez le trajet public Cloudflare en conservant le mode prévu.

Choisir Origin CA seulement pour le trajet adapté

Un certificat Cloudflare Origin CA constitue une alternative pour une origine destinée au trafic proxifié. Il protège le trajet Cloudflare vers serveur ; il n’a pas la confiance publique habituelle des navigateurs. Désactiver le proxy pour ouvrir directement cette origine peut donc créer un avertissement distinct, même si le certificat convient à Cloudflare.

Si cette solution correspond à l’architecture confirmée, l’administrateur trouve la création dans SSL/TLS, Origin Server, puis Origin Certificates et Create Certificate. Il choisit les noms et le format requis, conserve séparément le certificat et sa clé, puis les installe à l’origine avec la procédure propre au serveur. La clé générée n’est plus consultable après fermeture de l’écran : son rangement privé doit être préparé.

Pour un contrôle local, le responsable peut utiliser explicitement l’autorité Origin CA officielle appropriée dans son outil de vérification. Un rejet par le magasin public par défaut ne suffit pas à déclarer ce certificat invalide pour Cloudflare. Cela ne justifie pas de désactiver tous les contrôles. Si un accès direct par navigateur est aussi requis, faites choisir une solution de certificat compatible avec cet accès au lieu de changer le proxy pendant l’incident.

Corriger une négociation 525 à partir des traces serveur

Pour une erreur 525, demandez le journal TLS du composant qui reçoit Cloudflare : serveur Web, répartiteur ou autre terminaison chiffrée. Il peut refuser la connexion avant qu’une ligne apparaisse dans le journal d’accès HTTP. Chercher uniquement dans le journal WordPress risque alors de ne rien montrer d’utile.

L’exploitant vérifie l’écoute sur le port sécurisé attendu, la sélection par SNI et la présence d’une configuration TLS compatible. Les suites cryptographiques du trajet Cloudflare vers origine ont leur propre documentation ; les réglages destinés au navigateur ne décrivent pas nécessairement cette liaison. Faites comparer les paramètres actuels et les messages d’échec, sans activer d’anciens protocoles pour tenter une compatibilité aveugle.

Si une authentification mutuelle ou un accès réservé à Cloudflare existe, le contrôle doit en tenir compte. Ne supprimez pas cette protection pour obtenir un test direct vert. Une restriction réseau attendue et un échec de négociation ne sont pas interchangeables. En cas d’intermittence, recherchez un nœud différent, une configuration non appliquée partout ou une erreur qui coïncide avec les horaires relevés. Chaque piste doit être confirmée par des traces avant modification ; un code 525 n’établit pas à lui seul un problème de version TLS.

Appliquer une seule correction et conserver un retour possible

Avant l’application, le responsable sauvegarde la configuration du service et identifie le certificat encore utilisable. Il prévoit comment revenir à une affectation précédente valide si la nouvelle configuration ne charge pas. Cette préparation concerne le service qui termine TLS, même si les fichiers de WordPress sont hébergés ailleurs.

Une modification de fichiers n’est pas nécessairement active immédiatement. Le prestataire utilise son contrôle de configuration et sa procédure d’application habituels, puis confirme que le service répond encore et présente les éléments attendus. Évitez une commande générique de redémarrage : un même serveur peut héberger plusieurs sites et plusieurs composants.

1. Annoncez le périmètre exact au responsable du service.
2. Vérifiez la sauvegarde des valeurs et fichiers concernés.
3. Faites tester puis appliquer la correction par le mécanisme documenté.
4. Contrôlez les erreurs récentes et le certificat réellement servi.
5. Si la modification échoue, restaurez une configuration connue comme valide et confirmez son application.
6. Si l’ancienne version contient déjà le défaut, gardez le diagnostic ouvert : y revenir n’est pas une réparation. Demandez une correction ciblée ou un retour vers une origine préparée, sans affaiblir globalement la validation.

Valider le trajet public et les origines concernées

Après réparation, ouvrez l’adresse publique habituelle en conservant le passage par Cloudflare. Contrôlez le nom qui échouait et les variantes réellement utilisées. Une page connue et sans effet externe suffit au premier relevé ; aucun paiement ni envoi de formulaire n’est nécessaire pour vérifier une liaison TLS.

Faites confirmer par l’exploitation qu’une requête de contrôle a bien joint l’origine réparée. Une page déjà conservée par un cache peut s’afficher alors que le prochain accès au serveur échouera encore. Si plusieurs origines existent, chacune doit être cohérente ; quelques accès publics réussis ne garantissent pas que tous les nœuds ont reçu la correction.

Comparez les heures de contrôle avec les erreurs serveur. La disparition de 525 ou 526 doit s’accompagner d’une connexion conforme au mode attendu. Un nouveau code 403 ou 500 signifie que le diagnostic a changé d’étape, pas que le site est intégralement rétabli. Conservez séparément les résultats du contrôle direct autorisé et ceux du trajet Cloudflare. Si le défaut était intermittent, répétez quelques lectures espacées et examinez la période correspondante dans les traces, sans lancer une boucle intensive. Fermez le ticket seulement lorsque les preuves décrivent le même état sur les chemins concernés.

Prévenir l’expiration et transmettre un dossier exploitable

Après résolution, notez qui gère le renouvellement et qui déploie le certificat sur toutes les origines. Ces responsabilités peuvent appartenir à deux équipes différentes. Une automatisation d’émission réussie ne garantit pas l’installation dans le composant qui reçoit effectivement Cloudflare.

Gardez un inventaire privé des noms couverts, des dates et du mécanisme de suivi. Pour Origin CA, prévoyez votre propre contrôle d’expiration plutôt que de supposer qu’une alerte sera envoyée. Vérifiez le trajet Cloudflare après chaque migration, changement de terminaison TLS ou modification du routage ; préparez le certificat de la nouvelle destination avant sa mise en service.

Si vous devez escalader l’incident, fournissez le domaine, le code, les heures, le Ray ID disponible, le mode effectif et le changement récent. Joignez les erreurs TLS ciblées et les observations du certificat par le canal privé du prestataire. N’envoyez ni clé privée, ni mot de passe, ni export complet du compte. Indiquez aussi ce qui n’a pas été établi, par exemple un nœud non contrôlé ou un test direct empêché par une protection légitime. Cette précision permet au support de poursuivre une hypothèse vérifiable et évite de conclure à partir d’une simple disparition temporaire de l’erreur.