TLS, DNS-01 and reverse vs forward proxy

Extracted from the master document on 2026-09-04. §N numbering preserved so cross-references don’t break.

21. TLS and DNS-01

Vaultwarden Web requires a secure context: going in over http://IP:port reaches the service, but the browser won’t grant it the permissions it needs. An SSH tunnel encrypts the transport, but the URL is still http:// and the browser still treats it as insecure.

Client ── HTTPS/TLS ──► Caddy ── internal HTTP ──► Vaultwarden:80
                          ▲
                          └── TLS termination: only Caddy holds certificates

Certificate issuance over DNS-01, step by step:

 1. Caddy needs a cert for vault.balserosworld.net
        │
 2. Caddy asks Let's Encrypt (ACME) → "prove it's yours"
        │
 3. Caddy uses the Cloudflare API and creates a temporary TXT record
        │      _acme-challenge.vault.balserosworld.net = <value>
        │
 4. Let's Encrypt looks that TXT record up over public DNS
        │
 5. It matches → the certificate is issued
        │
 6. Caddy deletes the TXT record and stores the cert in the caddy_data volume

Why DNS-01 and not HTTP-01: HTTP-01 requires Let’s Encrypt to be able to come in on port 80 from the Internet. There is no inbound open here — and we don’t want to open any. DNS-01 proves control of the domain without any incoming connection.

22. Reverse proxy vs forward proxy

FORWARD PROXY — acts on behalf of the CLIENT
  Client ──► Proxy ──► external server
  uses: egress control, filtering, caching, policies
  note: the proxy still knows the client and can log the origin

REVERSE PROXY — sits in front of the SERVERS
  Client ──► Reverse Proxy ──► Backend
  the client knows the public entry point; the proxy picks and protects backends

In BalserosWorld:

Client
   │
   ▼
 Caddy ──┬──► Vaultwarden
         ├──► Uptime Kuma
         ├──► Portainer
         └──► Nextcloud AIO