Uptime
TLS certificate
Also called SSL certificate.
TLS certificate is a signed document that ties a domain name to a public key so browsers can set up an encrypted connection and trust who is on the other end.
How it is measured
Inspect with openssl s_client or a probe: subject and SANs, issuer, validity dates, key type and size, chain, and revocation or OCSP status. Check that every hostname you serve appears in the SANs.
Check from several vantage points and protocol versions. A certificate correct on the CDN can differ from the origin's, and old Android devices may fail without the right intermediate.
Worked example
An agency launches a client site on a new subdomain, store.example.test, behind a CDN. The certificate covers example.test and www.example.test only. Chrome shows NET::ERR_CERT_COMMON_NAME_INVALID at 10:05 on launch day.
The SAN list lacks the new name. Reissuing with three names takes 2 minutes with ACME. A launch checklist item to run openssl against each hostname would have caught it on staging.
How it differs
TLS certificate is the credential, with names, issuer, and key. SSL expiry is one property of it, the end date. The certificate covers name mismatch, chain, and key strength. Expiry covers only the clock.
Common errors
Missing SANs. Self-signed certificates in production. Serving an incomplete chain. Different certificates on origin and CDN. Letting the private key leak into a repository. Leaving TLS 1.0 and 1.1 enabled.
In practice
Run a full chain test on each public hostname with an SSL checker. Remove TLS 1.0 and 1.1. Keep private keys outside git, and add a monitor for names and chain alongside the expiry alert. Turn on HSTS only after you are sure every subdomain is covered.