3 votes

Transformer un site Apache http en site sécurisé https via le reverse proxy de Nginx

Je dois soutenir un vieux site WordPress fonctionnant sur un serveur web Apache. Pour rendre les choses plus sûres, ce serveur Apache se trouve dans un conteneur Docker, et il est accessible au monde entier via une configuration de proxy inverse Nginx. Ce site est actuellement servi via http, et j'aimerais le migrer vers https.

Je pense que j'ai deux options :

  1. Le certificat SSL est installé pour le site Nginx, et il fait proxy_pass vers le site http simple sur le conteneur Apache :

    server {
        listen      443 ssl;
        server_name www.example.com;
    
        ssl_certificate /etc/nginx/ssl/letsencrypt/live/www.example.com/fullchain.pem;
        ssl_certificate_key /etc/nginx/ssl/letsencrypt/live/www.example.com/privkey.pem;
    
        access_log  /var/log/nginx/example.com.access.log;
    
        location /  {
            proxy_pass       http://Apache2-PHP5.6:80;
            proxy_set_header Host            $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         }
    }

    Dans ce scénario, du point de vue du serveur Apache, il sert toujours le site via http

  2. C'est plus laborieux : le certificat SSL est installé à la fois sur le serveur Nginx de la passerelle et sur le site Apache mandaté. Il faudrait alors modifier http a https en el proxy_pass valeur de la configuration.

J'aimerais que tout se passe bien dans le premier scénario. Mais le fait qu'Apache ait l'impression de servir des choses via http introduit quelques problèmes : il y a des redirections d'URL cachées que j'aimerais vraiment ne pas avoir à reconfigurer/déboguer. Et ces redirections d'URL font quelque chose comme ceci : si l'URL demandée est http://www.example.com Il est réécrit (http status 301) comme suit http://www.example.com/main . Cette redirection est reçue par le navigateur et, bien que la première demande ait été faite en https, l'URL redirigée est maintenant en http. Par ailleurs, le site html contient plusieurs références complètes à ses propres ressources (fichiers JavaScript et CSS) qui incluent également la référence au protocole. Il n'est pas clair à ce stade si ces références adoptent le protocole de la manière dont la requête a été faite, ou si ce protocole est codé en dur. Quoi qu'il en soit, cela ne fonctionne malheureusement pas sans un sérieux travail de recherche.

Il me reste donc l'option 2. J'ai essayé, ça marche, je peux configurer le même certificat SSL sur Nginx et sur l'Apache conteneurisé. Mais j'aimerais savoir si c'est vraiment comme ça qu'il faut laisser tourner. Parce que même si le serveur Apache sait maintenant que le contenu est servi en https, il y a maintenant un double SSL-ing pour chaque requête. Cela ne me semble pas correct.

5voto

Mark Points 41

Vous pouvez résoudre le problème dans votre option #1 (qui, comme vous l'avez dit, est une bien meilleure approche) en définissant le HTTP_X_FORWARDED_PROTO dans votre configuration nginx avec

proxy_set_header X-Forwarded-Proto $scheme;

et en configurant WordPress pour qu'il le reconnaisse en ajoutant cette ligne à wp-config.php

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Voir aussi Article de soutien à Wordpress pour une variante de cette solution.

3voto

PulledBull Points 248

Vous devriez être en mesure d'indiquer à Apache que la requête entrante est mandatée à partir d'une requête HTTPS à l'aide de l'option proxy_set_header X-Forwarded-Proto "https"; déclaration dans la première configuration

1voto

Bob Points 5179

Normalement, je préférerais faire tout le travail lourd sur le proxy inverse et garder le site de base qui est exposé aussi original que possible.

Votre problème semble être essentiellement que le backend (WordPress) génère et utilise des URI (absolus) qui diffèrent de ceux que vous voulez que les visiteurs utilisent.

Vous pouvez y remédier en réécrire le contenu (HTML) que WordPress génère dans nginx avec l'option ngx_http_sub_module . Cela vous permettra également de réécrire les URL absolues avec quelque chose de similaire :

    location / {    
         sub_filter 'http://example.com/' 'https://www.example.com/' ;
         sub_filter 'http://www.example.com/' 'https://www.example.com/' ;
         sub_filter_once off;
         proxy_pass       http://Apache2-PHP5.6:80;
         proxy_set_header Host            $host;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;                
    }

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X