Combine two wildcard domains into single certificate

Help
1

Hi,
I successfully switched from pfsense/opnsense to caddy (2.4.6 / docker-compose / custom alpine build).

One thing i’m missing is the ability to have a single certificate for multiple domains when it’s the same dns provider (hetzner in this case)

*.domainx.net, *.domainy.com {
    tls {
        dns hetzner supersecret
    }

    @aaa host aaa.domainx.net
    handle @aaa {
        reverse_proxy 10.0.0.4:8080
    }

    @bbb host bbb.domainy.net
    handle @bbb {
        reverse_proxy 10.0.0.4:6000
    }

shouldn’t the above caddyfile be able to produce a single cert instead of two?
is there something i’m missing or is this a restriction of the hetzner dns provider?

this is only a minor inconvenience, as ip ssl is not working. (haven’t tested it with one domain only though if thats even a possibility)

2

AFAIK, certs are domain specific, so you will have at least 1 cert per root domain

It is possible however, for the same IP to serve multiple domains

3

Hi :slight_smile:

No, Caddy does not support SAN certificates (Subject Alternate Name), where one certificate “holds” multiple domain names.

Caddy will automatically fall back from LetsEncrypt to ZeroSSL if you hit any rate limits (if you are worried about that) :robot:

Also, there is also this rather huge thread/issue on GitHub in the past if you are interested:

1 Like
4

For managed certificates, Caddy always uses 1 subject per certificate. There are numerous reasons this is considered a best practice:

X.509v3 certificates can use extensions, one of which is Subject Alternative Name (SAN). The client provides a list of names to be validated when requesting a certificate, and the names which are validated by the CA are added as SANs.

Although it is possible to map many names to one certificate (M:1), a one-to-one (1:1) mapping is recommended. 1:1 is easy to manage, less error-prone, reduces failures at scale, reduces the impact of revocation, and speeds up certificate maintenance. It also can enhance security since each certificate can use a different private key; thus if one key is compromised, the security of connections to the other sites is not automatically compromised as well. The only notable downside is that it may use more storage space since you will have more certificates.

M:1 might be required if:

  • Storage space is extremely limited (unlikely, because storage is cheap).
  • The web host / service provider charges for certificates and you need to reduce that cost.
  • You need to manage fewer certificates due to CA-enforced rate limits.
  • Your server software only allows one certificate per virtual host, and the virtual host serves multiple domains.

Using M:1 has little benefit in automated settings, complicates the addition and removal of names, slows down certificate issuance, and increases the chance of validation errors. There will be greater logical and operational complexity by combining many names onto one certificate. In addition, all those names necessarily share a single private key, so if one key is lost, all those sites need a new certificate with a different key. Multi-SAN certificates also have a larger size, so they slow down TLS handshakes.

If a single web server or cluster of servers is handling all subdomains of a single registered domain, it is often better to use and manage a single wildcard certificate. With Let’s Encrypt, this implies configuring the ACME DNS challenge, which requires control over the DNS for the registered domain. Managing certificates for many subdomains of the same registered domain without control over the DNS is not recommended.

(Upon re-reading, I just realized that one other reason is missing from that document: multiple SANs per certificate creates a small information leak by implicitly associating two subjects to be related to each other. This might not be desirable in some situations.)

This actually has nothing to do with the number of names per certificate(s). Rather, your config does not tell Caddy to serve on the IP address, so it doesn’t manage any certificate for the IP address. You only gave it wildcard DNS names, no IP addresses.

X.509 certificates support multiple subjects.

To clarify, Caddy only supports SAN certificates. It just doesn’t use more than 1 SAN per certificate. (For reasons described above.)

And fortunately, this is often not the rate limit people hit.

1 Like
5

Ok thanks,
No issues with rate limiting so far.

I guess it’s not that important. Users without SNI are rare and the “added security” with users not knowing what other domains are available is fine

1 Like
6

And you can still make your site work for users without SNI. There are two ways:

  • Use Caddy’s default_sni global option to specify a default certificate to serve up.
  • Add your IP address to your Caddyfile so Caddy will serve on the IP address and manage a cert for it as well. (The cert will be self-signed though.)
1 Like
7

OK - so this is a clarification I needed:

If we specify an IP address to our Caddyfile, Caddy will serve on the IP address and manage a self-signed cert for it as well.

The effect will be similar to using the staging CAs and the user will have to “approve” to visit the site on most browsers and there will be a red/crossed out indicator on the browser bar (unless the user adds our cert to their trust store)?

Is all of this accurate?

1 Like
8

Basically, yep!

With the advantage that you can have users add your Caddy root CA to their trust store if you are careful with your root private key and then they won’t have to bypass warnings.

9

This topic was automatically closed after 30 days. New replies are no longer allowed.