Security
TLS chain troubleshooting: fix incomplete or untrusted certificate paths
TLS chain troubleshooting is about whether the server presents a certificate path a client can build to a trusted root. A server certificate can be valid for the hostname and dates yet still fail clients because an intermediate is missing, duplicated incorrectly, or chained to an unexpected trust path.
Inspect exactly what the server presents
Use an external TLS client or scanner to capture the leaf and intermediates in presentation order. Compare the issuer of each certificate with the subject/key identifier of the next certificate in the intended chain.
Servers normally should not need to send the root CA certificate.
Check hostname and date separately
A chain error is different from a SAN/hostname mismatch or an expired certificate. Record all three dimensions so fixing the intermediate does not hide another failure.
Also check SNI: a server with multiple certificates may present a default certificate when tested by IP without the hostname.
Account for client trust differences
Modern browsers may fetch or cache intermediates that a minimal API client does not, so test with the clients that matter. An apparently healthy browser result can coexist with application failures if the server is not presenting a complete chain.
Legacy clients may also lack trust for newer roots or algorithms.
Install the provider-recommended full chain
Use the certificate plus correct intermediate bundle supplied by the CA/ACME client, reload the service, and retest externally. Monitor automated renewal to ensure the chain file updates with the certificate.
- Capture presented chain.
- Separate chain/hostname/date errors.
- Test representative clients.
- Retest after service reload.