Most certificate monitoring focus is on web servers. That makes sense — web servers are the most visible, the most documented, and the most directly associated with TLS in most teams' mental models. But the certificate risk that causes the largest outages is rarely on the origin server. It is on the layer in front of it.
CDN edge nodes, load balancers, reverse proxies, API gateways, and WAFs sit between users and every service behind them. A single certificate on one of these components may be the TLS termination point for dozens or hundreds of backend services. When that certificate expires, all of them fail simultaneously from the user's perspective — even if every individual backend service has a valid, current certificate of its own.
The blast radius problem
Consider a typical architecture: a CDN handles TLS termination for an organisation's entire public surface. Traffic is routed based on path or host header to different backend services — the main website, the API, the customer portal, the admin interface. Each backend may have its own certificate for internal communication, but the certificate the user's browser sees is the CDN edge certificate.
If that CDN certificate expires, the browser receives an invalid certificate error before the request ever reaches a backend. Every service behind the CDN is effectively down — not because anything is wrong with the services themselves, but because the front door is broken.
The same pattern applies to:
- Hardware load balancers (F5 BIG-IP, Citrix ADC, Kemp) that terminate TLS for multiple virtual servers
- Reverse proxies (NGINX, HAProxy, Envoy) configured as the TLS endpoint for a service mesh or microservices architecture
- API gateways (Kong, Apigee, AWS API Gateway) handling authentication and routing for all API traffic
- Web Application Firewalls that sit in front of application servers
- Cloud-managed certificate services where certificates are attached to resources like Application Load Balancers in AWS or Front Door in Azure
Why edge certificates get missed
Several factors combine to make edge certificates systematically under-monitored in many organisations:
Different ownership. CDN and load balancer certificates are often managed by a network or infrastructure team, while application certificates are managed by development or DevOps teams. Certificate monitoring processes that developed around application certificates may never have been extended to cover infrastructure components managed by a different group.
Different tooling. Certificates on hardware load balancers and CDN platforms often cannot be managed through the same tooling as server certificates. They live in management consoles, provider portals, or proprietary APIs. This makes it easy for them to fall outside whatever certificate tracking system exists.
False confidence from scanning. External certificate scanners typically connect to the endpoint that users connect to — which means they see the edge certificate, not the origin certificate. If scanning is set up to check the origin server's IP directly, it sees the origin certificate and misses the edge certificate entirely. If it checks the user-facing domain, it sees the edge certificate — but only if that scanning is actually happening for all domains, including domains served only through the CDN.
Managed service assumption. Teams sometimes assume that because a CDN or cloud load balancer is a managed service, certificate management is handled automatically. Some providers do handle this — AWS Certificate Manager auto-renews certificates attached to CloudFront — but many do not, and the distinction is not always clear until something breaks.
Common failure scenarios
A few patterns come up repeatedly in edge certificate incidents:
The CDN certificate renewed, the origin did not update. Some CDN configurations require the customer to upload the renewed certificate manually. The CDN sends renewal reminders to an email address that nobody reads, the deadline passes, and the edge certificate expires while the origin certificate is current and healthy. Monitoring that only checks origin certificates completely misses this.
The wildcard expired and nobody noticed until a service failed. Wildcard certificates covering *.yourdomain.com are efficient but opaque. When the wildcard expires, every service using it breaks simultaneously. The scope of a wildcard makes it easy to lose track of what depends on it — and makes the outage correspondingly larger when it expires.
The third-party CDN certificate was not in anyone's inventory. Organisations frequently use multiple CDN providers — one for the main site, another for video delivery, a third for a specific geographic region. Certificates on each of these providers are separate, managed through separate portals, and often tracked by nobody.
A cloud resource certificate expired after the team that managed it changed. Cloud certificate management is often tied to individuals or teams. When an organisation restructures, the institutional knowledge of what certificates exist where and who manages them can be lost entirely.
What monitoring should cover
Effective certificate monitoring for edge infrastructure requires checking certificates at the point where users actually connect — not just at the origin. This means:
- Monitoring the user-facing domain and port combination, not the backend IP address. The certificate that matters is the one the user's browser validates.
- Covering all domains and subdomains served through edge infrastructure, including domains that may be on a CDN but not in the primary domain inventory.
- Checking across CDN providers — if traffic is split across multiple CDNs, each provider's edge certificate needs to be in scope.
- Including non-standard ports — not every service uses port 443. APIs on non-standard ports, internal services exposed for partner integrations, and development environments served on alternate ports all have certificates that need monitoring.
- Alert windows long enough to account for the renewal process. Replacing a certificate on a hardware load balancer may require a change management process, maintenance window, and sign-off. A 30-day alert window that is appropriate for an automated server certificate may be inadequate for an infrastructure certificate with a two-week change management process.
How CertControl handles edge certificates
CertControl monitors certificates at the connection point — the domain and port that users actually connect to. This means the edge certificate is what gets checked, regardless of whether traffic is served from a CDN, load balancer, or origin server directly.
The external scanner discovers certificates across all subdomains found in CT logs, including domains served through CDN providers that may not be in a manually maintained inventory. For internal load balancers and reverse proxies not reachable from the internet, the on-premise agent covers the same monitoring within your network perimeter.
Expiry alerts fire at configurable intervals — with longer lead times configurable for infrastructure certificates where the renewal process requires more coordination. The risk scoring system weights certificates covering many services higher, so edge certificates with broad blast radius surface at the top of priority lists rather than sitting quietly next to individual service certificates.