Active Directory Certificate Services: PKI - Key Archival and Management

Applies to

• Windows Server 2003,
• Windows Server 2003 R2,
• Windows Server 2008,
• Windows Server 2008 R2,
• and Windows Server 2012.

This article describes best practices and provides procedures for key archival and recovery operations with certification authorities (CAs) in Active Directory® Certificate Services (AD CS) in Windows Server® operating systems.

Active Directory Certificate Services (AD CS) in Windows Server 2003 Enterprise operating system introduced significant advancements for data protection, and private key archival and recovery. Starting with the Windows Server 2008 Enterprise operating system new capabilities and advancements were added, including advanced cryptography support so that data protection and key archival operations can be performed using the latest cryptographic algorithms and longer key lengths.

Encrypting File System (EFS) supports the use of Data Recovery Agents (DRAs) to decrypt files that have been encrypted by other users. Introduced with Windows Server 2003, AD CS includes key archival and recovery capabilities. With both data recovery and key recovery available as options, organizations can deploy the recovery technology that best meets their business requirements.

AD CS key archival can be performed either manually or automatically. Manual key archival requires users to export private keys and send them to a CA Administrator who imports them to the protected CA database. Automatic key archival is performed during the certificate enrollment process when a certificate template is configured to require key archival. During the certificate enrollment process, the private key is securely sent to the CA as part of the certificate request and is archived by the CA. For more information about manual key archival, see Understanding Manual Key Archival later in this article.

return to top

Key archival and recovery

Overview / Survival Guide

An overview/survival guide topic provides a guided view of a technology, solution or technology-related concept or activity through links to internal (TechNet Wiki) and external Microsoft and community information. For example, an overview of hyper-v for beginners or SQL Server pivot table survival guide. Typically, this type of topic will grow over time as other users contribute useful links and descriptions so it is okay to start with a short topic!

Begin with a description of the problem using general terms and broad concepts. This will provide context for the solutions that follow as well as set expectations for the reader. In separate sections, provide scoped guidance using appropriate headers by media type (videos, documents, white papers, blogs), task (plan, design, develop, deploy, maintain), feature (join, insert, delete, update, select), etc.

Media Type/Task/Feature 1

Describe the media type, task or feature. Media type requires less description, other classifications may require more.

• First Link. Brief description of how reference is useful.
• …

Repeat as needed.

References

Increase the credibility of the article by including useful references. This includes references used for the solution as well as relevant links to the TechNet Library, your blog, and other sites in community.

• First Reference. Brief description of how reference is useful.
• ...

Don't forget to tag the article with appropriate keywords so other users can find and learn from your experiences!

Key recovery requires that a certificate's private key must be archived. Key recovery does not recover encrypted data or messages, but does enable a user or administrator to recover keys that can subsequently be used for data recovery, that is, data decryption.

The following steps are an example of a key archival and recovery scenario.

1. A user submits a certificate request to an enterprise CA with a copy of the private key included in the certificate request. The CA encrypts and archives the certificate's private key in the CA database and issues the certificate to the user.
2. The certificate is used to encrypt data files; for example, by using EFS.
3. Because the certificate's private key is required to decrypt files that have been encrypted with the certificate, corruption of the key or loss of access to the key results in loss of the decrypted data. Under these circumstances a Certificate Manager can retrieve the archived private key from the CA database and, with assistance from a key recovery agent, can decrypt the private key to perform data recovery procedures or securely provide the key to the user.
4. The recovered private key can be imported to a user's local keys store to restore access to the key and encrypted files.

return to top

EFS data recovery

During the encryption process, EFS generates a random symmetric encryption key for each file that it encrypts. This symmetric encryption key is referred to as a file encryption key (FEK) and is used for both encryption and decryption of the data in a file. After the data in the file is encrypted, the FEK is encrypted using the public keys associated with each account that is included in the file's access control list (ACL). All of the encrypted FEKs are stored in the encrypted file with the encrypted data. In this way, any of the accounts with access to the file can also decrypt the file by using their private key to decrypt the FEK.

Because an encrypted file can be decrypted only by using a private key that can decrypt the file's FEK, encryption of a file creates a risk of data loss if the owner's access to their private key is lost; for example, in the case of data corruption, a lost or stolen smart card, or when the owner of the private key leaves the organization without providing access to the key. An organization can mitigate the risk of data loss by using data recovery agents and creating a data recovery policy to define secure data recovery procedures. The data recovery agents' public keys, along with the file owner's public key, are used to encrypt the file's FEK. This ensures that, in addition to the file owner, there is also another individual that can decrypt the file's data. Because of the security implications of having data recovery agents, it is important to define secure processes and procedures for data recovery.

For more information about data recovery, see Data Recovery and Encrypting File System (EFS) (http://go.microsoft.com/fwlink/?LinkID=153668).

return to top

Choosing between data recovery and key recovery

Whether an organization chooses data recovery or key recovery depends on the organization's requirements and policies. Each technology can be implemented independently or they can be used together. For example, some organizations may have policies that restrict access to a private key to only the owner of the key. Key recovery would not be consistent with this policy. Likewise, some organizations may have policies restricting access to data to only the individual that originated the data. Neither key recovery nor data recovery is consistent with such a policy.

Some key considerations are:

• Key recovery
  • Requires access to private keys by individuals other than the key owner.
  • Some private keys can be used for digital signatures, which could enable impersonation of the private key's owner.
  • Private keys can be recovered regardless of which applications use the keys.
  • Key recovery also enables EFS data recovery.
• Data recovery
  • Requires access to encrypted data by individuals other than the data owners.
  • Supported by EFS but not by all encryption systems.

Security Note
A private key that is known or suspected to be compromised should be revoked as soon as possible. Data encrypted with the compromised key should be recovered by using the revoked key and encrypted with a new key.

For more information about the differences between key recovery and data recovery, see Key Recovery vs Data Recovery Differences. 

return to top

System requirements for automated key archival and recovery

• Active Directory® Domain Services (AD DS) domain with at least Windows Server 2003 schema extensions.

• Enterprise CA running on one of the following operating systems:

  • Windows Server 2003 Enterprise Edition or Windows Server 2003 Datacenter Edition
  • Windows Server 2008 Enterprise or Windows Server 2008 Datacenter
  • All editions of Windows Server 2008 R2
  • All editions of Windows Server 2012

• Version 2 or version 3 certificate templates.

• Enrollment can be performed on any of the following operating systems:

  • Windows 2000 and Windows Millennium Edition - Enrollment with key archival in Windows 2000 and Windows Millennium Edition can be performed only by using CA Web enrollment pages and the private key must be marked as exportable during enrollment.
  • Windows XP
  • Windows Vista
  • Windows 7
  • Windows 8
  • Windows Server 2003
  • Windows Server 2003 R2
  • Windows Server 2008
  • Windows Server 2008 R2
  • Windows Server 2012

return to top

Key Recovery Best Practices

Best practices should be followed when implementing key archival and recovery in an organization. First, key recovery by an administrator implies impersonation. In other words, the act of recovering an archived private key enables the person performing the recovery (in most cases, an administrator) to access and potentially to use the private key of another individual. Because of this potential, administrators who perform key recovery should be highly trusted. Implementation and operation of a key archival and recovery solution should be carefully planned and monitored for security purposes.

return to top

Protecting Key Recovery Agent Keys

How KRA keys are protected comes down to a balance between security versus ease of administration and management. KRA private keys are critical to key recovery and should be both protected from compromise and guarded against loss or misplacement.  

For smaller organizations that have not implemented role separation between CA administrators and KRAs, it is recommended to implement three to five KRA Certificates and to store them in a central place, either on dedicated hardware or smart cards.

For larger organizations that have implemented a KRA role, ensure that there is a process for tracking and renewing KRA certificates.

return to top

Renewing Key Recovery Agent Certificates

The default lifetime of a KRA certificate is two years. When a KRA certificate expires, the keys must be preserved to maintain recoverability of content that was encrypted using keys currently protected with this KRA certificate. However, the certificate must be renewed, or a new certificate enrolled, to preserve automatic key recovery functionality. The certificate can be renewed with the same keys, renewed with new keys, or new KRA certificates can be enrolled. If a KRA certificate and its private key are known not to have been compromised, it may be a good choice to renew with the same key. This means the number of KRA keys the organization must keep track of remains at a minimum. If a key has not been compromised, it can still be used for a number of years, depending on the strength of the cryptographic algorithm used.

return to top

Auditing Key Recovery

Since the act of retrieving an encryption key and using a KRA certificate to decrypt it is highly sensitive, consider enabling auditing of these events. This can be done in the Certification Authority Microsoft Management Console (MMC) by right-clicking the CA node, choosing Properties, clicking the Auditing tab, and selecting “Store and retrieve archived keys”. Once this setting is enabled, an event will appear in the Security log for each key archival and/or recovery action.

return to top

Other Best Practices

1. If a key is known to be compromised, it should be revoked immediately and never used again.
2. Keys or certificates that are used to secure high-value transactions or are identified as high-value certificates should not be recovered except under extreme circumstances.
3. Private keys that are used for signing should never be archived or recovered because the potential for more than one person to possess and use a private key introduces non-repudiation issues.
4. When a key has been compromised or lost, it should be revoked before allowing key recovery. Despite key compromise, it may be necessary to recover a key for the purpose of decrypting old data and encrypting with a new key.
5. Issue the least number of certificates and key pairs possible to ease key management and reduce user confusion.
6. Issue encryption certificates with longer lifetimes than signing certificates.
7. Issue only one valid key pair for a given application purpose at one time.
8. Develop a recovery process that includes role separation of Certificate Managers and KRAs.
9. Minimize the number of CAs that archive keys for a certificate purpose, that is, if possible, do not archive keys for users across a large number of CAs because this can make recovery operations confusing.
10. If performing key archival over the Certification Services Web enrollment pages, it is important to use Secure Sockets Layer (SSL) on the enrollment Web site to protect the enrollment traffic from tampering or malicious interception.
11. Use roaming user profiles or certificate roaming, if possible, to reduce user confusion, accidental key loss, and the need for manual import and export operations to enable key roaming.

return to top

Understanding Manual Key Archival

Manual key archival is supported in Active Directory Certificate Services as a separate operation from enrollment while still offering centralized key archival. Users may export their private keys into *.pfx files [Public Key Certificate Standard (PKCS) #12 format] or through Outlook into the *.epf format. The following section describes the procedure to export private keys manually from a Windows client so that they may be manually archived on the CA. This is especially useful for users who have enrolled with third-party CAs that do not support key archival.

Exporting Keys and Certificates

Keys and certificates may be exported to Windows clients by one of three methods.

• PKCS #12 (*.pfx file) export from the Certificates MMC snap-in on Windows 2000, Windows XP, Windows Server 2003, Windows Vista, or Windows Server 2008, Windows Server 2008 R2, Windows Server 2012.
• PKCS #12 (*.pfx file) export from the Outlook 2003 or 2007 client.
• *.epf file format from the Outlook 2000 or Outlook 2002 client.

If a user has enrolled for Exchange Advanced Security with version 1 certificates (first offered with Exchange 5.0 Key Management Server), direct export from Outlook into the *.epf file format will be necessary. X.509 version 1 certificates and keys may not be exported into PKCS #12 format on the Windows client.

If only X.509 version 3 certificates have been used, the PKCS #12 format may be used.

return to top

Exporting Keys from the MMC

To export the certificate and private key while logged on as the user

1. Click the Start button, and then click Run.
2. Type mmc.exe, and then press Enter. An empty MMC shell appears.
3. Select the Console File menu, and then select Add/Remove Snap-in.A dialog box appears with a list of all the snap-ins that have been added to this MMC shell. (For Windows XP users only) Click Add.
4. A list appears with all the registered snap-ins on the current machine. (starting in Windows Vista, the list appears without clicking Add).
5. Click the Certificates snap-in and click Add, choose My User Account, and then click Finish. (For Windows XP users only) In the Add/Remove Snap-in dialog box, click Close.
6. In the Add/Remove Snap-in dialog box, click OK.
7. The MMC now contains the personal certificate store for the currently logged-on user.
8. Expand the tree view of the certificate store. Click Certificates - Current User, Personal, and then Certificates. When you click the Certificates folder on the left, the right-hand pane will display a list of all the certificates for the currently logged-on user.
9. Right-click the certificate intended for export.
10. Click All Tasks, and then click Export on the context menu. A wizard will guide you through the export process.
11. Click Yes, export the private key, and then click Next.
12. When exporting a private key, the *.pfx file format is used. The *.pfx file format is based on the PKCS #12, which is used to specify a portable format for storing or transporting a user's private keys, certificates, and miscellaneous secrets.
13. Select the appropriate check boxes, and then click Next. As a best practice, strong private key protection should also be used as an extra level of security on the private key when exporting. The private key should be deleted only if you are performing archival and will no longer use the key on that machine.
14. The *.pfx file format (PKCS #12) allows a password to protect the private key stored in the file. Choose a strong password, and then click Next.
15. The last step is to save the actual *.pfx file. The certificate and private key can be exported to any writeable device, including a network drive or disk. After typing or browsing for a file name and path, click Next.

Once the *.pfx file and private key have been exported, the file should be secured on a stable media and transferred in a secure manner to the CA on which the key will be imported in accordance with the organization’s security guidelines and practices.

return to top

Import a Key Manually on a CA

To import a key manually on a CA, on the CA server, open a command prompt window, and run the following command.

C:\CertUtil.exe –f –importKMS <name of file>

Note: The –f flag is required when the key and certificate pair have not been issued from the CA in question.

The file may be in one of three formats.

• KMS export file
• PKCS #12 format (*.pfx file)
• Outlook export format (*.epf)

The previous command will work only after the CA was configured for key archival. For more information about the actions required for enabling key archival, see Implementing Key Archival Walkthrough.

return to top

Understanding Automatic Key Archival

The following sections document in detail how the key archival and key recovery processes work in Windows Server 2003 and later versions of Certificate Services, as well as step-by-step guides for implementing the features in production.

return to top

Understanding the Archival Process

The general steps in the process of certificate enrollment with automatic archival of a user’s private key are described in the following steps and in Figure 5.

1. The client finds CAs in Active Directory Domain Services (AD DS) enrollment services container in the Configuration partition.

2. The client makes an authenticated Distributed Component Object Model (DCOM) connection to the CA and requests the CA’s Exchange certificate (encryption certificate).

3. The CA sends the exchange certificate to the client.

4. The client validates that the CA’s exchange certificate has been signed by the same key as the CA signing certificate and performs a revocation status check. This ensures that only the intended CA may decrypt the certificate request containing the private key.

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

6. The CA validates that the encrypted private key cryptographically pairs with the public key in the certificate request.

7. The CA validates the signature on the request with the public key in the request.

8. The CA encrypts the private key from the user request with a random Triple Data Encryption Standard (3DES) or Advanced Encryption Standard (AES) symmetric key and then encrypts the symmetric key with one or more KRA public keys. AES will be used for the symmetric key only if a Windows Server 2008 CA has been configured to use a CNG key provider that supports AES and the correct registry settings have been configured by entering the following commands at the command line on the CA.

   • certutil -setreg CA\EncryptionCSP\CNGEncryptionAlgorithm AES
   • certutil -setreg CA\EncryptionCSP\SymmetricKeySize 256
   • Note: that other AES key lengths supported on Windows Server 2008 are 128 and 192.
   • Note: that if the CA is configured to use the AES symmetric key algorithm, ensure that all computers on which key recovery will be performed by the KRAs also support AES.

9. The CA saves the encrypted key binary large object (BLOB) containing the encrypted private key and the symmetric key encrypted with one or more KRA public keys to the CA database.

10. The CA processes the certificate request normally.

11. The CA responds to the client with a CMC full PKI response.

    • Note: Signature only keys will not be archived by default.
    • Note: Denied and resubmitted requests will also not archive private keys.

return to top

Certificate Request

A certificate request can be driven from at least three different sources in Windows Server 2003 and Windows Server 2008. The sources built into the operating system are the Web browser (Microsoft Windows Internet Explorer®), the certificate enrollment wizard, and auto-enrollment. One of the formats the certificate request uses is the CMC format for certificate requests, which supports an optional encrypted data payload. This is the format required for certificate requests with private key archival. Technically, any client that supports the CMC protocol may enroll with an Enterprise CA and request that the private key be archived by the CA. The CA enforces the archival option through a template flag. For more information about the CMC request format, see Appendix A: Certificate Request Structure.

return to top

CA Exchange Certificate Retrieval

Before the private key can be encrypted and delivered to the CA server, the client must first retrieve the CA’s exchange certificate. The CA exchange certificate is an encryption certificate for the CA that can be used by clients to encrypt their private keys as part of their certificate request. The CA exchange certificate is issued by the CA itself, with a subject name set to the CA name plus a suffix to distinguish the certificate from a root CA certificate. The client will verify that the exchange certificate is signed by the same key that issued the CA certificate; this step is performed to provide additional security and to prevent man-in-the-middle attacks. For that reason, a CA may not use a certificate issued by another CA for an exchange certificate.

return to top

CA Exchange Certificate Generation

A Windows Server 2003 or Windows Server 2008 CA will automatically generate a short-lived exchange certificate for key archival usage. Starting with Windows Server 2008, the administrator will be able to specify a CNG provider and an advanced cryptographic algorithm to generate CA Exchange certificates. The provider name and key length are set by configuring the following registry keys, the same two keys used to specify key exchange certificate provider name and key length in Windows Server 2003 CAs.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\CA Name}\EncryptionCSP\Provider and

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\CA Name}\EncryptionCSP\KeySize

Further, in Windows Server 2008, two new registry settings are introduced to configure a provider type (CNG or Cryptography API) and the CNG algorithm name.  

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\CA Name}\EncryptionCSP\ProviderType, (set to 0 for a CAPI CSP and 1 for a CNG provider) and

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\CA Name}\EncryptionCSP\EncryptionAlgorithm

