What TLS actually asserts

A certificate proves one thing: whoever holds the matching private key controls these names, and an issuer vouches for that. It says nothing about whether a site is honest, safe or competent.

What is in one #

• A public key.
• A list of names it covers, in the Subject Alternative Name extension.
• Validity dates.
• The issuer.
• A signature from that issuer over all of the above.

The matching private key is not in the certificate. It stays on the server, and possession of it is what the certificate is really about.

$ openssl x509 -in cert.crt -noout -subject -issuer -dates -ext subjectAltName

The common name field is historical. Browsers stopped using it for hostname matching years ago, so a certificate without a SAN list matches nothing however correct it looks.

Chains #

Your server presents a leaf certificate and usually one or more intermediates. The client walks up: leaf signed by intermediate, intermediate signed by a root. If the root is in the client's trust store, the chain validates.

Roots are kept offline and their intermediates do the day-to-day signing, so a compromised intermediate can be revoked without replacing the root in every device on earth.

Serving an incomplete chain is the classic misconfiguration: it works in your browser, which may have cached the intermediate, and fails on a phone or a curl. Send the leaf and every intermediate, not the root.

$ openssl s_client -connect photos.example.com:443 -servername photos.example.com </dev/null

Look for the chain it presents and the final verify result.

How an issuer decides #

For a public authority, the whole product is verification of control over a name. Three challenge types:

• HTTP-01: serve a specific file at a specific path. Requires the name to be publicly reachable on port 80.
• DNS-01: publish a specific TXT record. Does not require the service to be reachable at all, which is how a private service gets a public certificate.
• TLS-ALPN-01: prove it during a TLS handshake on port 443.

DNS-01 is how a service that is not publicly reachable can still obtain a public certificate for a domain you control. This book keeps its chapter 8 private authority for the LAN and lets Tailscale Serve manage certificates for the private mesh instead.

Why your own authority works, and where it stops #

Being an authority means having a keypair and signing things with it. There is no technical barrier: what a public authority has is a place in everyone's trust store, earned through audits.

So a private authority works for names and devices you control. It does not scale to unmanaged devices, because each one would need to trust your root, which grants substantial authority.

Your CA private key can mint a certificate for any name at all, including your bank's, and every device trusting your root would believe it. That is why it does not live on the server and why installing somebody else's root is not a small favour.

Expiry #

Public certificates have got shorter and continue to. Automate renewal and monitor it: an expired certificate is an outage, and the failure is total rather than gradual.

$ echo | openssl s_client -connect photos.example.com:443 \
    -servername photos.example.com 2>/dev/null | openssl x509 -noout -enddate

Worth a monitoring check, alerting a couple of weeks before.

What TLS does not do #

• It does not say the site is trustworthy. Phishing sites have valid certificates.
• It does not normally hide which site you visited. DNS and SNI can disclose the name. Encrypted DNS and Encrypted Client Hello reduce those leaks only when the whole client-to-service path supports them.
• It does not protect data at rest. Encryption stops at the server.
• It does not remain encrypted through a terminating proxy. Traefik reads the request after TLS termination before forwarding it. Tailscale Serve terminates its private HTTPS endpoint on the home server.