Understanding User Key Recovery
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
A recovery operation is initiated by an end-entity that has lost access to a private key. The key recovery process is explained in Figure 6.
.gif "Art Image")
Figure 6: Key Recovery Process
The following are the key recovery steps.
The Certificate Manager (CA Officer) locates and retrieves the user’s encrypted private key from the CA database. The encrypted BLOB(s) 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.
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.
The user imports the key to the user’s local, protected, keys store.
It is at the discretion of organizational policy 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 the Windows Server 2003 Certification Authority 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 include the following:
CA Administrator Configures and maintains the CA, designates other CA administrators and certificate managers, and renews CA certificates.
Certificate Manager Approves or denies certificate enrollment requests and revokes issued certificates.
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).
Auditor Defines what events are audited for Certificate Services and reviews the security log in Windows Server 2003 for success and failure audit events that are related to Certificate Services.
Note
Role-based administration is supported by both Windows Server 2003 Enterprise CAs and stand-alone CAs running Windows Server 2003, Enterprise Edition or Windows Server 2003, 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 and Common Criteria, see Appendix B: Additional Information.
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 Key Recovery Agents, see Implementing Key Archival Walkthrough.
Key Recovery Agent Certificate
A new certificate template exists in the Windows Server 2003 schema to support the KRA role. This certificate will use a unique Extended Key Usage extension to identify a KRA certificate. A Windows Server 2003 Certification Authority will only use 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 is marked as critical; however, the Key Recovery Object Identifier must exist in the Extended Key Usage extension for the certificate to be used.
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 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. It should be a best practice of any organization to
Validate the identity of a user requesting key recovery.
Separate the roles of CA Officer and KRA as a minimum of two physical persons.
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.
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>
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 Certification Authority.
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
Once the actual serial number of the certificate is known, the command may be run again with the serial number instead of the CN to retrieve the actual recovery BLOB.
Important
If a CA Administrator has configured the server to use, for example, three of a possible five available KRAs, certutil –recoverkey 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 listed by certutil -recoverkey.
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
Log on to a CA or a Windows XP Professional machine that has the Administration Tools pack installed as a CA Officer who has Certificate Management authority of the user(s) in question.
On the Administrative Tools menu, open Certification Authority.
In the console tree, expand Certification Authority, and then click Issued Certificates.
On the View menu, click Add/Remove Columns.
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.
Click OK.
In the details pane, scroll to the right and ensure that the last issued key has a value in the Archived Key column.
Double-click the user certificate.
Click the Details tab
Write down the serial number of the certificate (do not include spacing between digit pairs). This is required for recovery.
Click OK.
Close Certification Authority.
Command-Line Key Recovery
Command line key recovery is done by using the certutil.exe command-line tool. This tool is installed by default on the certificate server and it can be installed separately on a Windows XP Professional or Windows Server 2003 machine as part of the Windows Server 2003 Administration Tool Pack. The certutil.exe command structure was designed to perform batch and scripted processes.
Recovery Using the Certificate Serial Number
Once the serial number(s) is known, key recovery can occur through the certutil.exe command- line tool.
To recover private key(s)
Open a command-prompt window.
At the command prompt, type Certutil -getkey #################### outputblob where #################### is the serial number of the certificate that should be recovered and outputblob is the file name of the encrypted BLOB that is extracted from the CA database.
If a specific CA is to be targeted instead of all Enterprise CAs in the forest, use the following syntax.
Certutil -config <machine name\CA name> -getkey #################### outputblob
The outputblob file is a PKCS #7 file containing the KRA certificate(s) and the user certificate with its entire certificate chain. The inner content is an encrypted PKCS #7 structure containing the private key [encrypted to the KRA certificate(s)].
To decrypt the PKCS #7 encrypted BLOB, the logged on user must have the private key of one or more of the KRAs for the target encrypted BLOB. If the CA Officer is not a Key Recovery Agent, the CA Officer must transfer the encrypted BLOB file to a user that holds a KRA private key for further processing.
At the command prompt, type the following command:
Certutil -recoverkey outputblob user.pfx –p password where:
outputblob is the encrypted PKCS #7 file to be decrypted.
user.pfx is the output file name for the user private keys in PKCS #12 format.
password is the password for the *.pfx file.
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 in 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 their local store, they will receive an error.
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
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
Recovery Batch File
The certutil.exe –getkey command is an advanced tool that can be used with explicit commands and 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
Outputfile:
@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.
The tool finds all possible CAs that are registered in Active Directory. Then, it will query each CA for keys that have been archived for the specified user.
@goto start Querying northwind5.nwtraders.com\TestCA9.....................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 a3The 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"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"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"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
Note that the following output is expected when the user has multiple archived keys.
CertUtil: -GetKey command FAILED: 0x8002802c (-2147319764)
CertUtil: Ambiguous name.
This 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.
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> with no output file name will list the certificate hashes (thumbprints) 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 probably a good best practice to keep the list of all KRA certificates 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 previously.
Setting the Timeout Option
When keys are recovered from a CA using the command line or the key recovery tool, 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 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 Appendix B: Additional Information.
Using the Key Recovery Tool
The key recovery tool is a Windows Server 2003 Resource Kit tool for recovering keys from a Windows Server 2003 CA instead of using the certutil.exe command-line tool.
The tool may be launched from the command line by running krecover.exe. The tool is dependent on the existence of the certutil.exe and other binaries, which are available by default in Windows Server 2003 and in the Administration tool pack of Windows XP Professional. The tool is also dependent on one dynamically linked library (crutredir.dll), which is installed by the resource kit.
When launched, the tool will look similar to the following:
.gif "Art Image")
Figure 7: Key Recovery Tool Interface
The tool will automatically enumerate the forest for the currently logged on user and identify Enterprise CAs that may have archived private keys stored. The tool will filter out the following from the list of available CAs.
CAs that are not Enterprise CAs
CAs that are not running Windows Server 2003, Enterprise Edition
CAs that are running Windows 2000
CAs that the current user does not have CA Administrator or CA Manager permissions for
The following are several options enabled by the tool.
Search—Allows a Certificate Manager to search for archived keys for a user based on several search criteria options.
Recover—Allows a Certificate Manager who holds a KRA private key to recover a user from a CA database.
Show KRA—Displays the valid KRA certificates that may decrypt the user private key.
Retrieve BLOB—Allows a Certificate Manager to retrieve the encrypted user’s private key from the database for the purpose of transferring to a KRA.
Decrypt BLOB—Allows a KRA to decrypt and create a *.pfx file for an encrypted BLOB retrieved from the database by a Certificate Manager.
If the user does not have adequate permissions on the CA to recover a user or is not a Certificate Manager, an error similar to the following will be displayed.
.gif "Art Image")
Figure 8: Failed to enumerate the KRA certificates Error Message
Recovering a Specific User’s Keys
To recover the private key(s) of a specific user, enter a user name and click List to list all the certificates for that user with an archived key. In the User Name field, enter the user name (as described previously), or domain\user_name, or user_name@northwindtraders.com—any input that is valid for the certutil -getkey command.
Important
For the key recovery tool to recover a key for a user, the same permissions apply as in the certutil.exe command-line as described in the previous section.
If no key(s) is found for the selected user on the selected CA(s), the following dialog box will appear.
.gif "Art Image")
Figure 9: No archived keys were found Message
– or –
.gif "Art Image")
Figure 10: No archived keys were found Message
Here, you can select one or more certificates to be recovered, and then click Recover. If you select more than one certificate, you will be prompted if you want all the keys to be recovered in a single *.pfx file, or if you want separate *.pfx files for every certificate.
.gif "Art Image")
Figure 11: Single or Separate *.pfx Prompt Message
In either case, you will be prompted for a destination for the *.pfx file. The dialog box looks like the following:
.gif "Art Image")
Figure 12: Output File Dialog Box
When saving a *.pfx file, the tool will prompt for a location to save the *.pfx file and require a password to be set on the PKCS #12 file. When recovering a single private key, the default name for the *.pfx file will be the certificate serial number that corresponds to the private key. The output file name may be changed.
If the tool cannot recover a key for a user, the following dialog box will be displayed.
.gif "Art Image")
Figure 13: Recovery Failure Message
If you do not have a valid certificate and private key for a KRA that was used to encrypt and archive the private key of the user on the CA, the following error will be displayed.
.gif "Art Image")
Figure 14: Invalid Certificate and Private Key Message
Recovering Version 1 and Version 3 Certificates
A Windows Server 2003 CA may be used to archive both X.509, and version 1 and version 3 certificates as detailed previously. The key recovery tool allows recovery of both types, although x.509 version 1 certificates must be exported separately as they may only be exported in the *.epf format for Outlook. The Windows Server 2003 CA supports the following version 1 certificates and keys to be imported and exported from the database.
Profile Version=2, CAST=3, Protection=40, EPFALG_CAST_MD5
Profile Version=2, CAST=3, Protection=64, EPFALG_CAST_MD5
Profile Version=3, HashCount=0, Protection=128, EPFALG_RC2_SHA
Profile Version=3, Protection=128, EPFALG_3DES
If no version 1 certificates are in the recovery selection, the user will not be prompted any differently. If one x.509 version 1 certificate is in the selection, the user will be prompted for an *.epf file name for export. If more than one x.509 version1 certificate is selected, the user will be prompted whether the user would like one *.epf file or separate *.epf files for each key recovered. X.509 version 1 certificates will be recovered first and then the x.509 version 3 certificates will be recovered. If both version 1 and version 3 certificates have been selected, the user will be prompted twice whether the certificates should be recovered in a single file or separate files. X.509 version 1 and version 3 certificates may not be recovered in a single file together.
Importing Recovered Keys
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.
To import a recovered key for an individual user
Log on as the user who needs to recover their private key(s).
Click the Start button, and then click Run.
Type mmc.exe, and then press Enter. An empty MMC shell starts up.
Select the Console menu, and then click Add/Remove Snap-in. A dialog box appears with a list of all the snap-ins that have been added to this MMC shell.
Click Add.
A list appears with all the registered snap-ins on the current machine.
Double-click the Certificates snap-in, choose My User Account, and then click Finish.
In the Add Standalone Snap-in dialog box, click Close, and then click OK in the Add/Remove Snap-in dialog box.
The MMC now contains the personal certificate store for the user.
Expand the tree view of the certificate store. Click Certificates, Current User, Personal, and then Certificates.
In the console tree, right-click Personal, click All Tasks, and then click Import.
In the Certificate Import Wizard dialog box, click Next.
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.
On the Password page, in the Password box, type the password for the key file, and then click Next.
On the Certificate Store page, click Automatically select the certificate store based on the type of certificate, and then click Next.
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.