By default, if the CA Exchange template is available, it will be used for extensions and the validity and overlap periods, but not for the Cryptographic Service Provider (CSP) information specified in the previous registry settings. If the validity and overlap periods specified in the registry differ from the template, the registry values are rewritten, so there will be consistent behavior if the template is unavailable in the future. If the template is not available, hard-coded extensions will be used along with the registry validity and overlap period settings.

If the following registry flag is configured using certutil.exe, the template must be available or the attempt to generate a CA Exchange certificate will fail. In addition, the machine object of the CA (LOCAL SYSTEM) must have Enroll access to the template. This flag is not currently set during setup; it must be manually applied.

certutil -setreg ca\CRLFlags +CRLF_USE_XCHG_CERT_TEMPLATE

The CA Exchange certificate template has a default expiration of one week and a template overlap period of one day. Note that the previous settings apply to both Enterprise CAs and stand-alone CAs.

return to top

Restricting Key Archival

Certificate Services may be effectively prevented from archiving private keys through the use of qualified subordination and policy constraints. When submitting and processing a request to a parent or root CA for a subordinate CA certificate, the parent CA may exclude the key archival policy in the subordinate CA. For more information about Qualified Subordination, see Qualified Subordination Overview.

return to top

Private Key Payload

The encrypted private key is stored in an unauthenticated attribute as a CMS EnvelopedData object. This poses no concern from a security perspective as the private key is later validated to cryptographically match the public key in the certificate request, which is also signed by the same private key. For more information about the format and object structure, see Appendix A: Certificate Request Structure.

Note that in Windows Server 2008, the symmetric key used by the client can also be specified in the Certificate Templates MMC on the Request Handling tab. If “Use advanced Symmetric algorithm to send the key to the CA” is checked, the client will use the AES algorithm.  Note that you will have to ensure any CA’s that process requests based on templates with this checkbox enabled support the AES algorithm.

return to top

Key Verification

The CA must check that the encrypted private key is cryptographically associated with the public key in the certificate request. Because the client encrypted the private key using the public key from the CA’s exchange certificate, the CA can decrypt the private key payload contained in the request. For encryption keys, 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. For signing keys, the CA will reject the request and will not archive a key that is marked for signature only.

To verify the cryptographic association between the public and private keys, the CA loads the key pair into a CSP that supports the specified algorithms. A Windows Server 2003 CA will use the default-enhanced RSA CSP on the CA by default or a hardware CSP, if available. Both the encrypted private key material payload and the private key loaded into the server-based CSP are securely discarded since the private key will be archived using a different key controlled by a recovery agent and is not available for the CA after verification of the payload. The decrypted private key memory is cleared prior to freeing the memory.

 

Note that the Windows Vista and Windows Server 2008 operating systems introduce a new security capability called process isolation, which means that the private key material never exists in user memory space.

return to top

Key Encryption

Once the private key has been successfully verified, the CA must then encrypt the private key and archive it for future recovery. To provide separation between the recovery agent role and the CA administrator role, the certificate request process and certificate issuance are completed after key archival has occurred. For more information about role separation, see Configuring the CA to Allow Key Archival.

The CA will not use its own key to encrypt the private key. Instead, it will use a dynamically generated symmetric key. This symmetric key will be encrypted using a public key from a KRA certificate (or certificates) configured on the CA. Each certificate request and private key archival operation will generate a new random 3DES or AES symmetric key using the same provider that was used to generate the CA signing key. This ensures that a hardware security module (HSM) can be used to generate the long-term keys that protect the individual private keys. In a Windows Server 2003 CA, the symmetric key algorithm is 3DES by default and cannot be changed. In Windows Server 2008, the algorithm and key length can be specified using registry settings.

AES will be used for the symmetric key only if a Windows Server 2008 CA has been configured to use a CNG key provider that supports AES. Also, the correct registry settings must be configured by entering the following commands at the command line on the CA (see section CA Exchange Certificate Generation for the exact registry keys).

certutil -setreg CA\EncryptionCSP\CNGEncryptionAlgorithm AES

certutil -setreg CA\EncryptionCSP\SymmetricKeySize 256

Note: other AES key lengths supported on Windows Server 2008 are 128 and 192.

Note: if the CA is configured to use the AES symmetric key algorithm, ensure that all computers on which key recovery will be performed by the KRAs also support AES.

If multiple recovery agents are associated with the CA, the symmetric key will be encrypted individually with each recovery agent’s public key to allow any one recovery agent to perform a recovery operation. The actual KRA(s) used may randomly vary if a round-robin selection of KRAs is chosen. For example, if a CA Administrator configures four KRA certificates on a CA for use, but requires a minimum of two KRAs to be used, when the CA service starts, a random start point in the KRA list is chosen. Two of the four KRAs will be chosen from that start list, start point, and then for each subsequent archival operation, the list order will be incremented by two. Therefore, a round robin affect is achieved for all key archival operations. These encrypted keys along with the issued certificate will be collectively referred to as the recovery BLOB and are stored as a PKCS #7–encrypted BLOB in the database.

return to top

Key Archival

The private key database is the same as the database used to store the certificate requests. The CA supports storing the encrypted private key along with the associated encrypted symmetric key and issued certificate. The recovery BLOB will be stored in the same row as the signed certificate request and any other information the CA persists in its database for each request transaction. The actual encrypted BLOB is stored as an encrypted PKCS #7 BLOB. For more information about the format and object structure, see Appendix A: Certificate Request Structure.

The Microsoft Certification Authority uses the Microsoft Jet database engine upon which various Jet utilities may be used for maintenance purposes.

return to top

Understanding User Key Recovery

A recovery operation is initiated by an end-entity that has lost access to a private key.

The following are the key recovery steps.

