Reverse proxy, domaine et HTTPS

Objectifs

À la fin de cette leçon, vous saurez :

• expliquer le rôle d'un reverse proxy (Caddy/Nginx) ;
• faire pointer un domaine vers votre serveur ;
• comprendre l'obtention automatique des certificats.

Le reverse proxy : la porte unique

Internet ──:443──→ Caddy (TLS)
                    ├── /      → frontend (fichiers statiques)
                    ├── /api   → backend:3000
                    └── autres → 404

Pourquoi une porte plutôt que des services exposés directement :

• TLS centralisé : un seul endroit chiffre/déchiffre ;
• une seule origine : même domaine pour site et API — pas de CORS ;
• rate limiting, headers, compression appliqués en un point ;
• les services internes ne publient AUCUN port : invisibles d'Internet.

Terminologie : le proxy « upstream » est votre backend ; la terminaison TLS se fait au proxy qui parle HTTP en interne.

Virtual host : un serveur, plusieurs sites

Le terme virtual host désigne ce mécanisme : un seul serveur (une seule IP) sert plusieurs noms de domaine. Le client annonce le site voulu dans l'en-tête Host: de chaque requête ; le proxy choisit le bloc de configuration correspondant — dans un Caddyfile, simplement monsite.fr { ... }. C'est ainsi qu'un même VPS héberge monsite.fr ET api.monsite.fr : deux virtual hosts, deux blocs, un processus.

Caddy : HTTPS automatique

monsite.fr {
    handle /api/* {
        reverse_proxy backend:3000
    }
    handle {
        root * /srv/web/dist
        try_files {path} /index.html
        file_server
    }
}

Deux lignes de configuration et Caddy obtient, renouvelle et installe seul les certificats Let's Encrypt. Nginx fait pareil avec plus de verbe (certbot en cron). Le principe sous-jacent est ACME : le serveur démontre le contrôle du domaine (un fichier ou un enregistrement DNS), l'autorité émet le certificat valable ~90 jours, renouvellement automatique.

Clé privée, clé publique : qui garde quoi

Le certificat n'est qu'une moitié de la paire asymétrique vue au chapitre 12. La clé publique circule librement — elle est DANS le certificat, visible par tous vos visiteurs. La clé privée, elle, ne quitte jamais votre serveur : c'est elle qui prouve votre identité pendant la négociation TLS et déchiffre l'échange initial. Perdre la clé privée (ou la laisser dans une image Docker !) revient à donner le tampon du notaire : quiconque la possède peut se faire passer pour votre domaine. D'où la règle absolue : clé privée sur le serveur, permissions strictes (600), jamais versionnée.

Le chemin complet d'un domaine

1. Acheter monsite.fr chez un REGISTRAR
2. Zone DNS : A @ → IP_PUBLIQUE_DU_SERVEUR   (+ AAAA si IPv6)
3. TTL court pendant l'installation, puis remonté
4. dig monsite.fr vérifie la propagation
5. Caddy écoute sur :443, présente le certificat, route

www devient un CNAME vers la racine ; les sous-domaines (api.monsite.fr) sont d'autres A/CNAME dans la même zone. Retenez le schéma final du parcours complet du cursus :

navigateur → DNS → IP publique → :443 proxy TLS → conteneurs → NestJS → PostgreSQL

Exercice

1. Sur un serveur de test (ou VM), installez Caddy et proxifiez /api vers votre API.
2. Simulez : ajoutez monsite.local 127.0.0.1 dans /etc/hosts et testez.
3. Décrivez ce que voit un attaquant qui scanne vos ports : pourquoi seulement 80/443 ?

Résumé

• Reverse proxy = TLS + routage + protection, services internes cachés.
• ACME/Let's Encrypt : certificats automatiques à démonstration de contrôle.
• Domaine = registrar + zone DNS + A vers l'IP publique.