Why a Valid Certificate Can Still Fail

Teams sometimes renew a certificate and still see browser errors. The new cert exists in the provider dashboard. Customers still get privacy warnings. That gap usually means the served configuration does not match what you renewed.

Common causes beyond expiration

• Hostname mismatch: cert covers www.example.com but users hit example.com
• Incomplete chain: missing intermediate cert on the load balancer
• Wrong cert deployed to one edge node in a pool
• SNI or port mismatch on shared infrastructure
• Cloudflare or CDN still serving older edge cert

Why external checks matter

Internal openssl commands against localhost do not prove what a customer sees. External SSL monitors handshake the same hostname and port browsers use. They catch partial deploys and DNS splits that internal tooling misses.

Run the same check from at least two perspectives if your product serves global customers. Regional DNS or CDN misconfiguration often shows up in one geography first.

What to monitor together

• Certificate expiration on the public hostname
• HTTPS availability with full chain validation
• DNS resolution for apex and www
• Redirect behavior between http and https

Treat renewal as a deploy with verification, not a checkbox in a CA email. After every change, confirm the served cert serial matches the one you expect from outside your network.

Keep a screenshot or openssl output from the public hostname in the change ticket. Future you will thank present you when a load balancer still serves last month's cert after a successful renewal dashboard message.

When to page immediately

Expiration warnings can wait for business hours. Active TLS handshake failures on the customer hostname should not. Treat handshake errors as availability incidents with the same urgency as a 503 on login.

Record which hostname and port failed in the alert title so responders do not debug the wrong certificate during a stressful rollout.