AnonymousDeity, 10 months ago (edited 10 months ago)

But, the connection is unsecured over HTTP. I’d like to take it a step further in order to make the connections go over HTTPS.

Why? You’re already VPN’d into a machine you control via tailscale. Protecting the specific application TCP traffic with TLS is kind of redundant at that point. If you really care, just use nginx not Caddy because this will never work using Tailscale DNS, self sign a cert for your Tailscale domain and use nginx to serve traffic on the Tailscale network device.

Also, use docker compose. This will feed DNS records into the containers’ /etc/hosts file as well as put the containers on their own network so the main containers won’t be exposed directly, only caddy.

docker-compose.yml

<span style="color:#323232;">version: "3.4"
</span><span style="color:#323232;">services:
</span><span style="color:#323232;">  caddy:
</span><span style="color:#323232;">    container_name: caddy
</span><span style="color:#323232;">    image: ghcr.io/authp/authp:latest  # I use authp for OAuth authentication instead of VPN-only access
</span><span style="color:#323232;">    restart: unless-stopped
</span><span style="color:#323232;">    ports:
</span><span style="color:#323232;">      - 443:443
</span><span style="color:#323232;">      - 443:443/udp
</span><span style="color:#323232;">      - 80:80
</span><span style="color:#323232;">    volumes:
</span><span style="color:#323232;">      - ${ROOT}/config/caddy/Caddyfile:/etc/caddy/Caddyfile
</span><span style="color:#323232;">      - ${ROOT}/config/caddy/data:/data/
</span><span style="color:#323232;">    dns:
</span><span style="color:#323232;">      - 1.1.1.1  # set these to your local DNS if you have one, I run pihole
</span><span style="color:#323232;">      - 8.8.8.8
</span><span style="color:#323232;">      - 8.8.4.4
</span><span style="color:#323232;">  whoami:
</span><span style="color:#323232;">    container_name: whoami
</span><span style="color:#323232;">    depends_on:
</span><span style="color:#323232;">      - caddy
</span><span style="color:#323232;">    image: containous/whoami
</span><span style="color:#323232;">    restart: unless-stopped
</span>

Caddyfile

<span style="color:#323232;">{
</span><span style="color:#323232;">	http_port 80
</span><span style="color:#323232;">	https_port 443
</span><span style="color:#323232;">}
</span><span style="color:#323232;">
</span><span style="color:#323232;">whoami.example.com{
</span><span style="color:#323232;">    reverse_proxy whoami:80
</span><span style="color:#323232;">}
</span>

As you can see the Caddyfile directs the Caddy container to reverse proxy whoami.example.com to http://whoami:80, which uses the /etc/hosts entry that docker-compose inserts for whoami to the whoami container’s Docker IP address. In this scheme, only Caddy needs to have a port listening on the host machine. Assuming Caddy can access your tailscale network, this will work - for that. (although I worry that Tailscale mounts the network device as a unix socket, which may complicate matters - I ran into this when trying some bullshit with nginx/openresty)

The issue that you’re having in your logs is that you’re trying to get Caddy to get a TLS cert for machine.domain.ts.net, which will never work, because machine.domain.ts.net is not a globally recognized DNS record - it’s a split zone DNS for within the Tailscale network exclusively. LetsEncrypt needs to be able to prove you own machine.domain.ts.net in order to issue a cert for it, meaning it needs to be able to resolve the domain and chat with Caddy. Since LetsEncrypt isn’t on your Tailscale network, it cannot do this.