Rewrite current setup for automatic TLS on demand for new wildcard domain

[gmichaelr (Greg Rupel)]

1. The problem I’m having:

I want to rewrite my current setup to use automatic on demand TLS SSL cert pull with Let’s Encrypt using Cloudflare. It must be wildcard. I currently have it already setup using a stored certificate that is manually pulled once year and I want to move away from that. I also need to change the domain name from *.test.org to *.test2.com

2. Error messages and/or full log output:

None

3. Caddy version:

v2.8.4 h1:q3pe0wpBj1OcHFZ3n/1nl4V4bxBrYoSoab7rL9BMYNk=

4. How I installed and ran Caddy:

Normal with no module add-ons like cloudflare.

a. System environment:

Raspberry Pi 4+ running bookworm

b. Command:

PASTE OVER THIS, BETWEEN THE ``` LINES.
Please use the preview pane to ensure it looks nice.

c. Service/unit/compose file:

d. My complete Caddy config:

*.test.org {
        tls /etc/caddy/server.pem /etc/caddy/key.pem
        reverse_proxy /tautulli* 192.168.59.205:8181
        reverse_proxy /radarr* 192.168.70.207:7878
        reverse_proxy /sonarr* 192.168.70.207:8989
        reverse_proxy 192.168.59.205:5055
        reverse_proxy /sabnzbd* 192.168.70.207:8080/sabnzbd
        @plex host plex.test.org
        handle @plex {
                reverse_proxy 192.168.59.205:32400
        }
        import /etc/caddy/caddy_security.conf
}

5. Links to relevant resources:

#Security headers for www.test.org caddyfile
header /* {
    Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    X-Xss-Protection "1; mode=block"
    X-Content-Type-Options "nosniff"
    X-Frame-Options "DENY"
    Content-Security-Policy "upgrade-insecure-requests"
    Referrer-Policy "strict-origin-when-cross-origin"
    Cache-Control "public, max-age=15, must-revalidate"
    Feature-Policy "accelerometer 'none'; ambient-light-sensor 'none'; autopl>
    Server "No."

[Whitestrake (Matthew Fay)]

Howdy @gmichaelr!

You might not need it to be actually on-demand - if you know what the domain name is going to be, you could just have Caddy actively maintain the certificate and save yourself a little bit of complexity. But if you do need to only requisition the certificate on-demand, I can point you to the docs for On-Demand TLS to get you started. You’ll need to set tls { on_demand } in your site block and configure an ask endpoint in your global options in order to mitigate bad actors abusing your setup, the doc will explain those further.

As for doing this with the Cloudflare DNS module, I can point you at a helpful wiki post:

How to use DNS provider modules in Caddy 2

Caddy 2 uses a new and improved DNS provider interface for solving the ACME DNS challenge. All you have to do is plug the service provider(s) you need into your build, then add the DNS challenge to your configuration! Getting a DNS provider plugin How you choose to get a custom Caddy build is up to you; we’ll describe two common methods here. Method 1: Go to the Caddy download page. Find your DNS provider in the list of modules (dns.providers.*) and select it. Download your custom Caddy bu…

And the Cloudflare DNS module itself, with specific usage instructions, is over at: GitHub - caddy-dns/cloudflare: Caddy module: dns.providers.cloudflare

If you’ve got any specific questions, feel free to ask here.

[gmichaelr (Greg Rupel)]

I already have the standard caddy version with no cloudflare module. It is as easy I just pulling the one with the module and overwriting everything?

I would probably no do the tls on-demand then and just use the 90 day tls certs that are built-in to the module. Would there be anything special I need to adjust besides removing the location to the current TLS cert?

[Whitestrake (Matthew Fay)]

It kinda depends on how you installed Caddy. You just wrote you installed “Normal with no module add-ons like cloudflare” but that’s what you installed, now how; it matters whether you used apt, or if you downloaded from the website, or if you’re using Docker, etc etc etc.

In the case of a Debian based package manager there’s some extra steps you’ll want to follow to keep systemd integration. For a downloaded binary you can just download a new binary or run caddy add-package. Docker would have to build a custom image.

@gmichaelr

Would there be anything special I need to adjust besides removing the location to the current TLS cert?

Nope, just add the Caddyfile config required to enable the DNS challenge, then remove the line importing your manually provided cert/key, then reload/start Caddy and watch the logs to make sure it all goes off without a hitch. Give us a shout here if it goes awry.

[francislavoie]

On-Demand TLS is for when you don’t know the domains ahead of time. In your case, you do, you know you want a wildcard cert for your specific domain. So that’s not the feature you need.

But like Matthew said, your post was incomplete so we’re not sure how you’re actually running Caddy. We need to know that to know how to best help you.

@gmichaelr

reverse_proxy /sabnzbd* 192.168.70.207:8080/sabnzbd

This is invalid syntax, you can’t have path in a proxy upstream address (i.e. the /sabnzbd at the end of that line).

@gmichaelr

5. Links to relevant resources:

#Security headers for www.test.org caddyfile
header /* {
    Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    X-Xss-Protection "1; mode=block"
    X-Content-Type-Options "nosniff"
    X-Frame-Options "DENY"
    Content-Security-Policy "upgrade-insecure-requests"
    Referrer-Policy "strict-origin-when-cross-origin"
    Cache-Control "public, max-age=15, must-revalidate"
    Feature-Policy "accelerometer 'none'; ambient-light-sensor 'none'; autopl>
    Server "No."

You really don’t need any of this. Don’t set headers you don’t understand. Properly designed apps will set their own security headers as needed. In fact, you could be breaking some of the apps with this by overriding the headers the apps try to set.