Your CDN is hiding SSL problems from you

If you run anything behind a CDN, you've probably set up SSL monitoring once and forgotten about it. You point your monitoring tool at https://yourdomain.com, it confirms the certificate is valid, and you sleep well at night.

The problem: that check is telling you about your edge certificate. It's not telling you anything about what happens between your CDN and your origin server. And in a CDN architecture, those are two completely different certificates, with two completely different failure modes.

This post walks through three ways CDNs routinely hide SSL problems from standard monitoring, why a common production outage at AWS-fronted services follows this exact pattern, and what you actually need to monitor to catch these issues before your users do.

The misconception: "I have a CDN cert, so my origin cert doesn't matter"

This belief shows up constantly in production. The reasoning seems sound: SSL terminates at the edge, the user only ever talks to the CDN, so the origin doesn't need a valid cert. Right?

Not quite. If your CDN is configured to verify the origin's certificate — which it should be, since anything else is a man-in-the-middle attack waiting to happen — your origin cert directly affects whether content can be fetched. CloudFront calls this "Origin Protocol Policy: HTTPS Only" with origin SSL validation. CloudFlare calls it "Full (strict)". Fastly calls it certificate hostname verification. Whatever the name, the contract is the same: if the origin cert is invalid, expired, or misnamed, the CDN refuses to talk to it.

So the origin cert absolutely matters. The trick is that it doesn't fail loudly — it fails quietly, in ways your monitoring won't see.

Three ways CDNs hide SSL problems

1. Cache outlives the cert

CDNs cache aggressively. That's the point. When your origin certificate expires, the CDN doesn't immediately stop serving traffic — it keeps returning cached responses for as long as those objects are fresh. Static assets with long TTLs (images, CSS, JS bundles) can sit in cache for hours or days.

During this window, everything looks perfect from the outside. Public URLs return 200s. Edge cert is valid. Synthetic monitoring is green.

Then the cache starts expiring. Cache misses hit your origin. The CDN tries to revalidate over HTTPS. The handshake fails. Suddenly you have 502 Bad Gateway errors spreading through your traffic like a slow leak — not all at once, but gradually as different cache keys time out.

By the time someone notices, you have no idea when the cert actually expired, because it expired hours or days before the symptoms showed up.

2. Auto-renewal failure (silent edition)

Most modern CDNs auto-renew their edge certificates. CloudFlare Universal SSL, AWS Certificate Manager certs attached to CloudFront, Fastly managed TLS — they all rotate certs automatically before expiry.

The renewal process requires domain validation. Usually that means a DNS record (CNAME for ACM, TXT for others) that the CDN can verify points where it expects. If that DNS record gets removed, modified, or never propagated to a new nameserver, the renewal fails.

Here's the kicker: the existing cert keeps working until its own expiry date. So renewal can fail months before you notice. You get an email about it (maybe — if it goes to a monitored address), and that's it. No alarm fires, no monitor turns red. Then one day the existing cert finally expires, the renewal still hasn't succeeded, and your entire domain goes dark.

This pattern is especially common after domain migrations, DNS provider changes, or any infrastructure work where someone "cleaned up" old records they didn't recognize.

3. Edge says OK, origin handshake is broken

Most SSL monitoring tools hit your public URL and check whatever certificate the TLS handshake returns. In a CDN setup, that's the edge cert. The edge cert can be perfectly fine while the origin handshake is broken for any number of reasons:

Origin cert expired
Origin cert hostname doesn't match (you serve api.example.com but the cert is for old-api.example.com)
Intermediate certificate missing from the chain
Origin TLS version mismatch with what the CDN requires
Origin presents a self-signed cert and the CDN is configured strict

If the CDN can still serve from cache, users see no symptoms. Cache-miss requests fail with 502s, but might be a small enough percentage that they look like noise in your error rate dashboard. You won't know there's an SSL problem until cache hit rate drops or someone investigates the 502s.

A real example: CloudFront in front of an S3-backed origin

A scenario we see frequently: a team runs a high-traffic application behind CloudFront. The origin is an ALB sitting in front of services that pull objects from S3, accessed at origin.example.com, with a Let's Encrypt certificate renewed by certbot on a host and copied to the load balancer via automation.

One day the renewal automation breaks. Maybe the ACME challenge fails because someone changed the load balancer's listener rules. Maybe the host running certbot was decommissioned in a cleanup. Doesn't matter — the cert stops renewing.

