Caddy est un serveur web, comme apache ou nginx, mais plus moderne : il gère notamment tout seul les certificats SSL (https) via letsencrypt, et propose une configuration par défaut sécurisée. Les fichiers de conf deviennent très simples car y'a plus que du spécifique au service à mettre en place.
Il gère aussi bien le reverse proxy, en 1 ou 2 lignes de conf.
Par défaut, la connexion d'internet vers le serveur caddy est en https.
Ensuite, la connexion entre le serveur caddy et le service en backend se fait par défaut en http. Ce choix peut s'expliquer par le fait que le LAN est sensé être secure, et que le backend n'a en principe pas de connexion directe bidirectionnelle à internet (principe du reverse proxy), et il est donc difficile d'obtenir sur le backend un certificat valide.
Nous allons mettre en place une connexion https entre le backend (caddy) et le proxy (caddy aussi). inspiration
Nous devons utiliser un autre certificat que celui entre caddy et le WAN, aussi nous utiliserons caddy comme autorité de certification (CA) vis à vis du backend. Car, oui, caddy peut agit comme CA. Cependant les certificats obtenus ne sont valides que vis-à-vis d'un certificat interne à caddy (mais on peut installer ce certificat partout où on veut).
Caddy n'attribue des certificats qu'à des FQDN (Full Qualified Domain Name), et non des IP. Il nous faut donc une communication par DNS entre le frontend et le backend. Plutôt que de mettre un serveur DNS exprès en place, nous utiliserons les fichiers hosts
des 2 serveurs
# copier le certificat root local dans le store de l'os : cp /var/lib/caddy/.local/share/caddy/pki/authorities/local/root.crt /usr/local/share/ca-certificates/frontend.local.crt update-ca-certificates rc-service caddy stop rc-service caddy start
Copier le certificat de l'autorité de certification du frontend au backend. Sur le front end, le certificat se trouver dans /var/lib/caddy/.local/share/caddy/pki/authorities/local/root.crt
On en profite pour rendre accessible ce nouveau certificat au serveur web du backend avec un bon chmod
ou chown
Sur le backend, on va dire à caddy de faire confiance à ce certificat, et d'aller voir le frontend pour obtenir un certificat pour la liaison https
# Caddyfile https://backend.local { tls { ca https://frontend.local/acme/local/directory ca_root /var/lib/frankenphp/frontend.local.crt } ... }
On adapte le caddy file :
# FRONTEND Caddyfile # ACME Server frontend.local { # defining FQDN for ACME server acme_server # defining the ACME server tls internal } # reverse proxy vers le backend https://wiki.example.com { # defining incoming FQDN (WAN) reverse_proxy https://backend.local { header_up Host {upstream_hostport} } }
Proxmox inscrit des trucs dans le fichier hosts, il faut éviter d'aller dans sa zone sous peine de voir ses modifs écrasées au prochain reboot du container.
Fichier /etc/hosts
:
127.0.0.1 localhost.localdomain localhost frontend.local <-- ::1 localhost localhost.localdomain # --- BEGIN PVE --- 192.168.0.18 www3.local www3 xxx.yyy.z.uuu name # <-- PAS le bon endroit # --- END PVE --- 192.168.0.19 backend.local # <-- le bon endroit
Proxmox inscrit des trucs dans le fichier hosts, il faut éviter d'aller dans sa zone sous peine de voir ses modifs écrasées au prochain reboot du container.
Fichier /etc/hosts
:
127.0.0.1 localhost.localdomain localhost backend.local <-- ::1 localhost localhost.localdomain # --- BEGIN PVE --- 192.168.0.19 wiki.local wiki xxx.yyy.z.uuu name # <-- PAS le bon endroit # --- END PVE --- 192.168.0.18 frontend.local # <-- le bon endroit