In this blog post, I will be talking about Microsoft certification authority auto key archival, and explain in details how this is accomplished. Archive encryption keys is one of the most tasks to perform against digital certificates used for encryption.

Let me start by talking about basics before digging into the details. When Microsoft certification authority server issues a certificate, it will maintain the public key of the certificate in its database. The private key of that public key, usually is not kept or stored in the CA database.

Well, a client will usually construct a private and public key, and will then send only the public key to be signed by the CA private key to construct a digital certificate. In this flow, the private key is never transmitted at constructed at the CA server.

Saying that, Microsoft CA server only has records of all digital certificates and their public keys. So why to do we need the CA server to archive the private key also?

When you enroll for a digital certificate, it can be used for signing or encryption purposes. Signing certificates do not need to be archived or preserved, as you can always can replace the signing certificate with a new one, without losing anything.

Digital certificates used for encryption purposes, are the type we are focusing on. If you encrypt a file, and you lose the private key, then you lost the file forever. You cannot just replace the digital certificate used for encryption with a new one. Saying that, you should always archive or have a backup of all your encryption certificates. This is why, Microsoft certificate authority has an option to archive and preserve the private key for issued certificate.

But since the private key of any new digital certificate is never sent to the certification authority, there should be away to govern the whole private key archival. This blog post is written it help you understand how Microsoft certificate authority can be used to archive private keys, specifically those used for encryption. Once archived, you can later on export the private key from the CA database anytime, and send it to the user, in case he lost the private key and want to recover encrypted content. Let us move on and see how to archive encryption keys.

Archive encryption keys

To archive encryption keys, a lot of work need to be done to facilitate secure transmission of private key from client to the CA, and also to securely store the private key on the CA database itself. You can configure whether you want a specific type of certificates to have their private keys archived at the CA, by configuring the certificate template to archive private keys.


archive encryption keys

The tricky thing when considering how to archive encryption keys, is that when an application requests a certificate, the machine from which the certificate request is requested, is the same machine from which the private and public keys of the certificate are created. In other words, the private key of the certificate is created on the requester’s machine and not on the CA. What will happen next is that the machine will send the public key to the CA, so that the CA will sign the public key. The private key will never leave the requester machine.

To archive encryption keys, a new way for issuing private keys and public keys will be followed. Even then, the private and public keys are created on the requester’s machine and not on the CA. Then the machine will send the public key so that the CA can sign it. The new thing is that the private key will be sent to the CA for archiving purposes.


archive encryption keys

  • CA configured for Key Archival will issue a special short lived certificate named CA Exchange Certificate. The CA exchange certificate is issued by the CA itself where the subject and issuer are almost the same. However, the subject contains a suffix to distinguish the certificate from a root CA.
  • Client makes an authenticated distributed component Object Model DCOM connection to the CA and requests the CA’s Exchange certificate (encryption certificate).
  • The CA sends the CA Exchange certificate to the client computer.
  • The client performs the following tests on the CA Exchange certificate:
    • Verifies that the CA Exchange certificate is signed by the CA’s signing certificate. This ensures that the private key is being sent to the correct CA and only the intended CA can decrypt the private key.
    • Performs a certificate validation and revocation status check on the CA Exchange certificate.
  • The client encrypts the private key corresponding to the request with the CA exchange certificate public key, builds a CMC request, and sends a CMC full PKI request to the CA (the request contains both the private and public key of the user). After the CMC request is ready and encrypted with the CA Exchange certificate, the user sign the request with his public key. The CA validates that the encrypted private key is the matched key to the public key in the CMC request. To do this, the CA encrypts randomly generated data with the public key in the request, and then decrypts the data with the private key passed in the unauthenticated attributes of the CMC request. The decrypted data is verified against the original random data. If any of the validation steps fail, or if the data does not match, the request is rejected
  • The CA validates the signature on the request with the public key in the request to ensure that the contents of the request are not modified.
  • The CA encrypts the user request’s private key with a random 3DES symmetric key and then encrypts the symmetric key with one or more Key Recovery Agent certificate public keys defined in the CA’s properties.
  • The CA saves the encrypted key BLOB—which contains the encrypted private key and the symmetric key encrypted with one or more Key Recovery Agent certificate’s public keys—to the CA database.
  • The CA processes the certificate request normally and responds to the client with a CMC full PKI response containing the certificate issued to the requester.

Requirement to archive encryption keys

  • One or more users must acquire a certificate with the Key Recovery Agent application policy or the Enhanced Key Usage (EKU) object identifier (OID). This certificate allows the private key holder to decrypt private key material stored in the CA database. By default, the Key Recovery Agent certificate template requires certificate manager approval for issuance to ensure that only authorized personnel receive the Key Recovery Agent certificate.
  • The CA must be configured and enabled for key archival. In the CA’s properties, you must designate one or more Key Recovery Agent certificates that the CA must use to encrypt the private keys archived in the CA database. If at least one Key Recovery Agent certificate is designated, key archival is enabled at the CA (once Certificate Services is restarted). 

Important   All designated Key Recovery Agent certificates must be valid. If any of the Key Recovery Agent certificates are revoked, or fail any certificate validation test, key archival is not possible at the CA and certificate requests that require key archival will fail. 

  • A certificate template is enabled for key archival.

Final Thoughts

I hope by now you know how and why to archive encryption keys. Doing so will give you assurance that you can recover any encrypted content in your enterprise. There is nothing worse than locking your self and not able to recover an encrypted content because the encryption certificate is lost or cannot be located. Think of a stolen smart card that you should replace and put the private key again on it, so that the holder can decrypt previously encrypted content.