Troubleshooting: Certificate Errors

Three failures that look identical to a user and are not

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

▸Tell a name mismatch from an expiry from an untrusted chain, in the capture
▸Explain why the connection would have been encrypted anyway
▸Say which failures are the server's to fix and which are the client's

Before this lesson — it builds directly on:

The TLS Handshake

Certificate warnings are clicked through constantly, and the reason that is dangerous is easy to state. The connection is still encrypted. Encryption did not fail. What failed is the check that the other end is who you asked for — and an encrypted conversation with an impostor is exactly the attack TLS was built to stop. Three causes account for nearly all of them, and each is visible in the capture: the certificate is for a different name, its dates have passed, or its chain does not reach a root you trust.

✗ Common misunderstanding: The certificate is what encrypts the connection.

Why that's wrong: Encryption comes from the key agreement. The certificate's job is identity: proving the server is who the name says.

Correct model: Certificate = identity. Key agreement = confidentiality. A connection with a bad certificate is still encrypted — to a party you have not identified.

The packets prove it: In the hostname-mismatch trace the handshake proceeds normally and the client rejects it afterwards, on identity grounds alone.

Watch these fields in the lab: tcp.payload

A sealed envelope from somebody whose identity you have not confirmed

the seal working perfectly: → encryption that was never in doubt
the name on the letterhead not matching who you wrote to: → a name mismatch
a signature you cannot trace to anyone you know: → an untrusted chain

Where it breaks down: You could open the envelope anyway and judge the contents. A client cannot — it aborts before sending its request, so there is nothing to inspect and no partial outcome to reason about.

1Name. Does the certificate cover the name in the SNI? If not, the server is presenting the wrong certificate — usually a default one, a wrong binding on a load balancer, or a name added to DNS but never to the certificate. The server owner fixes this.
2Dates. Is now between notBefore and notAfter? If not, it expired — or, occasionally, the client's clock is wrong, which is worth checking on embedded devices. Usually the server owner; occasionally the client.
3Chain. Does every signature verify up to a root this client trusts? If not, an intermediate is missing from what the server sent, or the root is not in this client's store. Almost always the server owner, even though it presents as a client inconsistency.

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

A certificate error appears. What has definitely NOT failed?

Which failure works in some clients and not others, and why?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.