Reverse-proxy nginx : avertissement de sécurité WordPress

Lors du déploiement de notre blog pour l’association C.H.A.T.O.N.S, après avoir redirigé le flux au-travers du reverse-proxy nous rencontrions un message d’erreur sous Firefox (et sûrement d’autres navigateurs) indiquant que le site n’était pas sécurisé.

Un moteur de blog plutôt connu…

Allons-y pour un bref article de recherche d’un souci encore jamais rencontré, exercice de style de dépannage.

Récupération d’informations

Premièrement, j’ai commencé par mettre en doute mon client, n’ayant jamais rencontré cette problématique que ça soit sur le blog que vous lisez en ce moment ou sur les autres services Web derrière le reverse-proxy nGinx.

Toutefois le certificat SSL était bel et bien actif, fonctionnel et correspondant aux différents sous-domaines utilisés. nGinx ne remontait aucune erreur et le WordPress fonctionnait évidemment en interne (HTTP sans SSL). De plus, le site s’affichait quand même mais on avait l’impression qu’il avait le CSS cassé (affichage tout moche, contenu présent).

Enfin, en autorisant “l’exception de sécurité” dans Firefox, le site s’affichait alors sans problème. Mais il me paraissait très frustrant d’avoir un reverse-proxy avec véritable certificat SSL qui m’affichait quand même des avertissements de sécurité et forçait les visiteur⋅teuse⋅s à mettre en place une exception de sécurité pour voir notre blog.

WordPress étant fonctionnel, la seule étape entre le client externe et le serveur était par déduction le reverse-proxy : pourquoi donc nGinx nous embêtait pour WordPress alors que les autres services fonctionnaient bien ?

Recherche

Ensuite, une fois que j’étais certain du “coupable”, il m’a fallu effectuer des recherches sur internet. Pour paraphraser une phrase bien célèbre impliquant d’habitude un GAFAM :

DuckDuckGo, qwant ou Searx sont vos amis.

pensez à utiliser des moteurs de recherches alternatifs !
searX meta-moteur de recherche

J’ai commencé par trouver des résultats peu similaires (souvent des admins ayant une impossibilité d’utiliser leur WordPress derrière le reverse-proxy, ce qui n’était pas entièrement notre cas). Le temps d’affiner ma recherche j’ai finalement trouvé des forums renvoyant vers un article de blog qui répondait totalement à notre problématique. Merci à Albin A. Henriksson !

La problématique rencontrée venait du fait que WordPress renvoyait un mélange de contenu sécurisés et non-sécurisés (HTTPS/HTTP) et, contrairement à ma première idée, devait être réglé à la fois dans la configuration de WordPress et dans la configuration d’nGinx.

Dépannage du reverse-proxy

Finalement j’ai suivi les instructions suivantes, comme indiquées par l’article. Premièrement ajouté cette instruction au début du fichier wp-config.php pour forcer le transfert http sur SSL pour tous les éléments :

define('FORCE_SSL_ADMIN', true);
if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
 $_SERVER['HTTPS']='on';
le reverse-proxy par excellence : nginx
le reverse-proxy en question

Ensuite, il fallait “forcer” la définition https dans WordPress, à la fin du même fichier afin que le moteur de blog se définisse lui-même (et ses liens) comme tournant exclusivement sur SSL :

define('WP_HOME','https://nomdevotreWP.TLD');
define('WP_SITEURL','https://nomdevotreWP.TLD');

Enfin, dans la configuration nGinx, sous le bloc correspondant au wordpress ajouter :

proxy_set_header X-Forwarded-Proto https;

Cette dernière instruction indique quel est le protocole utilisé entre le client et le reverse-proxy.

Bilan

Ce petit exemple de découverte-recherche-résolution de problématique d’administration système est un petit rappel de bonnes pratiques et de choses à avoir en tête :

  • Douter de soi, de son client, de son poste, de sa pratique, parfois le problème est entre la chaise et le clavier.
  • Quelqu’un a déjà eu le problème avant vous, pas d’inquiétudes.
  • Toujours faire des recherches, selon toute vraisemblance la solution existe et a été documentée.
  • Faites des sauvegardes de vos points d’avancement, cela vous permettra de faire des tests et de pouvoir revenir en arrière si vous “aggravez” la problématique ou en créez de nouvelles.
  • Communiquez avec votre équipe : parfois un⋅e collègue pourrait avoir la solution en tête, ou le lien kivabien l’indiquant, et également pour éviter de “toucher à tout en même temps”. Il n’y a rien de plus frustrant que de rédiger un article pendant 2 heures ou développer une amélioration et tout perdre car l'(autre) admin rollback sur une sauvegarde.
  • Faites des pauses, il est bon d’aller marcher cinq minutes ou simplement de passer sur une autre tâche quelques heures (selon l’urgence de la problématique rencontrée) il est très rare pour ne pas dire impossible de trouver la solution à un souci donné après plus d’une ou deux heure(s) de recherche sans interruptions. On finit toujours par ne plus voir ce qui est sous notre nez.

Sur ces petits conseils, je vous souhaite bon courage pour la suite, n’abandonnez jamais, l’informatique est parfois frustrante je le concède, mais il y a peu de choses aussi satisfaisantes que de finalement réussir à dépanner une problématique, installer un service ou déployer une correction de bug après des heures, jours ou semaines à s’embêter dessus.

7 commentaires

  1. Bonjour,
    Je rencontre le même problème avec wordress et le reverse-proxy nginx. J’ai suivi vos intructions mais ça ne fonctionne pas. Vous rajouter bien la ligne de code suivante  » proxy_set_header X-Forwarded-Proto https;  » dans le fichier wordpres du dossier sites-available du reverse-proxy nginx?

    Au plaisir de vous lire,

    Thomas

    • Bonjour Thomas, merci de me lire.
      Oui l’instruction proxy_set_header va dans le bloc “location” du bloc “server” (qui peut être dans un fichier dédié effectivement) dans ngnix correspondant à votre site WordPress.

      Avez-vous bien éditez les fichiers WordPress (en php) indiqués dans l’article?
      Bon courage !

        • Ravi d’avoir pu vous aider Thomas 🙂

          Je viens de migrer mon blog, je confirmes que ce post est toujours d’actualité (et bien utile hahaha)

  2. bonjour,
    merci pour ce tuto qui me rassure, même si pour le moment c’est ko de mon côte!
    j’essaie de faire à peu près pareil.
    J’aimerais avoir confirmation du protocole entre le reverse proxy et le wordpress, http ou https?
    De mon côté je n’ai pas mis en place https et cela ne fonctionne pas, faut-il le faire?
    Quand je mets
    define(‘FORCE_SSL_ADMIN’, true);
    je n’ai plus accès à l’admin, qui n’est pas sur le nom de domaine, je préfère garder l’admin depuis mon réseau local, est-ce possible?
    Pour le moment, mon site, est moche et n’a pas d’image…

  3. le lien vers l’article d’A. Henriksson ne fonctionne plus et je n’ai pas retrouvé l’article par une recherche 🙁
    Serait-il possible d’en avoir les points importants? S’il y en a d’autres que ceux mentionnées….

    • Bonjour ! Désolé du temps de réponse, je t’ai retrouvé l’article sur archive.org (wayback machine) : tu peux le consulter ici.

      J’éspère que cela peux t’aider, d’ici là bon courage et à bientôt !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *