How Does TLS Certificate Validation Work, and How Do You Debug Failures?

Question and Applicable Context

After api.example.com rotates its TLS certificate, browsers and a normal curl https://api.example.com request succeed. A Java 21 worker using a custom truststore fails with SunCertPathBuilderException: unable to find valid certification path. Meanwhile, curl https://203.0.113.10 reaches the same load balancer but fails identity verification.

Explain how a TLS client builds and validates a certificate path, how it matches the intended service identity, why these clients can reach different results, and how you would diagnose and repair the incident without disabling certificate or hostname verification.

Use these explicit assumptions: api.example.com and 203.0.113.10 are fictional; the endpoint uses an ordinary publicly trusted server certificate; the Java worker's custom truststore is independent of the browser's trust configuration; and the load balancer can host multiple TLS names on one IP address. The task is certificate authentication and operational diagnosis. Cipher-suite negotiation, the TLS 1.3 key schedule, and 0-RTT are outside the main scope.

This question fits general software engineering, networking, SRE, platform, security, backend, and client interviews. A useful answer must connect PKI rules to observable client behavior instead of reciting “leaf, intermediate, root.”

What the Interviewer Evaluates

First, can the candidate separate four decisions that are often collapsed into one?

1. Path construction: find one candidate sequence from the leaf through zero or

more intermediates to a locally configured trust anchor.

1. Path validation: verify that the candidate path satisfies signatures, time,

CA constraints, key usage, name constraints, critical extensions, algorithm and policy requirements, and the intended TLS server purpose.

1. Service-identity matching: match the configured reference hostname or IP

address against the corresponding subjectAltName identifier.

1. Handshake proof: verify CertificateVerify so the peer proves possession of

the leaf certificate's private key and binds it to this handshake.

Second, can the candidate explain client disagreement without inventing a universal cause? Browsers, operating-system tools, containers, JVMs, mobile apps, and corporate proxies can use different trust anchors, cached or discoverable intermediates, clocks, algorithms, revocation policies, and reference identities.

Third, can the candidate run a controlled investigation? A strong answer captures the exact certificate chain delivered with the correct SNI, reproduces validation with the failing client's trust material, preserves the hostname while pinning an IP, compares successful and failing paths, and checks every load-balancer instance.

Finally, can the candidate repair trust safely? Importing an arbitrary leaf, accepting all certificates, skipping hostname checks, or using curl -k only hides the failed security control. The repair must restore the intended chain or trust policy and include a rollback and expiry plan for any temporary trust change.

Questions to Clarify Before Answering

• What exact URL and reference identity does each client use? Connecting to an IP

literal asks for an IP identity. Connecting to the same IP while retaining the URL https://api.example.com asks for the DNS identity api.example.com.

• What trust store is active at runtime? Confirm the actual JVM options, container

image, user, process environment, and mounted truststore rather than inspecting a developer laptop's default store.

• What chain did the failing request receive? SNI, load-balancer listener, region,

proxy, IPv4 versus IPv6, and deployment skew can change the certificate presented.

• Did every client fail at the same time? Check local time, certificate validity,

CA-bundle version, algorithm policy, and whether only one backend or edge instance serves the new chain.

• Is TLS intercepted? A corporate proxy can replace the public leaf with a

certificate issued by an enterprise root that a browser trusts but the custom JVM truststore does not.

• What does the error identify? A path-building error, expired certificate,

hostname mismatch, unsupported algorithm, revocation failure, and TLS negotiation failure are different branches. Preserve the full exception and validation trace.

30-Second Answer Framework

“I split the check into path construction, path validation, service-identity matching, and private-key proof. The server normally sends its leaf and required intermediates; the client constructs a path to a trust anchor already trusted locally. It then validates signatures, time, CA and key constraints, critical extensions, algorithms, and server purpose. Separately, it matches the configured DNS name or IP address to the same type of SAN entry. SNI helps the server select a certificate, but it does not establish trust or prove the hostname.

Browser success does not prove the Java path is valid because the custom JVM truststore, intermediate discovery, proxy roots, clock, and policies can differ. I would capture the chain with the correct SNI, replay it against the worker's exact truststore, compare the built paths, and use curl --resolve to hold the DNS identity constant while targeting the IP. I would fix the served intermediate or the deliberately managed trust anchor, never disable verification, and retest every edge plus the real worker.”

Step-by-Step Deep Dive

1. Establish the three independent inputs. The verifier needs a target leaf certificate, a set of untrusted intermediate certificates that may help construct a path, and one or more local trust anchors. “Untrusted” here does not mean malicious; it means that an intermediate is path-building material and does not become a trust anchor merely because the server sent it.

An HTTPS server normally sends the leaf certificate followed by the intermediates the client needs. It generally does not need to send the root. The verifier's trust decision ends at a root or other anchor configured by local policy. Sending a root cannot make an unknown root trusted.

