How to Reuse Wildcard SSL Certificate for all Subdomains in Caddy?

Help
1

1. The problem I’m having:

I’m currently setting up Caddy to manage SSL certificates for my domain, and I’ve encountered an issue where Caddy is issuing separate SSL certificates for each subdomain, despite having a wildcard certificate.

2. Caddy version:

v2.8.4

3. How I installed and ran Caddy:

Caddy Docker Container

a. System environment:

OS - Ubuntu
Architecture - arm64
Docker version 27.1.1, build 6312585

b. My complete Caddy config:

{
    email {email}
}

domain.tld, *.domain.tld {
    tls {
        dns cloudflare {token}
    }
}

webdav.domain.tld {
    reverse_proxy webdav:8000
}

logs.domain.tld {
    reverse_proxy dozzle:8080
}

In this setup, Caddy has issued certificates for:

domain.tld
*.domain.tld
webdav.domain.tld
logs.domain.tld

My expectation was that Caddy would only issue certificates for domain.tld and *.domain.tld, and that the wildcard certificate would cover all subdomains like webdav.domain.tld and logs.domain.tld. Doesn’t caddy check if already existing cert covers the newer site block ?
How can I configure Caddy to reuse the wildcard certificate for all subdomains and avoid issuing separate certificates for specific subdomain ?

Apart from this, i would also like to know how to know if caddy supports Multi SAN certificate. Say a single ssl cert which is valid for both *.adguard.domain.tld & adguard.domain.tld ?

2

Caddy doesn’t check this, no. You can think of each site block kinda like its own little island, unaffected by the other sites except for global options.

In the Caddyfile, your only option to assign site configuration to a wildcard certificate is to literally put that configuration in a wildcard site block.

It’s possible to differentiate hosts under a wildcard site with a host matcher, e.g.:

*.example.com {
  @foo host foo.example.com
  reverse_proxy @foo <upstream>

  @bar host bar.example.com
  handle @bar {
    # Grouped config for bar.example.com
  }
}

You can read up on that at Request matchers (Caddyfile) — Caddy Documentation.

Alternatively, JSON can give you very precise control over TLS automation for site names and host matching selection.

Caddy does not support multi-SAN as it’s not considered best practice for HTTPS automation. You can read up on that here: https://github.com/https-dev/docs/blob/master/acme-ops.md#use-one-name-per-certificate

Caddy does support manually importing your own certificate if you’d prefer to acquire and maintain your own multi-SAN cert without automation.

2 Likes
3

Thanks for the heads up. AdGuard Home is the only service i know which needs a Multi SAN cert, just to confirm the syntax for it specifically

*.adguard.domain.tld, adguard.domain.tld {
    tls /path/to/your/certificate.crt /path/to/your/private.key
    ... other directives as needed
}

Is the above correct or i need something else too ?
I want to confirm that if I use an imported Multi-SAN certificate that matches my site addresses, Caddy won’t attempt to issue its own certificate. While it’s clear that Caddy doesn’t support Multi-SAN certificates directly, my concern is whether Caddy will at least recognize that the certificate is Multi-SAN and covers both site addresses. I wish there was an auto-https directive that could be applied to specific site blocks to control this behavior more precisely.

4

That looks like good configuration to me.

Caddy won’t attempt to issue its own certificate for any site block you import your own cert for. Using the tls <cert> <key> syntax creates a manual SNI certificate selection association for that specific cert for all the site addresses you’ve specified for that site block. Caddy ignores everything else; doesn’t matter if you specify the wrong certificate, if the cert has one name or fifty names or is out of date, Caddy will load it and serve it for requests to that site, as you’ve configured. That can create its own footguns sometimes, but there’s definitely no need to worry about Caddy ignoring your directive and automating a cert anyway.

2 Likes
5

We have a WIP feature that would help with what you’re trying to do, but it’s not finalized yet:

2 Likes