Intermediate CA Expiry Against a Firmware-Pinned Root
A fleet of 40,000 industrial gateways validates the cloud endpoint's certificate chain against a root CA public key compiled into firmware. The chain today is a self-signed Root A (2048-bit RSA, expires 2038), an intermediate B cross-signed by Root A and by Root C, the new corporate root, and leaf server certificates with 90-day lifetimes. Root A's private key was retired last year and its HSM slot destroyed; the CA can still issue from intermediate B because that key lives in a different HSM. Intermediate B expires in 21 days. Firmware is delivered over the air, but 6,200 units in the field have a bootloader that cannot be updated and will only ever trust the Root A key. A new intermediate from Root C is ready and is trusted by no deployed firmware. OCSP runs in soft-fail mode and the responder had 40 minutes of downtime last month.
1. Can the CA extend intermediate B's validity? Explain what actually happens at expiry and which component fails first.
Read the worked answer
No. Validity dates are fields inside the signed tbsCertificate, so changing them means producing a new certificate, and anything chaining to Root A must be signed by Root A's private key. That key was destroyed with its HSM slot, so the CA cannot issue anything new terminating at Root A: not a renewed intermediate B, not a cross-certificate of Root C, not a fresh leaf under a Root A chain that outlives B.
At expiry, validation fails on every device at the same instant, because path validation requires each certificate in the chain to be inside its validity period at validation time. A leaf issued by intermediate B with a two-year validity is still invalid the moment B expires - renewing leaves buys nothing. Expiry is checked locally against the device clock and has nothing to do with OCSP, so soft-fail mode and the responder outage are irrelevant to this failure; they affect only revocation checking. Expect a few devices to fail earlier or later because of clock skew, which makes the first hour of diagnosis confusing.
Consequences: the 33,800 updatable gateways need firmware that trusts Root C, plus leaves issued from a Root C intermediate, all before the expiry date. The 6,200 fixed-bootloader units cannot be fixed cryptographically. They need field replacement or a documented per-customer workaround such as a local relay terminating TLS on their behalf. That relay also needs a certificate the device trusts, so check whether those bootloaders validate on every connection or only at install time; if only at install, a relay installed before expiry buys time at the cost of a device that verifies nothing afterwards, which must be a written risk decision.
2. Sequence the work for the next 21 days and explain what you would check before committing to any plan.
Read the worked answer
Day one, before anything else: confirm Root A's private key is genuinely unrecoverable. Ask about offline CA backups, HSM backup cards, a second site, and any copy used to sign B's original cross-certificate. If a usable copy exists the problem collapses, because Root C can be cross-signed under Root A, so this question is worth more than any other work in the first 48 hours.
Then, in order:
Inventory by firmware version and determine which trust anchors each build actually contains. Until you know whether it is 6,200 or 9,000 unpatchable units, every plan is guesswork.
Issue the new intermediate from Root C and start the CA and certificate-pipeline change. That is the longest critical path for the updatable fleet.
Ship firmware trusting both roots, serve the Root C chain, and keep the Root A chain alive until the last updatable device has moved.
Decide the 6,200 by cost: field service, customer-site relay, or contractual risk acceptance with each affected customer notified in writing before the expiry date rather than after.
Fix the monitoring. An OCSP responder that can be down for 40 minutes unnoticed means revocation events are invisible. Short-lived leaves are a stronger control than soft-fail OCSP here, because expiry is enforced locally whether or not the responder is up.
Do not plan around extending validity. There is no flag for it, and a vendor offering to extend an already-issued certificate is describing something else.
3. What certificate-pinning policy should the next firmware adopt, and what design mistake caused this situation?
Read the worked answer
The mistake was not pinning the root - that is the most stable level to pin. It was pinning exactly one anchor with no successor and no way to update the pin set except by firmware, which turns a routine rotation into a field emergency.
Three changes for the next firmware:
Pin a set, not a value. Ship at least two independent trust anchors, the current hierarchy and its successor, and allow the pin set to be updated by signed configuration as well as by firmware. Record each pin's rollover date in the release calendar, and treat a pin set with no successor as a code-review defect.
Pin at the right level. Pinning a leaf guarantees an outage at the next renewal. Pinning an intermediate is workable if a backup intermediate and a cross-signed path ship alongside it. Pinning the root SPKI is correct, provided there is more than one.
Build a recovery path. If the pin set can be replaced by a signed update over the management channel, a lost anchor becomes an operational incident rather than a truck roll. Where the bootloader truly cannot be updated, its pin set is the highest-value configuration in the product and deserves root-key treatment: two anchors from different CAs, documented custody, and an expiry plan for each.
Also ask what pinning is buying. It defends against a compromised public CA or a TLS-intercepting proxy. Certificate transparency monitoring plus a pinned set delivers most of that without a single point of failure, and it fails in a way operations can see before customers do.