Intermediate certificate

Certificate authorities never sign a website's certificate with the root key. They sign an intermediate, lock the root key offline, and issue from the intermediate, which can be replaced in weeks rather than the twenty years a root lives. When a server forgets to send its intermediate, browsers paper over the gap and stricter clients do not, so a site can look fine in Chrome and fail in an app.

How it works

An intermediate certificate is an authority certificate that is not a trust anchor. It carries the basicConstraints extension with CA set to true, which permits it to sign further certificates, and it is itself signed by a root or by another intermediate. Verification climbs from the server's certificate upward, checking each signature against the key held in the certificate above it, and halts when it reaches something already present in the local trust store.

Splitting issuance this way buys three things. The root key stays in an offline module that comes out only for scripted, witnessed ceremonies. Damage is contained, because a compromised intermediate can be revoked and reissued without touching any device's root store. And an authority can separate its product lines, so trouble in the cheap automated tier does not implicate the audited one.

Cross-signing is the trick that makes a new authority usable at all. One intermediate key can hold two certificates: one signed by its own organization's root, one signed by an established root that is already sitting on old devices. Let's Encrypt relied on this for years, because ISRG Root X1 was missing from Android versions that had stopped receiving updates, so it served a chain cross-signed by IdenTrust. The crutch outlived the root behind it, which expired on September 30, 2021, and Let's Encrypt finally stopped serving the cross-signed chain on June 6, 2024.

Chain assembly is the part operators get wrong. A server should send its own certificate plus every intermediate above it, stopping short of the root, which the client already has. Browsers hide omissions by fetching the missing piece from the URL in the authority information access extension or by reusing a cached copy. A payment library, a mobile app or a command line client usually does neither and simply reports an untrusted chain.

Where you see it

BIP70 shipped intermediates inside the payment message itself. The pki_data field carried an X509Certificates structure whose first entry was the merchant's own certificate, followed by whatever intermediates were needed to reach a root, with the root omitted because the wallet was expected to hold it already. That is exactly the ordering a TLS server sends, moved into a protocol buffer.

Outside bitcoin, intermediates announce themselves whenever a connection succeeds in one program and fails in another. An exchange whose API endpoint throws a certificate error at a trading script while the website loads normally has almost always dropped an intermediate from its chain. Testing with a tool that does not perform the browser's silent repair work is how you catch it before your bot does.

Intermediate certificate vs root certificate

A root and an intermediate are both authority certificates, and the difference is who signed them and where the key lives. A root is self-signed and draws its power from a vendor's inclusion list. An intermediate draws its power from the signature above it, which means the issuing authority can revoke it in an afternoon, with no software update anywhere. In day to day operation the intermediate does nearly all the signing while the root does almost none, and that asymmetry is the whole reason the layer exists.