Does your SSL monitor actually check the certificate chain?

Probably not, unless you have specifically checked. A green result on most SSL monitoring dashboards means the TLS handshake succeeded and the certificate has not expired, and neither of those confirms the certificate chain your server sends is actually complete on its own.

What a green check usually means

A typical SSL monitor connects to your server, completes a TLS handshake, and reads the leaf certificate's expiry date. If the handshake succeeds and the date is in the future, it reports the certificate as valid. That is a real check, and it catches the most common failure, an expired certificate, reliably.

It does not confirm that your server sent every intermediate certificate needed to build a complete path from your certificate to a trusted root. A server missing an intermediate can still complete a handshake successfully with plenty of clients, because desktop browsers fetch the missing piece for you: Chrome, Firefox, and Safari support AIA (Authority Information Access) fetching, downloading a missing intermediate on the fly, and they also cache intermediates seen on other sites, so a chain that is actually broken can look perfectly fine every time you check it in a browser.

The clients that do not get this help are the ones a browser-based spot check, or a monitor that only confirms handshake success, will never exercise: curl, most language HTTP libraries, mobile apps, webhook receivers, and other server-to-server integrations. They see exactly what your server sends and nothing more.

Why this keeps getting more likely, not less

Certificate lifespans have been shrinking for years, and the trend continues: 200-day maximum validity is already the norm, and the industry is on a path toward 47-day certificates by 2029. That means far more renewals per year than a decade ago, and every renewal is a fresh opportunity for automation to update the leaf certificate while quietly dropping an intermediate, especially after a CA rotates which intermediate it issues from, something that happens without any announcement most site operators would notice.

A concrete version of the failure: a payment webhook, a partner API integration, or a mobile app backend starts failing TLS verification the week a renewal goes out with an incomplete chain. Nobody on the team notices anything wrong, because every browser they check the site in works fine. The failure sits in a queue of silently dropped webhook deliveries or a support ticket from one specific customer's integration, and it can take weeks to connect that symptom back to a certificate that "looks fine" to everyone who only ever checked it in Chrome.

A two-minute test on your own setup

Run this against your own domain to see the chain your server actually sends, independent of any browser help:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -showcerts </dev/null

Two things to look at in the output: count the certificates returned (your leaf plus every intermediate should be there, a chain ending with only the leaf is the incomplete-chain problem), and check the final line for Verify return code: 0 (ok). A non-zero code with a message like unable to get local issuer certificate means OpenSSL, acting like a non-browser client, could not build a trusted path from what your server sent.

What to actually check in your monitoring setup

Whether you run your own uptime checks or use a vendor, the honest question is not "does it show a green check," it is what that check actually tests:

• Does it validate the certificate against a trusted root store independently, the way a non-browser client would, rather than confirming the handshake completed?
• Does it verify the cryptographic signature at each step of the chain, leaf to intermediate to root, not only that certificates with matching names were presented?
• If you run the same domain behind a load balancer or multiple servers, does it check every IP the domain resolves to, or only whichever one it happened to hit that day? A chain can be complete on one server and missing on another after a partial certificate rollout.

If the honest answer to any of those is "I don't know," that is worth finding out before an incomplete chain reaches production, not after a webhook integration or a partner's server starts failing and nobody can explain why it still works fine in a browser.

What WebPixie checks specifically

WebPixie's SSL monitoring validates the full chain from leaf to intermediate to root on every daily check, with cryptographic signature verification for RSA, EC/ECDSA, Ed25519, and Ed448 certificates, not only a successful handshake and an expiry date. It also resolves your domain to every IP it points to and confirms each one serves the same, working certificate, which is exactly the load-balancer-inconsistency case above. Expiry still matters, and gets its own 15-day warning window, but it is one signal among several, not the only thing being tested.

The chain-validation logic itself follows the same path-building rules defined in RFC 5280, the X.509 certification path validation standard every browser and TLS library ultimately implements, applied the same way regardless of which client happens to be asking.