Intermediate CA Incident Response: Scope Trust Before Rotating

An intermediate certificate authority can issue certificates that chain to a trusted root within its permitted constraints. A suspected key compromise is therefore a trust-graph incident, not a normal leaf-certificate renewal. Responders must determine what the intermediate could sign, where its chain is trusted, and how revocation will reach relying parties.

The practical model

Treat intermediate ca incident response: scope trust before rotating as a system with four review points: preserve facts and stop issuance, map the blast radius, prepare replacement and revocation, validate every relying path. Give each point an owner, a measurable acceptance condition, and a rollback trigger. Thresholds should come from observed workloads, contracts, or risk tolerance rather than an unexplained default.

Preserve facts and stop issuance

Record certificate fingerprints, serial number, issuer, validity, name constraints, policy identifiers, key-usage extensions, publication points, HSM audit data, and issuance logs. Disable the affected signing path without destroying evidence. Confirm whether the private key could be extracted or only misused through an authorized interface.

Map the blast radius

Inventory every unexpired certificate issued by the intermediate, including TLS, code signing, client authentication, document signing, or private PKI uses. Determine which roots and trust stores accept each chain. Name constraints and extended key usage can reduce scope, but only if relying-party implementations enforce them correctly.

Prepare replacement and revocation

Create replacement hierarchy material in a clean ceremony, validate HSM controls, and reissue legitimate leaf certificates. Coordinate certificate revocation list and OCSP updates, trust-store communications, timestamp implications, and application pinning. Do not revoke first if doing so would strand critical systems without a tested replacement path.

Validate every relying path

Test browsers, operating systems, Java stores, appliances, mobile apps, mTLS clients, build systems, and offline validators. Monitor for new certificates chaining to the affected intermediate and for clients still presenting old chains. Keep an evidence-backed timeline and publish facts without exposing keys or exploitable internal details.

Common pitfalls

• Rotating only the public certificate while retaining a suspect private key.

• Assuming one browser’s behavior represents all validators.

• Forgetting code-signing timestamps and offline devices.

• Deleting issuance logs before establishing the complete certificate set.

A focused test plan

1. Preserve facts and stop issuance: verify that record certificate fingerprints, serial number, issuer, validity, name constraints, policy identifiers, key-usage extensions, publication points, HSM audit data, and issuance logs. Then introduce the failure case “rotating only the public certificate while retaining a suspect private key” and confirm that the system fails visibly, stays within its safety boundary, and has a documented recovery action.

1. Map the blast radius: verify that inventory every unexpired certificate issued by the intermediate, including TLS, code signing, client authentication, document signing, or private PKI uses. Then introduce the failure case “assuming one browser’s behavior represents all validators” and confirm that the system fails visibly, stays within its safety boundary, and has a documented recovery action.

1. Prepare replacement and revocation: verify that create replacement hierarchy material in a clean ceremony, validate HSM controls, and reissue legitimate leaf certificates. Then introduce the failure case “forgetting code-signing timestamps and offline devices” and confirm that the system fails visibly, stays within its safety boundary, and has a documented recovery action.

1. Validate every relying path: verify that test browsers, operating systems, Java stores, appliances, mobile apps, mTLS clients, build systems, and offline validators. Then introduce the failure case “deleting issuance logs before establishing the complete certificate set” and confirm that the system fails visibly, stays within its safety boundary, and has a documented recovery action.

Primary references

• Internet PKI certificate profile, RFC 5280

Conclusion

CA incidents require careful containment because trust is distributed. Stop signing, map every accepted path, build a clean replacement, revoke with ecosystem coordination, and verify that old trust actually disappears.