Your monitoring says the cert is fine. Your customer says the site is broken. Both are right.
Internal monitoring sees what your origin reports. External monitoring sees what the customer's browser sees. These are not the same thing, and the difference between them is where most "we didn't know" outages live.
What internal monitoring actually monitors
An internal cert monitor typically runs on or near the systems it's monitoring. It reads the cert file from disk, parses the fields, checks expiry, maybe runs a local openssl s_client against the local hostname. The check confirms what the origin server knows about its own state.
Things internal monitoring catches:
- Cert expiry on the host being monitored.
- Cert file existence and basic validity on disk.
- Local TLS handshake completion from the same machine that holds the cert.
Things internal monitoring doesn't catch:
- CDN/edge serving a stale cert while origin is fine.
- Regional routing differences (the cert your US-East customers see vs the one your APAC customers see).
- Network-layer issues that block customer traffic but not internal traffic.
- DNS misconfigurations that send some customers to the wrong endpoint.
- Customer-side trust store issues (the cert chains through a CA that the customer's browser version doesn't trust).
- Pinning failures (the customer's app pinned the old cert; renewal broke them).
- SAN coverage gaps that affect a specific hostname.
All of the second list shares a property: the failure is in the path between origin and customer, not at the origin. Internal monitoring can't see those by definition.
What "external" actually means
External monitoring runs probes from outside your infrastructure. Specifically, the probe should be:
- On the public internet, not inside your VPC. Hits your public DNS, traverses your public-facing CDN/edge, gets the same TLS handshake a customer would get.
- From multiple geographies, because CDN edges differ by region and some failures are regional.
- Using browser-equivalent validation logic, not just "did the handshake complete." A handshake can complete and still fail browser-side validation (chain incomplete, weak cipher negotiated, OCSP revoked, hostname mismatch on a SAN edge case).
- Continuous, not on-demand. The cert was fine at issuance; it can break afterward through configuration drift, CDN cache poisoning, or upstream rotation.
These properties matter. A probe from inside your network that hits an internal load balancer doesn't tell you what your customer sees. A probe from one geographic location doesn't tell you what your customers in other geographies see. A check that confirms the handshake completed but not that the cert validates correctly misses real failures.
The TLS handshake is path-dependent
This is the part most internal monitoring setups don't account for. The TLS handshake your customer sees depends on every hop between them and your origin. If a CDN edge has a stale cert, your customers routed through that edge see the stale cert. If a regional load balancer serves a different cipher than your origin, customers in that region get the different cipher.
Internal monitoring assumes the cert your origin holds is the cert your customer receives. That's true sometimes. It's not true when there's any kind of caching, edge termination, regional differentiation, or upstream proxy in between - which is most production environments.
Check your own domain right now
The fastest way to see the difference: run an external SSL scanner against a domain you care about and compare the output to whatever your internal monitoring shows. Look at the chain depth, the cipher negotiated, the SAN coverage, the OCSP status. If they match, your monitoring is probably catching what matters. If they don't, the gap is exactly the kind of thing that causes the next "we didn't know" outage.
The scan takes a few seconds. The information is concrete enough that you can make a real decision about whether your current monitoring covers what your customers actually experience.
See what your customers see, not what your origin reports
TLS Radar runs continuous external probes from multiple geographies against every certificate in your inventory, using browser-equivalent validation logic. Catches the failures internal monitoring can't see: CDN-side issues, regional differences, chain breaks at the edge, OCSP revocation. Built to scale from a handful of sites to enterprise portfolios with API integration, SAML/SSO, and pricing tailored to your certificate volume.
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.