TLS Troubleshooting Interview Questions: Certificate Chains, SNI, and Expiration

A certificate renewal finishes successfully, yet a service still fails for some clients. One engineer checks the certificate file on disk and says the rollout is complete. Another runs a TLS command, sees a certificate, and declares the connection trusted. Neither check proves what the failing client actually received and accepted.

Strong TLS troubleshooting interview answers separate destination selection, service identity, certificate-path validation, and time. They also identify where TLS terminates. A browser talking to a gateway and that gateway talking to a backend are two different security relationships.

Evidence boundary: Protocol and certificate facts below come from IETF standards; command semantics come from OpenSSL 3.5 documentation. The rollout matrix and incidents are original practice exercises, not candidate reports or promises about an employer's interview. Start with Explain TLS Handshakes and HTTPS Traffic Inspection and explain what each observed handshake step establishes.

Which connection and which TLS endpoint are failing?

Official protocol fact: TLS 1.3 negotiates security parameters and authenticates the handshake using its defined messages. In its normal certificate-based server authentication, receiving a certificate is only part of that process. Much of the handshake after ServerHello is encrypted, so a passive capture does not necessarily reveal the certificate exchange. RFC 8446

Original diagnostic method: Draw the actual hops before examining certificates. A common path is client to edge gateway, followed by gateway to application server. The second hop may use TLS, mutual TLS, or a different configured transport. Verify the architecture rather than assuming end-to-end TLS from the public URL alone.

For each failing attempt, record destination address and port, intended hostname, client implementation, trust configuration, timestamp, and error text. Include proxy settings and the workload environment when they change the route.

If the public handshake succeeds but the gateway returns an upstream error, investigate the backend relationship. Replacing the public certificate may have no effect on a backend certificate that the gateway rejects.

Likewise, a TCP connection succeeding narrows the investigation but does not prove that TLS completed. State the last observed boundary rather than grouping every failure under “the port is open.”

Is the displayed certificate list a trusted chain?

Official certificate foundation: X.509 validation evaluates a certification path against a trust anchor and applicable constraints. Certificate validity intervals and extension constraints participate in that process; matching an issuer name alone is not sufficient validation. RFC 5280

Interview reasoning: Distinguish three objects: what the server sent, the path the client constructed, and the trust anchors the client already trusts. These can differ across clients.

An illustrative deployment sends a leaf certificate plus an intermediate. The client uses its configured trust store to validate an acceptable path. Merely adding a root certificate to the server's response does not make that root trusted by the client.

Suppose a developer's browser succeeds while a minimal container fails. Missing intermediate delivery, different trust stores, or differing validation behavior are hypotheses worth testing. The browser's success does not prove every client received everything it needed, and the container's failure does not automatically mean the leaf expired.

Compare the served list and the client's actual trust configuration. Do not “fix” the application by trusting whichever certificate it just received. That removes the independent basis of authentication.

How are SNI and hostname verification different?

Official SNI fact: The server-name extension lets a client indicate the hostname it is contacting, allowing a server sharing an address to select an appropriate configuration. Sending that name is not itself proof that the selected certificate authenticates it. RFC 6066

Official identity fact: RFC 9525 specifies service-identity matching using appropriate subject alternative names. Its current rules do not use the subject Common Name as the service identifier. Existing libraries may retain older behavior, which is another reason to record the actual client version. RFC 9525

Original example: You want to test api.example.com on a particular gateway address. Connecting to the address while omitting the intended server name may select a default virtual host. A mismatch from that test might describe your changed experiment rather than the production request.

Preserve the intended name for server selection and independently check that the returned certificate authenticates it. Those are separate operations even when they use the same string.

An HTTP Host header is another value at another layer. Sending it after TLS does not retroactively select the certificate already presented during the handshake. Explain this ordering when an interviewer asks why changing an HTTP request header did not fix the TLS failure.

What is a useful OpenSSL diagnostic command?

Official tool behavior: OpenSSL documents -showcerts as the list sent by the server, not a verified chain. Its test client can continue after certificate-verification errors unless -verify_return_error is used. -servername and -verify_hostname serve different purposes. OpenSSL s_client documentation

Original command exercise: This is illustrative syntax for an authorized endpoint, using a documentation address. Substitute the target address and the intended service name; the command has not been run against your infrastructure.

openssl s_client \
  -connect 192.0.2.10:443 \
  -servername api.example.com \
  -verify_hostname api.example.com \
  -verify_return_error \
  -showcerts

