Your Certificate Is Valid and Your Site Loads Fine — and Your TLS Still Grades Weak

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 Merlonix runs its TLS check, it does not stop at "did the certificate validate." It captures the negotiated protocol version, the negotiated cipher suite, and the full chain of certificates the server presented, and grades 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 (Cloudflare 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 Merlonix offers, 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.

What Merlonix ships

Merlonix grades the live handshake on every socket-path SSL check — no separate feature to enable, no dark flag. It captures the negotiated protocol, the cipher and its forward-secrecy/AEAD properties, and the full presented chain; it records the grade on the check row and surfaces the specific issues (weak_protocol:TLS 1.0, no_forward_secrecy, weak_sig_alg:sha1WithRSAEncryption, expired_in_chain, incomplete_chain) rather than a single opaque letter. Across production it has graded thousands of real handshakes this way. When a previously-observed posture worsens on an unchanged certificate, that transition raises an additive alert the cert-identity classifier would never see — and a posture that is merely steadily weak stays a dashboard finding instead of a nightly page.

A valid certificate tells you the document is in order. It says nothing about the negotiation. Those are two different clocks, and only one of them is on your expiry dashboard.