Understanding Key Archival

  • Article

It came to my attention that there is little understanding regarding the relationship between archived private keys and Key Recovery Agent (KRA) certificates. With this blog post I would like to clarify what you can expect from the recovery mechanism and why.

Relationship between archived private keys and Key Recovery Agent certificates

Microsoft TechNet offers two operations whitepapers called Key Archival and Management in Windows Server 2003 and Active Directory Certificate Services Longhorn Beta3 Key Archival and Recovery which you should be familiar with before turning on key recovery.

Apparently, both papers are not 100 % clear about the effects of adding KRA certificates to the CA configuration. Step 9 of the key archival process explains that a private key is encrypted with the KRA’s public key before it is stored in the CA database. That’s a true statement but think about the effect when you have archived private keys in the CA database and you are adding a new KRA certificate to the list of key recovery agents at the CA.

At the time when the private keys have been archived, the public key of the newly added KRA certificate was not available to the CA. Therefore, you cannot recover private keys from the database with a KRA certificate which was not part of the CA configuration when a private keys were archived. This is a very important piece of information! You have to have a lifecycle strategy for your KRA certificates to ensure private key recovery at any time.

Imagine the scenario illustrated in the drawing below:

image

A certificate from KRA (a) is added to the CA configuration. From that point in time on, the CA has access to the KRA's public key. If an archival request comes in, the CA is able to encrypt the random symmetric encryption key (used to encrypt the end-entity private key) with the KRA’s public key. Due to the fact, that the certificate from KRA (b) is added to the CA configuration after the end-entity private key was archived, KRA (b) is not able to recover the end-entity private key. You may assume, that the CA is doing an implicit re-encryption of the already archived private keys when a new KRA certificate is added to the CA configuration but it’s not!

At this point you may ask for a solution for the problem. What should be done after adding a new KRA certificate to the CA configuration? If you are not comfortable with the default behavior, the only way is to export all archived private keys from the CA database and import them again. While importing the private keys, the CA is using the currently configured KRA certificates to encrypt the random symmetric encryption keys used to encrypt the private keys. I described this procedure in the Active Directory Certificate Services Upgrade and Migration Guide in section Exporting Archived Encryption Keys (Optional) . The procedure is a bit cumbersome especially because I did not investigate how to automate the getkey operation explained in step #10 for all exported certificates. May be with a Powershell script the entire export/re-import can be automated.

Even if the above approach is not the most comfortable way, you should be aware of the facts. I want to avoid any surprise where you cannot recover end entity certificates because of a misunderstanding of key archival.

KRA certificates and the CA configuration

It is a recommended practice configuring the KRA certificates before enabling key recovery. True statement, but what’s happening when a KRA certificate expires and must be renewed?

As the Active Directory Certificate Services Longhorn Beta3 Key Archival and Recovery whitepaper states in section Renewing Key Recovery Agent Certificates between the lines, a CA will not use an expired KRA certificate to encrypt new incoming private keys for archival. The CA administrator must ensure that the KRA certificates are valid while key recovery is enabled. Therefore it is highly recommended to watch out for event 127 ("Key recovery certificate %1 is about to expire soon and will not be used upon expiration. Contact your administrator to renew this certificate.  %2  %3") which warns about a soon expiry of a KRA certificate. The event was introduced with Windows Server 2008. If you are catching event 127, immediate action is recommended: To keep the number of KRA keys used for private key encryption at a low level, you should renew the expiring KRA certificate with the existing key. You would have two KRA certificates and on KRA key in this scenario. If you are renewing the KRA certificate with a new key instead, you must be aware that all newly arriving private keys are encrypted with this new KRA key. Thus you are maintaining two KRA certificates and two KRA keys for key recovery.

KRA certificate characteristics

Generally, the validity of a KRA certificate is verified whenever it is used to archive a private key while processing a request. The KRA certificate must meet the following requirements:

  • The KRA certificate’s Key Usage extension must have either CERT_KEY_ENCIPHERMENT_KEY_USAGE or CERT_KEY_AGREEMENT_KEY_USAGE set.
  • The KRA certificate must chain to any trusted root, and the chain must be valid for szOID_KP_KEY_RECOVERY_AGENT. Note, while it is the default configuration that a KRA certificate is issued by the CA that is also configured for key archival, there is no technical dependency between the KRA certificate and the archiving CA. A Windows CA can be configured to use any trusted and valid KRA certificate.
  • None of the certificates in the KRA certificate chain is be revoked.

Summary

The following practices are recommended when dealing with KRA certificates and keys:

  • define the number of KRA certificates before enabling key recovery and do not add or remove KRA certificates randomly at a later time
  • use longer certificate validity times for KRA certificates to keep the number of renewals at a low level
  • renew KRA certificates before they expire with an existing key
  • watch out for event 127 in the event log. The event was introduced with Windows Server 2008.
  • think about the key storage for KRA keys. User profiles can be lost. If the only copy of a KRA key is stored in a user profile, you may loose the capability to recover private keys