The address selects where to connect. The server name preserves virtual-host selection. Hostname verification checks the intended identity, and returning verification errors prevents a continued diagnostic handshake from being mistaken for validation success.

Interpret the full output and exit behavior, including connection failures and certificate errors. Do not reduce it to “a certificate printed” or a single line copied without its context. This command is not a complete application request, and its result does not establish HTTP routing or authorization.

For a private CA, configure the intended trust material explicitly and document it. OpenSSL's verification options describe trust stores and validation controls; the effective policy must match the client you are investigating. OpenSSL verification options

If you add a custom CA solely for the test, say so. A passing result under that test configuration does not prove the production client uses the same trust store.

Why does renewal succeed while some requests still fail?

Original rollout exercise: A service has three TLS termination instances. A deployment updates the certificate files, but one instance continues presenting the previous certificate. Another presents the new leaf without the intended intermediate. The certificate-management job reports success because issuance completed.

Do not treat issuance, distribution, activation, and client validation as one event. Build a matrix from actual served results:

Use certificate fingerprints or serials to distinguish observations, together with issuer, names, and validity dates. A filename such as current.pem is not a reliable description of what a running process serves.

When testing individual instances, preserve the intended SNI and identity checks. Otherwise, targeting an address directly can introduce a virtual-host difference and contaminate the rollout comparison.

A fresh connection is important. Existing sessions and resumed handshakes may not exercise the exact same path as a new full handshake. State which kind of test your evidence covers.

Is expiration the leaf certificate's only time problem?

Interview reasoning based on certificate validation: Check the validity information and relevant path elements, not just the leaf's end date. Also establish the failing client's clock. A clock error can make otherwise expected material appear outside its validity interval.

In an original practice case, a replacement certificate has a future start time relative to a misconfigured client. The renewal dashboard looks healthy, but that client's evaluation fails. Your next action is to compare trusted time and the reported validation error, not to issue another certificate blindly.

For another variation, the leaf remains current but path validation fails involving intermediate material. Identify the actual error and path before asserting a cause. A generic TLS alert is weaker evidence than the local validator's detailed result.

Avoid promising one universal revocation check across browsers, language runtimes, and private clients. Validation policy differs. If the interview includes revoked certificates, explain which mechanism and client policy are in scope and what evidence demonstrates that the intended check occurred.

A sensible operational test uses the client types that matter to the service and makes those assumptions explicit. “Works on my browser” is a starting observation, not coverage of every deployed runtime.

What changes when the service uses mutual TLS?

Original diagnostic extension: Add a second authentication direction to the diagram. The client validates the server; the server also evaluates the client credential under its own trust and authorization configuration. Success in one direction does not establish success in the other.

If a server rejects a client after a renewal, compare which client certificate was actually selected, what chain accompanied it, and which trust configuration the server used. Keep private keys out of diagnostic reports; identifiers and public certificate metadata are usually sufficient to correlate the attempt.

Then separate authentication from authorization. A valid client certificate may identify a workload that still lacks permission for a particular operation. An application-level denial after a successful handshake should not automatically trigger certificate replacement.

For gateway-to-backend mutual TLS, investigate the gateway's client identity. The browser's identity or public server certificate is not interchangeable with that credential.

How should you close a TLS troubleshooting answer?

Original model answer: “I would reproduce with the failing client configuration and intended hostname, identify the TLS termination point, and record the served certificate list and validation error. Then I would compare identity, trust path, and time separately. After repair, I would verify fresh connections across affected instances and a real application request.”

Add a discriminating test: if the same endpoint passes with one trust store and fails with another, investigate that difference before changing routing. If different endpoint instances present different fingerprints, investigate rollout consistency before changing every client's policy.

Define a safe recovery condition. A rollback must use material that is still acceptable under the required validation policy; reverting to an expired certificate is not a recovery plan. Keep verification enabled so the test measures the intended security boundary.

Practice TLS reasoning with these PracHub questions

These verified destinations include direct TLS and PKI practice plus adjacent architecture exercises. They are not evidence that each question originally included the renewal scenario above.

Continue with Design a PKI for internal mTLS and certificates. Explain how you would prove a renewal is active on the served endpoint and accepted by the intended client.

Sources and Further Reading

• IETF RFC 8446: TLS 1.3
• IETF RFC 6066: TLS Extensions, Including Server Name
• IETF RFC 9525: Service Identity in TLS
• IETF RFC 5280: X.509 Certificates and Path Validation
• OpenSSL 3.5: s_client
• OpenSSL 3.5: Verification Options