Unfortunately, there are a large number of PKI design aspects that, once configured, cannot be changed without a complete redeployment. Many of these aspects can also have a significant impact on the long-term usefulness of your PKI. And since PKI components are around for many years, the ramifications of decisions made during the design phase can be significant.
What Can and Can’t be Remediated
What can be done if a component of the PKI is compromised? Or if a change is needed to the CA? What is the net effect of that change? Is it something that can be mitigated or not?
If your PKI has been compromised, the most conservative approach is to consider that even a minor compromise puts the entire environment at risk, and because of that, the intended level of assurance is lost and a new PKI must be implemented. Certificates must be immediately replaced and issued from a new, uncompromised PKI. For some less critical use cases, an enterprise may opt to continue as is, tighten up some of the controls and monitor the PKI environment more closely to ensure the compromise doesn’t happen again, but this decision should be made on a case-by-case basis.
How Remediation Affects Certificates
Some things can’t be changed, such as CA names — most products forbid it. Signing algorithm and key length are two other certificate features that can’t be changed without revoking and re-issuing every certificate. While some minor changes can be made along the way, certain changes will have broad-reaching effects. For example, consider the location of your Certificate Revocation Lists (CRL). While you may decide to publish the CRL to a new location, existing certificates that have already been issued will not reflect that new location. If an application performs revocation checking and cannot find the CRL, or if the CRL is expired, revocation checking will fail, which can have significant consequences.
A best practice for many CAs is to issue certificates with a limited life span, say one or two years, depending on the use case. However, through bad practices, necessity, or lack of appropriate tools to manage the certificate lifecycle, organizations sometimes issue certificates with longer life spans. The challenge occurs when a widespread change to certificates is needed. Certificates with longer life spans cannot be updated until the current certificate expires. This is especially true with auto-enrollment certificates, where default settings may control certificate issuance to an old root that should no longer be trusted.
Preparing for a security audit is always challenging, often more so when trying to provide an audit trail for security tools like PKI that may have never been audited before, or that do not typically have dedicated monitoring and management. If an enterprise doesn’t have access to its complete inventory of certificates, it’s impossible to say with any level of certainty that every certificate is under the protection of the established PKI controls and is being employed for the intended use.
The Role of Policies and Practices
The Certificate Policy (CP) and Certification Practice Statement (CPS) are the guiding documents that outline how certificates and the PKI are managed, providing proof of the intended level of assurance to a relying party during a certificate handshake. Even privately rooted CAs, at a minimum, should have corresponding CP and CPS documents that correctly identify how an organization will use, consume, and manage certificates in the infrastructure around them.
Build a Security Level and Stick to it
Depending on the use case, an organization may plan for a PKI with low, medium or high assurance. The key is to maintain the original assurance level over time. Not maintaining this original level degrades the integrity of PKI and all applications that rely on it. Not only do you risk having to explain why the original level wasn’t maintained after a breach, but an auditor may perceive the downgrade as a failure to adhere to a specific standard.