Unable to Export certificates as Personal Information Exchange - PKCS #12 (.PFX) file format.

Question

We are using Windows 2003 Certificate Authorities, and we are unable to Export certificates as .PFX, our only options are, DER encoded binary X.509 (.CER), Base-64 encoded X.509 (.CER), or Cryptographic Message Syntax Standard - PKCS #7 Certificates (.P7B).  The .PFX option is grayed out in the Certificate Export Wizard on the CA.
This posses a problem because our Windows 2008 server running IIS 7 wants us to import a certificate as .PFX
can someone explain what is happening and how to fix it please

Answer 1

Greg --
The private key doesn't exist on the CA, but it does exist on the computer on whic you created the request. Here's what happens when you request a certificate.
If you're generating a request with a new key pair -- which you will in the vast majority of cases -- Windows first generates the public and private key pair. The private key is written to a key store. Where the key store is located will depend on which
Cryptographic Service Provider (CSP) or Key Storage Provider (KSP) is specified in the template. KSPs were introduced in Windows Server 2008/Vista, and are only available in v3 templates. In the case of most of the default Microsoft CSP/KSPs (with the exception
of those used with Smart Cards), the key store is located in either the user's profile, or in the case of computer certificates, the All Users profile. It is at this point, by the way, that the properties of that private key are also written to the key store.
One property of interest to you immediately is whether or not Windows should allow the private key to be exported.
Once the key pair is generated, the request is then created. The request contains the information that should be in the certificate. This information is generally specified by the template with the exception of the Subject field, which contains the Common
Name or Distinguished name of whoever is requesting the certificate. In the case of IIS, the Subject will be your site name. The public key is included in the request. Windows then signs the request with the newly created private key.
Windows also creates a dummy certificate object in the Certificate Enrollment Requests store so that it knows that there is an outstanding request.
At this point, the request is saved to a file or sent to an online CA depending on how you generated the request. Note that the private key is
not sent to the CA in most cases. The exception to this rule occurs when you have Key Archival enabled on the CA, and the template specifies that the private key should be archived in the CA database. If this is the case, Windows retrieves
the CA Exchange certificate from the CA and uses the public key in that certificate to encrypt the newly created private key. This encrypted private key is included in the request.
Once the CA receives the request, it processes that request to determine if it should issue the certificate or not. In the case of the Enterprise CA, this decision is based on the permissions on the template. One can also specify that certain templates
require CA manager approval before they can be issued. Assuming that everything is correct in the request, and that the necessary information can be retrieved from Active Directory (perhaps the user's email address, or the computer's DNS host name -- it depends
on the settings in the template), and that any CA Manager approvals specified in the template have been performed, the CA builds the certificate and signs it with its current private key. The certificate has been created.
This certificate is stored in the CA database, which is why you can export it in the Certificate Authority snap-in. If the encrypted private key for that certificate has been included in the request to be archived, the CA decrypts it first with its CA Exchange
private key, and then re-encrypts it using the public key(s) for any Key Recovery Agents configured on the CA. The newly encrypted private key is also stored in the CA database. Note that this encrypted private key can only be retrieved and decrypted
by a valid KRA.
The CA then returns the certificate to principal who requested it. If the request was first saved as a file and then submitted to the CA you have to retrieve the certificate manually. It is only returned automatically if you submitted the request via the
Certificiates MMC, or if the application you use to submit the request retrieves it for you. IIS does this, when you use the certificate request wizard to request a Web Server certificate.
When the client has received the certificate, it locates the dummy certificate object in the Certificate Enrollment Requests store. From this object, Windows copies the location of the key store for the private key (among other things). This dummy certificate
object is then deleted, and the new certificate is imported into the Personal store. The private key information is then written to an internal property of the certificate in the store. This is how Windows locates the private key of that certificate in order
to use it when you invoke the associated certificate.
When you go to export the certificate and private key, Windows reads the private key locate information from the certificate properties in order to find the key store wherein it is located. Assuming export is allowed, the certificate and private key are written
to a password protected PFX file.
That's how a certificate request gets turned into a certificate, and explains why the private key doesn't exist on the CA. If you need to generate a PFX file, then you'll have to export the certificate from the computer on which you generated the request.
Hope this helps.
Jonathan Stephens
Jonathan Stephens