When a browser receives a certificate, it runs through several checks before deciding to trust it — all before the page starts loading. Missing any one of them is enough to trigger a warning.
- Chain validation — can the certificate be traced back, through intermediates, to a root certificate in the trust store?
- Expiry — is today's date within the certificate's validity window?
- Hostname match — does the domain being visited appear in the certificate's SAN field?
- Revocation status — has the certificate been revoked, checked via OCSP or CRL?
- Key usage and extensions — is the certificate actually authorized for TLS server authentication, not just any use?
Where trust stores differ
Chrome, Firefox, Safari, and Windows each maintain their own trust store, which occasionally causes a certificate to be trusted in one browser but not another — most commonly with newer CAs still building up cross-platform trust, or very old root certificates being phased out at different speeds.
Why trust stores occasionally diverge across browsers on the same device
Chrome and Firefox each maintain their own independent trust store rather than relying on the operating system's, while Safari and Edge generally defer to the OS-level store — this is exactly why a certificate can occasionally be trusted in one browser but flagged in another on the identical device, since they're not always consulting the same underlying list.
What happens when a root certificate itself expires or is removed
Root certificates occasionally age out of trust stores as cryptographic standards evolve, or get removed entirely following a serious compliance failure — this is part of why very old, unpatched devices sometimes can't connect to modern HTTPS sites at all, since their built-in trust store was frozen at whatever shipped with the device.
Why revocation checking is the step most likely to be silently skipped
Unlike chain validation and expiry checking, which are straightforward local computations, revocation checking requires a live network request (OCSP) or a downloaded list (CRL) — some browsers have historically soft-failed this specific step when it's slow or unreachable, making it the one trust check most likely to be silently bypassed under real-world network conditions.
Why key usage and extended key usage fields matter beyond just the chain
Even a certificate with a perfectly valid chain will be rejected if its Key Usage or Extended Key Usage extensions don't explicitly authorize it for TLS server authentication — a certificate issued for a different purpose, like email signing, won't work for securing a website even if every other check passes cleanly.
What happens when two different checks give conflicting signals
If a certificate is technically unexpired but revoked, browsers prioritize the revocation status over the expiry check, treating an actively revoked certificate as untrusted regardless of its stated validity window — revocation represents a more urgent, deliberate signal than the certificate's own passive expiry date.
Why this entire checklist runs invisibly, every single time
All of these checks, chain validation, expiry, hostname matching, revocation status, happen automatically within milliseconds on every single HTTPS connection — the complexity is real, but it's specifically designed to be invisible to a visitor when everything is correctly configured.
What happens technically when a browser encounters a certificate type it doesn't recognize
If a certificate uses an extension or feature a specific browser version doesn't recognize, browsers generally follow a fail-safe approach, treating unrecognized critical extensions as reason for caution rather than simply ignoring them, reflecting TLS's general design philosophy of erring toward rejection when genuinely uncertain.
A closing thought
A quick closing thought: every one of these checks happens in milliseconds on every single connection you make — genuinely remarkable complexity operating invisibly behind what feels like an instant, unremarkable page load.