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é.

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 !

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 !

Edit : grâce à un commentaire (ci-dessous) j’ai appris que le blog n’était plus accessible, il est trouvable sur la Wayback Machine d’archive ORG.

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';

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.