Bridge SSL
Intermediate certificate: what it is, why CAs use it, how to check it
An intermediate certificate is a CA certificate signed by a root, and its key signs the HTTPS certificates of websites. The authority behind it is an intermediate certificate authority, or subordinate CA; RFC 5280 writes certification authority [1]. A browser trusts it only through the path from your certificate, via the intermediate, to a root already in its store. So your server sends the intermediate with its own certificate, and only the root may be left out [3].
- Signed by
- a root CA or another subordinate CA (Baseline Requirements §1.6.1) [2]
- Basic constraints
- critical, cA TRUE, path length optional (RFC 5280 §4.2.1.9) [1]
- Extended key usage
- serverAuth required, anyExtendedKeyUsage forbidden (Baseline Requirements §7.1.2.10.6) [2]
- Where to get it
- the authority, with your certificate, or the authority information access address in it (RFC 5280 §4.2.2.1) [1]
Why certificate authorities sign through an intermediate
The Baseline Requirements leave no other option. A root's private key may sign only the root's own certificate, certificates for subordinate and cross-certified CAs, infrastructure certificates, and certificates for OCSP response verification (§6.1.7) [2]. A website certificate is none of these. So every publicly trusted website certificate is signed by an intermediate, free CA certificates included.
The rule protects something hard to replace. A root reaches visitors inside trust stores that browser and operating-system vendors maintain, and the root certificate authority cannot change those stores on its own schedule. The authority signs an intermediate with the root key on its own schedule. If the intermediate's key is compromised, the issuing CA must revoke it (§4.9.1.2) [2] and can sign a replacement under the same root. Nothing on visitors' devices has to change.
Intermediates also divide the work. An intermediate whose extended key usage or name constraints limit what it may issue is what the requirements call technically constrained [2]. A cross-certificate goes further: one authority issues it to another, and the requirements define it as a certificate used to establish a trust relationship between two CAs [2].
How SSL certificate authorities validate requests and pass audits is a separate subject from the certificates they sign with.
What an intermediate certificate contains
A publicly trusted TLS intermediate follows the TLS Subordinate CA Certificate Profile, §7.1.2.6 of the Baseline Requirements, which is built on RFC 5280 [1][2]. These fields set it apart from your own certificate:
| Field | In a TLS intermediate | What it does |
|---|---|---|
| basicConstraints | required, critical; cA TRUE; pathLenConstraint optional | without cA TRUE the key must not be used to verify certificate signatures [1] |
| keyUsage | required, critical; keyCertSign and cRLSign | keyCertSign allows signing certificates and is valid only with cA TRUE [1] |
| extKeyUsage | required; serverAuth, clientAuth allowed; anyExtendedKeyUsage, code signing and OCSP signing forbidden | keeps the intermediate to TLS [2] |
| authorityInformationAccess | recommended | addresses of the issuer's certificate and OCSP responder [2] |
| issuer | byte for byte the subject of the CA that signed it | lets a client find the next certificate up [2] |
Reading a test intermediate: extensions and path length
The output on this page comes from a test chain built for it, with its own root named Example Lab Root CA, on OpenSSL 3.0.13. Reading the intermediate:
$ openssl x509 -in intermediate.pem -noout -subject -issuer -ext basicConstraints,keyUsage,extendedKeyUsage
subject=C = US, O = Example Lab, CN = Example Lab Intermediate CA
issuer=C = US, O = Example Lab, CN = Example Lab Root CA
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
X509v3 Extended Key Usage:
TLS Web Server AuthenticationpathLenConstraint, part of basic constraints, counts the intermediate certificates allowed below this one, not counting the certificate at the end of the path. Zero means none, and no value means no limit [1]. The test intermediate has pathlen:0. Let it sign a second CA, let that CA sign a server certificate, and verification stops at the intermediate:
$ openssl verify -CAfile root.pem -untrusted untrusted.pem cert2.pem
C = US, O = Example Lab, CN = Example Lab Intermediate CA
error 25 at 2 depth lookup: path length constraint exceeded
error cert2.pem: verification failedOpenSSL describes error 25 as the basicConstraints path-length parameter being exceeded [4].
Is this file an intermediate certificate?
Read the subject, the issuer and the basic constraints. Those three fields settle it.
| Field | Root | Intermediate | Leaf (your certificate) |
|---|---|---|---|
| subject and issuer | identical: the root signs itself | differ: the issuer is a root or another intermediate | differ: the issuer is an intermediate |
| basicConstraints cA | TRUE; path length not recommended | TRUE; path length allowed | FALSE if present, never a path length |
| keyCertSign | set | set | not allowed |
| extKeyUsage | not allowed | required, with serverAuth | required, with serverAuth |
The rows follow the root, CA and subscriber profiles of the Baseline Requirements, §7.1.2.1.2, §7.1.2.1.4, §7.1.2.10, §7.1.2.7.6, §7.1.2.7.8, §7.1.2.7.10 and §7.1.2.7.11 [2]. A file with CA:TRUE and an issuer that differs from its subject is an intermediate. A file whose subject equals its issuer is a root, or a self-signed certificate outside any trust store.
How to tell the server does not send the intermediate
Ask the server for its certificate chain with openssl s_client and read the depth= lines: 0 is the server's own certificate, 1 the intermediate certificate that signed it, 2 the root certificate. A verify error line appears under certificates that fail [4]. A test server sending only its own certificate (output abridged):
$ openssl s_client -connect 127.0.0.1:28443 -servername example.com -CAfile root.pem </dev/null
depth=0 CN = example.com
verify error:num=20:unable to get local issuer certificate
depth=0 CN = example.com
verify error:num=21:unable to verify the first certificate
Verify return code: 21 (unable to verify the first certificate)num=20 under depth=0 means the server does not send the intermediate: the client found no issuer for the server's certificate. num=21 follows because the chain holds one certificate that is not self-signed [4]. Under a higher depth, num=20 means the intermediate arrived and the client does not trust the root above it. With the intermediate added, the same check lists depth=2, depth=1 and depth=0 and ends with Verify return code: 0 (ok).
For a public site, drop -CAfile and connect to the hostname on port 443. Use the command line: a browser that cached the intermediate elsewhere can hide the fault.
Where to get the intermediate certificate
From the authority that issued your certificate, at the same time. An ACME client downloads a PEM chain with your certificate first and the issuer after it (RFC 8555 §7.4.2, §9.1) [5]. Buying by hand, you receive the certificate and its intermediate certificates together.
If you only have the certificate, it names the place to fetch its issuer: the caIssuers entry of the authority information access extension [1]. The Baseline Requirements say a subscriber certificate should carry it (§7.1.2.7.7) [2].
$ openssl x509 -in cert.pem -noout -issuer -ext authorityInfoAccess
issuer=C = US, O = Example Lab, CN = Example Lab Intermediate CA
Authority Information Access:
CA Issuers - URI:http://ca.example.net/lab-intermediate.cerThat address serves a single DER certificate or a certs-only CMS bundle [1]. Convert DER to PEM with openssl x509 -inform DER -in intermediate.cer -out intermediate.pem [4]. Then confirm it is the right one: openssl verify -CAfile root.pem -untrusted intermediate.pem cert.pem prints cert.pem: OK only if this intermediate links your certificate to the root.
Putting it in the server's chain file
In the file the server reads, put your certificate first and each next certificate after the one it signs. The root may be left out [3].
On Bridge CDN there is nothing to assemble. Bridge SSL is the certificate layer of Bridge CDN: TLS is terminated at the edge, so no certificate file and no chain sit on your server.
Which intermediate signs your certificate is the authority's decision. An ACME server may offer alternative chains for the same certificate [5], and anything beyond that is part of how to choose a certificate authority.
FAQ
What is an intermediate SSL certificate?
It is the certificate of the authority that signed your SSL certificate. A root signed it, its basic constraints say CA TRUE, and your server sends it with your own certificate so that clients can link the two to a root they trust.
Is an intermediate CA the same as a subordinate CA?
Yes. The Baseline Requirements use subordinate CA for an authority whose certificate is signed by a root or by another subordinate CA, and intermediate certificate authority is the everyday name for the same thing.
What is an intermediate certificate bundle?
A file of one or more intermediate certificates, in order, that the server sends after its own certificate. The PEM chain an ACME client downloads already holds your certificate followed by its issuer. The root may stay out.
How do I install an intermediate certificate?
Add the intermediate certificate to the chain file your server reads, after your own certificate, and reload the server. Then repeat the openssl s_client check above: no verify error line and Verify return code: 0 (ok) mean it is served.
Sources
RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile: §4.2.1.3 key usage, §4.2.1.9 basic constraints, §4.2.2.1 authority information access.
CA/Browser Forum Baseline Requirements, version 2.3.1: §1.6.1, §4.9.1.2, §6.1.7, §7.1.2.1.2, §7.1.2.1.4, §7.1.2.6, §7.1.2.7.6, §7.1.2.7.7, §7.1.2.7.8, §7.1.2.7.10, §7.1.2.7.11, §7.1.2.10.
RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3: §4.4.2 certificate list.
OpenSSL 3.0 manual: X509_STORE_CTX_get_error (verification error descriptions), openssl-s_client, openssl-x509, openssl-verify.
RFC 8555, Automatic Certificate Management Environment (ACME): §7.4.2 downloading the certificate, §9.1 application/pem-certificate-chain.