Unable to Export certificates as Personal Information Exchange - PKCS #12 (.PFX) file format
Posted on 2012-04-10 18:54 Leo.W 阅读(524) 评论(0) 编辑 收藏 举报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
February 18th, 2010 11:27pm
Too late to fix the existing.Your certificate template must allow export of private key (enable the option on the Request Handling tab - if I remember correctly). The ability to export the private key is determined at the time of key generation (prior to creation of the actual certificate).Can you tell me more about your scenario? In many cases, IIS can have different certificates in a LBS cluster, as long as the subject information is identical on each node. That being said, there are some apps that do require the same certificate. In those cases, you need to move towards custom requests (not domain requests) that request a custom certificate template that enables key exportBrian
February 19th, 2010 12:09am
Thank you Brian for the quick reply. I do have a check box in the "Allow private key to be exported" section on the Request Handling tab, that's why this is driving me crazy. Well all this was prompted by an error when trying to use IIS on a Windows Server 2008 to request a Domain Certificate from a Windows 2003 CA. Create Certificate The certificate request was submitted to the online authority, but was not issued, The request was denied. I have permissions on the template set to: Authenticated Users - Read, Write, Enroll The2008Server$ - Read, Write, Enroll Domain Admins - Read, Write, Enroll Domain Computers - Read, Write, Enroll I am able to run the Certificate MMC and request it that way and it works.
February 19th, 2010 12:39am
You cannot do a Domain request as it is hard coded to request the Web Server certificate template, not your custom template that you have created that enables key export.- you can verify this by doing a dump of the binary request that failed. CHeck out the actual certificate template requestedBrian
February 19th, 2010 12:51am
dope, thank you very much Brian that explanation helps a lot, I wish the error message said that instead of "check your permissions you idiot" you don't know how much hair I lost trying to troubleshoot this
February 19th, 2010 4:21pm
OK, I don't mean to beat a dead horse to death, but... On my Windows Server 2003 Enterprise Edition SP2 Certificate Authority server I launch the Certificate Authority MMC, I click on Issued Certificates, then I find and click on the Web Server certificate I issued to a Windows 2008 Server Standard Edition SP2 based on a duplicated template version 100.7 with the export private key enabled feature on, then I click on the Details tab and Copy to File button, that launches the Certificate Export Wizard I click on Next and the Personal Information Exchange - PKC #12 (.PFX) is grayed out ... but ... when I go to the Windows 2008 Server Standard Edition SP2 that got the certificate and launch the Certificate MMC and go to Certificates (Local Computer) \ Personal \ Certificates and doble click on the issued certificate then go to the Details tab click on Copy to File button and launch the Certificate Export Wizard, click Next, say Yes, export the private key, click Next, then the Personal Information Exchange - PKC #12 (.PFX) is available. THAT MAKES ABSOLUTELY NO SENSE TO ME I reissued the cert a few times and same result every time.
February 19th, 2010 11:15pm
This means that Microsoft listened when people stated that they wanted to be able to export Web server certificates.In the *newer* build, you are able to do that.In the *older* build you cannotRemember what I said earlier, the decision whether the private key is exportable is made **before** the request is event sent to the CA. You can override this option in the certificate template. So Windows SErver 2008 does. Windows Server 2003 does not.Brian
February 20th, 2010 1:11am
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 StephensJonathan Stephens
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 StephensJonathan Stephens
April 19th, 2010 1:23am
Jonathan,
that was really helpful, But i am still having issues with the export.
i am pretty much on the same situation, and no matter what, i can't export the private key. i have setup the template to archive the key, export the key, but still, it's not letting me export the key. I also tried to export from the machine where i installed
the certificate but no luck.
I am trying to deploy the wireless security using computer certificate, and i don't thing it will work without the private key installed on the machine.
thanks,
julu007
that was really helpful, But i am still having issues with the export.
i am pretty much on the same situation, and no matter what, i can't export the private key. i have setup the template to archive the key, export the key, but still, it's not letting me export the key. I also tried to export from the machine where i installed
the certificate but no luck.
I am trying to deploy the wireless security using computer certificate, and i don't thing it will work without the private key installed on the machine.
thanks,
julu007
January 8th, 2011 4:26pm
Click on the issued certificate and copy to a file.
Double click the newly created file and select "Install Certificate"
The Import Wizard opens, select Next.
Select "Automatically select the certificate store...", click Next
Click Finish
Now go to MMC and add snapin.
Click Certificates and select Certificates - My user account, click Finish
Now go into Certificates- Current User
Personal
Certificates
Right Click the certificate you just imported and select export
Select next
You can now export the .pfx file with password.
March 24th, 2011 12:19pm
