TLS handshakes and certificate chains: trust, names and failures
Separate TLS trust validation, hostname checks and key agreement. Diagnose incomplete certificate chains and test the identity a client actually expects.
TL;DR: TLS must authenticate the intended peer and establish protected traffic keys before HTTP can succeed. A certificate can have a valid chain and still identify the wrong service; verify trust and the requested name separately.
Follow the connection through the TLS boundary
A client first chooses a destination, often through DNS resolution, and establishes the underlying transport. For a typical TLS 1.3 connection over TCP, ClientHello and ServerHello negotiate parameters and key agreement. The server then proves its identity with the certificate exchange and handshake authentication. Finished messages bind the handshake to the derived keys. RFC 8446 specifies that protocol.
Do not explain modern TLS as “the browser encrypts a session key with the server's RSA certificate.” Certificate authentication and ephemeral key agreement perform different jobs. Also distinguish server authentication from mutual TLS, where the server requests and validates a client certificate.
This is a simplified full handshake without client authentication or early data. A resumed connection differs, and protocol selection at a reverse proxy can differ from the protocol used to its backend.
A chain and a name answer different questions
The leaf certificate names the service. Intermediate certificates connect its issuer to a trust anchor the client accepts. A server normally supplies the leaf and required intermediates; the client maintains its own trusted roots. Sending an arbitrary root with the chain does not make that root trusted.
Service identity checking compares the client's expected name with supported subject alternative names. Modern guidance in RFC 9525 rejects reliance on the certificate's Common Name for this purpose. A certificate for api.example.com does not authenticate billing.example.com just because both names resolve to the same address.
| Check | Question answered | Example failure |
|---|---|---|
| Chain validation | Does this credential lead to an accepted trust anchor? | Missing intermediate or unknown CA |
| Validity period | Is this certificate usable at the client's current time? | Expired leaf or incorrect clock |
| Service identity | Does it identify the requested DNS name or IP address? | Wrong SAN for the requested host |
| Handshake proof | Does the peer prove possession of the relevant key? | Wrong key paired with certificate |
| Protocol negotiation | Can the peers agree on supported parameters? | Incompatible protocol configuration |
A browser and a minimal container may have different root stores or intermediate-certificate caches. Success from one client does not prove that a newly started workload can validate the same endpoint.
Diagnose an incomplete chain without disabling verification
Consider an illustrative incident after rotating the certificate on an ingress controller. Existing browser sessions appear healthy, while fresh connections from a batch worker fail. The new secret contains the leaf certificate only. A browser may have cached an intermediate, while the worker has only its normal root bundle.
Capture the certificate chain actually served at the affected address using the intended server name. Compare it with the deployed secret and the CA's issued chain. Then test from the worker's runtime image, including its trust store. Repairing the server's chain serves all eligible clients; adding the leaf as a new trust anchor on every worker would hide the configuration error and create rotation debt.
With local certificate files from a controlled test, OpenSSL can separate chain and hostname checks:
openssl verify -CAfile root.pem -untrusted intermediate.pem \
-verify_hostname api.example.com leaf.pem
The command assumes PEM files containing the named certificates. It does not contact the service, test the deployed private key or reproduce the application's complete TLS policy. A successful file check therefore needs a separate connection check against the actual endpoint.
SNI, HTTP host and proxies can disagree
Server Name Indication helps a TLS endpoint select a certificate before it receives an HTTP request. The HTTP authority or Host header arrives later. Changing the header alone cannot fix a certificate selected for the wrong TLS name.
Suppose an engineer connects directly to a load balancer IP while expecting a DNS-name certificate. The investigation must distinguish address selection from the service identity being verified. Preserve the intended DNS identity while directing the test to a particular address using a client that supports that separation. Do not turn verification off and describe the result as a successful TLS test.
For a proxy chain, draw each independently secured hop. The external certificate can be correct while the proxy rejects the backend certificate, producing an HTTP error at the edge. Check the proxy's upstream error record and its trust configuration before rotating the public certificate again.
Check the claim an interview answer makes
Certificate issuance and renewal connects domain validation to the certificate clients actually receive after a reload.
Self-check: the certificate is unexpired, its issuer is trusted and the TCP connection succeeds. Is the service authenticated?
Not yet. Verify the expected name, the actual handshake and applicable certificate constraints. For the incident above, also confirm that the server supplied the needed intermediates to a clean client. Then proceed to HTTP connection behavior; an HTTP timeout and a TLS validation failure need different evidence.