1. The Certificate Manager (CA Officer) locates and retrieves the user’s encrypted private key from the CA database. The encrypted BLOB is protected by access control lists (ACLs) to ensure that only a valid Certificate Manager is able to copy the BLOB from the database. Since it is encrypted with the KRA’s public key, the Certificate Manager cannot extract the user’s private key, but it can retrieve it from the CA. The encrypted PKCS #7 BLOBs in the database contain the Issuer name and serial number of each KRA certificate for KRA identification purposes. Once extracted, the Certificate Manager sends it to the appropriate KRA for decryption. For more information about the format and structure of the recovery BLOB, see Appendix A: Certificate Request Structure.
2. The KRA decrypts the user’s private key and stores it in a password-protected file format (PKCS #12) and sends it to the user.
3. The user imports the key to the user’s local, protected, keys store.

Organizational policy determines whether a KRA and a Certificate Manager may be combined into one role or separate roles. For better security, it is recommended that the Certificate Manager and the KRA roles be separated. Because Certificate Services supports role separation, an organization could easily implement a two-step process to recover the private key(s) of a user.

Understanding Role Separation

Role-based administration is used to organize CA administrators into separate, predefined task-based roles. It is recommended that the management roles are distributed among several individuals in your organization to ensure that a single individual cannot compromise PKI services. Role separation enables one person to audit the actions of another person.

The Common Criteria PKI management roles in Windows Server 2003 and Windows Server 2008 include the following:

1. CA Administrator. Configures and maintains the CA, designates other CA administrators and certificate managers, and renews CA certificates.
2. Certificate Manager. Approves or denies certificate enrollment requests and revokes issued certificates.
3. Backup Operator. Performs backups of the CA database, the CA configuration, and the CA’s private and public key pair (also known as a key pair).
4. Auditor. Defines what events are audited for Certificate Services and reviews the security log for success and failure audit events that are related to Certificate Services.

Note: Role-based administration is supported by Enterprise CAs and stand-alone CAs running Windows Server 2008 and Windows Server 2003, Enterprise Edition or Datacenter Edition.

To help determine role separation, you can use the Common Criteria specification, which defines security standards for all forms of network security and includes specifications for managing PKIs.

For more information about Role Separation, see Role-based administration. For more information on Common Criteria, see Common Criteria Portal.

return to top

Understanding the Key Recovery Agent Role

KRAs are information technology (IT) administrators who can decrypt users’ archived private keys. An organization can assign KRAs by issuing KRA certificates to designated administrators and configure them on the CA. The KRA role is not one of the default roles defined by the Common Criteria specifications but a virtual role that can provide separation between Certificate Managers and the KRAs. This allows the separation between the Certificate Manager, who can retrieve the encrypted key from the CA database but not decrypt it, and the KRA, who can decrypt private keys but not retrieve them from the CA database. For more information about how to implement KRAs, see Implementing Key Archival Walkthrough.

return to top

Key Recovery Agent Certificate

A pre-defined certificate template called “Key Recovery Agent” exists in the Windows Server 2008 and Windows Server 2003 versions of Certificate Services to support the KRA role. This certificate uses a unique “Key Recovery Agent” object identifier (OID) (1.3.6.1.4.1.311.21.6) in the Extended Key Usage extension to identify it as a KRA certificate. A Windows Server 2003 or Windows Server 2008 CA will only use KRA certificates that have been properly formatted as per the following information, although it is not necessary for the certificate to contain the Microsoft-specific extensions.

KRA certificates, when issued by an Enterprise CA, are automatically published in the configuration container of Active Directory. The actual certificates are published to the userCertificate attribute of the KRA object when issued to an IT administrator. The location in the configuration container is as follows:

CN=KRA,CN=Public Key Services,CN=Services,CN=Configuration,DC=<domainname>

The KRA certificate contains the following X.509v1 fields.

• Version
• Serial Number
• Signature Algorithm
• Valid From
• Valid To
• Subject
• Issuer
• Public Key

The KRA certificate contains the following X.509v3 extensions identified in RFC 3280.

• Authority Key Identifier
• Subject Key Identifier
• Authority Information Access
• Key Usage
• Subject Alternative Name
• CDP (CRL Distribution Point)
• Extended Key Usage (Key Recovery Object Identifier = 1.3.6.1.4.1.311.21.6)
• Application Policies (Policy Identifier = Key Recovery Agent)

The KRA certificate will contain the following X.509v3 extensions specific to Microsoft.

• Certificate Template Name
• Certificate Template Information

Note: None of the extensions are marked as critical; however, the Key Recovery Object Identifier must exist in the Extended Key Usage (EKU) extension for the certificate to be used.

return to top

Understanding the Key Recovery Process

Users may require their private keys to be recovered for a multitude of reasons. Key recovery from a Windows Server 2003 or Windows Server 2008 CA may be accomplished using the command-line tool, certutil.exe.

The recovery of a private key is a manual process that requires the user(s) to contact an administrative authority to perform the necessary processes. The following best practices should be considered by any organization.

1. Validate the identity of a user requesting key recovery.
2. Separate the roles of CA Officer and KRA as a minimum of two physical persons.
3. Develop a mechanism to securely deliver the private keys and passwords to end users. Examples could include e-mail of the *.pfx file and leaving a voice mail with the password for the *.pfx file for the user. Discussion of these best practices is beyond the scope of this white paper.

The key recovery process consists of three major steps.

1. Finding recovery candidates. In this step, the certificate manager or CA administrator locates the correct certificate entry in the CA database and obtains its serial number and the serial number of the KRA certificate(s) required to recover the key. Both pieces of information will be required to perform key recovery.
2. Retrieve PKCS #7 BLOB from Database. This is the first half of the actual key recovery step, in which a certificate manager or CA administrator retrieves the correct BLOB from the CA database. This PKCS #7 BLOB contains the certificate and the encrypted private key to be recovered. The private key is encrypted with the public key of one or more KRAs.
3. Recover key material and save to protected PKCS #12 (.pfx) file. This is the second half of the key recovery step, in which the holder of one of the KRA private keys decrypts the private key to be recovered and generates a password-protected .pfx file containing the certificate and private key.
4. Importing recovered keys. The password-protected .pfx file is delivered out of band to the end user, and the end user imports it into his local user certificate store. Alternatively, the KRA or an administrator can perform this step on behalf of the user.

return to top

Finding Recovery Candidates

A CA Officer (Certificate Manager) can perform recovery of private key(s) using the CN (CommonName), UPN (UserPrincipalName), down-level name (domainname\username), certificate serial number of the certificate, or an SHA1 (Secure Hash algorithm) hash (thumbprint) of the certificate. The process is known as finding candidate certificates for recovery.

Examples:

• User1@nwtraders.com (denotes UPN)
• nwtraders\user1 (denotes the down-level name)
• Users\nuser1 (denotes a user in the default users container of Active Directory)
• User1 (denotes the CN)
• <serial number of the certificate>
• <SHA1 hash (thumbprint) of certificate>

return to top

Finding Recovery Candidates by Using Command-Line Tools

To recover a user using their CN, type the following command.

Certutil -getkey <”cn of user”> outputblob

If only one certificate has been issued to that user, that certificate and private key will be generated into the specified <outputblob> file. If more than one certificate has been issued to that CN, certutil.exe will list the serial number(s) of all the certificates issued to that CN on a specific CA.

Example:

"user1.nwtraders.com\CA1"

 

Serial Number: 1464be10000000000007  

Subject: CN=user1, CN=Users, DC=nwtraders, DC=com  

NotBefore: 1/13/2001 11:51 AM  

NotAfter: 1/13/2002 11:51 AM  

Template: KeyA, KeyArchival  

Cert Hash(sha1): a2 7f 77 bc 2f 7b eb 26 bd 3e ed 43 b8 2a 24 04 2e 55 b8 64

 

Serial Number: 1464fcbc000000000008

 

Subject: CN=user1, CN=Users, DC=nwtraders, DC=com

NotBefore: 1/13/2001 11:51 AM

NotAfter: 1/13/2002 11:51 AM

Template: KeyA, KeyArchival

Cert Hash(sha1): 21 bd 88 2c 2a 84 0c e5 57 7b 2a bf f0 43 4b b3 ed bf 02 5a

return to top

Finding Recovery Candidates by Using the Certification Authority MMC Snap-In

A CA Officer may determine the serial number of a certificate that has been archived. To determine the serial number of an archived certificate

1. Log on to a CA as a CA Officer who has Certificate Management authority of the user(s) in question.
2. On the Administrative Tools menu, open the Certification Authority.
3. In the console tree, expand Certification Authority, and then click Issued Certificates.
4. On the View menu, click Add/Remove Columns.
5. In the Add/Remove Columns dialog box, in the Available Column list, select Archived Key, and then click Add. Archived Key should now appear in the Displayed Columns listing.
6. Click OK.
7. In the details pane, scroll to the right and ensure that the certificate in question has a value in the Archived Key column.
8. Double-click the certificate.
9. Click the Details tab.
10. Write down the serial number of the certificate (do not include spacing between digit pairs). This is required for recovery.
11. Click OK.
12. Close the Certification Authority.

return to top

Key Recovery

Key recovery is done by using the certutil.exe command-line tool. This tool is installed by default on the CA and on Windows Vista. The certutil.exe command structure was designed to perform batch and scripted processes.

return to top

Retrieving the Key BLOB from the CA Database

After performing the previous steps the serial number(s) of the certificate(s) to be recovered should be known. Key recovery is performed using the certutil.exe command- line tool. The following command will retrieve the actual recovery BLOB from the CA database and save it to a file called “outputblob”.

certutil -getkey <serial#> outputblob

The “outputblob” is a PKCS #7 file containing the certificate and one or more copies of the private key, encrypted with the public key of one or more KRAs.

Note that the serial number(s) of the KRA certificate or certificate(s) required for key recovery are listed in the output of the certutil -getkey command as Recipient Info.

Important: If a CA Administrator has configured the server to use, for example, three of a possible five available KRAs, certutil –getkey will list the three KRAs that were used to encrypt the selected subject's private key. At the time of archival, the three KRAs were randomly selected (out of five possible) by the CA to encrypt the subject’s private key. To perform the recovery operation, it will be necessary to have one of any of the KRAs whose serial numbers are listed by certutil –getkey.

To recover private key(s)

1. If the CA Officer is not a KRA, the CA Officer must transfer the encrypted BLOB file to a user that holds a KRA private key for further processing.

2. At the command prompt on a computer on which the KRA certificate and private key are available, the KRA should type the following command.

   • Certutil  -recoverkey  outputblob  user.pfx where:
   • outputblob is the encrypted PKCS #7 file containing the key to be decrypted.
   • user.pfx is the output file name for the user private keys in PKCS #12 format.
   • Important: If the KRA certificate was generated using an advanced CryptoAPI Next Generation (CNG) algorithm, such as ECC, you must specify the provider using the “-CSP” flag in the “recoverkey” command. For example:
   1. • certutil –csp “Microsoft Software Key Storage Provider” –recoverkey user.pfx
   • Important: If the KRA certificate was generated using an advanced CryptoAPI Next Generation (CNG) algorithm, such as ECC, it cannot be used to provide key recovery for end-user certificates generated with third-party– (non-Microsoft) or smart card–based CSPs.
   • The PKCS #12 format allows for the private key file to be protected with a password. Certutil.exe will prompt the KRA for a password when generating the PKCS #12 file.
   • The system will search for a valid private key in the store of the logged on user that corresponds to a valid KRA certificate that was used to encrypt the recovery BLOB. If the user does not have the proper private key in the user’s local store, an error will display.

3. Enter and confirm a password for the file that cannot be randomly guessed. The user should be given the password through a secure out-of-band mechanism that is separate from the file itself to ensure strong security in the recovery process.

Note: If auditing is enabled for key recovery, an event log message will be generated when a private key is recovered from the database. The event log message will be similar to the following:

• Event Type: Success Audit
• Event Source: Security
• Event Category: Object Access  
• Event ID: 787
• Date:  2/19/2001
• Time:  5:23:45 PM
• User:  NWTRADERS\User1
• Computer: SERVER1
• Description: Certificate Services retrieved an archived key.
• Request ID 12

return to top

Recovery Batch File

The certutil.exe -getkey command is an advanced tool that can be used with explicit commands. It can also build batch file syntax to perform a complete recovery operation. The following is the command-line syntax for certutil.exe -getkey.

Usage:

CertUtil -GetKey [Options] SearchToken [RecoveryBlobOutFile]

Retrieve archived private key recovery blob

SearchToken - Used to select the keys and certificates to be recovered.

RecoveryBlobOutFile - Output file containing a certificate chain and an associated private key, still encrypted to one or more KRA certificates.

If the following command is performed using any of the previous SearchToken criteria, the certutil.exe tool will output the complete syntax that can be used.

Example: certutil -v -getkey user1@northwindtraders.com >myBatchfile.bat

Output file:

@goto start

Querying northwind5.nwtraders.com\TestCA9..................... 

 

"northwind5.nwtraders.com\TestCA9"

  Serial Number: 611e23c200030000000e

  Subject: E=user1@nwtraders.com, CN=user1, CN=Users, DC=nwtraders, DC=com

  UPN:user1@nwtraders.com

  NotBefore: 1/12/2002 1:24 PM

  NotAfter: 1/12/2003 1:24 PM

  Template: EFS2

  Version: 3

  Cert Hash(sha1): d6 41 99 e7 e7 24 73 34 02 41 53 2d 29 11 a8 3b e6 aa 12 2f

 

  Serial Number: 6131f9c300030000000f

  Subject: E=user1@nwtraders.com, CN=user1, CN=Users, DC=nwtraders, DC=com

  UPN:user1@nwtraders.nttest.microsoft.com

  NotBefore: 1/12/2002 1:45 PM

  NotAfter: 1/12/2003 1:45 PM

  Template: EFS2

  Version: 3

  Cert Hash(sha1): 1a cc 8d 26 7f 9f 70 6c 65 05 a0 84 8c 4c e9 b7 b4 6c 66 a3

 

:start

 

@echo Version 3 certificates and keys:

CertUtil -config "northwind5.nwtraders.com\TestCA9" -getkey

611e23c200030000000e "user1-611e23c200030000000e.rec"

 

CertUtil -config "northwind5.nwtraders.com\TestCA9" -getkey

6131f9c300030000000f "user1-6131f9c300030000000f.rec"

 

CertUtil -p "UQcYLsJ(57s]FuBl" -recoverkey -user "user1-611e23c200030000000e.rec" "

user1-611e23c200030000000e.p12"

 

CertUtil -p "UQcYLsJ(57s]FuBl" -recoverkey -user "user1-6131f9c300030000000f.rec" "

user1-6131f9c300030000000f.p12"

 

CertUtil -p "UQcYLsJ(57s]FuBl,iG1-bOt&tqdvJiu1" -MergePFX -user "user1-611e23c20003

0000000e.p12,user1-6131f9c300030000000f.p12" "user1.p12"

 

@del user1-611e23c200030000000e.rec

@del user1-611e23c200030000000e.p12

@del user1-6131f9c300030000000f.rec

@del user1-6131f9c300030000000f.p12

@echo PASSWORD: "iG1-bOt&tqdvJiu1"

 

@goto exit

CertUtil: -GetKey command FAILED: 0x8002802c (-2147319764)

CertUtil: Ambiguous name.

The following is an explanation of the previous syntax, which can be run by Certificate Managers that hold a valid KRA private key.

1. The tool finds all possible CAs that are registered in Active Directory. It then will query each CA for keys that have been archived for the specified user.
   • @goto start
   • Querying northwind5.nwtraders.com\TestCA9.....................
2. The tool will show the archived keys found for the user on each CA that is queried. It will list the most important details on each archived key found that will be useful for Certificate Managers and administrators.
   • "northwind5.nwtraders.com\TestCA9"
   • Serial Number: 611e23c200030000000e
   • Subject: E=user1@nwtraders.com, CN=user1, CN=Users, DC=nwtraders, DC=com
   • UPN:user1@nwtraders.com
   • NotBefore: 1/12/2002 1:24 PM
   • NotAfter: 1/12/2003 1:24 PM
   • Template: EFS2
   • Version: 3
   • Cert Hash(sha1): d6 41 99 e7 e7 24 73 34 02 41 53 2d 29 11 a8 3b e6 aa 12 2f
   • Serial Number: 6131f9c300030000000f
   • Subject: E=user1@nwtraders.com, CN=user1, CN=Users, DC=nwtraders, DC=com
   • UPN:user1@nwtraders.nttest.microsoft.com
   • NotBefore: 1/12/2002 1:45 PM
   • NotAfter: 1/12/2003 1:45 PM
   • Template: EFS2
   • Version: 3
   • Cert Hash(sha1): 1a cc 8d 26 7f 9f 70 6c 65 05 a0 84 8c 4c e9 b7 b4 6c 66 a3
3. The tool will retrieve the encrypted recovery BLOB(s) from the CA. Note that the administrator must be a Certificate Manager for the recovered user(s) on the CA.
   • @echo Version 3 certificates and keys:
   • CertUtil -config "northwind5.nwtraders.com\TestCA9" -getkey 611e23c200030000000e "user1-611e23c200030000000e.rec"
   • CertUtil -config "northwind5.nwtraders.com\TestCA9" -getkey 6131f9c300030000000f "user1-6131f9c300030000000f.rec"
4. The tool will decrypt the recovery BLOB(s) and generate *.pfx files (PKCS #12 format) for each recovered key and set a random password as denoted after the –p parameter. Note that the administrator must have a valid KRA private key to perform this step.
   • CertUtil -p "UQcYLsJ(57s]FuBl" -recoverkey -user "user1-611e23c200030000000e.rec" "user1-611e23c200030000000e.p12"
   • CertUtil -p "UQcYLsJ(57s]FuBl" -recoverkey -user "user1-6131f9c300030000000f.rec" "user1-6131f9c300030000000f.p12"
5. The tool will merge the multiple *.pfx files (if applicable) into a single *.pfx file to simplify the process for the user installing recovered keys. The certutil.exe –MergePFX command is automatically used to perform this process.
   • CertUtil -p "UQcYLsJ(57s]FuBl,iG1-bOt&tqdvJiu1" -MergePFX -user "user1-611e23c200030000000e.p12,user1-6131f9c300030000000f.p12" "user1.p12"
6. The tool will clean up any temporary files used during the process.
   • @del user1-611e23c200030000000e.rec
   • @del user1-611e23c200030000000e.p12
   • @del user1-6131f9c300030000000f.rec
   • @del user1-6131f9c300030000000f.p12
   • @echo PASSWORD: "iG1-bOt&tqdvJiu1"
   • @goto exit
7. The following output is expected when the user has multiple archived keys. This following output implies that a full key recovery could not be performed because the command line was not specific enough to retrieve a specific recovery BLOB.
   • CertUtil: -GetKey command FAILED: 0x8002802c (-2147319764)
   • CertUtil: Ambiguous name.

return to top

CA Officer Does Not Have a KRA Certificate

As mentioned previously, a CA Officer need not also hold a KRA certificate. In the case where the CA Officer does not hold a valid KRA certificate and only has permissions to retrieve a recovery BLOB, running certutil.exe –getkey <serial number> will list the certificate serial numbers of all of the KRA(s) that may be used to decrypt (recover) the recovery BLOB in question. The CA Officer can then determine which KRA(s) may be used and send the recovery BLOB to one of the valid KRA(s).

The previous procedure is extremely useful in an organization that has a round-robin selection of KRA(s) when archiving private keys. In a round-robin archival, it may be difficult to always predict which KRA(s) were used to encrypt any specific private key of a user. It is a good best practice to keep the list of all KRA certificate hashes accessible so that they may be readily identified in the previous scenario.

 

The following certutil command may be used to list all the information from Active Directory, including KRA certificate hashes.

Certutil.exe –DS – v > c:\output.txt

Note: This command will dump all PKI information and certificates from Active Directory and may be more usable when placing the output in a text file as shown.

Setting the Timeout Option for Recovery Commands

When keys are recovered from a CA using the command line, the recovery tool(s) will build a complete chain for the end-entity certificate, if possible. Sometimes a chain may not be able to be built after a long time due to infrastructure changes, CA certificate availability, and so on; the tool may also timeout when trying to build these chains. The certutil –recoverkey command and other commands that verify chains or construct *.pfx files accept a –t MilliscondCount option. This allows key recovery to avoid a 15-second timeout for each user key when building a chain. Fetching the certificate specified in the Authority Information Access (AIA) extension Uniform Resource Locators (URLs) can time out when the recovered keys are associated with expired encryption certificates and the CAs have been decommissioned. For more information about certificate chains and status, see Windows XP: Certificate Status and Revocation Checking and How Certificate Revocation Works.

return to top

Importing Recovered Keys

Importing recovered keys can be done with either the command line or the Certificate Import Wizard (available on the Certificates MMC).

To import the recovered certificate and key material into the user’s certificate store, use the following command where user.pfx is the file created from the earlier “recoverkey” command performed by the CA administrator or KRA.

certutil –user –importPFX {user.pfx}

Note that the certutil tool will prompt the end user for a password. This password should be delivered out of band from the administrator or KRA to the end user.

Important: If the end-user certificate has either of the following properties, you must specify the CSP in the “importPFX” command.

• It uses a third-party CSP or a smart card CSP.
• It was generated using an advanced CryptoAPI Next Generation (CNG) algorithm, such as ECC.

For example: certutil -CSP “Microsoft Software Key Storage Provider” -importPFX user.pfx

If either is true, you will not be able to use the following Certificate Import Wizard steps to import the certificate and key, and you must use the command line.

The following steps would be performed by an end user who has received the recovered key file (*.pfx file) and associated password from an administrator. It is assumed that the password and associated file have been transmitted to the user in a method consistent with the organization’s security policy.

Note: See the previous command-line steps if the certificate being recovered was generated using a third-party, smart card, or advanced CNG provider.

To import a recovered key for an individual user

1. Log on as the user who needs to recover their private key(s).
2. Open the Certificates MMC.
3. Expand the tree view of the certificate store. Click Certificates, Current User, Personal, and then click Certificates.
4. In the console tree, right-click Personal, click All Tasks, and then click Import.
5. In the Certificate Import Wizard dialog box, click Next.
6. On the Files to Import page, in the File name box, type the name and path of the recovered key file (*.pfx), and then click Next.
7. On the Password page, in the Password box, type the password for the key file, and then click Next.
8. On the Certificate Store page, click Automatically select the certificate store based on the type of certificate, and then click Next.
9. On the Completing the Certificate Import Wizard page, click Finish. The wizard will report that the import was successful.

Note: A *.pfx file can also be selected (double-click) to invoke the certificate import wizard.

return to top

Implementing Key Archival Walkthrough

Use the following procedure to configure a CA for key archival. The first step in enabling key archival on a CA is enrolling for one or more KRA certificates.

return to top

Enrolling a Key Recovery Agent

The following section explains the steps for enrolling a KRA.

return to top

Configuring the Certificate Templates

A certificate template suitable for creating KRA certificates, called “Key Recovery Agent” is installed in Active Directory by default when a Windows Server 2008 or Windows Server 2003 CA is installed (or when certificate templates are upgraded to the Windows Server 2003 or Windows Server 2008 version). By default, only Enterprise Administrators or Domain Administrators may request a KRA certificate because these are the only groups configured by default with the “Enroll” permission on the template. Using the Certificate Templates MMC snap-in, the administrator can view and update certificate template permissions, as well as duplicate templates and edit other template properties.

Note: Only a domain with the Windows Server 2003 schema or higher will support version 2 templates, and only a Windows Server 2008, Enterprise Edition or Windows Server 2003, Enterprise Edition CA may issue a version 2 template certificate.

To configure a certificate template

1. Log on to the CA computer as an Enterprise or Domain Administrator.
2. Click the Start button, click Run, and then type certtmpl.msc and press ENTER.
3. In the details pane, double-click Key Recovery Agent.
4. In the Key Recovery Agent Properties dialog box, click the Security tab.
5. Add the appropriate user(s) or group(s) with both Read and Enroll permissions.
6. Click OK to close the dialog box.

Next, the Certification Authority must be configured to issue this type of certificate.

return to top

Certificate Template Permissions

For a user or a computer to enroll for a certificate template, it must have appropriate permissions set on the template in Active Directory. A user or computer must have both Enroll and Read permissions to enroll for a selected certificate template. The Read permission allows the template to be discovered by the user and the Enroll permission is enforced by the enterprise CA when a user requests a certificate for a selected template. The enterprise CA must also have Read permissions on a template to enumerate the template in the directory and issue certificates based on that template. Normally, the enterprise CA is included in the Authenticated Users group, which has Read permissions by default on a template.

Read, Write, and Enroll permissions are given to Enterprise Administrators by default on installation of a fresh Windows Server 2008 or Windows Server 2003 enterprise CA. If the domain has been upgraded from Windows 2000, Enterprise Administrators will not have this permission by default. The Write permission allows a user to set or modify the permissions on a selected template.

The Autoenroll permission is set on a template to enable the designated user(s) or computer(s) to enroll automatically for a certificate based on the selected certificate template. The Autoenroll permission is needed in addition to the Enroll permission for a user to enroll automatically.

The Write permission allows a user to modify the contents of a certificate template. Note that version 2 or higher certificate templates may be modified. Version 1 certificate templates may only have the ACLs modified.

return to top

Smart Card Support

Smart cards are supported for use in conjunction with KRA certificates. It may be necessary to use a smart card and CSP that supports at least an 8-KB smart card to enroll for a KRA certificate on a smart card. If a smart card does not have adequate memory to support a KRA certificate, the following error will be generated on enrollment.

Error: 0x80100028

An attempt was made to write more data than would fit in the target object.

All recovery operations are supported using a smart card. The system will prompt the recovery agent to insert an appropriate smart card when the key is needed to decrypt the recovery BLOB.

return to top

Configuring an Enterprise CA to Issue KRA Certificates

An Enterprise CA must be configured to issue a KRA certificate.

To configure an Enterprise CA to issue a KRA certificate

1. On the Administrative Tools menu, open the Certification Authority snap-in.
2. In the console tree, expand Certification Authority, and then click Certificate Templates.
3. Right-click the Certificate Templates node, click New, and then click Certificate Template to Issue.
4. In the Select Certificate Template dialog box, click Key Recovery Agent, and then click OK.
5. Close the Certification Authority MMC snap-in.

return to top

Enrolling a User with a KRA Certificate

A user may enroll for a certificate with a CA by using the Certificates MMC snap-in, through the CA Enrollment Web pages, or (though not recommended) via auto-enrollment. The KRA template is marked to be “pended” by the CA, which means that the certificate request must first be approved by a CA Administrator or a Certificate Manager before the KRA certificate is issued. After approval, pended certificate requests may only be retrieved through the Web enrollment interface or through the auto-enrollment process.

Important: It is strongly recommended not to automatically enroll KRA certificates without some kind of manual intervention, as this may cause a proliferation of KRA certificates and confusion for CA Administrators when recovery is required.

return to top

KRA Enrollment with Certificates MMC

To enroll for a KRA certificate using the Certificates MMC

1. Log on to as a user with Read and Enroll permissions on the Key Recovery Agent template.
2. Launch the Certificates MMC.
3. Expand Certificates – Current User, and then select the Personal node.
4. Right-click and choose All Tasks, and then select Request New Certificate.
5. On the Certificate Enrollment wizard, click Next.
6. Select Key Recovery Agent, and then click Enroll.
7. Once the Certificate Enrollment wizard is finished, the KRA certificate will be shown as STATUS:Enrollment Pending. This is the default behavior of the KRA certificate template. The CA Manager or Administrator must now approve the certificate request. Click Finish.

return to top

Approving the Request

To approve the pending KRA certificate request

1.   Log on to the CA as the CA administrator or another user with authority to issue certificates.

2.   Launch the Certification Authority MMC and select the Pending Requests folder.

3.   Right-click the pending request, select All Tasks, and then click Issue.

As a result of the CA administrator or manager issuing the KRA certificate, the certificate is added to the local machine KRA store on the CA itself, as well as to the Active Directory KRA object.  

All certificates in the local machine KRA store can be viewed by entering the following command.

certutil -viewstore KRA

All KRA certificates in Active Directory can be viewed by entering the following command.

certutil -viewstore "ldap:///CN=contoso-CONTOSO-LHS2-CA,CN=KRA,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=msft”

Completing the Enrollment

To complete the enrollment and ensure that the KRA user has possession of the private key required for Key Recovery

1. Log on to as the user who previously requested the KRA certificate.
2. Launch the Certificates MMC.
3. Select Certificate – Current User.
4. Right-click, select All Tasks, click Automatically Enroll and Retrieve Certificates.
5. Select Key Recovery Agent, and then click Enroll.
6. Click View Certificate.

The certificate is now in the current user’s Personal Certificates store on the machine, and the private key is available to the logged on user.

return to top

KRA Web Enrollment

To enroll through a Web page

1. Connect to the CA using a Web URL, for example: http://<CA_Computer_Name>/Certsrv
   • The Web enrollment pages that ship with the Windows Server 2003 version of Certificate Services are supported by Windows 2000, Windows XP, and Windows Server 2003 clients. The Web enrollment pages that ship with Windows Server “Longhorn” edition are supported by Windows Vista and Windows Server 2008 clients. Unfortunately, the Web enrollment pages that shipped with the Windows Server 2003 version of Certificate Services cannot be used by out-of-the-box Windows Vista clients. For more information, see the Knowledge Base article 922706 http://support.microsoft.com/kb/922706
2. A Web site will open allowing you to request a certificate. Click Request a Certificate.
3. On the next Web page, click Advanced Certificate Request.
4. Select Create and submit a request to this CA. The next page will allow the user to select various configuration options, including the type of certificate to request.
5. Choose Key Recovery Agent as the Certificate Template. The keys should be marked as exportable. This will enable an administrator (KRA) to export the private keys from the local store of the workstation to a disk or other medium for safe storage. Strong private key protection is also recommended, as this will require a password to be used when accessing the private key.
6. When finished, click Submit. The Web page will show that the request is being generated. When the key generation and request is complete, if the request had included Enable strong private key protection, a dialog box will appear showing that a protected item is being created (KRA private key). In this dialog box, you can set the security level on the private key. If the workstation will be used for KRA operations and the private key is to be kept in the protected store, it is recommended that the security level be set to High. This will ensure that access to the private key will require a separate password.
7. Click Next.
8. Choose a password, confirm it, and then click Finish.
9. Click OK to confirm. The Web page will appear and offer a link to install the certificate. If the Certification Authority is configured to set all certificate requests to pending, the user will have to return to the Web link to install the certificate after the CA administrator or a CA Officer has approved the request.

Important:

• The user may have to return to the Web link using the same machine that was used to generate the request. This is due to the fact that certificate pending information is stored as a browser cookie. If auto-enrollment is enabled in Active Directory for the user, the user will not be required to actually return to the Web page. The auto-enrollment process will automatically retrieve the certificate for the user when available. For more information about the auto-enrollment process, see the Certificate Auto-Enrollment in Windows XP.
• If the issuing CA is in a hierarchy, a second option will appear on the Web page to download the entire path (certificate chain). You should choose to download the entire chain.

The default KRA certificate template requires that the certificate request be pended and not issued automatically. When a certificate request is pended, a CA Officer (Certificate Manager) must manually issue the certificate, assuming that the request was valid. Pending certificate requests can be issued through the Certification Authority MMC and by selecting the pending request node.

The Certificate Manager (or administrator of the server, if role separation is not enabled) can right-click the certificate request and choose to issue or deny the request. For more information about Certificate Managers, see Configuring Certificate Managers.

After the certificate has been issued, the user (KRA) can return to the Web pages to retrieve the pending request.

The user should select View the status of a pending certificate request.

The Web page will display all the pending requests for that user that have been requested from that machine. As mentioned previously, this is managed through Web browser cookies. The user should select the appropriate certificate.

The last page allows the user to install the selected certificate and private key into the local MY store of the user.

return to top

Configuring the CA to Allow Key Archival

This section details the steps required to configure the CA to allow key archival.

Note that if the CA is enabled to enforce role separation, only a CA Administrator may configure KRAs on a CA. Role separation is enabled through the registry and only a local server administrator may configure the registry. The easiest way to enable the CA for role separation is to use the following certutil.exe command-line tool.

certutil -setreg ca\RoleSeparationEnabled 1

It is necessary to stop and start certificate services for the setting to take effect: net stop certsvc && net start certsvc

Note: Certutil.exe and other tools may be installed on a Windows XP Professional machine by installing the Administrative Tools (adminpak.msi) that are found in the \i386 directory on all Windows Server 2003 CD-ROM media.

return to top

Enabling a Key Recovery Agent

To enable a KRA

1. Log on as Administrator of the server or CA Administrator, if role separation is enabled.
2. On the Administrative Tools menu, open Certification Authority.
3. In the console tree, select the CA.
4. Right-click the CA name, and then click Properties.
5. Click the Recovery Agents tab.
6. To enable key archival, click Archive the key.
7. By default, the CA will only use one KRA. However, a KRA certificate must first be selected for the CA to begin archival. To select a KRA certificate, click Add. The system will find valid KRA certificates and display the available KRA certificates. KRA certificates are normally published to Active Directory by an Enterprise CA when enrollment occurs. KRA certificates are stored under the KRA container in the Public Key Services branch of the configuration partition in Active Directory. Since a CA may issue multiple KRA certificates, each KRA certificate will be added to the multi-valued userAttribute attribute of the CA object.
8. Select one certificate and click OK. You may view the highlighted certificate to ensure that you have selected the intended certificate.
9. After one or more KRA certificates have been added, click OK to enable key archival on the CA. However, Certificate Services must be stopped and started to enable the use of the selected KRAs. KRA certificates are only processed at service start.

return to top

Configuring Certificate Managers

To recover the private keys of a user, the CA enforces that a person be a Certificate Manager (if defined) and also holds a private key for a valid KRA certificate. As a best practice, most organizations separate these two roles. By default, the CA Administrator is a Certificate Manager for all users unless otherwise explicitly defined. A KRA is not necessarily a CA Officer (Certificate Manager). They may be segmented as separate roles. A KRA is defined as a person who holds a private key for a valid KRA certificate.

A CA Officer is defined as a Certificate Manager who has the security permission on the CA to Issue and Manage Certificates. The security permissions are configured on a CA using the Security tab on the CA Properties in the Certification Authority MMC snap-in.

A CA Administrator can define more specific CA Officer Roles on a CA by using the Certificate Managers tab (called Certificate Managers Restrictions tab in Windows Server 2003 CAs). By default, any user or group that has the permission to Issue and Manage Certificates is also a CA Officer and can issue, revoke, or export a recovery BLOB for any other user who has been issued a certificate from that CA. 

A CA Administrator can define that individual CA Officers have the ability to issue, revoke, and recover certificates for defined sets of user(s) and group(s) by selecting the Restrict certificate managers option. Once the option has been selected, a CA Administrator may define CA Officers’ roles as required. Starting with Windows Server 2008 CAs, certificate managers can also be restricted by certificate template

Configuring User Templates

Finally, for key archival to happen automatically upon user enrollment, you must enable the corresponding certificate template for key archival.

1. In the Certificate Templates MMC, right-click the template that should enforce key archival, and then select Properties.
2. On the Request Handling tab, select the Archive subject’s encryption private key check box. Once the check box has been selected, the CA will always enforce key archival for that template. In Windows Server 2008 CAs, you can optionally select the option to “Use advanced symmetric algorithm to send the key to the CA”.

Important: Before enabling this option, ensure that both the clients and the CAs that will issue certificates for this template are capable of using the AES encryption algorithm. Otherwise, enrollments for this template will fail.

Note: A Windows Server 2003 CA will not allow archival of a key marked for signature only and will reject the request, even if sent programmatically to the CA.

return to top

Key Archival and renew with the same key

Windows Server 2012 and Windows 8 introduce the ability to Renew with the same key. Renewal with the same key will work even if the key is marked as non-exportable.

Key archival issues can occur when certificate templates are changed after certificates are issued. For example, if a certificate template is initially configured such that the private key cannot be exported and renew with the same key is enabled and certificates are issued from that template. Then at some later point, the certificate template is changed to require key archival. When the certificates that were issued before the change to require key archival are renewed, those keys will not be archived.

The user interface warns the certificate administrator of this situation when key archival is enabled and Renew with the same key is already enabled with the following message: will warn of such a potential issue with the following message: Key archival is only enabled for future certificates. Keys for certificates that are already issued will not be archived. The following certification authorities are currently issuing certificates based on this template.

return to top

Troubleshooting

This section identifies a number of common mistakes in configuring the KRAs on a CA. The most common error in archiving user private keys on a CA is that the CA is either not configured for key archival or does not have any valid KRA certificate(s) added.

1. The number of recovery agents required by the CA must be less than or equal to the number of available KRA certificates. If an invalid number of recovery agents is entered, the following error message will appear: The number of recovery agents to use must be between one and the number of recovery agents defined.
2. If an error occurs in trying to validate the KRA certificate when Certificate Services is started, the Recovery Agents tab on the Certification Authority will show that the selected KRA certificate is invalid. This can occur due to a corrupted certificate, corrupted registry entry, deleted certificate, revoked certificate, and so on. The following figure shows an example of a corrupted certificate or registry entry on the Recovery Agents tab as shown in the Status column of the selected KRA.
3. Similarly, a revoked KRA certificate will also show an error on the Recovery Agents tab when Certificate Services is stopped and started. The error will be displayed in the status column of the KRAs certificates listing.

return to top

Event Log Messages Related to Key Archival and Recovery

The following table lists the Windows Server 2008 CA event log messages related to key archival and recovery. Note that a new event, a warning event for KRA certificate expiration, has been added.

Event Name	ID	Level	Text	Variables
MSG_E_KRA_NOT_ADVANCED_SERVER	81	Error	Active Directory Certificate Services key archival is only supported on Advanced Server.  %1	ErrorCode
MSG_E_TOO_FEW_VALID_KRA_CERTS	82	Error	Active Directory Certificate Services could only verify %1 of %2 key recovery certificates required to enable private key archival. Requests to archive private keys will not be accepted.	NumberofValidKRACerts, RequiredNumberofValidKRACerts
MSG_E_LOADING_KRA_CERTS	83	Error	Active Directory Certificate Services encountered an error loading key recovery certificates. Requests to archive private keys will not be accepted.  %1	ErrorCode
MSG_E_INVALID_KRA_CERT	84	Error	Active Directory Certificate Services will not use key recovery certificate %1 because it could not be verified for use as a Key Recovery Agent.  %2  %3	KRACertIndex, KRACertSubjectName, ErrorCode
MSG_E_CANNOT_LOAD_KRA_CERT	85	Error	Active Directory Certificate Services ignored key recovery certificate %1 because it could not be loaded.  %2  %3	KRACertIndex, KRACertSubjectName, ErrorCode
MSG_E_BAD_REGISTRY_CA_XCHG_CSP	86	Warning	Active Directory Certificate Services could not use the provider specified in the registry for encryption keys.  %1	ErrorCode
MSG_E_BAD_DEFAULT_CA_XCHG_CSP	87	Error	Active Directory Certificate Services could not use the default provider for encryption keys.  %1	ErrorCode
MSG_E_USE_DEFAULT_CA_XCHG_CSP	88	Warning	Active Directory Certificate Services switched to the default provider for encryption keys. %1	DefaultProvider Name
MSG_E_CANNOT_CREATE_XCHG_CERT	96	Error	Active Directory Certificate Services could not create an encryption certificate.  %1.  %2.	Disposition, ErrorCode
MSG_E_TOO_MANY_KRA_INVALID	98	Error	Active Directory Certificate Services encountered errors validating configured key recovery certificates. Requests to archive private keys will no longer be accepted.	none
MSG_W_EXPIRATION_KRA_CERT	127	Warning	Key recovery certificate %1 is about to expire soon and will not be used upon expiration. Contact your adminstrator to renew this certificate.  %2  %3	KRACertIndex, KRACertSubjectName, ErrorCode

return to top

Loading KRA Certificates

When certificate services starts on a CA, the CA attempts to load the KRA(s) defined by the CA Administrator. If the CA is unable to load one or more KRA(s), event log messages will be generated; however, certificate services will continue to start. If the CA is unable to load a KRA(s) successfully as defined by a CA Administrator, the CA will deny all requests for key archival and not issue any certificates that have key archival defined in the certificate template. The following event log messages may appear in the Certification Authority’s Application Log when an error occurs in loading KRA certificates. The event log messages indicate that action is required by a CA Administrator to properly configure or reconfigure KRAs.

Event Type:   Error

Event Source:   CertSvc

Event Category:   None

Event ID:   83

Date:     12/20/2000

Time:     8:24:24 AM

User:     N/A

Computer:   SERVER1

Description:

Certificate Services encountered an error loading key recovery certificates. Requests to archive private keys will not be accepted. The system cannot find the file specified.0x80070002 (WIN32: 2)

This is a global error that can be caused by one of several conditions.

•   The Certification Authority cannot open the KRA store on the local machine.

•   The Certification Authority cannot find a corresponding certificate in the KRA store on the local machine that matches the hash of a certificate set in the registry as a KRA.

•   The registry has been edited incorrectly or is corrupted.

•   The count of KRA certificate hashes in the registry equals zero.

•   A certificate hash in the registry corresponds to a certificate in the KRA store that is not a KRA certificate type.

•   The KRA certificates are revoked, expired, or invalid.

Event Type:   Error

Event Source:   CertSvc

Event Category:   None

Event ID:   82

Date:     12/27/2000

Time:     9:05:25 AM

User:     N/A

Computer:   SERVER1

Description:

Certificate Services could not load any valid key recovery certificates. Requests to archive private keys will not be accepted.

This error is usually caused when none of the certificates specified in the user interface (UI) (which corresponds to the registry) is a valid KRA certificate. This event log message is usually accompanied by the previous global event log message.

Event Type:   Error

Event Source:   CertSvc

Event Category:   None

Event ID:   84

Date:     1/24/2003

Time:     08:49:27

User:     N/A

Computer:   SERVER1

Description:

Certificate Services will not use key recovery certificate 6 because it could not be verified for use as a Key Recovery Agent.  CN=User1, OU=Users, DC=nwtraders, DC=com  The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)

This error usually occurs when the CA receives an error when retrieving the CRL to check the status of the KRA certificate.

Event Type:   Error

Event Source:   CertSvc

Event Category:   None

Event ID:   98

Date:     1/24/2003

Time:     08:49:28

User:     N/A

Computer:   SERVER1

Description:

Certificate Services encountered errors validating configured key recovery certificates. Requests to archive private keys will no longer be accepted.

Event Type:   Error

Event Source:   CertSvc

Event Category:   None

Event ID:   85

Date:     12/27/2000

Time:     9:05:25 AM

User:     N/A

Computer:   SERVER1

Description:

Certificate Services ignored key recovery certificate 0 because it could not be loaded. Cannot find object or property. 0x80092004 (-2146885628)

This error usually occurs when a specific KRA certificate cannot be found in the KRA store on the local machine of the Certification Authority. Specifically, a KRA certificate has been specified in the UI or registry, and the certificate has been deleted or corrupted in the KRA store. This event log message is usually accompanied by a more global event log message. 

return to top

KRA Certificate Status

When certificate services starts on a Certification Authority, the CA attempts to load the configured KRA(s). The CA must validate the status of each KRA certificate. If the CA is unable to retrieve a current CRL for each KRA certificate, the CA will not be able to load and use that KRA.

The following event log message will be logged in the application event log of the CA.

Event Type: Error

Event Source: CertSvc

Event Category: None

Event ID: 84

Date:  1/12/2001

Time:  11:47:23 AM

User:  N/A

Computer: SERVER1

Description:

Certificate Services ignored key recovery certificate 1 because it could not be verified for use as a Key Recovery Agent. CN=User1, OU=Users, DC=nwtraders, DC=com The revocation function was unable to check revocation because the revocation server was offline.

0x80092013 (-2146885613)

return to top

Importing Exchange KMS Export File

The Windows Server 2003 CA may fail during the importation of the KMS data file if the key size used for the export certificate is greater than 1024 bits in size. The Windows Server 2003 CA may fail with the following message when a key size of greater than 1024 bits is used.

Processing KMS exports from:

   CN=Certification Authority, OU=Test, O=Contoso, C=US

 

KMS export file signature verifies

CertUtil: -ImportKMS command FAILED: 0x80070057 (WIN32: 87)

CertUtil: The parameter is incorrect.

User Enrollment Errors

A user certificate request for a template that requires key archival will be denied if one of the following conditions exists.

•   No KRA has been defined on the CA.

•   No KRA can be successfully loaded. (KRA certificates are revoked, expired, and so on.)

•   The minimum number of KRA certificates defined by the CA Administrator cannot be loaded.

If the user enrolls through a Web page, the following text will display on the Web page.

Your request failed. An error occurred while the server was processing your request.

Contact your administrator for further assistance.

Request Mode:

newreq - New Request Disposition:

(never set) Disposition message:

(none) Result:

Cannot archive private key. The certification authority is not configured for key archival. 0x8009400a (-2146877430) COM Error Info:

CCertRequest::Submit Cannot archive private key. The certification authority is not configured for key archival. 0x8009400a (-2146877430) LastStatus:

Cannot archive private key. The certification authority is not configured for key archival. 0x8009400a (-2146877430) Suggested Cause:

No suggestions.

If enrolling through the MMC, the following error will be displayed: The certificate request is incorrect. Cannot archive private key. The certification authority is not configured for key archival.

The CA will also log the following error to the application event log of the CA.

Event Type:   Error

Event Source:   CertSvc

Event Category:   None

Event ID:   21

Date:     1/12/2001

Time:     4:23:39 PM

User:     N/A

Computer:   SERVER1

Description:

Certificate Services could not process request 16094 due to an error: Cannot archive private key. No valid key recovery agent is defined for this certification authority. 0x8009400b (-2146877429). The request was for NWTRADERS\User1.

If the CA is unable to retrieve a current CRL for the CA itself or any of its parent CA(s), it will be unable to issue a certificate when a user submits a request. If the CA does not have a valid CRL for itself, the following error message will be displayed in the application event log of the CA.

Event Type:   Warning

Event Source:   CertSvc

Event Category:   None

Event ID:   53

Date:     1/6/2001

Time:     11:24:05 AM

User:     N/A

Computer:   SERVER1

Description:

Certificate Services denied request 1471 because the revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613). The request was for CN=user1, OU="Test", O="NWTraders", L=Redmond, S=WA, C=US, E=user1@nwtraders.com. Additional information: Denied by Policy Module

