SSL Certificate Showing Expired for Some Visitors but Not Others: What Is Happening and How to Fix It

An SSL certificate showing as expired for some visitors but not others is always a deployment or routing issue, not a certificate validity issue. A certificate either is expired or is not ,  it cannot be expired for some visitors and valid for others. What varies by visitor is which server or CDN edge node they connect to. One of those servers or nodes has the old expired certificate; the others have the new valid one.

The three configurations that produce this pattern are: CDN edge nodes receiving certificate updates at different times (the most common cause), multiple origin servers behind a load balancer with an inconsistent certificate deployment, and split DNS serving different certificate configurations to internal vs external networks. Each has a different fix.

Rapid Diagnosis: Identify Which Cause Applies

Cause 1: CDN Edge Node Certificate Propagation Lag

CDNs operate global networks of edge nodes (sometimes called Points of Presence or PoPs). Each edge node terminates TLS for visitors in its geographic region. When a certificate is updated on the origin server, the CDN must push that updated certificate to all edge nodes. This propagation is not instant.

During the propagation window, some edge nodes have the new certificate and some have the old one. A visitor routed to a node with the new certificate sees a valid HTTPS connection. A visitor routed to a node with the old (possibly expired) certificate sees the certificate error. The same visitor may see the error on one page load and not another if subsequent requests are routed to different nodes.

CDN-specific certificate update behavior

• Cloudflare: certificate updates propagate across Cloudflare’s global network within minutes to a couple of hours depending on edge node cache state. Cloudflare manages TLS termination at the edge for domains proxied through Cloudflare (orange cloud). If using a custom origin certificate behind Cloudflare, the origin certificate update does not affect edge behavior until the edge’s cached certificate expires or is purged.
• AWS CloudFront: when a new ACM (AWS Certificate Manager) certificate is deployed to a CloudFront distribution, CloudFront propagates the certificate to all edge locations. AWS documentation states propagation completes within minutes globally, but during peak propagation load, some edge locations may lag.
• Fastly: certificate updates propagate across Fastly’s network within minutes. Fastly’s platform documentation recommends verifying certificate status from multiple geographic locations after update.
• Azure CDN: certificate propagation on Azure CDN follows Azure’s managed certificate pipeline. Propagation typically completes within minutes but Azure’s documentation notes that full global propagation may take up to a few hours in edge cases.

Fix for CDN propagation lag: wait 1-2 hours after certificate deployment for propagation to complete across all edge nodes. If the error persists beyond 2 hours, trigger a manual cache purge in the CDN dashboard, which forces edge nodes to re-request the updated certificate from the origin. For Cloudflare, Purge Cache under Caching removes cached certificates from edge nodes.

How to verify CDN propagation status

Use SSL certificate checking tools with multiple geographic probes to see which certificate each region’s edge node is serving:

• org SSL Check: queries the domain from multiple global locations and shows which certificate is returned from each location
• SSL Shopper SSL Checker: similar multi-location check with certificate validity and expiry details per probe location
• Direct curl from different servers: if you have access to servers in different regions, run curl and check certificate details from each region

curl -vI https://yourdomain.com 2>&1 | grep -E ‘SSL certificate|expire|subject|issuer’

If different probe locations show different certificate expiry dates, CDN propagation lag is confirmed as the cause.

Cause 2: Split DNS Serving Different Certificates to Different Networks

Split DNS (also called split-horizon DNS) is a configuration where the same domain name resolves to different IP addresses depending on the querying network. The most common scenario: internal corporate DNS resolves yoursite.com to an internal server IP; external DNS resolves the same domain to the public-facing server IP.

If the internal server has a different SSL certificate than the external server ,  or if the internal server’s certificate is expired while the external server’s is current ,  employees on the corporate network see the certificate error while external visitors do not (or vice versa).

This scenario is identified by the employee/external visitor pattern in the diagnostic table above: if the error only affects users on a specific network (corporate VPN, office network) and not external visitors, split DNS is the likely cause.

Diagnosis: from the affected network, run a DNS lookup and compare the resolved IP to the DNS lookup from an external network:

nslookup yourdomain.com

If the IP addresses differ between networks, split DNS is confirmed. Check the SSL certificate on each resolved IP:

openssl s_client -connect INTERNAL_IP:443 -servername yourdomain.com < /dev/null 2>/dev/null | openssl x509 -noout -dates

openssl s_client -connect EXTERNAL_IP:443 -servername yourdomain.com < /dev/null 2>/dev/null | openssl x509 -noout -dates

Fix: install a current valid certificate on the internal server, or update the split DNS configuration so both the internal and external resolution point to a server with a current certificate. If the internal server was intentionally serving a different certificate (e.g. an internal CA certificate for internal systems), this requires either updating that internal certificate or accepting that internal users will receive a different certificate.

Cause 3: Load Balancer With Incomplete Certificate Deployment

Load balancers distribute traffic across multiple origin servers. TLS termination can happen at the load balancer level (the load balancer decrypts and re-encrypts) or at the origin server level (end-to-end encryption to the origin). When TLS terminates at the load balancer, certificate updates only need to be deployed to the load balancer. When TLS runs end-to-end to the origin servers, every origin server needs the certificate updated.

Inconsistent errors that appear intermittently for any visitor (not tied to geography or network) indicate load balancer routing to servers with different certificate states. Request 1 goes to Server A (new certificate, no error). Request 2 goes to Server B (old expired certificate, error shown). Same visitor, same browser, error on one request but not the next.