Edge cert (ACM-managed, attached to the CloudFront distribution): renews automatically, no problem. Public monitoring: green. Internal dashboards: green.

The origin cert quietly expires. CloudFront, configured with Origin Protocol Policy: HTTPS Only and full origin verification, refuses to fetch from origin. But CloudFront's cache is healthy — for hot objects, hit rate is over 90%. Users see a slightly elevated error rate, mostly on long-tail URLs.

Roughly 24 hours later, cache for less-popular endpoints starts to drain. 502s climb. Someone notices, digs in, and finds the origin cert expired the previous day. The fix takes ten minutes. The post-mortem question is uncomfortable: how did we ship 24 hours of degraded service before anyone noticed?

The answer is the topic of this post. Edge monitoring saw the edge. Nothing was watching the origin.

How to monitor both layers

Catching this requires three checks running in parallel, not one.

Edge certificate check. Standard HTTPS monitoring against your public hostname. Verify the cert chain, expiry, and hostname match. This is what most monitoring tools do by default — and it's necessary but nowhere near sufficient.

Origin certificate check. Connect directly to your origin (skip the CDN) and verify the cert it presents. This means hitting the origin's hostname or IP with the appropriate Host header. The catch: your origin probably isn't publicly routable, or is behind a WAF that blocks non-CDN traffic. You need a monitoring source that can either reach it directly or use an internal probe inside your VPC.

Cache-miss behavior check. Periodically force a cache miss and verify the response is fresh from origin, not stale. This is the only way to catch the cache-masked origin failure mode before the cache naturally drains. A typical technique: append a random query string and require a 200 response with origin-fresh headers (Age: 0, X-Cache: Miss, etc.).

Combining these gives you separate signals for each of the three failure modes above. Drop any one and you have a blind spot.

This is exactly the pattern StableSSL is built around. We probe edge and origin certificates separately, track their renewal cycles independently, and run cache-miss synthetic checks against CDN-fronted properties so you find out about origin handshake failures before your users do. But you can build a basic version of this yourself with two cron jobs and openssl s_client — the important thing is that you're checking both layers, not just the one your browser sees.

CDN-specific checklists

The principle is universal; the configuration knobs differ. Here's what to verify on each major CDN.

CloudFlare

Set SSL/TLS mode to "Full (strict)" — anything less means the edge accepts invalid origin certs
Use CloudFlare Origin CA certs on your origin (15-year certs that only validate against CloudFlare)
Turn on Authenticated Origin Pulls for an extra mTLS layer between edge and origin
Monitor both Universal SSL status and origin cert expiry separately

Fastly

Confirm Managed TLS hostnames are validated and renewing
Set TLS configuration on origins to require certificate verification with hostname matching
Check the certificate hostname in your origin definition matches what the origin actually presents (a common mismatch when origins are referenced by IP but the cert is for a hostname)
Monitor TLS subscription state via the API, not just expiry date

CloudFront

ACM certificate attached to the distribution must be in us-east-1 — easy to forget after region migrations
Origin Protocol Policy should be HTTPS Only or Match Viewer, not HTTP Only
Set OriginSSLProtocols explicitly (TLSv1.2 minimum) — the default has shifted over time
For custom origins, the origin domain name must match the CN/SAN on the origin cert exactly
Monitor ACM renewal events via CloudWatch alongside origin cert checks

Akamai

Verify property hostnames have valid certificates provisioned in Certificate Provisioning System (CPS)
Set Origin Certificate Validation to verify hostname and trust chain (the default is often more lenient than people expect)
For mutual TLS setups, ensure client certs at origin are renewed in step with edge configuration
Track CPS deployment status, not just cert expiry — deployments can lag for hours

The pattern is the same across all of them: there's an edge cert and an origin cert, they fail differently, and your monitoring needs to treat them as separate things.

Closing thoughts

SSL monitoring isn't really one problem anymore — it's at least two, and in some architectures more. Every CDN, load balancer, and reverse proxy in your stack is a potential termination point, with its own certificate, its own renewal cycle, and its own failure modes that won't show up at the layer above.

If your monitoring only sees one of those layers, you're operating with a known blind spot. The fix isn't expensive or complicated. It just requires looking at every TLS handshake in your stack, not only the one your users hit.