return to top

Certificate Template Not Supported by the CA

If a user tries to enroll with a CA for a template that is not supported by that CA, the following event log message will be entered in the CA application event log.

Event Type:   Warning

Event Source:   CertSvc

Event Category:   None

Event ID:   53

Date:     1/16/2001

Time:     2:07:02 PM

User:     N/A

Computer:   SERVER1

Description:

Certificate Services denied request 8 because the requested certificate template is not supported by this CA. 0x80094800 (-2146875392). The request was for NWTRADERS\Administrator. Additional information: Denied by Policy Module The request was for certificate template (1.3.6.1.4.1.311.21.8.4144336743.1329436349.2065260953.3989445610.1.27) that is not supported by the Certificate Services policy.

return to top

Client CSP Does Not Permit Key Export

For the client enrollment process to generate and send a private key to the CA, the key must be marked as exportable when the key is generated. If the certificate template is not set to allow key exportable or if the third-party CSP (if applicable) does not support exportable keys, enrollment will fail and the enrollment wizard will return an error that the key is not exportable. Third-party CSPs may report varying errors, such as “catastrophic failure”, when this occurs. If a Windows 2000 or Windows Millennium Edition client performs enrollment with key archival, the following error may appear if the key is not marked for export.

0x80090009 - NTE_BAD_FLAGS