Diagnosis: check the certificate on each origin server behind the load balancer directly by connecting to each server’s IP:

openssl s_client -connect ORIGIN_SERVER_1_IP:443 -servername yourdomain.com < /dev/null 2>/dev/null | openssl x509 -noout -dates

openssl s_client -connect ORIGIN_SERVER_2_IP:443 -servername yourdomain.com < /dev/null 2>/dev/null | openssl x509 -noout -dates

If expiry dates differ between servers, certificate deployment is incomplete.

Fix: deploy the current certificate to all origin servers. If using an automated deployment tool (Ansible, Terraform, Kubernetes Secrets), verify that the deployment job ran successfully on all nodes, not just the first one in the inventory. After updating all origin servers, verify from the load balancer level that the certificate presented externally is the current one.

Cause 4: Client System Clock Skew

A certificate has a notBefore and notAfter date. A client whose system clock is significantly wrong may interpret a valid certificate as expired (if the clock is ahead of the certificate’s notAfter date) or as not yet valid (if the clock is behind the certificate’s notBefore date).

This cause is specific to individual users: the error affects only one user or one device, is not reproducible by anyone else, and the same user may not see the error on a different device. It is the least common of the four causes but worth eliminating before assuming a deployment issue.

Identification: ask the affected user to check their system clock. A difference of more than a few minutes from the actual time can cause certificate validation errors. NTP sync resolves this.

This cause does not require any change to the certificate or server configuration.

Why HSTS Failures Do Not Produce Inconsistent Errors

A question this scenario sometimes prompts: could HSTS cause some visitors to see errors and not others? The answer is no, and understanding why helps confirm the diagnosis.

HSTS (HTTP Strict Transport Security) is a browser-level directive cached from the HTTP response header. Once a browser has received an HSTS directive for a domain, that specific browser enforces HTTPS for the full max-age duration. If the certificate is then expired, that specific browser blocks the site. A visitor using a different browser, or a first-time visitor whose browser has not cached the HSTS directive, may not be blocked in the same way.

This pattern looks different from CDN/load balancer inconsistency: HSTS inconsistency would split between returning visitors (with HSTS cached) and new visitors (without HSTS cached), not between geographic regions or network locations. If the error is geographic or network-specific, HSTS is not the cause.

When to Buy a New Certificate

The three causes above are infrastructure and deployment issues that can be fixed without buying a new certificate. The case where a certificate purchase is necessary:

• The certificate expired because automated renewal failed: if Let’s Encrypt renewal failed silently, the certificate may be genuinely expired and need replacement. Diagnose by checking the certificate expiry date with SSL Labs or the openssl command. If expired, renew via Certbot or ACME client, or purchase a replacement DV certificate from an authorized reseller. The advantage of a paid certificate in this scenario is that the multi-year subscription removes the 90-day renewal cycle that created the failure point. Sectigo PositiveSSL DV from Certera: $4.99/year.
• The certificate was deployed only to the load balancer and origin servers need separate certificates: if the architecture requires individual origin server certificates, purchase a certificate per server or a wildcard certificate covering all origin hostnames.
• The deployment process itself needs updating: for organizations where certificate deployment to multiple servers is a manual process, a paid multi-year certificate from a reseller eliminates the 90-day renewal frequency that makes manual deployment unsustainable. A 3-year Sectigo subscription renewed once every 3 years is operationally simpler than a Let’s Encrypt certificate renewed every 90 days across multiple servers.

The 47-day certificate validity trajectory (coming 2028-2029 per CA/B Forum Ballot SC-081v3) makes automated renewal and consistent deployment across all CDN edge nodes, load balancer nodes, and origin servers a non-negotiable operational requirement. Organizations that have not yet automated certificate deployment across their full infrastructure should treat the 47-day deadline as a forcing function. A multi-server deployment that manually deploys certificates today needs automation in place before 2028, regardless of which CA issues the certificates.

Frequently Asked Questions

The SSL Labs scan shows the certificate is valid but some users still see expired certificate errors. How?

SSL Labs runs its check from specific probe locations. If the expired certificate is on a CDN edge node that SSL Labs does not query, or on an origin server not queried by SSL Labs, the scan returns the valid certificate from the node it did reach. Use a multi-location tool like DNSChecker.org SSL Check, which queries from many more geographic probe points, to catch edge nodes still serving an expired certificate. If DNSChecker shows different certificate results from different probe locations, CDN propagation lag or load balancer inconsistency is confirmed.

A user in a specific country reports the error consistently. No one else can reproduce it. What do I check?

This is geographic routing to a specific CDN edge node, the most common presentation of Cause 1. Use DNSChecker.org to check SSL certificate details specifically for the user’s country or region. If that region shows an expired certificate and other regions show a valid one, trigger a manual cache purge in your CDN dashboard to force that edge node to re-request the certificate from the origin. If the CDN does not provide a per-region cache purge, a global cache purge forces all edge nodes to update simultaneously.

We deployed a new certificate to our load balancer but the error persists on some requests. We checked the load balancer.

Check the origin servers individually, not just the load balancer. TLS termination can happen at the load balancer (in which case only the load balancer certificate matters) or at the origin server level (in which case each origin server needs its own current certificate). If TLS runs end-to-end from client to origin through the load balancer, each origin server certificate is what the client ultimately validates. Use the openssl command above with each origin server’s IP to check whether all origin servers have the current certificate.