Certificate monitoring answers one question well: is the cert expired, and is it the cert you expect? An expiry monitor watches not_after. A change monitor diffs the leaf's fingerprint and pages you when it rotates unexpectedly. Both are worth having, and both are looking at the certificate.
Neither of them looks at the handshake.
A certificate is a document. The handshake is the negotiation that document is presented inside — which protocol version the two sides agreed on, which cipher suite they settled on, and which chain of intermediates the server actually sent to get you from its leaf up toward a root. All three can be misconfigured while the certificate itself is flawless: valid dates, correct subject, trusted issuer, green padlock, zero browser warnings. The site loads. Nothing throws. And the connection is still graded weak.
This is a different failure class from the one the browser SSL error pages catch. ERR_SSL_PROTOCOL_ERROR, "your connection is not private," a name-mismatch interstitial — those are hard failures a visitor hits and reports. Weak posture is the opposite: it is the connection that succeeds. No user will ever file a ticket about it, because from their chair nothing is wrong. It surfaces only if something is deliberately grading the negotiation itself.
A graded handshake has three axes
When we run a TLS check, we do not stop at "did the certificate validate." We capture the negotiated protocol version, the negotiated cipher suite, and the full chain of certificates the server presented, and grade each one.
Protocol version. Anything below TLS 1.2 — SSL 3.0, TLS 1.0, TLS 1.1 — is deprecated and flagged. These still exist in the wild on load balancers and appliances nobody has reconfigured since the certificate was last renewed by an automated tool that touches only the cert, not the protocol floor. An unknown or unmapped version code is deliberately not asserted weak; you do not manufacture a finding out of a value you could not identify.
Cipher suite. Two properties decide the grade: forward secrecy (an ephemeral ECDHE/DHE key exchange, so a future key compromise cannot decrypt today's recorded traffic) and an AEAD bulk cipher (GCM, ChaCha20-Poly1305, CCM — authenticated encryption, versus a legacy CBC or RC4 construction). The grade falls out of the two:
- strong — forward secrecy and AEAD. The modern default.
- acceptable — exactly one of the two. RSA key exchange with a GCM cipher, or ECDHE with a legacy CBC cipher. Secure today, not ideal.
- weak — neither. RSA key exchange plus CBC/RC4/3DES. This is the posture a compliance reviewer flags on sight.
An unrecognised suite is graded acceptable, never weak — the same discipline as the protocol case: absence of recognition is not evidence of a problem.
The chain. Servers present a leaf plus the intermediates needed to link toward a root. Three things go wrong here without the leaf itself being invalid: an intermediate is missing or out of order (some clients fetch it anyway and hide the break, others fail — the classic "works in my browser, breaks on your Android"), a certificate anywhere in the chain carries a SHA-1, MD5, or MD2 signature, or an intermediate has expired even though the leaf has plenty of life left. That last one is its own finding: leaf expiry is what an ordinary expiry monitor already covers; an expired intermediate is a distinct, actionable fact it does not.
The one that actually bites: a silent downgrade on the same cert
Grading a handshake once tells you your current posture. The event worth an alert is the change — and specifically the worsening one.
A server can be reconfigured to a weaker cipher, dropped below TLS 1.2, stripped of forward secrecy, or handed a broken chain, all while presenting the exact same certificate. The leaf fingerprint does not move. Its expiry does not move. A cert-expiry monitor sees nothing. A cert-identity diff — the thing that pages you when the certificate rotates — sees nothing, because the certificate did not rotate. The bytes on the wire got weaker and every certificate-shaped monitor stayed green.
So posture needs its own comparison: previous observed posture versus current, reporting only a downgrade — cipher strength dropped a rank, protocol fell below 1.2, forward secrecy was lost, a chain that was complete is now broken. An upgrade is not an incident. And because it compares previous-to-current, a posture that is persistently weak fires at most once on the transition into that state: the next check sees previous and current both weak, finds no transition, and stays quiet. A steady weak posture is a finding on your dashboard, not a page every five minutes. Only the moment it got worse rings the phone.
This is the same alerting discipline every good monitor converges on from a different direction — a heartbeat keys its alert on the outage, not the asset; a posture check keys its alert on the transition, not the state. Both exist to say the loud thing exactly once.
The honest limits
It would be easy to claim more than this check delivers, so here is exactly what it does not do.
The chain assessment is structural, not cryptographic. It checks that the subject and issuer distinguished names link the presented certificates into a proper ordered chain, and it scans every certificate for a weak signature algorithm and for expiry. It does not verify each signature against a bundled Mozilla or platform trust store, because the environment it runs in (edge workers) ships no such store. It reliably catches the two most common real-world chain misconfigurations — a missing/out-of-order intermediate and a SHA-1 signature — without pretending to be full RFC 5280 path validation.
The protocol and cipher grades reflect the client hello we offer, which advertises up to TLS 1.2. So the check detects a server stuck below 1.2 or lacking modern ECDHE/GCM suites; it makes no claim about whether the server also supports TLS 1.3, because the probe never offers 1.3 to find out. Reporting "we didn't ask" as "not supported" would be a lie, so the grade stays silent on it.
Stating the boundary is the point. A posture grade you can trust is one that tells you where its own knowledge stops.
Bottom line
A valid certificate tells you the document is in order. It says nothing about the negotiation underneath it — the protocol floor, the cipher's forward secrecy and AEAD properties, the intermediates in the chain. Those can all degrade on an unchanged, unexpired certificate, throwing no error and showing no padlock warning, invisible to every certificate-shaped monitor. Grade the handshake, not just the document. And alert on the worsening transition — once — not on every check of a steady state.
I write about the boring, silent failure modes of web infrastructure at merlonix.com/blog, where this post first appeared. Merlonix grades the live TLS handshake on every SSL check — protocol, cipher, and presented chain — and alerts when a previously-observed posture worsens on a cert that never changed.
→ Your Certificate Auto-Renewal Will Fail Silently One Day
→ ERR_SSL_PROTOCOL_ERROR: What It Actually Means
→ A Dead-Man's Switch That Pages Once and Goes Quiet
