Your site loads fine in Chrome. The padlock is green, no warnings, everything looks perfect. Then a customer says your checkout page is "not secure" on their Android phone, or your app's HTTP client throws SSL: certificate_verify_failed, or a payment gateway webhook to your server just silently fails. You check the browser again — still fine. This is almost always an incomplete SSL certificate chain, and it's one of the most common "but it works for me" support tickets we see.

Symptom: Works in the Browser, Fails Everywhere Else

An incomplete chain doesn't break every client the same way, which is exactly what makes it confusing. Typical reports look like:

  • curl or wget on a server return SSL certificate problem: unable to get local issuer certificate
  • Older Android devices (roughly pre-7.1) show "Your connection is not private"
  • Mobile banking or payment SDKs fail SSL pinning/validation and reject the connection
  • PHP's cURL, Python's requests, or Node's https module throw certificate verification errors when calling your API
  • SSL Labs (ssllabs.com/ssltest) grades your site with a "Chain issues: Incomplete" warning
  • Uptime monitors (UptimeRobot, Pingdom) flag SSL errors even though the site is up

Meanwhile Chrome, Firefox, and Safari on a modern desktop don't complain at all. That's the giveaway.

Cause: Your Server Isn't Sending the Full Trust Path

A publicly trusted SSL certificate isn't validated on its own — it's validated as a chain: your certificate, signed by an intermediate CA certificate, which is in turn signed by a root CA that's built into the operating system or browser's trust store.

Modern desktop browsers are forgiving. They cache intermediate certificates they've seen before and can often fetch the missing one automatically via AIA chasing (Authority Information Access). Curl, older mobile OSes, most programming-language HTTP libraries, and many IoT/embedded clients don't do this — they only trust what your server actually hands them during the TLS handshake. If your server sends just the leaf certificate and skips the intermediate, those clients have no way to build a path to a trusted root, and they fail closed.

This usually happens for one of these reasons:

  • You installed a custom SSL certificate manually (via CSR) and only pasted the certificate itself into cPanel's SSL/TLS Manager, leaving the "Certificate Authority Bundle (CABUNDLE)" field empty
  • The CA bundle you pasted is outdated — CAs occasionally rotate their intermediate certificates, and an old bundle references a superseded one
  • You're on Nginx and only referenced the single .crt file in ssl_certificate instead of a concatenated full-chain file
  • A migration or backup restore brought over the leaf certificate but not the matching intermediate

Note this is different from AutoSSL's free Let's Encrypt certificates, which almost always ship the correct chain automatically. Incomplete chains are overwhelmingly a manually-installed, paid-certificate problem.

Fix: Verify, Then Reinstall With the Full Chain

First, confirm it's actually a chain problem and not something else. From any terminal:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com < /dev/null 2>/dev/null | openssl x509 -noout -text | grep -A2 "Authority Information Access"

Faster and more readable: run your domain through SSL Labs' SSL Test. Under "Chain issues" it will say Incomplete if the intermediate is missing, and it lists exactly which certificate is absent.

If you're on cPanel hosting (SkyServer shared/reseller hosting)

  1. Log into cPanel and open SSL/TLS Manager > Install and Manage SSL for your site (HTTPS)
  2. Find the domain and click Manage SSL Sites
  3. Make sure all three fields are filled: Certificate (CRT), Private Key (KEY), and critically the Certificate Authority Bundle (CABUNDLE)
  4. If your CA (Sectigo, DigiCert, GoDaddy, etc.) emailed you separate files, the bundle is usually named something like ca-bundle.crt or intermediate.crt. If you only have one combined file from the CA's portal, download the "full chain" or "intermediate + root" bundle specifically from their download page — don't reuse your own certificate file here
  5. Click Install Certificate. cPanel will validate the chain and warn you if it still can't build a path to a trusted root

If you're on a VPS running Nginx

Concatenate your certificate and the CA bundle into a single full-chain file, leaf certificate first:

cat yourdomain.crt intermediate.crt > fullchain.crt
server {
    ssl_certificate     /etc/nginx/ssl/fullchain.crt;
    ssl_certificate_key /etc/nginx/ssl/yourdomain.key;
}

Reload Nginx with nginx -t && systemctl reload nginx and re-test.

If you're on Apache

Apache uses a separate directive for the chain in older configs:

SSLCertificateFile      /etc/ssl/yourdomain.crt
SSLCertificateKeyFile   /etc/ssl/yourdomain.key
SSLCertificateChainFile /etc/ssl/intermediate.crt

(On newer OpenSSL/Apache builds, SSLCertificateChainFile is deprecated — append the intermediate to the same file referenced by SSLCertificateFile instead, same as the Nginx example above.)

If it's Let's Encrypt via AutoSSL and still broken

This is rarer, but if a previous manual certificate is still cached somewhere (a CDN, a load balancer, an old vhost config pointing at stale files), AutoSSL's correct chain never actually gets served. Check what's live with the openssl s_client command above rather than trusting what's saved in cPanel — and if you're behind Cloudflare, make sure its SSL mode and edge certificate aren't the ones actually terminating and re-serving TLS to end users.

Prevention

  • Whenever you install or renew a paid SSL certificate manually, always download the CA's "full chain" or "intermediate bundle" file from their portal — never assume the certificate file alone is enough
  • After every SSL install or renewal, re-run the SSL Labs test as a habit, not just when someone complains
  • Prefer AutoSSL (Let's Encrypt) for standard sites where you don't specifically need an EV/OV certificate — it manages the chain correctly on its own and auto-renews
  • If you manage certificates outside cPanel (custom Nginx/Apache on a VPS), script a quick openssl s_client or curl -v check into your deployment or renewal process so a broken chain fails your pipeline instead of failing silently in production

Frequently Asked Questions

Why does my site show a valid padlock in Chrome if the chain is broken?

Chrome (and most modern desktop browsers) can fetch a missing intermediate certificate automatically via AIA chasing, and it caches intermediates it has already seen from other sites. Command-line tools, many mobile OSes, and most programming-language HTTP libraries don't do this fetch, so they fail where the browser quietly succeeds.

Does this affect SEO or Google rankings?

Not directly through Googlebot in most cases, since Google's crawler is generally chain-tolerant. But it can hurt indirectly — API integrations, payment webhooks, and structured data validators that fail SSL checks against your domain can cause real functional and trust problems that do affect your site's performance and reputation.

I only pasted one certificate file into cPanel — where do I get the CA bundle?

Go back to the CA's issuance/download portal (Sectigo, DigiCert, Comodo, GoDaddy, etc.) using the order reference from your purchase. There's almost always a separate download link for "intermediate certificate," "CA bundle," or "full chain" distinct from your primary certificate download.

Will AutoSSL fix this automatically if I switch to it?

Yes, in almost all cases. AutoSSL issues free Let's Encrypt certificates and installs the correct chain as part of that process. Switching from a manually-installed certificate to AutoSSL resolves incomplete-chain issues for the vast majority of sites.

How do I know for sure which certificate is missing?

Run your domain through SSL Labs' SSL Test. Its "Chain issues" section names the exact incomplete or missing certificate and often links directly to the correct intermediate you need to add.