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:
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 following practices are recommended when dealing with KRA certificates and keys: