by Dr. Thomas Barnes, USFWS

TLS cert inheritance, as encountered with Caddy

I think I made up the term “TLS inheritance”, but it feels like it fits here.

As I currently understand it, when a server is serving content over HTTPS/443 and TLS cert A has been configured for it at all, unless the server software itself specifically identifies a different cert B to be presented for a different subdomain, A will be presented, even if the server configuration doesn’t specify a cert for the subdomain.

Hopefully my example clarifies that. I ran into this using Caddy as a reverse proxy to serve 2 sites from the same machine:

{
    debug
}

https://site1.home.alexandercalvert.me {
    tls /.../fullchain.pem /.../privkey.pem
    reverse_proxy http://localhost:<port1>
}

https://site2.home.alexandercalvert.me {
    reverse_proxy http://localhost:<port2>
}

My cert was configured for *.home.alexandercalvert.me, so it was valid for both sites, but as you can see it wasn’t being explicitly configured for site2, only for site1. However, with this configuration both sites were being served with HTTPS successfully via reverse proxy. When I removed the tls ... line from site1’s config, both sites failed together as well.

It seems I’m not documenting anything new here, but being new-ish to this side of web dev, I found it hard to find any explanation of this behavior until I encountered this thread. The poster there had sort-of the opposite problem, where his cert was configured for only 1 of the sites he was serving, so he was getting unexpected TLS issues on the other one. The root cause is the same as mine though, so thanks to those folks for having that discussion and answering my questions too.