TLS Debugging: Why the Certificate Is "Invalid"

Certificate verification is a sequence of checks, each of which fails with its own reason: does a name in the certificate’s Subject Alternative Names match the host I asked for; is the current time within notBefore–notAfter; can I build a chain from this certificate through intermediates to a root I trust; is the chain valid at each link (signatures, key usage, name constraints); is it revoked (rarely checked strictly); and, before any of that, could we agree on a protocol version and cipher at all. The browser flattens all of this into a red page; the tools do not.

Two of the six are not about the certificate at all. A wrong system clock makes every certificate look expired or not-yet-valid — on a device whose battery died, a VM restored from a snapshot, or a container with a frozen time source — and the symptom is "every HTTPS site is broken", which is the tell. A protocol or cipher mismatch happens before certificates are exchanged: a server that only offers TLS 1.2/1.3 against a client stuck on TLS 1.0 (old Android, Java 7, .NET 4.5 defaults) fails with handshake_failure or protocol_version, and the certificate is never seen.

openssl s_client -connect host:443 -servername host opens a TCP connection, performs a TLS handshake with SNI set to host, prints the certificate chain the server sent, the verification result, and the negotiated protocol and cipher, then waits for input (type Q or Ctrl-C). Add -verify_hostname host to make it check the SAN like a browser would (older versions do not by default), -showcerts to dump every certificate in PEM, and -tls1_2 / -tls1_3 / -cipher to test a specific client capability. -CAfile points at a custom trust store — the way to test a private CA.

The two lines that matter are Verify return code at the bottom and the Certificate chain block at the top. The chain lists what the server sent, numbered from the leaf: s: is the subject, i: the issuer. If the last entry’s issuer is not a root in your store and there is no further entry, the intermediate is missing. Verify return code: 0 (ok) is the goal; any other number is one of the causes above.

A server is supposed to send the leaf certificate and every intermediate up to (but not including) the root. When an operator installs only the leaf, verification depends on whether the client can find the intermediate on its own. Chrome, Safari and Windows (via CryptoAPI) implement AIA fetching: they read the Authority Information Access URL in the leaf, download the intermediate, and verify successfully — and Chrome also carries a bundled set of known intermediates. OpenSSL-based clients (curl, Python requests, PHP, Ruby), Go, and Java (by default) do not fetch; they see a chain ending at an unknown issuer and fail. The same site is green in the browser and red in every backend integration, monitoring probe and mobile SDK.

It is also intermittent in a maddening way: a client that recently verified another site using the same intermediate may have it cached (OpenSSL does not, but browsers and the Windows store do), so "works on my machine" is literally true. The test is openssl s_client -showcerts counting the chain, or an online SSL checker reporting "chain issues: incomplete". The fix is server configuration: fullchain.pem, not cert.pem, in nginx’s ssl_certificate; both SSLCertificateFile and the chain in Apache; the full chain in the Kubernetes TLS secret. Certificates and the Chain of Trust explains the chain of trust that this is breaking.

One IP address serves many hostnames, and the server picks a certificate based on the Server Name Indication extension the client sends in the ClientHello. If the client sends no SNI (some very old clients, some health checkers, openssl s_client without -servername), the server serves its default virtual host’s certificate — often the first one alphabetically, or a self-signed placeholder — and the client sees a name mismatch. If the ingress or vhost mapping is wrong, the right SNI gets the wrong certificate. Both look identical to the browser: "this certificate is for other.example.com".

The test is to vary SNI and watch the certificate change: openssl s_client -servername a.example.com vs -servername b.example.com vs none. When testing a specific backend by IP, curl --resolve api.example.com:443:IP https://api.example.com/ keeps SNI and Host correct, whereas curl https://IP/ sends the IP as SNI (or none) and reports a mismatch that has nothing to do with the real problem. CDNs and TLS-terminating load balancers add one more certificate to keep straight: the one the client sees belongs to the edge; the origin’s certificate is verified (or not) by the edge, and a misconfigured origin shows up as a 5xx from the edge — see HTTP Debugging: 502, 503 and 504 Are Different Failures.

curl -vI https://host/ prints the TLS negotiation in * lines between the connect and the request. SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 names the protocol and cipher; subject, start date, expire date, issuer describe the leaf; subjectAltName: host "x" matched cert’s "x" is the name check; SSL certificate verify ok. is the chain check. When it fails, curl stops with curl: (60) SSL certificate problem: … and the reason from OpenSSL, or (35) for handshake-level failures such as protocol mismatch. curl -k disables verification and is useful for one thing only: proving that everything else works while you fix the certificate. Never leave it in a script.

Distinguish (60) from (35): 60 means the handshake completed enough to receive a certificate that then failed verification; 35 means the handshake itself failed, which points at protocol, cipher, SNI routing to a dead backend, or a server that speaks plain HTTP on the port.