Applies to Windows 8 and Windows Server 2012

Introduction

When exporting a PKCS#12 (PFX) digital certificate file that includes the certificates private key, a password is typically assigned to the file to protect the private key from compromise. Several situations could result in reduced security of a PFX file secured with a password, such as:

• The passwords selected may be of limited length or complexity.
• Automation challenges, especially considering scripts in which the password is stored in the script.
• If a group of administrators require access to the same PFX, the password must be shared among them. Some added security considerations in this situation include:
  • The method by which the password is shared. How will the password be shared, email, verbally, or some other method?
  • Administrative group membership changes. What happens when an administrator leaves the group?

A new feature available to Windows 8 and Windows Server 2012 is to utilize Active Directory Domain Services (AD DS) accounts to protect the private keys contained within digital certificates in PKCS#12 (PFX) format. This is useful for the export, import, and sharing of digital certificates as PFX files. For example, a single PFX file could potentially be shared among multiple web servers in a web farm. Prior to Windows 8 and Windows Server 2012 you were given the opportunity to provide a password when exporting a certificate as a PFX file. Windows 8 and Windows Server 2012 provide a new dialog box when exporting a certificate that allows you to secure the file to an AD DS account, such as a group.


Return to top

Requirements

There are several requirements that must be in place for this feature to work:

• The digital certificate must be exported from a Windows 8 or Windows Server 2012 domain member.
• The certificate client must be joined to a domain with a Windows Server 2012 domain controller available.
• The digital certificate must be exported in the PKCS#12 (PFX) file format

Note: There is not a specific Active Directory forest or domain schema level required for this feature. However, you must have at least one Windows Server 2012 domain controller in the forest in order to utilize the option to protect the PFX to an AD DS account.

Command Line or Scripts

The export-pfxcertificate Windows® PowerShell cmdlet as well as the certutil command allow you to secure a PKCS#12 (PFX) file format certificate. For example, you can export a digital certificate using the -protectto parameter and specifying the account to which you want to protect the certificate. The following screen capture illustrates the enumeration of the certificates in the LocalMachine store and then the export of a specific certificate from that store using the certificate thumbprint and the -protectto parameter to specify the web servers group of the CPANDL domain. The command that performs this action is as follows.

export-pfxcertificate -cert 89473A116CCAAAB0B05412D8C1DDDE3EA693BC33 -protectto "cpandl\web servers" -filepath "C:\Exported PFXs\SSLCert.pfx"



The equivalent certutil command is:
certutil -f -protectto "cpandl\web servers" -exportpfx My 89473A116CCAAAB0B05412D8C1DDDE3EA693BC33 "C:\Exported PFXs\SSLCert.pfx"



Note: Certutil defaults to the localmachine store. If needed, use the switch -user to specify the user store.

Return to top

Allow older client computers to access the PFX

There is actually a password created on the exported PFX file, even when the file is secured to an AD DS account. This allows client computers prior to Windows 8 and Windows Server 2012 to access the file. As specified in PKCS#12, a password is used to derive an encryption key that is then used to encrypt the contents of the file. Regardless of the encryption algorithm is used, the encryption strength is partially dependent upon password strength (length and complexity).

When a PFX file is protected using an AD DS group, there is still a password generated by the system. The system creates a password based on a randomly generated 32-byte number which makes it a very strong password (the length of password in character is actually 40+ characters due to Base64 encoding of the random number). The system then encrypts the password using Windows 8 data protection APIs that allow protecting data to one or more security principals. Finally, the system adds the encrypted password to the PFX file.

When the PFX file is imported, the system sees that the PFX file has an encrypted password included and tries to unprotect it using data protection APIs. If the user or computer account that is trying to import the PFX file is in the list of security principals configured during export, the account is able to unprotect the password and gain access to the PFX contents.

You do not have to allow the system to set the password. You can both protect the PFX file to a group as well as set your own password. This may be useful if you plan to export the PFX file to a system that will only support passwords of a specified length. Further, you are not required to secure the PFX file to an AD DS account; you could just specify a password. However, if you want both secure the PFX file to an AD DS account and specify your own password, you can do so through the user interface or through the export-pfxcertificate cmdlet.



Return to top

Determine the system set PFX password

If you need to determine the password that the system has configured for an exported PFX, you can do so by using the Display Password option in the user interface during import. You can only display the password if you are using an account that was explicitly (or through group membership) granted permissions to the PFX file during certificate export.


 
The ability to see the system set password could be useful in cases where you need to import the PFX into a system that does not support AD DS account secured PFX files (for example, into client computers running operating systems prior to Windows 8 or Windows Server 2012).
 
Return to top