2. Build candidate paths before validating one. The leaf names an issuer; an intermediate can name another issuer; cross-signed CAs can create more than one possible route. A client can source intermediates from the handshake, a cache, or an implementation- specific discovery mechanism. RFC 5280 defines path validation but deliberately leaves the procedure for obtaining the candidate sequence outside its scope. Therefore two standards-compliant clients can have different construction inputs and select different paths.

A SunCertPathBuilderException means the Java path builder did not find a path it could accept with its available certificates and policy. Plausible causes include a missing intermediate, an absent trust anchor in the custom store, an unusable alternative path, or a policy constraint. The exception alone does not prove which one occurred.

3. Validate the selected path. For each relevant link, the client verifies the certificate signature with the issuer's public key and processes constraints. Important checks include:

• the current time falls within the certificate's validity interval;
• every issuing certificate is permitted to act as a CA under basicConstraints, and

any path-length limit is respected;

• CA key usage permits certificate signing, while the leaf is suitable for the intended

TLS server purpose under applicable key-usage and extended-key-usage policy;

• name constraints, certificate policies, and recognized critical extensions are

processed correctly;

• algorithms and key strengths satisfy the client's current security policy; and
• the path terminates at a trust anchor selected by local policy.

Revocation is another policy dimension. Clients differ in how they obtain and handle CRLs, OCSP responses, stapled status, network errors, and soft-fail versus hard-fail conditions. Do not assume that “RFC 5280 path validation passed” proves every client performed the same online revocation checks.

4. Match the service identity separately. The reference identity comes from a trusted input such as the configured HTTPS URL, not from reverse DNS, the certificate itself, or whatever name an attacker supplies. Under RFC 9525, modern service identity is represented in subjectAltName; clients must not fall back to the subject Common Name for this purpose.

DNS names and IP addresses use different SAN types. https://api.example.com requires a matching DNS-ID. https://203.0.113.10 requires the exact IP address in an iPAddress SAN; a DNS SAN containing api.example.com does not satisfy it. If supported, a wildcard must be the entire left-most label and matches exactly one label: *.example.com can match api.example.com, but not v2.api.example.com or example.com.

SNI and verification have different jobs. SNI tells a multi-tenant server which certificate to present. The reference identity tells the client which name that certificate must cover. A request can send correct SNI and still fail hostname checking, or omit SNI, receive a default certificate, and then fail for a different reason.

5. Verify possession of the leaf private key. A valid path and matching SAN bind an identity to a public key. During a certificate-authenticated TLS 1.3 handshake, CertificateVerify signs the handshake transcript with the corresponding private key. Verifying it proves that the peer controls that private key in this negotiation. This is distinct from constructing the path and matching the hostname.

6. Explain why the three observations are compatible. The observations do not contradict one another:

7. Reproduce the endpoint and the path independently. Start with the exact DNS name and SNI. The following flags target OpenSSL 3.6; check openssl version first because the macOS system LibreSSL and older packages expose different options. -showcerts displays what the server sent; -verifyreturnerror stops on verification errors; -verify_hostname checks the intended DNS identity.

openssl s_client \
  -connect api.example.com:443 \
  -servername api.example.com \
  -showcerts \
  -verify_return_error \
  -verify_hostname api.example.com \
  </dev/null

Save the leaf and intermediate certificates as separate PEM files, obtain the exact trusted roots from the failing environment through an approved export, and replay path validation explicitly:

openssl verify \
  -CAfile worker-roots.pem \
  -untrusted served-intermediates.pem \
  -purpose sslserver \
  -verify_hostname api.example.com \
  leaf.pem

This experiment distinguishes trust anchors from intermediates. It does not perfectly emulate every JVM algorithm, revocation, or provider rule, so the decisive reproduction still runs inside the same Java image with trust-manager debug output and the same truststore. Redact internal names and certificate material before sharing logs.

To target a specific load-balancer address without changing the HTTPS reference name, preserve the URL and override resolution:

curl --resolve api.example.com:443:203.0.113.10 \
  https://api.example.com/health

Repeat for every advertised IPv4 and IPv6 address, region, and edge instance. Directly requesting https://203.0.113.10 is a different identity test and should not be used as proof that the certificate for api.example.com is wrong.

8. Repair the failed layer and prove the rollback path. If the server omits a needed intermediate, deploy the correct leaf-plus-intermediate bundle on every TLS terminator and confirm the served chain. If the organization intentionally uses a private or proxy CA, distribute its approved root through the managed truststore process with ownership, scope, fingerprint, expiry, and rollback recorded. If the wrong SAN was issued, replace the certificate. If clocks, stale instances, or algorithm policies differ, fix those conditions directly.

Do not import the endpoint leaf as a permanent root, copy an unexplained certificate from a browser cache, turn off endpoint identification, install a permissive trust manager, or ship curl -k. After repair, verify the real worker, browser, curl, every edge address, the previous certificate's removal, monitoring before expiry, and the failure behavior for a deliberately wrong hostname and an untrusted test chain.

