An incomplete SSL certificate chain usually means that a server sends its website certificate but fails to send the intermediate CA certificate that issued it. Some desktop browsers may still load the website because they have already cached the missing intermediate certificate. New devices, mobile apps, API clients, Java applications, and strict monitoring tools may instead report errors such as “certificate not trusted,” “unable to get local issuer certificate,” or “certificate verify failed.”
The solution is not to regenerate the private key or combine every available certificate into one file. You must identify the correct trust path and configure the server to send the website certificate first, followed by the required intermediate certificates. The root certificate normally should not be sent because it should already exist in the client’s trusted root store.
The configurations in this article were reviewed on August 3, 2026. Replace all example domains and file paths with your own values and validate the changes in a test environment before production deployment.
What Is an SSL Certificate Chain?
A typical TLS trust chain contains three levels:
Website or leaf certificate: the certificate issued to a specific hostname such as
www.example.com.Intermediate CA certificate: a certificate issued by a root CA or another intermediate CA and used to sign the website certificate.
Root CA certificate: the trust anchor stored in an operating system, browser, Java runtime, or application trust store.
A TLS server normally sends the website certificate and all required intermediate certificates. The client uses those intermediates to connect the website certificate to a root certificate it already trusts.
Typical correct order: website certificate → intermediate CA that issued the website certificate → higher-level intermediate CA, if required. The root certificate normally should not be included.
Common Symptoms of an Incomplete Certificate Chain
The website works in one browser but fails on some phones, older systems, or applications.
curlreportsSSL certificate problem: unable to get local issuer certificate.OpenSSL displays
Verify return code: 20or21.Java, Python, Node.js, or another API client reports a certificate verification failure.
A CDN cannot establish HTTPS with the origin and returns a 502, 525, 526, or a platform-specific origin TLS error.
An SSL testing tool reports “Chain issues,” “Incomplete chain,” or “Extra download.”
A successful test in your own browser does not prove that the chain is configured correctly. The browser may have obtained and cached the intermediate certificate during an earlier visit, through an operating-system update, or from the Authority Information Access location. A new client may not have that cached certificate.
Step 1: Check What the Server Actually Sends with OpenSSL
Use -servername to send Server Name Indication, or SNI. Without it, a server hosting multiple domains may return its default certificate:
openssl s_client \ -connect www.example.com:443 \ -servername www.example.com \ -showcerts \ -verify_return_error </dev/null
Check the following items in the output:
Whether the Certificate chain section contains only certificate number 0, the website certificate.
Whether each certificate’s Subject corresponds to the Issuer of the certificate before it.
Whether the final result is
Verify return code: 0 (ok).Whether the returned certificate covers the hostname you tested.
Running only openssl s_client -connect IP:443 without SNI may retrieve a different virtual host’s certificate. This can make a hostname configuration problem look like a certificate-chain problem.
If you have saved the certificates locally, you can also test whether the leaf certificate can be linked through the intermediate chain to a trusted root:
openssl verify \ -CAfile root-ca.pem \ -untrusted intermediate-chain.pem \ server-certificate.pem
The output server-certificate.pem: OK means that OpenSSL can build a valid path from those local files. It does not prove that the web server sends the same intermediate certificates, so run s_client again after changing the server configuration.
Step 2: Verify the Contents and Order of fullchain.pem
A full-chain file used by a server normally has this order:
-----BEGIN CERTIFICATE----- Website certificate -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- Intermediate CA that directly issued the website certificate -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- Higher-level intermediate CA, if required -----END CERTIFICATE-----
Never place the private key in a public certificate-chain file. Keep it in a separate, access-restricted file such as privkey.pem.
Certificate authorities commonly provide files with names such as:
cert.pemor a domain-named CRT file: usually the website certificate.chain.pemor CA Bundle: one or more intermediate certificates.fullchain.pem: the website certificate followed by the intermediate certificates.privkey.pem: the private key, which must remain confidential.
File names vary between certificate authorities, so do not rely on the name alone. Inspect each certificate’s Subject, Issuer, validity dates, and serial number:
openssl x509 -in certificate.pem \ -noout -subject -issuer -dates -serial
How to Configure the Complete Certificate Chain in Nginx
The file configured through Nginx’s ssl_certificate directive should contain the website certificate first and the intermediate certificates after it:
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate /etc/nginx/ssl/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/privkey.pem;
# Other website settings
}If your certificate authority provides separate files, create the full chain in the correct order:
cat server-certificate.pem intermediate-chain.pem \ > fullchain.pem
Do not reverse the order. Nginx expects the server certificate to appear first in the combined file, followed by intermediate certificates. If the order is wrong, Nginx may report a private-key mismatch because it tries to match the key against the first certificate in the file.
Test the configuration before reloading Nginx:
nginx -t systemctl reload nginx
For a containerized deployment, confirm that the file mounted inside the container was updated. Replacing an unused copy on the host will not change the active certificate. Also check whether other Nginx instances or load-balancer nodes still serve the old chain.
How to Configure the Complete Certificate Chain in Apache
In Apache HTTP Server 2.4.8 and later, SSLCertificateFile can contain the website certificate and its intermediate certificates, with the website certificate first:
<VirtualHost *:443> ServerName www.example.com SSLEngine on SSLCertificateFile /etc/apache2/ssl/fullchain.pem SSLCertificateKeyFile /etc/apache2/ssl/privkey.pem </VirtualHost>
SSLCertificateChainFile has been deprecated since Apache 2.4.8 because intermediate certificates can be included directly in SSLCertificateFile. You may still see a separate chain-file directive on older systems, but new configurations should follow the documentation for the installed Apache version.
Check the configuration and perform a graceful reload:
apachectl configtest apachectl graceful
Depending on the Linux distribution, the relevant command may be apache2ctl or systemctl reload httpd. After the reload, test the certificates presented by the public endpoint again.
How to Configure a Third-Party SSL Certificate on a CDN
When importing your own certificate into a CDN or cloud platform, the interface commonly requests these values separately:
Website certificate or Certificate body.
Private key.
Intermediate certificates or Certificate chain.
The certificate-chain field normally contains only the intermediate certificates. Do not place the website certificate, private key, or root certificate in that field. Begin with the intermediate CA that directly issued the website certificate, followed by any higher-level intermediate.
For example, the certificate-chain field is optional when importing a certificate into AWS Certificate Manager. However, if the website certificate was not issued directly by a trusted root, the necessary intermediate chain must be supplied. AWS requires the certificates to be placed in order and says that the root certificate should not be included.
CloudFront also has an important regional requirement: an ACM viewer certificate used by a CloudFront distribution must be requested or imported in US East (N. Virginia), identified as us-east-1. A certificate in another AWS Region will not appear in the CloudFront viewer-certificate list.
A valid CDN edge certificate does not prove that the origin certificate is valid. Visitors use the viewer certificate when connecting to the CDN, while the CDN uses the origin certificate when connecting to the server. An incomplete origin chain can still cause an origin TLS failure.
Why You Normally Should Not Send the Root Certificate
A root certificate is a trust anchor in the client’s trust store. A client will not trust an unknown root merely because a server sends it during the handshake. Including the root adds unnecessary handshake data and may cause some certificate-import checks to fail.
The goal is not to send as many certificates as possible. The server should send the shortest valid intermediate chain that allows the client to reach a root it already trusts.
Common Certificate-Chain Configuration Mistakes
Only the Website Certificate Is Installed
This is the most common cause. A browser may automatically find the intermediate certificate, while an API client cannot, producing inconsistent results across devices.
The Certificates Are in the Wrong Order
Placing an intermediate certificate before the website certificate can prevent the service from starting, trigger a key-mismatch error, or cause a cloud platform to reject the import.
The Private Key or Root Certificate Is Added to fullchain.pem
The private key is not part of the certificate chain. Exposing it compromises the certificate’s security. The root certificate also normally should not be sent by the server.
The Website Certificate Does Not Match the Private Key
Compare public-key hashes instead of relying on an RSA modulus command that does not work for every key algorithm:
openssl x509 -in server-certificate.pem -pubkey -noout \ | openssl pkey -pubin -outform pem \ | sha256sum openssl pkey -in privkey.pem -pubout -outform pem \ | sha256sum
The two hashes should match. Never upload a private key to an online certificate-checking service.
The Wrong Virtual Host or Node Was Updated
One server may host several domain configurations, and one website may run on several load-balancer nodes. Check SNI, DNS records, IPv4 and IPv6 endpoints, and every backend node.
The Service Was Not Reloaded
Replacing a certificate file does not change the live certificate if Nginx, Apache, a load balancer, or a container still holds the previous configuration. Test the syntax, reload the service, and verify the public endpoint again.
Complete Repair and Verification Checklist
Use OpenSSL with SNI to inspect the certificates sent by the live server.
Confirm that the problem is a missing intermediate, not an expired certificate, hostname mismatch, or client trust-store issue.
Download the correct intermediate certificates from the certificate authority’s official source.
Inspect the website certificate’s Issuer and build the correct path to a trusted root.
Create the full-chain file in website-certificate-first order and normally exclude the root.
Confirm that the website certificate matches the private key.
Update the certificate configuration in Nginx, Apache, the load balancer, or the CDN.
Run a configuration test and reload the service gracefully.
Retest from another network or an environment that has not cached the intermediate certificate.
Check every node, IPv4 and IPv6, the CDN viewer connection, and the CDN origin connection.
Frequently Asked Questions
Does fullchain.pem contain the private key?
No. It normally contains the website certificate and intermediate certificates only. The private key belongs in a separate privkey.pem or key file with restricted permissions.
Should the root certificate be included in the chain?
Usually not. The root should come from the client’s trust store. The server needs to send only the website certificate and the intermediate certificates required to build the trust path.
Why does the website work in a desktop browser but fail in a mobile app?
The desktop may have cached the missing intermediate or may use a different trust store. A mobile app or API client without that cached certificate exposes the server’s incomplete chain.
Why is the old certificate still visible after replacement?
The service may not have reloaded, the request may be reaching another node, DNS may still point to an older server, the CDN may still use its old certificate, or the IPv4 and IPv6 backends may differ. Connect to each specific IP with OpenSSL while supplying the correct SNI hostname to isolate the problem.
Does a successful CDN certificate upload prove that the origin certificate is correct?
No. The CDN viewer certificate protects the visitor-to-CDN connection. The origin certificate protects the CDN-to-origin connection. Test both TLS paths independently.
Can I download an intermediate certificate from any website?
That is not recommended. Obtain it from the certificate authority, AWS Certificate Manager, or your certificate automation client’s official channel. Verify its Subject, Issuer, validity period, and fingerprint.
Conclusion
Fixing an incomplete SSL certificate chain requires the server to send the correct intermediate certificates in the correct order. It does not require exposing the private key, adding a root certificate indiscriminately, or requesting a new certificate without first identifying the actual problem.
For Nginx, the certificate file should begin with the website certificate and continue with the intermediate certificates. Apache 2.4.8 and later can use the same combined chain through SSLCertificateFile. A CDN certificate-chain field normally contains only the ordered intermediate certificates.
After deployment, use OpenSSL with SNI to inspect what the public endpoint actually sends. Test both the CDN viewer connection and the CDN-to-origin connection. The issue is resolved only when different clients can build a complete path from the website certificate to a trusted root.
CloudFlew provides CDN and SSL-related services. During certificate deployment, check the website certificate, private-key match, intermediate order, edge certificate, and origin certificate instead of relying on a single successful browser visit.
References
NGINX Documentation: Configuring HTTPS Servers, reviewed August 3, 2026
Apache HTTP Server Documentation: mod_ssl, reviewed August 3, 2026
OpenSSL Documentation: openssl-s_client, reviewed August 3, 2026
OpenSSL Documentation: openssl-verify, reviewed August 3, 2026
AWS Certificate Manager User Guide: Certificate Import Format, reviewed August 3, 2026
Amazon CloudFront Developer Guide: Certificate Requirements, reviewed August 3, 2026
