Many, many and many administrators request new certificates and mark private keys as exportable. Is this a good solution? Definitely no. Are there a reasons to do that? In most cases — no. Do I need to explain the subject? Definitely yes.

In many MS guides that are suited with custom certificate enrollment you may find certificate enrollment configuration INF file like this:

[NewRequest]
Subject = "CN=somename,O=company,C=US"
PrivateKeyArchive = FALSE
Exportable = TRUE
UserProtected = FALSE
MachineKeySet = TRUE
ProviderName = "Microsoft Enhanced Cryptographic Provider v1.0"
UseExistingKeySet = FALSE
RequestType = PKCS10

What exactly means selected line? This means that when certificate is issued, you can export the certificate with corresponding private key to a PFX container and move it to any other computer. Is this a risky? Let's see some featured examples.

Scenario 1

One internet-banking system obtained an SSL certificate from VeriSign. This can be an EV (Extended Validation) certificate, so bank customers will see a great green bar when they connect to internet-banking web site. Most likely administrators have used the selected line in the INF file. Now if server is gone off, or disks are damaged, administrators can restore the site and attach existing certificate (from PFX) with corresponding private key to the site. Very helpful feature. But...

Scenario 2

One internet-banking system obtained an SSL certificate from VeriSign. This can be an EV (Extended Validation) certificate, so bank customers will see a great green bar when they connect to internet-banking web site. Most likely administrators have used the selected line in the INF file. One malicious web administrator copied original web site content (customer registration window) to another rogue web server, exported the key from the original server and installed on fictional server. Now the malicious administrator can send internet-banking customers to rogue web site and get an access to customer accounts and money. As a result, reputation of the bank will be lost with its consequences.

Because multiple administrators have an access to web servers it is a big risk to allow to export the private key.

Scenario 3

One bank has obtained a certificate with exportable private key from VeriSign for sensitive document signing. Bank employee left his workstation to buy a coffee. It is not that uncommon when a user forget to lock his workstation. During this time another user can open local certificate store and export signing certificate to USB flash. Now malicious user can impersonate legitimate user, change document contents and sign them. Legitimate user will lost his work.

Because there always persist human factor, it is not possible to hold certificate private keys in a secure way (unless you are using hardware key storages -- smart cards), it strongly recommended to minimize the possibility of key loss or theft.

Scenario 4

Your organization has implemented network load balancing (NLB) cluster or a server cluster. Because all servers will serve the same host name, administrators generate single certificate with exportable private key and import the same certificate on all cluster nodes. I would like to quote Brian Komar on this case:

A common misconception is that the same certificate and private key pair must be deployed at each Web server in the cluster. Each node in the cluster does require its own certificate, but it is not necessary to deploy the same certificate and key pair at each node in the cluster. If a node in the cluster fails, all Web clients connected to that node must reestablish connections to another node in the cluster. Remember that this is a new SSL connection, which requires that a new symmetric session key be negotiated between the Web client and the Web server. In fact, if you purchase your Web Server certificates from a commercial organization, such as VeriSign or RSA, you might be required to purchase separate Web Server certificates for each node.

Scenario 5

Your organization implemented OCSP Responder for Offline CA (see more: The case of OCSP configuration for use with Standalone CAs). By default OCSP Responder re-enrolls signing certificate each 2 weeks. Because Offline CAs usually are turned off it is common when OCSP has independent signing certificate with longer validity period (from 6 months to several years). Because OCSP signing certificate never checked for revocation, it would be an Epic Fail when the key is lost. If someone gets an access to the OCSP signing certificate's private key, your revocation infrastructure will be no longer trusted, because anyone (who has an access to the signing key) can fabricate OCSP responses. As a result, your PKI will become compromised and you will have to rebuild your PKI hierarchy from Root CA (if OCSP signing certificate was issued by Policy CA, not Root CA, because is is possible to revoke Policy CA certificate) or from the scratch (if OCSP Signing certificate was issued by Root CA, because it is not possible to revoke Root CA cert).

Scenario 6

User has encrypted a confidential folder by using EFS. It is common when users forget their passwords. Suppose a user forget his password and asked tech support for password reset. Because EFS private keys are protected by original user password, after password reset the user will loose access to EFS encryption keys and encrypted confidential data. User will have to contact EFS recovery agent in order to get access to required confidential data.

Scenario 7

Your organization implemented secure mail, so each mail message MUST be encrypted. So far all is ok, but SUDDENLY the hard disk is failed. Administrator created a new profile and connected a user to his own mailbox. However user cannot read mail messages, because messages are encrypted and decryption key was only on failed hard disk.

We have discovered seven real-life scenarios and can summarize general cases when we MAY allow to export certificate private key and in others we MUST NOT allow this:

• You SHOULD allow the private key export that are used for user data encryption. Because these keys don't provide user or computer impersonation means it is recommended to implement private key archival or other key backup measures. As a better (but more expensive) solution you SHOULD implement smart cards and hold user certificates on them.
• You MUST NOT allow the private key export for keys that are used to sign data and authenticate users (client authentication, document signing, code signing). Because even if the private key is lost or stolen, users still will be able to access and validate signed data and it is very easy to revoke lost/stolen certificate and issue new one. As a better (but more expensive) solution you SHOULD implement smart cards and hold user certificates on them.
• You MUST NOT allow export for computer/machine private keys. Because computers don't sign or encrypt any long-term data except current secure communications. Therefore if particular computer's certificate is stolen, or computer changed its affiliation, ceased operation, you MUST revoke the certificate and issue a new one if required. As a better (but more expensive) solution you SHOULD store computer private keys on Hardware Security Module (HSM).

I still don't understand why Microsoft always include the flag Exportable = True in most certificate enrollment-related documentation, because there are no reasons except user encryption certificate scenarios and overal risks are higher than usability (as we discussed in scenario 1), because your company's reputation, data and money will gone off. Therefore if you see (even if this is Microsoft official document) the line: Exportable = True in the INF file, make sure if the target certificate is not EFS or mail encryption certificate and remove the line.

The key words "MUST", "MUST NOT", "MAY", "SHOULD" are to be interpreted as follows:

• MUST — this word mean that the definition is an absolute requirement of the specification.
• MUST NOT — this phrase mean that the definition is an absolute prohibition of the specification.
• MAY — This word, mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item.
• SHOULD — this word mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

(key word description source: RFC2119)