Open any HTTPS site, click the padlock, and you can see its certificate — but most people stop at "valid until 2025". The fields below that are useful, and a few of them tell you whether the operator actually knows what they're doing.
The fields that matter
Subject and Subject Alternative Names (SANs)
The Subject's Common Name (CN) used to be how the certificate said which hostname it was valid for. Modern browsers ignore the CN entirely and trust only the SAN list. Every hostname your server answers on must appear in the SANs — the apex, every www variant, every wildcard, and any aliases. A certificate without a matching SAN entry will be rejected even if the leaf is otherwise perfect.
Issuer
The Certificate Authority (CA) that signed your leaf certificate. Browsers ship a list of trusted root CAs; your leaf must chain back to one of them. Common public CAs include Let's Encrypt, DigiCert, Sectigo, and GlobalSign. Self-signed certs are issued by you and aren't trusted by default.
Validity period
Public certificates today are issued for at most 397 days, and the trend is shorter — many automated systems issue 90-day certs and rotate before expiry. "Valid from" and "Valid to" together define the lifetime. Anything within 30 days of expiry deserves attention; under 7 days, you're a renewal failure away from a user-visible TLS error.
Signature algorithm and key size
You want SHA-256 (or stronger) signature algorithms; SHA-1 is broken and has been removed from modern browsers. RSA keys should be 2048 bits or larger; ECDSA with P-256 or P-384 is preferred for new deployments because it's faster and smaller.
Chain of trust
Your server doesn't just send the leaf. It sends a chain: leaf → intermediate(s) → root. Browsers already trust the root, so your job is to send everything between the leaf and the root. The most common TLS misconfiguration in the wild is sending only the leaf and assuming clients will fetch the intermediate themselves — most won't, and they'll fail with "unable to verify".
SSL Checker shows you exactly what your server is sending. If the chain depth is 1 (only leaf), you have a chain problem. Most certificate issuers ship a "fullchain.pem" file specifically for this reason.
Revocation: OCSP, CRL, and OCSP stapling
Certificates can be revoked before their natural expiry — usually because a key was compromised. Browsers check revocation in two ways: by querying the CA's OCSP responder live, or by reading a CRL (Certificate Revocation List). Live OCSP queries leak which sites you visit to the CA and add latency, so modern servers do OCSP stapling: the server fetches the OCSP response itself periodically and "staples" it to the TLS handshake. Stapling is on by default in nginx and Apache modern config; if you're not using it, you're slower than you need to be.
The errors you'll actually see
- NET::ERR_CERT_DATE_INVALID — expired or not-yet-valid. Check "Valid to" against the current time.
- NET::ERR_CERT_AUTHORITY_INVALID — the chain doesn't terminate at a trusted root. Either you're using a self-signed cert or you're missing the intermediate.
- NET::ERR_CERT_COMMON_NAME_INVALID — the requested hostname isn't in the SANs. Add it.
- SEC_ERROR_OCSP_* — revocation check failed. Often transient; if it persists, check OCSP stapling on your server.
How to actually inspect a certificate
From the command line:
openssl s_client -connect example.com:443 -servername example.com < /dev/null \\
| openssl x509 -noout -textOr skip the typing and use SSL Certificate Checker — same data, formatted for humans, plus an at-a-glance "valid / expiring soon / expired" verdict.
What to set up while you're thinking about it
- Automate renewal. Manual renewal is how outages happen on a Sunday morning.
- Monitor expiry. A weekly cron job checking
not-afterand emailing you at 30 days, 14 days, 7 days, and 1 day costs nothing. - Enable HSTS once the certificate is solid — HTTP Headers Inspector verifies it's being sent.
- Avoid wildcards if you can; named SANs are easier to revoke surgically if a single host is compromised.