What a chain establishes
The edge presents a leaf certificate and generally sends the intermediate certificates required to build the chain. The client's trust store holds trusted roots or trust anchors, not a preinstalled copy of every site certificate. A path validation algorithm checks the signatures and relevant constraints along an acceptable path. A root need not be sent as part of the server's chain because the client already obtains its trust decision from its local policy.
The client also examines validity periods, permitted usages and other constraints relevant to the service. Name constraints, key usage, basic constraints and algorithm support can affect whether a plausible-looking chain is acceptable. Revocation and Certificate Transparency are additional policy areas whose exact enforcement differs across clients. It is misleading to describe revocation checks as universally hard-failing or to imply that Certificate Transparency alone establishes trust.
Imagine edge A sends the leaf and intermediate. Edge B sends the same leaf but omits the intermediate. Some clients can discover or cache the missing intermediate, while others fail to build an acceptable chain. The observed split might depend on operating system, trust store, browser behavior or connection history. A newer client may support a chain path that an older device cannot build because its trust anchors differ. So a certificate file that passes inspection on one engineer's laptop is not enough proof for the fleet.
SNI and the hostname you actually requested
A shared HTTPS edge hosts many names on one public IP. During the TLS handshake, a client can send Server Name Indication so the edge knows which certificate and virtual host configuration to use. An outdated client that omits SNI might be given a default certificate for some other domain. That failure can appear only for a subset of devices. It is unrelated to an expired leaf certificate, even though the user-facing warning can sound similar.
A reverse proxy can also choose the wrong certificate because of a deployment mistake or inconsistent edge configuration. I would test each public IP with the same hostname and the appropriate SNI, collect the served certificate chain, and compare the results across edges. Connecting directly to an IP without telling the test client the original hostname may reproduce a different handshake from the one real customers perform.
During a migration, old and new endpoints need valid certificate coverage for the same hostname for as long as both receive traffic. Terminating the old TLS listener before old DNS answers or connections disappear is another way to produce partial HTTPS failures. Keeping both endpoints available during migration is just as important for cryptographic identity as for application routing.
A diagnosis that preserves security
I would classify the failure by exact verification error: hostname mismatch, unknown issuer, incomplete chain, expired or not-yet-valid certificate, prohibited usage, unsupported algorithm, or a client-specific trust policy. Then I would correlate it with edge IP, client platform, SNI presence, issuance chain and deployment version. Local and remote clocks matter for validity periods, but a synchronized clock will not fix an untrusted issuer.
To validate an endpoint, I would use a TLS client that checks the requested hostname and trust path, not merely one that prints the certificate. For operational checks, openssl s_client can display peer chains with explicit server name settings, but its exit and verification behavior depend on flags and environment. Browser and mobile-client reproduction still matters. I would deploy a corrected full chain and test on representative trust stores before making certificate rotation the new incident.
The interviewer may ask whether a private enterprise root helps. It can, in an explicitly managed trust environment. It is not a fix for arbitrary public browsers, and it expands the trust and key-management responsibilities. The credible design includes certificate automation, renewal overlap, monitoring of expirations and chains, and deployment consistency across edge locations.
A browser's green lock is therefore the result of several checks tied to a name, not simply proof that a port speaks encryption. Once identity is correct, the next question becomes performance: how many network round trips does TLS need before an application can send its request, and which of those can safely be skipped?
