TLS certificates

A certificate is the proof that the server answering at a name is the one the name's owner intended. Browsers accept it only if several independent things are true at once, and a failure in any one of them produces a full-page warning. Visitors rarely click through those warnings, so a certificate problem is a self-inflicted outage as much as a security issue.

What a browser checks

• •The name matches. The hostname in the address bar must appear in the certificate's subject alternative names. A certificate for example.com does not cover www.example.com unless it is listed, and a wildcard covers one label only: *.example.com covers www.example.com but not a.b.example.com.
• •It is within its dates. Both the start and the end date must bracket the current time. Expiry is the single most common failure, and almost always an automation that quietly stopped.
• •It chains to a trusted root. The server must send its own certificate and every intermediate certificate between it and a root the browser already trusts. Roots are never sent, since they are pre-installed.
• •It is not revoked, and it was issued by an authority that has not been distrusted.
• •Its key is strong enough. RSA keys shorter than 2048 bits are rejected by modern clients. Elliptic curve keys such as P-256 are smaller and faster and are equally acceptable.

The missing intermediate

The most confusing failure is a chain that is incomplete. Chrome and Safari can often repair it by fetching the missing intermediate themselves, so the site looks fine to whoever configured it. But other clients, such as command line tools, mobile apps, API consumers and some email servers, do not, and they fail. The cure is to configure the server with the full chain file your authority provides, rather than only the single leaf certificate.

Lifetimes are getting shorter

The maximum lifetime of a public certificate is being reduced in stages: 200 days from March 2026, 100 days from March 2027 and 47 days from March 2029. Shorter lifetimes limit how long a stolen key or a mis-issued certificate is useful, but they make manual renewal impractical. Treat renewal as an automated job (ACME clients such as certbot, or your CDN's managed certificates) and monitor expiry independently, so you hear about a failed renewal weeks before it matters.

Common failure modes

• •Expired certificate from a renewal job that failed silently, often after a server or DNS change.
• •Leaf certificate installed without its intermediates.
• •A new subdomain added to DNS but not to the certificate.
• •A self-signed certificate left in place after a migration, which no browser will trust.
• •A certificate issued for 2048-bit RSA or better but still served alongside an old, weak one on a different IP.