The Ten-Year Root and the Unrecoverable Revocation Path
A retailer operates an internal two-tier PKI. The offline root CA has a 20-year self-signed certificate using RSA-2048 with SHA-1; it has issued one subordinate CA with a 10-year certificate. The subordinate issues TLS server certificates to 1,800 store appliances and point-of-sale devices. An auditor finds: the root private key is in an HSM, but a backup copy sits on a domain file share; the subordinate key is on a domain-joined Windows server; the OCSP responder was decommissioned last year; CRLs are published every 90 days; and no key-ceremony records exist for either CA. A junior administrator who had subordinate access left the company. Many appliances cannot be updated and expect certificates valid for at least five years. The PCI assessment is in 60 days. What are the priorities?
1. Rank the findings by risk and justify the ranking for this PKI.
Read the worked answer
Highest: root private-key backup on a file share
An offline root is the trust anchor for all 1,800 devices. A copy on a domain share is reachable by domain administrators and malware. If used, an attacker can mint a subordinate CA or issue device certificates that every appliance trusts; revocation cannot repair a compromised root without replacing the trust anchor. This outranks the SHA-1 signature because it is an immediate key-compromise path.
Second: subordinate key on a domain-joined server
Domain compromise becomes CA compromise. The subordinate can issue TLS certificates for any internal name, and the missing ceremony records mean you cannot prove the key was not copied. The departed administrator raises the same concern.
Third: revocation latency
OCSP is gone and CRLs are 90 days old, so a stolen POS certificate can remain valid for up to three months. That is serious for payment devices but is a detection/response gap, not a direct trust-anchor compromise.
Fourth: SHA-1 and long device validity
SHA-1 on the root-to-subordinate signature is a weakness, but practical collision attacks require more than a passive attacker. Five-year device certificates reduce agility and should be shortened where firmware allows.
Prioritize containment of the root backup, then re-key the subordinate, then fix revocation.
2. Design a revocation and validation approach that works for the store appliances and POS devices within the 60-day PCI window.
Read the worked answer
Constraints
Many appliances cannot be updated and may not support OCSP. A 90-day CRL is too slow for POS. You need a design that degrades safely without breaking checkout.
Recommended approach
- Stand up two OCSP responders behind a load balancer, with one in a separate administrative zone. Enable OCSP stapling at the TLS terminator so devices do not need direct internet or OCSP access.
- Publish a full CRL every 24 hours and delta CRLs every 4 hours; retain the 90-day CRL only as a fallback for devices that cannot parse delta CRLs.
- For devices that cannot check revocation at all, shorten certificate lifetimes to 90 days where firmware supports automated enrollment; where it does not, place those devices on a segregated VLAN with strict allowlisting and treat the residual risk as an exception with a dated migration plan.
- Revoke the departed administrator's certificates and any subordinate-issued certificates not accounted for in an inventory. Do not revoke the subordinate itself unless compromise is confirmed; that would break all devices at once.
PCI framing
Document the exception, the compensating network controls, and the 60-day evidence. A failed OCSP responder must not cause checkout outage, so configure soft-fail only on the legacy VLAN and hard-fail elsewhere.
3. Outline a migration to a SHA-256 root and subordinate that does not strand the embedded devices.
Read the worked answer
Design
Build a new offline root with RSA-3072/SHA-256 or ECDSA P-384/SHA-256 in an HSM, with a documented ceremony, split knowledge, and tamper-evident backups. Issue a new subordinate with a shorter lifetime, for example five years, and a policy that device certificates do not exceed two years where automation exists.
Transition without stranding devices
- Cross-certify the new root with the old root, or distribute the new root as a trusted anchor through the device-management channel before issuing new device certificates. Cross-certification preserves trust for devices that still trust only the old root.
- Run both roots in parallel. New enrollments go to the new subordinate; legacy devices keep old certificates until replacement or firmware update.
- For devices that cannot accept a new trust anchor, keep a dedicated legacy hierarchy reachable only from the segregated POS VLAN, with compensating controls and a hard end date. Do not let that hierarchy issue certificates for general internal services.
- Retire the old subordinate only after inventory shows no unexpired dependencies; then retire the old root after the longest device certificate plus CRL/OCSP overlap expires.
Sequencing
Contain the exposed root backup first. If root compromise is suspected, accelerate the cross-certified rollover and treat the old root as untrusted for new issuance immediately.