Why Is My SSL Certificate Invalid? A Practical Troubleshooting Guide

Your browser says the connection is not private, or a deployment monitor reports an invalid certificate. The tempting response is to reissue the certificate. Often that changes nothing.

An HTTPS connection has several moving parts: the server must present the right certificate for the requested name, send enough of the chain for a client to trust it, stay within the certificate’s validity dates, and negotiate a compatible TLS connection. A certificate file can look perfect on disk while the public endpoint still serves an old or completely different one.

Start with the SSL Checker. It performs a live handshake and separates expiry, hostname match, trust, the chain the server sent, and supported TLS versions. That separation matters: “invalid certificate” is a symptom, not a diagnosis.

First, check the endpoint a client actually reaches

Enter the public hostname, not the path to a certificate on your server. If the service is on a non-standard port, set that port too. When you are testing a single IP behind a virtual host or load balancer, set the intended hostname as SNI.

Record four things before changing configuration:

Do not collapse those results into one “SSL problem.” An expired certificate can have a correct chain; a valid certificate can be for the wrong name; a browser may trust an incomplete chain only because it already cached an intermediate.

Match the browser error to the right layer

Browser error names vary, but these patterns are useful:

These are starting points, not proof. For example, ERR_CERT_AUTHORITY_INVALID can be a genuinely missing intermediate, a company TLS-inspection proxy issuing from its own root, antivirus interception, or a captive Wi-Fi portal answering for every name. Test from another network before treating it as a server-wide outage.

Mixed-content warnings belong in a different bucket: they mean an otherwise secure page loaded an insecure subresource. Replacing the certificate will not fix them.

Expiry is not the same as a failed renewal

If the live certificate is expired, look at the exact notAfter date and then compare its serial number or SHA-256 fingerprint with the certificate you expected to deploy. A renewal can succeed at the certificate authority while the service continues to present the old file.

The usual reasons are mundane:

• a load balancer, CDN, ingress controller, or reverse proxy owns TLS instead of the application server;
• one node in a pool missed the reload, so failures appear only intermittently;
• the renewal job wrote a new file but did not reload the web server;
• the hostname resolves to an old IP, a staging endpoint, or both IPv4 and IPv6 while only one was updated.

Use the checker result to identify the resolved IP, then use DNS Lookup to inspect the A and AAAA records and their TTLs. Check both address families. “It works on my machine” can simply mean that your machine preferred the updated IPv4 address while another client used stale IPv6.

Revocation is different from expiry

An in-date certificate can also be revoked. NET::ERR_CERT_REVOKED means the client, using the revocation information it obtained, no longer trusts the certificate; it does not mean that notAfter is wrong. The SSL Checker shows whether OCSP stapling was presented, but it does not verify revocation. The source and caching of revocation information vary by client.

First confirm the serial number’s status with the CA. If the CA confirms revocation, immediately reissue and deploy a replacement at the actual TLS terminator, then investigate causes such as key compromise, misissuance, or a change in domain control. Only if the CA does not confirm revocation and the error is limited to one client should you investigate that client and its OCSP-stapling configuration.

A certificate covers SANs, not what its filename suggests

Modern clients verify the Subject Alternative Name (SAN) extension. The Common Name may be displayed, but it is not the field to rely on for hostname coverage.

Open the live leaf certificate in the Certificate Decoder and read every DNS SAN. Confirm the exact name a visitor requests:

• example.com and www.example.com are different names;
• *.example.com covers api.example.com, but not example.com and not v2.api.example.com;
• an IP address in the URL needs an IP SAN, not a DNS SAN;
• a certificate for an internal name is not automatically suitable for the public name.

If the SAN list is correct but the checker reports a mismatch, suspect routing. A server reached at an IP without the intended SNI name may return its default certificate. The same happens when a proxy routes by hostname but receives a different Host or SNI value than you expected.

A missing intermediate is not the same as an untrusted root

