When HTTPS fails, the certificate may look valid in a browser or control panel while a client, API, reverse proxy, or monitoring tool still rejects it. This troubleshooting guide maps common TLS certificate errors to observable symptoms, diagnostic commands, likely causes, and safe fixes, followed by a renewal checklist and a review schedule for developers and IT administrators.
Overview
TLS encrypts traffic between a client and a service and helps the client verify that it is communicating with the intended hostname. HTTPS depends on more than the certificate’s expiry date. The hostname must match, the certificate chain must lead to a trusted root, the server must negotiate a compatible protocol and cipher suite, and the client must send the correct Server Name Indication (SNI). The client’s system clock and trust store also matter.
“SSL certificate” remains a common term, but modern web services generally use TLS. In practical troubleshooting, the terms certificate error, SSL error, and TLS error may describe the same failed connection. Begin with the exact client that is failing: a browser, command-line tool, application runtime, load balancer, container, mobile device, or monitoring service. Different clients can use different trust stores, protocol settings, and proxy paths.
Do not disable certificate verification as a permanent fix. It can conceal a misconfiguration or expose credentials and application data to interception. If a temporary test requires verification to be bypassed, limit it to an isolated diagnostic request, record the result, and restore verification immediately.
What to track
The table below is designed for incident response and recurring certificate reviews. Replace example.com with the affected hostname and run commands from a suitable administrative system.
| Problem | Typical symptoms | Useful diagnostics | Likely cause and safe remediation |
|---|---|---|---|
| Certificate expired or not yet valid | Browsers display a date-related warning; APIs report an expired certificate; monitoring alerts at the certificate end date. | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject | The deployed certificate is outside its validity period, or the client clock is wrong. Renew and deploy the certificate, then confirm every endpoint and load-balancer listener. Check the system clock and time synchronisation on the client and server. |
| Hostname mismatch | The certificate is trusted but the browser says it was issued for another name. A service works on one hostname but fails on an alias or IP address. | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -ext subjectAltName | The requested hostname is absent from the certificate’s Subject Alternative Name (SAN) list, or the client is using an IP address not covered by the certificate. Request a certificate containing the exact DNS names used by clients and configure DNS and redirects consistently. |
| Incomplete certificate chain | One browser works while an older client, command-line tool, application, or monitoring agent reports “unable to get local issuer certificate” or “unknown issuer”. | openssl s_client -connect example.com:443 -servername example.com -showcerts | The server is sending only the leaf certificate or the wrong intermediate certificate. Configure the server with the leaf certificate plus the required intermediate chain, normally in the provider’s recommended order. Do not send a private root certificate to public clients unless your internal PKI requires it. |
| Untrusted issuer or outdated trust store | A certificate validates on a current workstation but fails in an old operating system, minimal container, embedded device, or private application runtime. | openssl verify -CAfile /path/to/ca-bundle.pem /path/to/certificate.pem | The client lacks a suitable trusted root, uses a custom CA bundle, or has an outdated trust store. Update the operating system or runtime trust store through normal change control. For private services, distribute the internal CA through an approved management process; never replace a trust store blindly. |
| Weak or incompatible TLS protocol | The client reports a protocol version or handshake failure. A legacy integration fails after a server hardening change. | curl -Iv https://example.com/ and, where authorised, test explicit versions such as openssl s_client -connect example.com:443 -servername example.com -tls1_2 or -tls1_3. | The endpoints have no mutually supported protocol or cipher configuration. Prefer currently supported TLS versions, normally TLS 1.2 and TLS 1.3 where compatible, and remove obsolete protocols through a planned change. Avoid weakening the server solely to accommodate an unmaintained client; update or isolate that client instead. |
| Missing or incorrect SNI | The IP address responds, but the intended hostname receives a default certificate or the wrong virtual host. One site on a shared listener works while another fails. | Compare openssl s_client -connect IP_ADDRESS:443 -servername example.com with a request that omits -servername. Also use curl -Iv --resolve example.com:443:IP_ADDRESS https://example.com/. | The client does not send SNI, the proxy routes it incorrectly, or the virtual-host configuration is incomplete. Test with the real hostname, configure the correct TLS listener and certificate, and investigate legacy clients that cannot send SNI. |
| System clock error | Several unrelated HTTPS services fail at once, with “not yet valid” or “expired” messages despite valid certificates elsewhere. | Check the host’s date, timezone, and time-synchronisation status. Compare results from another known-good system. | A client, server, VM, container, or network appliance has an incorrect clock. Correct time synchronisation and verify that the change persists after reboot or redeployment. |
For a first-pass comparison, curl -Iv https://example.com/ shows the connection path and HTTP response headers, while OpenSSL exposes the negotiated handshake and presented certificates. If a browser succeeds but an application fails, inspect the application’s runtime trust store, proxy settings, hostname, and TLS library rather than assuming the server is healthy for every client.
Cadence and checkpoints
Certificate management is an operational process, not a one-time deployment task. Set a monthly or quarterly review cadence based on certificate lifetimes, the number of endpoints, and the consequences of an outage. Automated expiry monitoring should provide earlier warning than the certificate’s final days, with alerts routed to an owner who can renew and deploy it.
Before renewal
- Inventory every public and private HTTPS endpoint, including alternate names, staging systems, APIs, mail-related services, load balancers, CDNs, ingress controllers, and management interfaces.
- Record the certificate authority, SANs, issuer chain, renewal method, deployment location, responsible owner, and rollback procedure.
- Confirm that DNS records, redirects, health checks, firewall rules, and proxy routes still point to the intended service.
- Check whether the private key is stored securely and whether access is limited to the systems that need it.
During renewal and deployment
- Use an approved ACME client or certificate-management workflow. Validate domain control through the intended challenge method and review the requested names before issuance.
- Install the complete server chain where the platform requires it. Keep the private key separate from logs, source repositories, tickets, and publicly accessible directories.
- Deploy to every relevant node, region, listener, container image, or edge service. A successful update on one server does not prove that a pool is consistent.
- Use a controlled reload or restart and retain the previous certificate and configuration only for the documented rollback window.
After deployment
- Test the production hostname with a browser and command-line client, including the correct SNI name.
- Check the served expiry date, SAN list, issuer, chain, and negotiated TLS version from outside the hosting environment.
- Exercise a representative API call or application login without disabling verification.
- Review monitoring, logs, and certificate inventories for nodes that were missed.
How to interpret changes
A certificate error that begins immediately after renewal often points to deployment, chain assembly, SAN selection, or virtual-host routing. An error that affects only one application usually points to its runtime trust store, proxy, hostname construction, or protocol support. An error affecting many clients at the same time is more likely to involve the server configuration, load balancer, DNS route, or certificate authority chain.
Compare more than the certificate’s subject and expiry date. Capture the requested hostname, destination IP, certificate chain, SANs, issuer, negotiated protocol, and client environment. This creates a useful before-and-after record for migrations and incident reviews. If several servers sit behind one address, test each node directly where it is safe and authorised to do so; inconsistent certificates commonly explain intermittent failures.
Be cautious with tests performed by IP address. HTTPS validation is normally hostname-based, and an IP request can select a different virtual host or fail hostname verification by design. Likewise, a successful browser test may rely on cached intermediates or a different trust store from the failing service.
When to revisit
Revisit this guide at least quarterly and whenever a certificate is renewed, a domain or hosting provider changes, a reverse proxy or web server is upgraded, or a new client runtime is introduced. Update internal runbooks after significant browser, operating-system, certificate-authority, ACME-client, or TLS-library changes. Trust-store behaviour and default protocol settings can change independently of your application code.
Use this practical review sequence:
- Start with the exact failing hostname and client, then record the full error message.
- Run
curl -Ivand an SNI-awareopenssl s_clientcheck from an appropriate network location. - Verify dates, SANs, chain completeness, issuer trust, system time, protocol compatibility, and virtual-host routing in that order.
- Fix the underlying configuration rather than bypassing verification.
- Test every production node and representative client, close the monitoring alert only after verification succeeds, and document the change.
A small certificate inventory, recurring expiry check, and repeatable command-line test can prevent a renewal from becoming an outage. Keep the inventory and commands with the service runbook so the next developer or administrator can reproduce the diagnosis without relying on a browser warning alone.
