Récemment, nous avons décidé au CHATON madata de faire un peu de ménage dans notre infrastructure en conteneurisant nos différents services via LXC (on verra plus tard si on passe sous Docker ou Kubernetes mais il ne faut pas brûler les étapes de la montée en compétences!).
Nous avons différentes instances Nextcloud (une pour nos structures adhérentes et une pour nous), jusque-là hébergé sur le même serveur Web (Apache) que nous souhaiterions passer en plusieurs conteneurs, servis derrière un reverse proxy NGINX. Tout marche bien, sauf lorsqu’il s’agit de faire de mettre en place TLS et les certificats dans NGINX. D’après les tutos glanés ici ou là, il me semblait qu’il suffisait de générer les certificats depuis le reverse proxy et pas depuis les backend. Or chez nous, on est obligé de générer les certificats (via certbot) depuis chaque serveur du backend pour ne pas avoir d’erreur (certificat auto-signé). Est-ce normal ? Je pensais que l’usage était de gérer les certificats au niveau du frontend ?
Merci d’avance
Armand, pour le chaton Madata (Association Défis)
Bonjour Armand,
J’ai déjà eu des situations similaires avec un reverse proxy qui se charge de renvoyer du contenu HTTP depuis différents conteneurs.
L’idée se serait que seul ton reverse proxy s’occupe des certificats et des connexions en HTTPS. Tu n’es pas obligé de servir le contenu en HTTPS entre le serveur de backend et le reverse proxy, car seul le reverse proxy a un accès direct au backend (HTTP peut suffire entre eux). Côté utilisateur, la connexion sera en HTTPS de manière transparente et sans problèmes
Mmh, c’est bien ce qui me semble et c’est le où je ne comprends pas. Voici comment j’ai procédé :
j’ai installé nginx sur mon reverse proxy,
je crée le fichier de conf suivant
server {
listen 80;
server_name url_du_backend;
location / {
proxy_pass http://ip_du_backend;
include proxy_params;
}
}
dans les sites-availables (et un lien dans les sites-enabled)
je redirige les ports 80 et 443 de la box dessus,
je désactive le virtualhost correspondant au site Web HTTPS dans le backend
je lance certbot sur mon reverse-proxy
Et quand j’essaye de me connecter, ça me dit que le certificat a été autosigné… et je dois ajouter une exception de sécurité pour accéder au site Web.
Faut-il modifier des fichiers de conf de nginx dans le frontend ou de apache dans le backend. Je me dis que je dois mal m’y prendre ?
La conf que j’ai donné, c’était avant de lancer certbot. J’obtiens donc la conf suivante :
server {
server_name test.defis.info;
location / {
proxy_pass http://IP_addr_backend;
include proxy_params;
}
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/test.defis.info-0001/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/test.defis.info-0001/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = test.defis.info) {
return 301 https://$host$request_uri;
} # managed by Certbot
server_name test.defis.info;
listen 80;
listen [::]:80;
return 404; # managed by Certbot
et voici mes proxy_params :
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
Sans succès. Toujours cette histoire de certificat autosigné. @Bschalck : Le même problème apparaît en adaptant ton fichier de conf avec mes FQDN et IP.
Je vais voir si ce n’est pas lié à mon backend et je vous redis !
Je pense que ça provenait de la config Apache du backend mais ça reste un peu un mystère. J’ai monté un autre conteneur Apache et là ça fonctionne avec la config générée par Certbot. Je prospecte et ramènerai des éléments pour expliquer l’origine de mon problème.
J’ai un soucis sensiblement identique avec un reverse proxy apache où je n’arrive pas à faire du SSL de bout en bout.
De client ← HTTP- > Reverse proxy ← HTTP → backend, pas de soucis
De client ← HTTPS → Reverse proxy ← HTTP → backend, idem pas de soucis.
De client ← HTTPS → Reverse proxy ← HTTPS → backend, ça coince
A priori, il y aurait 2 méthodes :
la première et la plus efficace serait que le RP laisse passer le protocole HTTPS sans opérer de vérification, laissant au backend le soin de décrypter les flux
la seconde serait que le RP décrypte les trames du client à l’aide d’un premier certificat et qu’il les recrypte avec un autre certificat pour communiquer en mode sécurisé avec le backend.
Je n’ai pas creusé suffisamment et il faudra que je m’y remette, sauf si quelqu’un a déjà la solution.
Je te recommande caddy si tu n’as pas des besoins délirants pour ton reverseproxy. La conf est ultra simple, il fait du letsencrypt par défaut donc tu peux même te passer de certbot. Typiquement j’ai viré un nginx comme ça. Pour exemple, je pointe sur un docker local sur le port 8001 :