Servers normally send the leaf certificate and one or more intermediate certificates. They should not send the root. The client uses those intermediates to build a path to a root already in its trust store.

Installing only cert.pem instead of the CA’s fullchain.pem is a common deployment error. Some browsers recover by downloading an intermediate from the Authority Information Access extension or by using a cached copy. Command-line clients, mobile apps, older devices, and locked-down enterprise environments may not. That is why a site can appear fine to one person and fail for customers.

The SSL Checker shows both whether the chain is trusted and whether the server sent a complete chain. A failure in the latter is often a missing intermediate, but it can also accompany an expired or otherwise untrusted certificate elsewhere in the chain. Inspect every supplied certificate before installing anything. If the leaf is valid and an intermediate is missing, install the issuer-provided full chain at the TLS terminator. Do not append a random root certificate to the server configuration.

Check SNI before blaming the certificate

One IP address can serve many HTTPS names. During the TLS handshake, SNI tells the server which certificate the client expects. Without the right SNI, the server may legally return its default certificate — it is simply wrong for the hostname you meant to reach.

This often appears after moving behind a CDN, reverse proxy, Kubernetes ingress, or shared load balancer. It also appears in monitoring: a probe that connects to an IP without SNI is testing a different request from a browser.

To isolate it, run two checks against the same IP: one with no SNI and one with the production hostname as SNI. Different certificates show that certificate selection changes with the request or the node reached; virtual hosting is common, but load balancing can also account for the difference. A wrong certificate only with SNI points to the proxy or routing rule for that hostname.

DNS can send users to the wrong TLS endpoint

DNS does not validate certificates, but it decides which endpoint is asked for one. Review A and AAAA records after a migration, and follow CNAMEs far enough to see whether a CDN or platform is in front. A low TTL does not instantly remove older answers from every resolver; it only limits how long a resolver may keep the answer it already has.

CAA records matter during issuance and renewal, not when a browser validates an already-issued certificate. If renewal unexpectedly fails, inspect CAA. If visitors see a hostname mismatch, inspect A, AAAA, CNAME, the CDN mapping, and SNI first.

Rule out client-only causes

If the certificate is valid from an independent network but one person still sees a warning, ask a narrower question: what is different about that client?

• Check the device clock and timezone; a badly wrong clock makes a valid certificate appear expired or not yet valid.
• Try another network. Hotel Wi-Fi, captive portals, enterprise TLS inspection, and security software can present their own certificate.
• Check whether a very old operating system or embedded device has a root store that trusts the chain; an update or a vendor-supported trust-store change may be necessary.
• Check whether the user entered an IP address, an old hostname, or an internal alias rather than the public hostname.

Do not tell someone to “click through” a certificate warning on a login, payment, or admin page. First establish why the client sees a different or untrusted certificate.

A safe order of operations

1. Check the public hostname with the SSL Checker, including the real port and SNI when relevant.
2. Identify the failing dimension: date, hostname, trust, chain, or TLS protocol. Determine revocation from the browser error and the CA’s status; the SSL Checker does not decide that.
3. Decode the live chain in the Certificate Decoder to compare its SANs, issuers, dates, serial numbers, and fingerprints with the certificates you intended to serve.
4. Inspect A, AAAA, CNAME, and CAA records with DNS Lookup if routing or renewal is involved.
5. Fix the TLS terminator that actually serves the bad certificate, then reload or redeploy it.
6. Recheck from the public endpoint and, for a multi-node service, repeat until each address serves the expected certificate.

That sequence keeps a certificate incident small. Instead of replacing certificates until the warning disappears, you establish whether the problem is the certificate, the chain, the name, the route, or the client that is looking at it.

If the live check points to the chain, continue with Why Is My Certificate Chain Incomplete?. If the certificate is trusted but does not cover the requested hostname, see Why Doesn’t My SSL Certificate Match My Domain?.