High-Quality Sample Answer

“I would not infer that Java is wrong because the browser works. Each verifier makes a decision from its own target certificate, intermediate set, trust anchors, reference identity, time, and policy.

I separate four checks. First, path construction finds a sequence from the leaf through intermediates to a locally trusted anchor. Certificates sent by the server are only construction inputs; they do not create trust. Second, path validation verifies signatures, validity, CA and key constraints, critical extensions, algorithms, policies, and server-auth purpose. Third, endpoint identification compares the configured name with SAN. A DNS URL needs a DNS-ID, while an IP-literal URL needs an IP-ID. SNI only selects the virtual host's certificate. Fourth, TLS verifies CertificateVerify to prove the peer holds the leaf private key for this handshake.

The browser may have a different root store, cached or discovered intermediate, or an enterprise proxy root. The Java 21 worker's custom truststore may lack the needed anchor or construction input, and its exception says only that no acceptable path was built. The IP curl failure is expected if the certificate covers the DNS name but has no IP SAN.

I would first capture the exact chain with openssl s_client, correct SNI, -verifyreturnerror, and -verify_hostname. I would inventory SANs, issuers, validity, basic constraints, key usage, EKU, algorithms, and fingerprints. I would then validate the saved leaf and served intermediates against an approved export of the worker's roots, and reproduce inside the Java container with its actual runtime flags. curl --resolve lets me test each load-balancer IP while keeping api.example.com as both the URL identity and SNI.

If an intermediate is missing, I fix the chain bundle on all TLS terminators. If an approved private or proxy root is absent, I distribute that root through the managed truststore workflow instead of trusting a leaf. If the SAN, clock, or policy is wrong, I repair that exact layer. I never use trust-all, disable hostname verification, or accept -k as a fix. I close the incident only when the real worker succeeds across every edge and negative tests still reject the wrong hostname and an untrusted chain.”

Common Mistakes

• Treating chain building and validation as one operation → clients can discover

different candidate paths before validation → **name the target, intermediate set, trust anchors, and policy separately.**

• Trusting a root because the server sent it → trust anchors come from local policy

→ treat server-provided certificates as untrusted construction inputs.

• Checking signatures but omitting CA constraints → a valid signature alone does

not authorize an issuer to sign certificates → **check basic constraints, path length, key usage, critical extensions, and purpose.**

• Using the certificate's name as the expected identity → that lets presented data

choose what it must prove → derive the reference identity from the configured URL.

• Assuming SNI performs hostname verification → SNI selects a virtual host →

perform SAN matching as a separate client check.

• Expecting a DNS SAN to validate an IP URL → DNS-ID and IP-ID are different types

→ use --resolve when the goal is to pin routing while preserving DNS identity.

• Blaming a missing intermediate from one exception → truststore, policy, time,

proxy, and deployment skew can produce similar symptoms → **capture the actual chain and reproduce with exact runtime inputs.**

• Repairing with -k or trust-all → this converts an authenticated channel into an

unauthenticated one → fix the chain, identity, managed root, clock, or policy.

Follow-Up Questions and Responses

Follow-up 1: Should the server send the root certificate?

Usually no. The server should send the leaf and the intermediates needed to reach a root the client already trusts. A root sent by the server is redundant for a client that trusts it and powerless for a client that does not. It also wastes handshake bytes.

Follow-up 2: Why can a browser recover from a missing intermediate while another client fails?

Implementations can have different intermediate caches or discovery behavior. One browser may already possess the intermediate or obtain it through an implementation- specific mechanism, while an isolated worker has only the handshake and its custom store. This is why servers should deliver the required intermediates instead of relying on client recovery. Confirm the actual path rather than assuming every browser behaves the same way.

Follow-up 3: Does a matching hostname make a self-signed certificate safe?

No. Identity matching and path trust are independent. A certificate can contain the right DNS SAN yet have no path to a locally trusted anchor. A private deployment can trust a self-signed root through controlled provisioning, but merely matching the name does not establish that trust.

Follow-up 4: How should revocation be discussed in an interview answer?

State the policy boundary. CRLs, OCSP, stapling, cached status, network access, and soft-fail or hard-fail rules differ across clients. Determine what the actual verifier checks and how it behaves when status is unavailable. Do not claim that all clients perform identical online checks, and do not silently weaken a required hard-fail policy to make an outage disappear.

Follow-up 5: What evidence closes this incident?

Record the served leaf and intermediate fingerprints per edge, the path built under the worker's exact roots, successful DNS-name and private-key proof, and successful real worker requests. Add negative tests for a wrong DNS name, an IP literal without IP-ID, and an untrusted chain. Confirm that no bypass remains, all load-balancer instances serve the intended bundle, monitoring covers expiry and rotation, and any temporary root or diagnostic artifact has an owner and removal date.