What to read first in any certificate
When a certificate lands in front of you, four fields decide whether it will work, in this order:
| Field | Question it answers | Failure mode |
|---|---|---|
| notBefore / notAfter | Is it currently valid? | Expired, or not yet active (clock skew) |
| Subject Alternative Name | Does it cover this hostname? | Name mismatch warning |
| Issuer | Is the CA trusted? | Self-signed or unknown CA |
| Signature algorithm / key size | Is the crypto modern? | SHA-1 or sub-2048-bit RSA rejected |
The legacy Common Name (CN) field is effectively dead — browsers have validated against SAN exclusively for years. If a domain works in an old tool but warns in Chrome, a CN-only certificate with no matching SAN entry is the classic cause.
Chain order is not optional
A server must present its certificates in a specific order: leaf first, then each intermediate, in ascending order toward the root — and it must not include the root itself (the client already trusts the root locally; sending it wastes bytes and can confuse some validators). When the intermediate is missing, the situation is maddening to debug because it’s client-dependent: desktop Chrome often “fixes” the chain via AIA fetching or a cached intermediate, so it looks fine on your machine, while a mobile client or a curl from a server fails. If “works for me, fails in CI,” suspect a missing intermediate first. The -showcerts output from the FAQ command reveals exactly what the server sends.
Expiry is an operational problem, not a calendar reminder
Manual renewal is how outages happen — someone leaves, a reminder is missed, and a flagship domain goes dark for a day. The durable fix is automation:
- ACME / Let’s Encrypt certificates last 90 days precisely to force automated renewal. A
certbotoracme.shtimer renews at ~60 days and reloads the server. Set it once; stop thinking about it. - Monitoring is the safety net for everything ACME doesn’t cover (paid EV certs, internal CAs, appliances). Alert at 30 and 7 days before notAfter, so a failed auto-renewal still has a human backstop.
SSL vs TLS, and what “disable SSL” really means
In conversation “SSL” still means “the encrypted connection,” but the SSL protocol versions (2.0, 3.0) are all broken and disabled everywhere. What you actually run is TLS — and in 2026 that means TLS 1.2 as the floor and TLS 1.3 preferred. When a security scan says “disable SSL,” it means disable SSLv3 and ideally TLS 1.0/1.1 on the server. The certificate itself is protocol-agnostic; the same cert works across TLS versions. Hardening the protocol is a server-config task separate from the certificate analysis you do here.