TLS certificates: chain, names and expiry

When a browser connects to a site over HTTPS it receives a certificate and checks four things before showing the padlock.

1. The name matches

The certificate lists the hostnames it covers in the subject alternative names. example.co.uk and www.example.co.uk are different names; a wildcard *.example.co.uk covers one label of subdomains but not the apex. Mismatch: TLS-HOSTNAME-MISMATCH.

2. The chain leads to a trusted root

The site's certificate is signed by an intermediate, which is signed by a root the browser trusts. The server must send the intermediate; a missing one produces "chain does not verify" (TLS-NOT-TRUSTED) in some clients while others fetch it silently.

3. It is within its validity period

Publicly trusted certificates now last at most 398 days, and the industry is moving to shorter lifetimes. Automate renewal; a Watch on whois.me.uk alerts you 30, 14, 7 and 1 days before expiry. Expired: TLS-EXPIRED.

4. It has not been revoked

Checked through OCSP or CRLs; rarely a problem for correctly issued certificates.

Beyond the certificate

• Protocols: TLS 1.2 and 1.3 only. Accepting 1.0 or 1.1 lowers your grade (TLS-OLD-PROTOCOLS).
• Key: 2048-bit RSA or ECDSA P-256.
• HSTS: a header telling browsers to always use HTTPS for your site.
• CAA: a DNS record restricting which authorities may issue for your domain.

Mail servers too

SMTP uses the same certificates. MTA-STS and DANE require the mail server's certificate to match the MX hostname, which is why the Mail facet checks it separately.