Incomplete Certificate Chain

SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration
SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration

All Entries

Scan Your Site

Check your website for this issue

Run an automated scan and see whether your site is affected — with plain-language findings and fixes.

Start Scanning
Category TLS / PKI Misconfiguration
Typical Severity Medium
OWASP A02:2021 – Cryptographic Failures
CWE CWE-295: Improper Certificate Validation
Relevant RFC RFC 5246 (TLS 1.2), RFC 8446 (TLS 1.3), RFC 5280 (X.509 PKI)
Also known as Missing intermediate certificate, broken chain of trust, untrusted certificate chain
Affected systems Any HTTPS web server, API endpoint, or TLS-enabled service that does not correctly configure its certificate bundle

Overview

In the X.509 Public Key Infrastructure (PKI) model, trust is established through a hierarchical chain: a trusted root Certificate Authority (CA) signs one or more intermediate CAs, which in turn sign end-entity (server) certificates. Browsers and operating systems ship with a store of trusted root CA certificates but generally do not pre-cache intermediate certificates.

An incomplete certificate chain occurs when a TLS server sends only its own end-entity certificate — or an incomplete subset of the chain — without including the necessary intermediate CA certificates. Clients that do not already have those intermediate certificates cached cannot independently verify the server's identity, leading to TLS handshake failures or browser security warnings.

How it works

During the TLS handshake (defined in RFC 5246 / RFC 8446), the server is required to send its certificate and, optionally, additional certificates forming the chain up to (but typically not including) the trusted root. The exact mechanism is:

  • Certificate message: The server sends a Certificate handshake message containing an ordered list of DER-encoded certificates. The first entry must be the server's own certificate; subsequent entries should be intermediate CA certificates in order toward the root.
  • Client path building: The client attempts to construct a certification path from the server certificate to a trusted root in its local trust store. If an intermediate CA certificate is absent from the server's message and not already cached locally, path building fails.
  • AIA fetching (unreliable fallback): Some clients (notably Windows/IE) may follow the Authority Information Access (AIA) extension in the server certificate to download missing intermediates via HTTP. However, this behaviour is not universal — many clients (strict mobile apps, IoT devices, curl without AIA support, and some browsers) do not perform AIA chasing, causing hard failures.
  • Misconfiguration cause: The issue most commonly arises when an administrator installs only the server certificate file without bundling the intermediate CA certificate(s) provided by the issuing CA, or when web server configuration (e.g., Apache SSLCertificateChainFile, Nginx ssl_certificate bundle) is set up incorrectly.

Business impact

The practical consequences depend on the client's tolerance and caching state:

  • Broken user experience: Browsers such as Firefox (which does not perform AIA chasing) will display a hard trust error, preventing users from accessing the site entirely. This directly reduces conversion and damages user trust.
  • API and automation failures: HTTP clients in server-to-server integrations (payment gateways, webhooks, CI/CD pipelines, mobile SDKs) commonly enforce strict chain validation and will refuse connections, potentially disrupting critical business workflows.
  • Compliance risk: PCI DSS, HIPAA-related guidance, and other frameworks require properly configured TLS. An incomplete chain is evidence of misconfiguration that can be flagged during audits.
  • Reputational damage: Public-facing services displaying certificate errors erode customer confidence and may be flagged by search engines or security rating platforms.
  • Intermittent failures: Because some clients cache intermediate certificates from prior connections, failures may appear intermittent and difficult to reproduce, complicating incident response.

How to fix it

  1. Obtain the full certificate bundle from your CA: When your CA issues a certificate, it also provides intermediate CA certificate(s). Download the complete chain file (often labelled ca-bundle.crt, chain.pem, or similar).
  2. Configure your web server to serve the full chain:
    • Nginx: Concatenate your server certificate and all intermediate certificates into a single PEM file in order (server cert first, then intermediates). Reference it with ssl_certificate /path/to/fullchain.pem;.
    • Apache: Use the SSLCertificateFile directive for the server cert and SSLCertificateChainFile (Apache 2.4.7 and earlier) or include intermediates in the same file referenced by SSLCertificateFile (Apache 2.4.8+).
    • IIS: Import the full PKCS#12 (.pfx) bundle which includes intermediates, or manually install intermediate certificates into the server's Intermediate Certification Authorities store.
    • HAProxy / Load balancers: Provide a PEM bundle containing the full chain in the configured certificate path.
  3. Verify the chain after deployment: Use a tool such as openssl s_client -connect example.com:443 -showcerts and confirm that all intermediate certificates are returned. Online tools such as SSL Labs' SSL Server Test also report chain completeness.
  4. Automate certificate management: Use ACME-based automation (e.g., Certbot, cert-manager for Kubernetes) which automatically provisions and renews the full certificate chain, reducing human error.
  5. Do not rely on AIA chasing: Never assume that clients will automatically fetch missing intermediates. Always serve the complete chain explicitly.
  6. Monitor continuously: Add certificate chain validation to your uptime and TLS monitoring stack to catch regressions after certificate renewals. Sensagraph detects incomplete certificate chains as part of its automated TLS scanning.

References

Frequently asked questions

An incomplete certificate chain occurs when a TLS server does not send all the intermediate CA certificates required for a client to verify the server's identity. Clients that cannot build a complete path from the server certificate to a trusted root CA will fail the TLS handshake or show a security warning.

Chrome (and other Chromium-based browsers on Windows) can follow the Authority Information Access (AIA) extension in the server certificate to automatically download missing intermediate certificates. Firefox does not perform AIA chasing, so it relies entirely on what the server sends. This means an incomplete chain fails immediately in Firefox but may succeed in Chrome if the intermediate has been cached or fetched via AIA.

Run: openssl s_client -connect yourdomain.com:443 -showcerts and inspect the output. Every certificate in the chain (server cert plus all intermediates) should appear between BEGIN CERTIFICATE and END CERTIFICATE markers. Online tools such as Qualys SSL Labs' SSL Server Test also report whether the chain is complete and in the correct order.

It is a misconfiguration rather than an exploitable vulnerability in the traditional sense. However, it directly undermines the TLS trust model, can cause service disruptions, and is classified under CWE-295 (Improper Certificate Validation) because it may lead clients to make incorrect trust decisions or fail to connect entirely.

Yes, indirectly. Clients that attempt AIA chasing to recover missing intermediates must make additional HTTP requests during the TLS handshake, increasing latency. Failed connections or repeated retries also consume server and client resources. Serving the full chain eliminates this overhead.