Note: If the CSP supports the one-time flag for key archival, known as (CRYPT_ARCHIVABLE), the key export flag is not required. The Microsoft default software CSPs support this flag. However, Windows 2000 and Windows Millennium Edition clients do not support this flag and must allow the key to be exported for enrollment to work with key archival.

return to top

Certification Authority CSP Not Supported for Key Archival Functions

If a software or hardware CSP is not capable of performing the symmetric and public operations for encrypting the private key(s) of users in the CA database, the CA will log an event in the application event log:

Event Type:   Warning

Event Source:   CertSvc

Event Category:   None

Event ID:   86

Date:     12/27/2001

Time:     8:13:54 AM

User:     N/A

Computer:   NORTHWIND5

Description:

Certificate Services could not use the provider specified in the registry for encryption keys. The keyset is not defined. 0x80090019 (-2146893799)

For more information, see the Help and Support Center at http://go.microsoft.com/fwlink/events.asp

Event Type:   Warning

Event Source:   CertSvc

Event Category:   None

Event ID:   88

Date:     12/27/2001

Time:     8:13:54 AM

User:     N/A

Computer:   NORTHWIND5

Description: Certificate Services switched to the default provider for encryption keys.

For more information, see the Help and Support Center at http://go.microsoft.com/fwlink/events.asp

To verify which CSP the CA is using for encryption operations associated with key archival, run the following command from the CA.

Certutil –getreg ca\EncryptionCSP\Provider

return to top

Certificate and Key Import Issues

If the CA has not been configured for key archival or if the CA has not been configured for foreign key import, the following error will occur when attempting to import a KMS export file or a foreign key import. Note that the keys were not archived in the following message.

Processing KMS exports from:

   O=microsoft, C=US

KMS export file signature verifies

Lock box opened, symmetric key successfully decrypted

CertUtil: Invalid Signature.

CertUtil: Invalid Signature.

CertUtil: Invalid Signature.

CertUtil: Invalid Signature.

CertUtil: Invalid Signature.

CertUtil: Invalid Signature.

CertUtil: Invalid Signature.

CertUtil: Invalid Signature.

CertUtil: Invalid Signature.

CertUtil: Invalid Signature.

CertUtil: Invalid Signature.

CertUtil: Invalid Signature.

CertUtil: Invalid Signature.

CertUtil: Invalid Signature.

CertUtil: Invalid Signature.

CertUtil: Invalid Signature.

CertUtil: Invalid Signature.

Users: 6

Ignored signature certificates: 25

Certificates with keys: 17

Certificates not imported: 17

Keys: 17

Keys not archived: 17

CertUtil: -ImportKMS command completed successfully.

return to top

Unable to Recover User

If a CA performing key archival is also enabled for role separation with specific Certificate Manager restrictions, a Certificate Manager may not be able to recover a user certificate until the machine account of the CA has been added to the Pre W2K Compatible Access Group of the domain in which the recover user belongs. This is a necessary requirement for the CA to enumerate the group memberships of Certificate Managers and recovered users to ensure that proper restrictions are enforced.

return to top

Missing KRA Certificate in the CA Registry

If one of the recipient KRA certificates from the HKEY_LOCAL_MACHINE KRA certificate store on the Certification Authority is deleted, key recovery tools, such as certutil –getkey, will fail because the server cannot find the KRA certificate to include in the recovery BLOB. The following error message will be displayed when this error occurs.

certutil -getkey "1b 4a b7 1e 00 00 00 00 00 1d"

Querying server1.nwtraders.com\CA1............

 

"server1.nwtraders.com\CA1"

  1b4ab71e00000000001d  CN="Users

 

Administrator"

CertUtil: -GetKey command FAILED: 0x80092004 (-2146885628)

CertUtil: Cannot find object or property

Note that the KRA certificate must be available in the registry on the CA, not the machine where the recovery tool(s) are used.

return to top

Appendix A: Certificate Request Structure

This appendix provides additional detailed information about the key archival process regarding the certificate request structure.

