Chapter 5 of 8
SNI, virtual hosts, chain order, wildcards, multiple listeners and mutual TLS.
About 11 minutes of reading
A server often hosts dozens of sites on one IP address. It cannot know which certificate to present until the client says which name it wants — that is what SNI does during ClientHello. The server then selects a certificate matching that name.
Consequences: an old client without SNI support gets the default certificate and may see a name mismatch; and an observer can see which site you asked for unless ECH is in use.
TLS requires the server to send its leaf certificate and the intermediates that connect it to a root the client trusts. Order matters for some clients: leaf first, then intermediates, then optionally the root (which is usually unnecessary).
cat fullchain.pem | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -print_certs -noout
# Expect: subject=leaf, then subject=intermediate, each issuer matching the next subject| Certificate name | Covers | Does not cover |
|---|---|---|
| shop.example.com | Exactly that name | www.shop.example.com |
| *.example.com | one label, e.g. api.example.com | example.com, a.b.example.com |
| SAN with several names | Every listed name | Anything not listed |
Wildcards are convenient and dangerous: one key on one server now protects every hostname under the domain, so a single compromise has a wider blast radius.
In mutual TLS (mTLS) the client also presents a certificate. The server validates it against a client trust store. This authenticates devices and services strongly, but it does not authorise them: you still need policy about what that identity may do.