PKI Certificate Services – Auto Key Archive

Hi everyone, i want to spend sometime explaining what is key archive in Microsoft Certificate Services.

When you issue a certificate, do you need to archive(backup) its private key ? The answer is : (Never) for signing certificates and (It Depends on your requirements) for encryption certificates.

For encryption certificates, suppose you are issuing an encryption certificate so your users can use EFS or S/MIME. What happen if they lost their certificate? Well, you will be the hero if you configured the certificate template to archive keys. This means that for every encryption certificate issued from the CA using this template, the CA will keep a copy of the private key.

So, when you create a certificate template, you will have an option to (archive) that certificate in the CA database.


The tricky thing, is that when an application request 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 is created. In other words, the private key of the certificate is created on the requester 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.

So when you enable key archival on the CA, 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 machine and not on the CA. Then the machine will send the public key so that the CA can sign it, and then will send the private key to the CA to archive it.

I will describe how this process works :


  • The 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.
  • The 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:
    1. 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.
    2. 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 for Key Archive :

  • 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.

2 comments on “PKI Certificate Services – Auto Key Archive

    • Well typically u use symmetric keys for encryption due to its small key soze and fast operations compared to PKI and u use pki for key exchange. However when the payload is small like requests or credit card numbers, the PKI can be used directly to do the enctyption

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s