A CA chain is an ordered list of certificate authority (CA) certificates – every intermediate CA between an issued certificate and the trusted root – that lets a receiver verify a device, gateway, or server certificate step by step, back to a root certificate it already trusts.
Key takeaways
- A CA chain links a certificate to a trusted root through intermediate CAs.
- Missing intermediates cause “untrusted certificate” errors on valid roots.
- Also called a certificate chain or chain of trust in PKI terminology.
- VOS devices and Titan Portal require uploading the chain, not just the cert.
- Each certificate is signed by the one above it, ending at a trusted root.
On this page: Why it mattersHow it worksTypesCA Chain & VersaFAQ
Why are CA chains important?
Certificate validation only works if the verifying party can trace a signed certificate back to a root it already trusts. Devices ship with a small set of trusted root CA certificates, but almost no certificate is signed directly by one of those roots – the root delegates signing to one or more intermediate CAs instead. A verifier holding only the final certificate cannot walk the signatures back to a trust anchor it recognizes.
This is why “untrusted certificate” and “unknown CA” errors are usually a missing-chain problem, not an invalid-certificate one. Getting the chain wrong breaks what it secures: browsers block the site, IPsec tunnels fail, directory binds fail. Intermediates also keep the root CA’s private key offline – the chain is what makes that protection possible.
What is a CA chain?
Structurally, a CA chain is a signature path: the trusted root CA certificate (self-signed, in a trust store) at the top, one or more intermediate CA certificates in the middle – each signed by the one above it – and the end-entity certificate (the device, server, or gateway certificate) at the bottom, signed by the last intermediate. A verifier checks each signature until one matches its trust store.
A CA chain is usually a single file – commonly .crt, .cer, or .pem – containing the intermediate certificates concatenated in order, sometimes with the root included. Software validating the end-entity certificate reads this file to fill gaps its own trust store can’t supply.
Types of CA chains
Chains vary mainly by depth and how the hierarchy connects. A single-intermediate chain – root, one intermediate, leaf certificate – is the most common shape in enterprise PKI. A multi-intermediate chain nests several intermediate CAs, letting a large CA delegate signing by policy, region, or business unit without overexposing the root. A single-tier chain has the root sign the end-entity certificate directly – simpler, but it uses the root key more often, so it’s more common on self-signed lab certificates than in production PKI. Cross-signed chains link separate hierarchies by having one CA sign another’s certificate, useful during a root migration.
CA Chain & Versa
On a VOS device managed through Versa Director, a CA certificate, its private key, and its CA chain are uploaded as separate custom objects – under Objects & Connectors > Custom Objects > CA Certificate, Keys, and CA Chains – first to the Director node, then to the appliance; chain files must be .crt, .cer, or .pem. The Configure CA Certificates, Key File, and CA Chains guide (and its NGFW equivalent) cover both steps. Once uploaded, the chain is selected inside an IPsec VPN profile for both local and peer certificate authentication.
In Titan Portal, MSPs and tenant administrators follow the same key-then-certificate-then-chain sequence to install certificates for SASE gateway VSA services, and can choose a default or custom CA chain when securing LDAPS to Active Directory.
Frequently asked questions
What is the difference between a CA certificate and a CA chain?
A CA certificate is a single certificate issued by one authority. A CA chain is the full ordered sequence of those certificates – every intermediate CA between an issued certificate and the trusted root – needed to verify it back to a root the verifier already trusts.
Why do I get an “untrusted certificate” error if the certificate is valid?
Usually the server or device sent only its end-entity certificate without the intermediate CA certificates. The client’s trust store holds only the root, so it can’t bridge the gap between the two; uploading or serving the complete CA chain resolves the error.
What file formats does a CA chain use?
CA chains are typically distributed as .crt, .cer, or .pem files containing PEM-encoded certificates concatenated in order, from the first intermediate certificate down to the last one, so validating software can read the entire trust path from a single file.
Does every certificate need its own CA chain?
No. Certificates issued from the same CA hierarchy share the same intermediates and root certificate. One uploaded CA chain object validates every device or gateway certificate issued from that hierarchy, so administrators upload it once rather than attaching a separate chain to each certificate.
Where is a CA chain used besides HTTPS traffic?
Beyond web traffic, CA chains authenticate IPsec VPN peers during certificate-based IKE negotiation, secure LDAPS binds to directory servers, and validate device or gateway identity certificates – anywhere one side must verify the other’s certificate back to a trusted root.
More on CA chains
If you want to learn more, these are sources we trust.
| IETF RFC 5280: X.509 PKI Certificate and CRL Profile | NIST CSRC Glossary |
|---|---|
| The IETF standard defining the X.509 certificate format and the certification-path (chain) validation model used across TLS, IPsec, and PKI. | NIST’s controlled definitions for PKI and certification-path terminology, useful for precise cross-reference against security specifications. |
Related terms
If you’re reading about CA chains, these are worth looking at next.
| Transport Layer Security | Secure Sockets Layer | Publish |
|---|---|---|
| The protocol a CA chain most often serves: verifying a server or peer certificate before an encrypted session is established. | TLS’s predecessor; CA chains validate SSL and TLS certificates through the same root-to-leaf trust path. | The Director/Concerto action that pushes an uploaded CA certificate, key, and chain out to the target appliance. |