An incomplete certificate chain means a client cannot build the required trust path from the website certificate to a trusted root. A certificate can have the correct hostname and expiry and still fail because an intermediate certificate is missing or wrong.
IN THIS ARTICLE
01 Identify and correct the chain
- Record the affected hostname, client and exact trust error. Check the certificate from an independent device or current TLS diagnostic tool.
- Identify the endpoint presenting the certificate. A website origin, CDN, load balancer and mail server can each have separate installations.
- Download the issuer's current intermediate bundle for this exact certificate. Use the order or official issuer repository, rather than an old bundle saved for a previous renewal.
- Have the authorised administrator install the chain in the platform's CA bundle or intermediate-certificate field. Keep the end-entity certificate and matching key in their correct fields.
- Reload the relevant service through its supported process if required. Verify the served chain again, including different active origin addresses.
- Test with the client that originally failed and update the certificate inventory with the corrected deployment.
02 Example: inspect the chain a website actually presents
From a workstation with a current OpenSSL trust store, inspect the certificate chain served by the affected HTTPS endpoint. Replace example.com with the real hostname. The command validates the hostname and stops on a verification error.
openssl s_client -connect example.com:443 -servername example.com \
-showcerts -verify_hostname example.com -verify_return_error </dev/nullRead the result: Review the server-presented chain and the verification result. The leaf certificate normally needs the appropriate intermediate certificates from the issuing authority. Sending the root certificate is not a substitute for a missing intermediate, and one client's cached intermediate can hide an incomplete server configuration.
Install the certificate authority's correct chain through the hosting panel or endpoint that terminates TLS. If a CDN is in front, test its edge and the origin using the appropriate trusted workflow. Keep the private key private and retest the actual browser or mail client after the chain is corrected.
Common questions
Why does one browser work while another fails?
A client may have cached an intermediate or use a different trust store. Success on one device does not prove that the server supplies a complete usable chain.
Should I ask visitors to install a root certificate?
For an ordinary public website, correct the public certificate deployment. Asking customers to change their trust store is not a routine fix for a missing intermediate.
Can I reuse the bundle from last year?
Only if the issuer confirms it is appropriate for this certificate. Issuing chains and trust transitions change; use the current supplied chain and test the result.