What is an intermediate CA?
An intermediate CA, also called a subordinate or issuing CA, is a certificate authority whose own certificate is signed by a root CA or by another intermediate, not by itself. It sits between the root that devices trust and the end-entity certificates on servers, users and devices. Nearly every certificate on the public web is issued by an intermediate, and enterprise PKIs follow the same pattern. The arrangement lets the root's private key stay offline while intermediates handle day-to-day issuance.
What makes a certificate an intermediate
A few extensions mark a CA certificate and limit what it can do:
- Basic constraints CA:TRUE allows the certificate to sign other certificates. Leaf certificates carry CA:FALSE.
- A path length constraint limits how many more CA levels may sit below it. An issuing CA marked
pathlen:0can sign only end-entity certificates. - Key usage includes certificate signing and CRL signing.
- Name constraints, when present, restrict the domains the CA may issue for, which is how an organization can be given its own technically constrained CA without gaining the power to issue for anyone else's domain.
Inspecting an issuing CA's certificate with openssl x509 -noout -ext basicConstraints,keyUsage -in issuing-ca.crt typically shows CA:TRUE, pathlen:0 along with the key usages Certificate Sign, CRL Sign.
How intermediates are organized
A two-tier PKI has an offline root and one or more online issuing CAs. Larger or regulated PKIs add a third tier of policy CAs between them so different branches can follow different rules. Organizations often split intermediates by purpose, one for TLS servers, one for employee smart cards and one for devices, so revoking one branch leaves the others working. Public CAs also create new intermediates periodically and retire old ones, and a single intermediate can be cross-signed by two roots so that older devices that know only the older root can still build a chain.
Why intermediate compromise matters
An intermediate's certificates are trusted exactly as much as the root's own. That is why a root revokes a compromised intermediate quickly, listing it on the root's CRL so every certificate beneath it fails validation, and why browser vendors react hard to misused intermediates. In 2015 the Chinese CA CNNIC issued an unconstrained intermediate to MCS Holdings, an Egyptian company, which installed it in a network device that generated certificates for Google domains. Google detected the forged certificates, and Chrome and Firefox stopped trusting new certificates from CNNIC's roots. Handing out an unconstrained intermediate amounts to handing over the power to impersonate any website.
Intermediate CA vs. root CA vs. leaf certificate
| Root CA | Intermediate CA | Leaf certificate | |
|---|---|---|---|
| Signed by | Itself | A root or another intermediate | An intermediate |
| Usually online? | No | Yes | Yes, on the server or device |
| In device trust stores? | Yes | No, the server sends it | No, the server sends it |
| Can issue certificates? | Yes | Yes, within its constraints | No |
Because intermediates aren't in trust stores, a server has to send its intermediate certificates along with its own in the TLS handshake. Leaving them out causes the classic missing intermediate error described under chain of trust.
Intermediate CA on the CompTIA Security+ exam
Intermediate CAs are taught with certificate authorities and the root of trust under SY0-801 objective 1.3, the cryptographic solutions objective. Wording such as "limit the damage if an issuing CA is compromised" or "keep the root CA offline" points to issuing through intermediates. "A site works in browsers but a script reports unable to get local issuer certificate" points to a missing intermediate on the server. Distractors include a longer root key, which does nothing against key theft, and self-signed certificates, which have no chain at all.