return to top

ASN.1 Structure

A certificate request for key archival to the CA is a CMC Full PKIRequest message as specified in RFC 2797. The ASN.1 structure used by the Windows Server 2003 CA is demonstrated in the following figure.

return to top

Understanding the PKCS #7 Message Content Structure

The first section of the CMC message contains a PKCS #7 message that has the relevant elements for generating a certificate request.

return to top

Understanding the controlSequence TaggedAttribute Element

The TaggedAttribute element in the message contains the following information.

Extensions—The Extensions section of the TaggedAttribute element contains the following extensions.

• Application Policies
  • Template Information
  • Key Usage
  • Enhanced Key Usage
• Attributes—The Attributes section of the TaggedAttribute element contains the following data.
  • Common Name
  • Template Name to be used
  • Hash of the encrypted private key BLOB  
• Other request information

return to top

Understanding the reqSequence TaggedRequest Element

The reqSequence TaggedRequest element contains a nested PKCS #10 message. This message contains the user’s public key in addition to other information relevant for generating the certificate.

return to top

Understanding the cmsSequence TaggedContentInfo Element

The cmsSequence TaggedContentInfo element can contain nested PKCS #7 and CMC messages. In a standard archival request, this element is not used.

return to top

Understanding the otherMsgSequence OtherMsg Element

Not Used

return to top

Understanding the Signatures Structure

The signatures section of the CMC message contains one or more signatures used to sign the request. The following is an example of the signatures section.

Signer Count: 1

Signer Info[0]:

Signature matches request Public Key

CMSG_SIGNER_INFO_CMS_VERSION(3)

CERT_ID_KEY_IDENTIFIER(2)

   0000  81 92 56 3a c4 31 f8 82  0c 54 c9 d0 98 4f d8 c5

   0010  34 63 9e cc

Hash Algorithm:

   Algorithm ObjectId: 1.3.14.3.2.26 sha1

   Algorithm Parameters: NULL

Encrypted Hash Algorithm:

   Algorithm ObjectId: 1.2.840.113549.1.1.1 RSA

   Algorithm Parameters: NULL

Encrypted Hash:

   0000  c1 ae 90 a7 a3 0b 52 66  ea c4 d0 04 17 2e 94 95

   0010  14 20 06 ...

return to top

Understanding the Authenticated Attributes Structure

The authenticated attributes section contains additional authenticated attributes, such as Content Type, Message Digest, and Client Information. The following is an example of the authenticated attributes section.

Authenticated Attributes[0]:

  3 attributes:

  Attribute[0]: 1.2.840.113549.1.9.3 (Content Type)

   Value[0][0]:

   Unknown Attribute type

   1.3.6.1.5.5.7.12.2 CMC Data

  Attribute[1]: 1.2.840.113549.1.9.4 (Message Digest)

   Value[1][0]:

   Unknown Attribute type

   Message Digest:

     5e 1f 0f f0 28 a4 fe 91 0d c2 2f 1a 18 78 7e 2e 10 7f 17 39

  Attribute[2]: 1.3.6.1.4.1.311.21.20 (Client Information)

   Value[2][0]:

   Unknown Attribute type

   Client Id: = 1

   XECI_XENROLL -- 1

   User: CONTOSO0\avibm

   Machine: dcross-stress.contoso.com

   Process: certreq

return to top

Understanding the Unauthenticated Attributes Structure

The unauthenticated attributes section contains the encrypted private key. The private key is contained in an enveloped PKCS #7 message that is encrypted to the CA’s exchange key. Since this is an unauthenticated attribute, the SHA1 hash of the PKCS #7 message is included as one of the attributes of the controlSequence TaggedAttribute attributes.

The following is an example of the unauthenticated attributes section.

Unauthenticated Attributes[0]:

  1 attributes:  

  Attribute[0]: 1.3.6.1.4.1.311.21.13 (Encrypted Private Key)

   Value[0][0]:

   Unknown Attribute type

================ Begin Nesting Level 1 ================

PKCS7 Message:

  CMSG_ENVELOPED(3)

  CMSG_ENVELOPED_DATA_PKCS_1_5_VERSION(0)

  Content Type: 1.2.840.113549.1.7.1 PKCS 7 Data

 

PKCS7 Message Content:

0000   d4 a6 31 b6 5a ee 62 90  cc 17 b1 7a 6a 0d 40 9a

..1.Z.b....zj.@.

0010   33 fd 11 14 0b ae 12 bd  3b 32 b8 73 af cc 1b 76

3.......;2.s...v ...

return to top

Performing Binary Export for a Request

To view and decode a CMS key archival request from a Windows Server 2003 CA, it is necessary to do a binary export directly from the CA database. A binary export can be easily achieved through the Certification Authority MMC snap-in or by using the certutil.exe command-line tool.

return to top

Binary Request Export Using the Certification Authority MMC Snap-In Walkthrough

To export a binary request using the Certification Authority MMC Snap-in

1. Log on to the CA machine using a CA Administrator account.
2. Open the Certification Authority MMC snap-in.
3. Click the Issued Certificates folder.
4. If the binary request column has not been previously added to the database view, it must be added to support a binary request export. To add a column to the view, click View on the menu bar, and then select the Add/Remove Columns menu option.
5. In the Add/Remove Columns dialog box, select the Binary Request field in the Available Columns list box on the left.
6. Click Add, and then click OK.

Next, a binary request can be exported.

1. Select a request from the issued certificates view, and then click the Action menu.
2. Select Export Binary Data on the All Tasks menu.
3. In the Export Binary Data dialog box, choose Binary Request as the column you want to export.
4. Click OK.

The data will be exported into ASCII format that can be opened in Notepad using notepad.exe.

Note: Following the previous steps will generate a dump of the certificate archival request only; it does not include the private key material. To dump a full certificate archival request including the private key material, follow the command-line option.

return to top

Binary Request Export Using the CertUtil.exe Command-Line Tool Walkthrough

To use the certutil.exe to view the certificate request including private key material, a request file has to be generated first.

To generate a request file

Run Notepad.exe.

Paste the following certificate request information into Notepad.

[Version]

Signature= "$Windows NT$"

[NewRequest]

Subject = "CN=Test Subject"

KeySpec = 1

Exportable = FALSE

PrivateKeyArchive = TRUE

[RequestAttributes]

CertificateTemplate = EFS

Note: Make sure that the CA is configured for key archival before starting this process. In this example, the EFS template is used; this should be changed to an existing certificate template that allows private key archival.

Save the file as CertificateRequest.inf, and then close Notepad.

From a Command Prompt, type the following command.

Certreq –new CertificateRequest.inf CertificateRequest.req

Notes:

•  This command will prompt you to select the CA to fetch the CA exchange certificate from, and to encrypt the private key to.
•  This command will write the request to a file named by the last argument on the command line: CertificateRequest.req.
•  To avoid using the CA selection dialog, you can specify the CA via -config CAMachineDNSName\CACertCommonName before or after the –new option.

5.   Type the following command.

certreq -submit CertificateRequest.req KeyArchival.cer KeyArchival. p7b KeyArchival.rsp

This command will prompt you to select the CA to submit the request to.

Notes:

•  This command will write the newly issued certificate, a PKCS7 containing only the issued certificate and chain, and the full CMC response to files named by the last three arguments on the command line: KeyArchival.cer, KeyArchival.p7b, and KeyArchival.rsp, respectively.
•  To avoid the U/I, you can specify the CA via -config CAMachineDNSName\CACertCommonName before or after the –submit.

6.   Type the following command.

certreq -accept KeyArchival.rsp

This command verifies the response, installs the certificate, and associates it with the private key.

7.   Type the following command.

Certutil –privatekey –dump CertificateRequest.req >CertificateRequest.txt

This command will generate a dump of the certificate archival request into the CertificateRequest.txt file.  

8. Type the following command.

Certutil –privatekey –dump KeyArchival.rsp >CertificateResponse.txt

This command will generate a dump of the certificate archival response into the CertificateResponse.txt file.

For non-Windows Server 2003 clients or servers enrolling to a Windows Server 2003 CA, the format of the request may be different. The reason is that non-Windows Server 2003 platforms may not support CMC data structures and, therefore, may not be able to encode the request information inside a PKIData object. Instead, the request information may be inside the Data body but not encoded as a PKIData object.

Note: certreq.exe and other tools may be installed on a Windows Server 2003 Professional machine by installing the Administrative Tools (adminpak.msi) that are located in the \i386 directory on all Windows Server 2003 CD-ROM media.

return to top

CMC Request and Response Examples

Request:

SEQUENCE :  

 OBJECT IDENTIFIER :  signedData [1.2.840.113549.1.7.2]

 CONTEXT SPECIFIC (0) :  

   SEQUENCE :  

    INTEGER : 3

    SET :  

      SEQUENCE :  

       OBJECT IDENTIFIER :  sha1 [1.3.14.3.2.26]

       NULL :  

    SEQUENCE :  

      OBJECT IDENTIFIER :  [1.3.6.1.5.5.7.12.2]

      CONTEXT SPECIFIC (0) :  

       OCTET STRING :  

         SEQUENCE :  

          SEQUENCE :  

            SEQUENCE :  

             INTEGER : 2

             OBJECT IDENTIFIER :  [1.3.6.1.5.5.7.7.8]

               SET :  

                SEQUENCE :  

                  INTEGER : 0

                SEQUENCE :  

                  INTEGER : 1

                SEQUENCE :  

                  SEQUENCE :  

                   OBJECT IDENTIFIER :  [1.3.6.1.4.1.311.21.10]

                   OCTET STRING :  

                     SEQUENCE :  

                      SEQUENCE :  

                        OBJECT IDENTIFIER :  encryptedFileSystem [1.3.6.1.4.1.311.10.3.4]

                  SEQUENCE :  

                   OBJECT IDENTIFIER :  keyUsage [2.5.29.15]

                   OCTET STRING :  

                   BIT STRING UnusedBits:5 :  

                      20

                  SEQUENCE :  

                   OBJECT IDENTIFIER :  extKeyUsage [2.5.29.37]

                     OCTET STRING :  

                      SEQUENCE :  

                        OBJECT IDENTIFIER :  encryptedFileSystem [1.3.6.1.4.1.311.10.3.4]

                   SEQUENCE :  

                     OBJECT IDENTIFIER :  [1.3.6.1.4.1.311.21.7]

                     OCTET STRING :  

                      SEQUENCE :  

                        OBJECT IDENTIFIER :  

 [1.3.6.1.4.1.311.21.8.4014942.3497959.5914804.3829722.12246394.103.3066650.1537810]

                        INTEGER : 100

                        INTEGER : 2

             SEQUENCE :  

               INTEGER : 3

               OBJECT IDENTIFIER :  [1.3.6.1.4.1.311.10.10.1]

               SET :  

                SEQUENCE :  

                  INTEGER : 0

                  SEQUENCE :  

                   INTEGER : 1

                  SET :  

                   SEQUENCE :  

                     OBJECT IDENTIFIER :  [1.3.6.1.4.1.311.21.21]

                     SET :  

                      OCTET STRING :  

                        9231E6C0B87445190EA2CA934B2807FF799

                        3C59F

             SEQUENCE :  

               INTEGER : 4

               OBJECT IDENTIFIER :  [1.3.6.1.5.5.7.7.18]

               SET :  

                OCTET STRING :  

                  436572746966696361746554656D706C6174653D4172636

                  869766554657374426173696345465326

            SEQUENCE :  

             CONTEXT SPECIFIC (0) :  

               INTEGER : 1

               SEQUENCE :  

                SEQUENCE :  

                  INTEGER : 0

                  SEQUENCE :  

                   SET :  

                     SEQUENCE :  

                      OBJECT IDENTIFIER :  commonName [2.5.4.3]

                      PRINTABLE STRING :  

