PKI Standard Practices

This section outlines some of the PKI standard practices.

Offline Root CA

  • The root CA should never be connected to the network or to the domain and no fingerprint of the server should ever be recorded since the root key compromise will impact the entire PKI hierarchy.
  • Root CAs should always stay offline and shut down except when signing the Issuing CA certificates and during root CRL publish.
  • Access to the Root CA to sign the Issuing CA request should be initiated in an agreed and controlled workflow so as to not compromise the Root CA in any means.
  • Once the Issuing CA certificate has been issued and Root CRL published the Root CA should be turned off.
  • Ensure to publish a reasonably short-lived Root CA CRL, the recommendations from NIST is to have the Root CA CRL published for 1 year and ensure to renew the CRL before expiry.
  • We strongly recommend that all your CA keys be stored securely in a FIPS 140-2 Hardware Security Module (HSM).
  • Protect the server during boot using Bitlocker or any other encryption system of choice and ensure to backup CA private key, CA registry Key, the CA database, and the CA certificate.
  • Ensure to enable an audit event to track all actions performed on the Root CA.

Inline with Compliance

  • Ensure to have a CP and CPS created to suit the organization's needs and ensure the PKI infrastructure meets all standards and requirements with respect to the CP and CPS.
  • Any changes or addition of features ensure to capture in the CP and CPS documents.
  • Ensure to renew the CA certificates (root and subordinate) within half its lifecycle.
  • Enterprise key and certificate security policies should align with the latest regulatory, industry-standard recommendations, and guidelines such as key storage, secure communication protocols (TLSv1.2), cryptographic algorithms (RSA-2048), and hashing algorithms (SHA-2).
  • Enterprise security architects should constantly monitor security standard recommendations and periodically update the enterprise's security policy.
  • Ensure all security events are audited and a periodic security audit is performed to validate the security adherences and metrics.
  • Encourage short-lived certificates for all key usages.

CSR Generation Standardization

  • A process must be defined across the enterprise to generate CSR that aligns with the security standards and to store keys securely.
  • Harden parameters such as Country and Organization in accordance with organizational requirements.
  • Access to keys should be restricted to authorized personnel.
  • Key Generation, Certificate Request, and Approval processes should be well defined.
Archival

Signing keys do not require archival. We can always generate new keys for signing since the signed data is not encrypted. But encryption keys have to be archived so that the encrypted files during the certificate validity can be decrypted even after the certificate expiry. Also, this is recommended for security audits.

Secure Storage of Keys

  • It is recommended to store private keys in HSM.
  • Ensure respective certificate owners or certificate authorized administrators are granted access to private keys using the RBAC solution.
  • Best practices training can be provided to certificate users and administrators to keep private keys secure.

Compromised CA/CA keys

  • Ensure to discover a compromise as quickly as possible by implementing tracking and detection mechanisms and performing regular manual operational sanity checks.
  • Establish well-defined communications plans for informing subjects, relying parties, and other stakeholders with sufficient details about the type of compromise so these parties can implement the appropriate remedial actions.
  • If a CA system or signing key compromise occurs, the organization should perform the following steps:
    • Ensure that certificates issued to the organization’s systems or users from the compromised CA are revoked.
    • Notify all owners of the affected certificates about the CA compromise and establish a point of contact for responding to questions and providing guidance and instructions.
    • Replace all certificates from the compromised CA with new certificates from a different CA effective immediately.
    • Ensure that all relying parties have the certificate trust chains required to validate certificates from the new CA.
    • Ensure that revocation checking is enabled on all relying party systems.
    • If the compromised CA is a root CA, the root certificate must be removed from all trust stores and relying on party systems.
Compromised Certificate Handling
  • Ensure to respond in a timely manner in case of a CA or end-entity certificate compromise and have a plan or workflow to replace all affected certificates or the trust chain.
  • In the event of a key or certificate compromise, a fresh key pair should be generated on a secured system. The compromised item should be revoked and taken out of the service as soon as the systems are secured.
  • If you are not sure of your private key possession, report it to your CA and suspend the key immediately. Once you find the key is secure, reinstate the certificate.

CA Compromise and Remediation Matrix

Issue Type Revoke compromised/counterfeit certificates Revoke CA certificate Replace all certs issued Remove/ Revoke Root certificate
Impersonation Yes NA NA NA
RA compromise Yes NA NA NA
CA system compromise NA Yes Yes NA
CA key compromise NA Yes Yes NA
Root CA compromise NA NA Yes Yes