'Test Subject'

                  SEQUENCE :  

                   SEQUENCE :  

                     OBJECT IDENTIFIER :  rsaEncryption [1.2.840.113549.1.1.1]

                     NULL :  

                   BIT STRING UnusedBits:0 :  

                     SEQUENCE :  

                      INTEGER :  

                        00DAFF7C6859557C698CDA4598222E8E90E

                        EB481889531E9F67F10C081F2545B060BE7

                        714E755325AC710774764DCA8120C6BEB7B

                        6EF74B0260EDD56DD299B242A94EE83C420

                        AC7FF0E694122E26EF67670782223C4E8D8

                        12C98047F24E10CF6A26FEBEEB826638924

                        F36B697CEA02EFC4CA0D108CB85047266AD

                        27DE582D181A1

                      INTEGER : 65537

                  CONTEXT SPECIFIC (0) :  

                   SEQUENCE :  

                     OBJECT IDENTIFIER :  [1.3.6.1.4.1.311.13.2.3]

                     SET :  

                      IA5 STRING :  

                        '5.2.3790.2'

                   SEQUENCE :  

                     OBJECT IDENTIFIER :  [1.3.6.1.4.1.311.21.20]

                     SET :  

                      SEQUENCE :  

                        INTEGER : 1

                        UTF8 STRING :  

                         'dcross-stress.contoso.com'

                        UTF8 STRING :  

                         'CONTOSO0\avibm'

                        UTF8 STRING :  

                         'certreq'

                   SEQUENCE :  

                     OBJECT IDENTIFIER :  [1.3.6.1.4.1.311.13.2.2]

                     SET :  

                      SEQUENCE :  

                        INTEGER : 1

                        BMP STRING :  

                         'Microsoft Strong Cryptographic P'

                         'rovider'

                        BIT STRING UnusedBits:0 :  

                         00000000000000000000000000000000

                         00000000000000000000000000000000

                         00000000000000000000000000000000

                         00000000000000000000000000000000

                         00000000000000000000000000000000

                         00000000000000000000000000000000

                         00000000000000000000000000000000

                         00000000000000000000000000000000

                         0000000000000000

                   SEQUENCE :  

                     OBJECT IDENTIFIER :  extensionReq [1.2.840.113549.1.9.14]

                     SET :  

                      SEQUENCE :  

                        SEQUENCE :  

                         OBJECT IDENTIFIER :  sMIMECapabilities [1.2.840.113549.1.9.15]

                         OCTET STRING :  

                           SEQUENCE :  

                            SEQUENCE :  

                              OBJECT IDENTIFIER :  rc2CBC [1.2.840.113549.3.2]

                              INTEGER : 128

                            SEQUENCE :  

                              OBJECT IDENTIFIER :  rc4 [1.2.840.113549.3.4]

                              INTEGER : 128

                            SEQUENCE :  

                              OBJECT IDENTIFIER :  desCBC [1.3.14.3.2.7]

                            SEQUENCE :  

                              OBJECT IDENTIFIER :  DES-EDE3-CBC [1.2.840.113549.3.7]

                        SEQUENCE :  

                         OBJECT IDENTIFIER :  subjectKeyIdentifier [2.5.29.14]

                         OCTET STRING :  

                           OCTET STRING :  

                            8192563AC431F8820C54C9D098

                            4FD8C534639ECC

                        SEQUENCE :  

                         OBJECT IDENTIFIER :  [1.3.6.1.4.1.311.21.10]

                         OCTET STRING :  

                           SEQUENCE :  

                            SEQUENCE :  

                              OBJECT IDENTIFIER :  encryptedFileSystem [1.3.6.1.4.1.311.10.3.4]

                        SEQUENCE :  

                         OBJECT IDENTIFIER :  keyUsage [2.5.29.15]

                         OCTET STRING :  

                           BIT STRING UnusedBits:5 :  

                            20

                        SEQUENCE :  

                         OBJECT IDENTIFIER :  extKeyUsage [2.5.29.37]

                         OCTET STRING :  

                           SEQUENCE :  

                            OBJECT IDENTIFIER :  encryptedFileSystem [1.3.6.1.4.1.311.10.3.4]

                        SEQUENCE :  

                         OBJECT IDENTIFIER :  [1.3.6.1.4.1.311.21.7]

                         OCTET STRING :  

                           SEQUENCE :  

                            OBJECT IDENTIFIER :  

 [1.3.6.1.4.1.311.21.8.4014942.3497959.5914804.3829722.12246394.103.3066650.1537810]

                            INTEGER : 100

                            INTEGER : 2

                SEQUENCE :  

                  OBJECT IDENTIFIER :  sha1withRSAEncryption [1.2.840.113549.1.1.5]

                  NULL :  

                BIT STRING UnusedBits:0 :  

                  31E945A575155D8F91E972DB26A52C8FAE16D7F5074365D

                  C2E585C8718AB09A4FBB67D8A78A63C76B14482A1DEDCAA

                  5B234035F3CFFABCAF3DEC24C5944ACE46A1BAFE857F310

                  7C21105C817FA88C0CCB23B88D2684327B40CB99E9A059F

                  3B95BAC6423740CA1B46B4DC58664863325004DCA2857C2

                  2B4117942CC7D39E86900

            SEQUENCE :  

            SEQUENCE :  

      SET :  

       SEQUENCE :  

         INTEGER : 3

         CONTEXT SPECIFIC (0) :  

          8192563AC431F8820C54C9D0984FD8C534639ECC

         SEQUENCE :  

          OBJECT IDENTIFIER :  sha1 [1.3.14.3.2.26]

          NULL :  

         CONTEXT SPECIFIC (0) :  

          SEQUENCE :  

            OBJECT IDENTIFIER :  contentType [1.2.840.113549.1.9.3]

            SET :  

             OBJECT IDENTIFIER :  [1.3.6.1.5.5.7.12.2]

          SEQUENCE :  

            OBJECT IDENTIFIER :  messageDigest [1.2.840.113549.1.9.4]

            SET :  

             OCTET STRING :  

               5E1F0FF028A4FE910DC22F1A18787E2E107F1739

          SEQUENCE :  

            OBJECT IDENTIFIER :  [1.3.6.1.4.1.311.21.20]

            SET :  

             SEQUENCE :  

               INTEGER : 1

               UTF8 STRING :  

                'dcross-stress.contoso.com'

               UTF8 STRING : 'CONTOSO0\avibm'

               UTF8 STRING : 'certreq'

         SEQUENCE :  

          OBJECT IDENTIFIER :  rsaEncryption [1.2.840.113549.1.1.1]

          NULL :  

         OCTET STRING :  

          C1AE90A7A30B5266EAC4D004172E949514200653AA5EA3C2BF17C7731DA8EB

          1A635CE1DC4F5AD9FB44EF2D9E8C9F961800DBEBC1ADE14E0459A8B46880DF

          01A177FC9B02B89113638F3A6A3B3ED0765BD16B905D6BCB404F65E79AAB12

          97F2F9F52D68D13373D41D510D97A954800368F8DEDEE13D8635EBF4364512

          17407F1A

         CONTEXT SPECIFIC (1) :  

          SEQUENCE :  

            OBJECT IDENTIFIER :  [1.3.6.1.4.1.311.21.13]

            SET :  

             SEQUENCE :  

               OBJECT IDENTIFIER :  envelopedData [1.2.840.113549.1.7.3]

               CONTEXT SPECIFIC (0) :  

                SEQUENCE :  

                  INTEGER : 0

                  SET :  

                   SEQUENCE :  

                     INTEGER : 0

                     SEQUENCE :  

                      SEQUENCE :  

                        SET :  

                         SEQUENCE :  

                           OBJECT IDENTIFIER :  domainComponent [0.9.2342.19200300.100.1.25]

                           IA5 STRING :  

                            'com'

                        SET :  

                         SEQUENCE :  

                           OBJECT IDENTIFIER :  domainComponent [0.9.2342.19200300.100.1.25]

                           IA5 STRING :  

                            'contoso'

                        SET :  

                         SEQUENCE :  

                           OBJECT IDENTIFIER :  commonName [2.5.4.3]

                           PRINTABLE STRING :  

                            'TestEnrollment'

                      INTEGER :  

                        18D0100D00000000005B

                     SEQUENCE :  

                      OBJECT IDENTIFIER :  rsaEncryption [1.2.840.113549.1.1.1]

                      NULL :  

                     OCTET STRING :  

                      A41AAE9CDA66F283D6D4BC829D2F58BCECFD3F

                      5A57EC8AE14021179AE5F93F03AE90747FD300

                      4573ED78F802E02AB3C6ADEDEAA367069DA399

                      8E1D2D34ABEEFF0F8DE2CB76078C56D883BD94

                      D7CE9C5CD75F5E3F442A467F74E07C5A434E4A

                      F1BDD6EC493F3A870764B6CC6446FA5D674255

                      D93F248DE23E0D96902C79901800

                  SEQUENCE :  

                   OBJECT IDENTIFIER :  data [1.2.840.113549.1.7.1]

                   SEQUENCE :  

                     OBJECT IDENTIFIER :  DES-EDE3-CBC [1.2.840.113549.3.7]

                     OCTET STRING :  

                      06003B8D3EB4B44C

                   CONTEXT SPECIFIC (0) :  

                     D4A631B65AEE6290CC17B17A6A0D409A33FD11140

                     BAE12BD3B32B873AFCC1B76A4022D0FB2B50E431A

                     1E48C8D45865EC5B730D7357D61C9495235143381

                     19CDBF34C5455B73C9FF38AEFBC4E32DD8145647B

                     46B0B4A60D29D062051F116C6BA49253D4590944A

                     7CCB70F43E7E850B34DE55074B3C5FF5AE1C5A18C

                     6BC271D1F2BC3FBBE19558252C894110CC801292D

                     63DA1485BDB957270E6C1A38FE33D672EA3E8D031

                     CD7BCFEF5C738818DCC43A6F76F3EC81701C561DF

                     9FA6032C47236D9A16973BDF6A033F4925CC5B491

                     C00C635C65F744C8FEBE19B1EDD2172AE3A7CFB70

                     87A6BCAE7BB52BCEEF412889C4A45ACAE0ACC0E43

                     A14C7AA34FB4B4C49360ADD0C65D1494B792E04D7

                     8D43C2EDB79974B5C08C87E0C72767C26A2EBF6F0

                     E273269D139F2D6F451301944B76218D9BD4C5931

                     50C79FA5DA1AF1383E5342EC2F5318E2404774345

                     B82A0CB4EE26FC0D59A1D18EDBBEFF6135675D014

                     293470B301CC59387C4E627E1F6B038A158A927B9

                     160387104BFC5466B7FB4107DF02D136E076F2CAD

                     94718ADD9F93C0D376A80A6E3796C6236888E6517

                     1D36A0F3BFAA8B8E44FC8DA426F3F19128A910D83

                     71A7D68CDFEFCA0BBF32888D8AC679975AE43BB6D

                     209D61F82EEA2463616E905177E929CFD3D85C8ED

                     8ED1EDCECA01CA1580960E87D57591817C863FE33

                     757F527DC7C6457ED5CEDC3BE1597A05BFB10A145

                     522C98AF266A992CC607434D3421D57A80195D052

                     557AE89652193B840FC27CB343C2C242445453E78

                     9E6E397DFC84363B4EAE801DF1BE2993D1AF13256

                     A1390C4B7D51127CC55FF0B1184D4E87967961E86

                     B722E1048C0

Response

SEQUENCE :  

   OBJECT IDENTIFIER :  signedData [1.2.840.113549.1.7.2]

   CONTEXT SPECIFIC (0) :  

    SEQUENCE :  

      INTEGER : 3

      SET :  

       SEQUENCE :  

         OBJECT IDENTIFIER :  sha1 [1.3.14.3.2.26]

         NULL :  

      SEQUENCE :  

       OBJECT IDENTIFIER :  [1.3.6.1.5.5.7.12.3]

       CONTEXT SPECIFIC (0) :  

         OCTET STRING :  

          SEQUENCE :  

            SEQUENCE :  

             SEQUENCE :  

               INTEGER : 1

               OBJECT IDENTIFIER :  [1.3.6.1.5.5.7.7.1]

               SET :  

                SEQUENCE :  

                  INTEGER : 0

                  SEQUENCE :  

                   INTEGER : 1

                  UTF8 STRING : 'Issued'

             SEQUENCE :  

               INTEGER : 2

               OBJECT IDENTIFIER :  [1.3.6.1.4.1.311.10.10.1]

               SET :  

                SEQUENCE :  

                  INTEGER : 0

                  SEQUENCE :  

                   INTEGER : 1

                  SET :  

                   SEQUENCE :  

                     OBJECT IDENTIFIER :  [1.3.6.1.4.1.311.21.17]

                     SET :  

                      OCTET STRING :  

                        DE73D68A50323310A01EEDDF66188213DC9

                        CD490

                   SEQUENCE :  

                     OBJECT IDENTIFIER :  [1.3.6.1.4.1.311.21.21]

                     SET :  

                      OCTET STRING :  

                        9231E6C0B87445190EA2CA934B2807FF799

                        3C59F

            SEQUENCE :  

            SEQUENCE :  

      CONTEXT SPECIFIC (0) :  

       SEQUENCE :  

         SEQUENCE :  

          CONTEXT SPECIFIC (0) :  

            INTEGER : 2

          INTEGER :  

            172B1FB96BBBF2BA49A64EBEA41833EF

          SEQUENCE :  

            OBJECT IDENTIFIER :  sha1withRSAEncryption [1.2.840.113549.1.1.5]

            NULL :  

          SEQUENCE :  

            SET :  

             SEQUENCE :  

               OBJECT IDENTIFIER :  domainComponent [0.9.2342.19200300.100.1.25]

               IA5 STRING : 'com'

            SET :  

             SEQUENCE :  

               OBJECT IDENTIFIER :  domainComponent [0.9.2342.19200300.100.1.25]

               IA5 STRING : 'contoso'

            SET :  

             SEQUENCE :  

               OBJECT IDENTIFIER :  commonName [2.5.4.3]

               PRINTABLE STRING :  

                'TestEnrollment'

          SEQUENCE :  

            UTC TIME : '040210162354Z'

            UTC TIME : '090210162738Z'

          SEQUENCE :  

            SET :  

             SEQUENCE :  

               OBJECT IDENTIFIER :  domainComponent [0.9.2342.19200300.100.1.25]

               IA5 STRING : 'com'

            SET :  

             SEQUENCE :  

               OBJECT IDENTIFIER :  domainComponent [0.9.2342.19200300.100.1.25]

               IA5 STRING : 'contoso'

            SET :  

             SEQUENCE :  

               OBJECT IDENTIFIER :  commonName [2.5.4.3]

               PRINTABLE STRING :  

                'TestEnrollment'

          SEQUENCE :  

            SEQUENCE :  

             OBJECT IDENTIFIER :  rsaEncryption [1.2.840.113549.1.1.1]

             NULL :  

            BIT STRING UnusedBits:0 :  

             SEQUENCE :  

               INTEGER :  

                00E23136361B94412ABD67C376C6AC882B50F45D9AD28719C1

                5B0F3125CB352E19F5A381A33FF2971CC4702747BD94C3EE93

                75493C1A48F5174BE1F8135CCFB641F3EE6042C4771E8E176A

                7B65E49E407903072C28E2CC92153454664630FDA3CC70A805

                086B586592AF45BFFE5CC82DCF1ED622DD9BE4ECF64D635600

                9338C96F7D2EF77447F3ACD2AFC9C76EBC7A77DAAA9245A0EE

                0398D041B37DD78BD77C46D84A808AECDB88EC4319B1E6ADB9

                19053A84D3403163003EE696F65E0A55F5EA7A4955870D451E

                E4A0AB684EE6ED503437A3F4388DC96A00A9F7D26E3527B3D0

                F657EFB8E431B24A97ADBD1475DAF545B9754856200E640E42

                CA8BF78614A953

               INTEGER : 65537

          CONTEXT SPECIFIC (3) :  

            SEQUENCE :  

             SEQUENCE :  

               OBJECT IDENTIFIER :  [1.3.6.1.4.1.311.20.2]

               OCTET STRING :  

                BMP STRING : 'CA'

             SEQUENCE :  

               OBJECT IDENTIFIER :  keyUsage [2.5.29.15]

               OCTET STRING :  

                BIT STRING UnusedBits:1 :  

                  86

             SEQUENCE :  

               OBJECT IDENTIFIER :  basicConstraints [2.5.29.19]

               BOOLEAN : 'FF'

               OCTET STRING :  

                SEQUENCE :  

                  BOOLEAN : 'FF'

             SEQUENCE :  

               OBJECT IDENTIFIER :  subjectKeyIdentifier [2.5.29.14]

               OCTET STRING :  

                OCTET STRING :  

                  10C8E49879236E65350924C24EFB074EFB5F4AA0

             SEQUENCE :  

               OBJECT IDENTIFIER :  cRLDistributionPoints [2.5.29.31]

               OCTET STRING :  

                SEQUENCE :  

                  SEQUENCE :  

                   CONTEXT SPECIFIC (0) :  

                     CONTEXT SPECIFIC (0) :  

                      CONTEXT SPECIFIC (6) :  

                        'ldap:///CN=TestEnrollment,CN=dcross'

                        '-stress,CN=CDP,CN=Public%20Key%20Se'

                        'rvices,CN=Services,CN=Configuration'

                        ',DC=contoso,DC=com?certificateRevoc'

                        'ationList?base?objectClass=cRLDistr'

                        'ibutionPoint'

                      CONTEXT SPECIFIC (6) :  

                        'http://dcross-stress.contoso.com/Ce'

                        'rtEnroll/TestEnrollment.crl'

             SEQUENCE :  

               OBJECT IDENTIFIER :  [1.3.6.1.4.1.311.21.1]

               OCTET STRING :  

                INTEGER : 0

         SEQUENCE :  

          OBJECT IDENTIFIER :  sha1withRSAEncryption [1.2.840.113549.1.1.5]

          NULL :  

         BIT STRING UnusedBits:0 :  

          CA9E6760A8DFB0D213E90D7450B5C7A7C5C920760D01EB45E4F46A23780841

          40EDE1A37BA123934C06A39F9638F86C9A50258E43E71DE44239A20DFD6EAE

          C636F6B50C964EF23A72B349F35530A96CC99AF8937F22F684AF5E39E64C90

          F49C0D87621BBB13DE9FAF84609C26C5ECEB37F479CAEF826D36C19FD5C80D

          B865D0C6FF287DE8FF0CD3FE0476E514ED82D9A23DCB684D28E3B93A229A7B

          D4DAF89E9A2F2D62599B91E8746830BCF88947611A82E9893137ABBA74B489

          6C9C1492DCA2A7FA75F46451C7838EC0E9FB5D9222D3895C116C2C13E3995F

          6D56ACB5F62FD7B764FAAB5AF0B5EA73AF3211B40AE44697DCB6E0D28E88E9

          00037A506832C0BA

       SEQUENCE :  

         SEQUENCE :  

          CONTEXT SPECIFIC (0) :  

            INTEGER : 2

          INTEGER : '18E922D0000000000060'

          SEQUENCE :  

            OBJECT IDENTIFIER :  sha1withRSAEncryption [1.2.840.113549.1.1.5]

            NULL :  

          SEQUENCE :  

            SET :  

             SEQUENCE :  

               OBJECT IDENTIFIER :  domainComponent [0.9.2342.19200300.100.1.25]

               IA5 STRING : 'com'

            SET :  

             SEQUENCE :  

               OBJECT IDENTIFIER :  domainComponent [0.9.2342.19200300.100.1.25]

               IA5 STRING : 'contoso'

            SET :  

             SEQUENCE :  

               OBJECT IDENTIFIER :  commonName [2.5.4.3]

               PRINTABLE STRING :  

                'TestEnrollment'

          SEQUENCE :  

            UTC TIME : '040812185455Z'

            UTC TIME : '050812185455Z'

          SEQUENCE :  

            SET :  

             SEQUENCE :  

               OBJECT IDENTIFIER :  domainComponent [0.9.2342.19200300.100.1.25]

               IA5 STRING : 'com'

            SET :  

             SEQUENCE :  

                OBJECT IDENTIFIER :  domainComponent [0.9.2342.19200300.100.1.25]

                IA5 STRING : 'contoso'

             SET :  

              SEQUENCE :  

                OBJECT IDENTIFIER :  commonName [2.5.4.3]

                PRINTABLE STRING : 'Users'

             SET :  

              SEQUENCE :  

                OBJECT IDENTIFIER :  commonName [2.5.4.3]

                PRINTABLE STRING :  

                 'Avi Ben-Menahem'

           SEQUENCE :  

             SEQUENCE :  

              OBJECT IDENTIFIER :  rsaEncryption [1.2.840.113549.1.1.1]

              NULL :  

             BIT STRING UnusedBits:0 :  

              SEQUENCE :  

                INTEGER :  

                 00DAFF7C6859557C698CDA4598222E8E90EEB481889531E9F6

                 7F10C081F2545B060BE7714E755325AC710774764DCA8120C6

                 BEB7B6EF74B0260EDD56DD299B242A94EE83C420AC7FF0E694

                 122E26EF67670782223C4E8D812C98047F24E10CF6A26FEBEE

                 B826638924F36B697CEA02EFC4CA0D108CB85047266AD27DE5

                 82D181A1

                INTEGER : 65537

           CONTEXT SPECIFIC (3) :  

             SEQUENCE :  

              SEQUENCE :  

                OBJECT IDENTIFIER :  sMIMECapabilities [1.2.840.113549.1.9.15]

                OCTET STRING :  

                 SEQUENCE :  

                   SEQUENCE :  

                    OBJECT IDENTIFIER :  rc2CBC [1.2.840.113549.3.2]

                    INTEGER : 128

                   SEQUENCE :  

                    OBJECT IDENTIFIER :  rc4 [1.2.840.113549.3.4]

                    INTEGER : 128

                   SEQUENCE :  

                    OBJECT IDENTIFIER :  desCBC [1.3.14.3.2.7]

                   SEQUENCE :  

                    OBJECT IDENTIFIER :  DES-EDE3-CBC [1.2.840.113549.3.7]

              SEQUENCE :  

                OBJECT IDENTIFIER :  subjectKeyIdentifier [2.5.29.14]

                OCTET STRING :  

                 OCTET STRING :  

                   8192563AC431F8820C54C9D0984FD8C534639ECC

              SEQUENCE :  

                OBJECT IDENTIFIER :  [1.3.6.1.4.1.311.21.10]

                OCTET STRING :  

                 SEQUENCE :  

                   SEQUENCE :  

                    OBJECT IDENTIFIER :  encryptedFileSystem [1.3.6.1.4.1.311.10.3.4]

              SEQUENCE :  

                OBJECT IDENTIFIER :  keyUsage [2.5.29.15]

                OCTET STRING :  

                 BIT STRING UnusedBits:5 :  

                   20

              SEQUENCE :  

                OBJECT IDENTIFIER :  extKeyUsage [2.5.29.37]

                OCTET STRING :  

                 SEQUENCE :  

                   OBJECT IDENTIFIER :  encryptedFileSystem [1.3.6.1.4.1.311.10.3.4]

              SEQUENCE :  

                OBJECT IDENTIFIER :  [1.3.6.1.4.1.311.21.7]

                OCTET STRING :  

                 SEQUENCE :  

                   OBJECT IDENTIFIER :   

           [1.3.6.1.4.1.311.21.8.4014942.3497959.5914804.3829722.12246394.103.3066650.1537810]

                  INTEGER : 100

                  INTEGER : 2

             SEQUENCE :  

               OBJECT IDENTIFIER :  authorityKeyIdentifier [2.5.29.35]

               OCTET STRING :  

                SEQUENCE :  

                  CONTEXT SPECIFIC (0) :  

                   10C8E49879236E65350924C24EFB074EFB5F4AA0

             SEQUENCE :  

               OBJECT IDENTIFIER :  cRLDistributionPoints [2.5.29.31]

               OCTET STRING :  

                SEQUENCE :  

                  SEQUENCE :  

                   CONTEXT SPECIFIC (0) :  

                     CONTEXT SPECIFIC (0) :  

                      CONTEXT SPECIFIC (6) :  

                        'ldap:///CN=TestEnrollment,CN=dcross'

                        '-stress,CN=CDP,CN=Public%20Key%20Se'

                        'rvices,CN=Services,CN=Configuration'

                        ',DC=contoso,DC=com?certificateRevoc'

                        'ationList?base?objectClass=cRLDistr'

                        'ibutionPoint'

                      CONTEXT SPECIFIC (6) :  

                        'http://dcross-stress.contoso.com/Ce'

                        'rtEnroll/TestEnrollment.crl'

             SEQUENCE :  

               OBJECT IDENTIFIER :  authorityInfoAccess [1.3.6.1.5.5.7.1.1]

               OCTET STRING :  

                SEQUENCE :  

                  SEQUENCE :  

                   OBJECT IDENTIFIER :  caIssuers [1.3.6.1.5.5.7.48.2]

                   CONTEXT SPECIFIC (6) :  

                     'ldap:///CN=TestEnrollment,CN=AIA,CN=Publi'

                     'c%20Key%20Services,CN=Services,CN=Configu'

                     'ration,DC=contoso,DC=com?cACertificate?ba'

                     'se?objectClass=certificationAuthority'

                  SEQUENCE :  

                   OBJECT IDENTIFIER :  caIssuers [1.3.6.1.5.5.7.48.2]

                   CONTEXT SPECIFIC (6) :  

                     'http://dcross-stress.contoso.com/CertEnro'

                     'll/dcross-stress.contoso.com_TestEnrollme'

                     'nt.crt'

             SEQUENCE :  

               OBJECT IDENTIFIER :  subjectAltName [2.5.29.17]

               OCTET STRING :  

                SEQUENCE :  

                  CONTEXT SPECIFIC (0) :  

                   OBJECT IDENTIFIER :  [1.3.6.1.4.1.311.20.2.3]

                   CONTEXT SPECIFIC (0) :  

                     UTF8 STRING :  

                      'avibm@contoso.com'

         SEQUENCE :  

          OBJECT IDENTIFIER :  sha1withRSAEncryption [1.2.840.113549.1.1.5]

          NULL :  

         BIT STRING UnusedBits:0 :  

          9D0000D2CC5668BEE443EBDE5EE4CADA5D61C17C00B262A3F231726FD2E7A8

          500603B89BE123D577FA2AE592567FB96743A6AE9B57AE089B1C205D6552F5

          5D60DD825D94D27301527FDB275035473DFC16A4F0C4886036A50CA1D320E3

          D284744CC0E552D1FFB24CD6110E6B17C86F830B5CC7A7E1791930320373CA

          C4E667BC372983597713CF8608389A6C82F9079FF8666C867BF2243DE5A22C

          20DBDBAD788A77758B68D9260EA5040A2F5C97C1AD80144F06F714D20BF671

          96BE5774D16080A9EAA5933C3C7EA34AE3F41DC001E0C2F83EA7AFAADA4812

          D0F27C48E288A20C44F085F328CCE6F478D6E4E89131D8EF43DA7B23DA39C9

          8CB15DE2EBA2BC8F

      SET :  

       SEQUENCE :  

         INTEGER : 1

         SEQUENCE :  

          SEQUENCE :  

            SET :  

             SEQUENCE :  

               OBJECT IDENTIFIER :  domainComponent [0.9.2342.19200300.100.1.25]

               IA5 STRING : 'com'

            SET :  

             SEQUENCE :  

               OBJECT IDENTIFIER :  domainComponent [0.9.2342.19200300.100.1.25]

               IA5 STRING : 'contoso'

            SET :  

             SEQUENCE :  

               OBJECT IDENTIFIER :  commonName [2.5.4.3]

               PRINTABLE STRING :  

                'TestEnrollment'

          INTEGER :  

            172B1FB96BBBF2BA49A64EBEA41833EF

         SEQUENCE :  

          OBJECT IDENTIFIER :  sha1 [1.3.14.3.2.26]

          NULL :  

         CONTEXT SPECIFIC (0) :  

          SEQUENCE :  

            OBJECT IDENTIFIER :  contentType [1.2.840.113549.1.9.3]

            SET :  

             OBJECT IDENTIFIER :  [1.3.6.1.5.5.7.12.3]

          SEQUENCE :  

            OBJECT IDENTIFIER :  messageDigest [1.2.840.113549.1.9.4]

            SET :  

             OCTET STRING :  

               17CEEAA968CDD0A92DFC7E9AA174F87755AD8A87

         SEQUENCE :  

          OBJECT IDENTIFIER :  rsaEncryption [1.2.840.113549.1.1.1]

          NULL :  

         OCTET STRING :  

          C5D3AC35D5AAE5766640A2EF87D8ED005BB9BD63D51B10D803EEFEA1261161

          3031241F695A2EDFF0240EE624D22FECB5AB6B74FD97A5DB12B3B873558AD5

          0BC6DB59E438A7150A27749F53CBA447CD0751D7D49EEE3EBD1BBB20234887

          5DD11DE26764DDEB2EBFA1E0023DD8CECF9C2530E2D0886FF26EAB747635A7

          A57B7CA154BD0083A1DA891A35C3CD7EF5BA735FBCD2FD811FABE68C988C4D

          172572BE63AE0575CF646756D4E66B2B127A699119368AAFB8B54661D317AF

          2DF2622A0FFF01F18D5EF261E830107BD7F58848813CA6C0F8BF681A214E37

          13618340D6DE9594829FB2B2DB1CFF973DC01F22D982846E474DDB9767D1BF

          51E8C66F934593B5

return to top

Recovery BLOB Structure

When stored in the CA database, the private key is stored as a PKCS #7 message, encrypted with a 3DES symmetric key that is encrypted to the KRA(s) public key as a column in the CA database. When the recovery BLOB is retrieved by the certutil –getkey command, the encrypted PKCS #7 and the KRA certificate hashes are retrieved from the database. Also, the encrypted PKCS #7 is wrapped inside a signed PKCS #7 to allow collecting the previous certificates and attaching them to the signed PKCS #7. The PKCS #7 is not protected with a password since it is already protected by the public key of the recovery agent(s). The outer PKCS #7 wrapper can contain the certificate chains for the recovery agent(s) and the end-entity to facilitate the recovery operations and construction of the end-entity PKCS #12 file. The following figure illustrates the recovery BLOB structure.

The recovery BLOB consists of wrapping the encrypted PKCS #7 in the database in another (signed) PKCS #7 to allow a number of certificates to be included in the recovery BLOB. The returned certificates include the full chain of the user certificate being recovered, the chain of the signing CA certificate (which may differ from the CA certificate under which the user certificate was issued), and the KRA certificates to which the key was encrypted. The szOID_ARCHIVED_KEY_CERT_HASH(1.3.6.1.4.1.311.21.16) is an attribute containing the SHA-1 hash of the certificate for the key being recovered, attached as an authenticated attribute to the CA signature of the recovery BLOB. This allows certutil -recoverkey recoveryblobfile to also display the Subject name of the KRA certificate(s) used to protect the private key BLOB.

Note: If a Key Recovery Agent (KRA) certificate is stored in a Cryptography Next Generation (CNG) Key Service Provider (KSP), the certutil -RecoverKey command will by default recover a key as a CNG certificate. This default behavior could cause an issue if you are recovering a Rivest, Shamir and Adleman (RSA) key for the Encrypting File System (EFS). EFS supports KSPs only for Elliptic Curve Diffie-Hellman (ECDH) keys.

A workaround for this problem is to specify the switch -csp “Microsoft Strong Cryptographic Provider” with certutil -importpfx to ensure that the key is recovered in the appropriate format.

return to top

ASN.1 Structure

The following is the ASN.1 structure of the PKCS #7 EnvelopedData object.

EnvelopedData ::= SEQUENCE {

version               Version,

recipientInfos           RecipientInfos,

encryptedContentInfo     EncryptedContentInfo

}

Storing the recovery BLOB as an enveloped PKCS #7 enables a recovery agent to retrieve the recovery BLOB from the CA database. The recovery agent’s private key is used to decrypt the EncryptedContentInfo to extract the PKCS #12 data. The following is the ASN.1 structure of the EncryptedContentInfo body.

EncryptedContentInfo ::= SEQUENCE {

contentType              ContentType,

contentEncryptionAlgorithm   ContentEncryptionAlgorithmIdentifier,

encryptedContent[0]        IMPLICIT EncryptedContent OPTIONAL

}

By definition, there can be multiple recovery agent certificates specified by RecipientInfo, where IssuerAndSerialNumber is used to disambiguate between multiple recovery agent certificates. Only the recovery agent certificates included in the RecipientInfo body of the enveloped PKCS #7 object can be used to recover the archived key material. The following is the ASN.1 structure of the RecipientInfo body.

RecipientInfo ::= SEQUENCE {

version              Version,

issuerAndSerialNumber   IssuerAndSerialNumber,

keyEncryptionAlgorithm   KeyEncryptionAlgorithmIdentifier,

encryptedKey          EncryptedKey

}

return to top

Appendix B: Additional Information

• Understanding Key Archival
• Key archival and recovery
• AD CS Key Archival and Recovery Event IDs
• Internet X.509 Public Key Infrastructure – Certificate and Certificate Revocation List (CRL) Profile
• Certificate Management Messages over CMS (CMC)
• PKCS #12 - Personal Information Exchange Syntax Standard 
• Common Criteria
• Migrating Exchange KMS to Windows Server 2003 CA

return to top