How do I create PFX certificate export for Azure Website from Network Solutions intermediate and domain certificate files?

3
votes

I purchased an SSL certificate from Network Solutions website. I received 4 .crt files. I believe three of those are intermediate certificates and the fourth is the actual certificate for my web site domain name.

I tried importing the actual certificate with DigiCert utility. It errors on the three intermediate files. It lets me import the domain certificate and export the PFX file but that throws a warning in a browser - no issuer chain provided.

I used a domain controller running Windows Server 2008 R2 to import the Intermediate Certification Authorities in MMC, then IIS Complete Certificate Request with the domain certificate. The Certification Path of the certificate now looks proper but MMC Certificate Export Wizard option for PFX file is grayed out - disabled.

I used MMC Certificate Templates snap-in to create a copy of the Web Server template with Request Handling setting Allow private key to be exported checked. This template does not seem to be used when Complete Certificate Request in IIS because PFX export is still disabled. Complete Certificate Request doesn't offer to select which certificate template to use.

I tried using the certificate details, Copy To File selecting P7B with Include all certificates in the certification path. Completing the wizard shows Export Keys set to No and no way to change it. Saving file then double clicking to open it allows export but again PFX option is disabled.

What is the piece of the puzzle I am missing?

2
azurewebssl-certificatepfx
It is unclear from your posting what you are doing and what you want to accomplish. Just a set of unrelated steps. For what purpose you used DigiCert utility? For what purpose you are using IIS certificate request control? – Crypt32
Sorry for the confusion. I am trying to add an SSL certificate to Azure Website. Azure Website requires a PFX format certificate. I bought an SSL certificate from Network Solutions. Network Solutions provided 3 intermediate certificates and 1 domain certificate - AddTrustExternalCARoot.crt, DV_NetworkSolutionsDVServerCA2.crt, DV_USERTrustRSACertificationAuthority.crt, and mydomain.com.crt. Google suggests there are ways to convert the four crt files into a PFX file. I was trying to follow their suggestions. – RJBreneman
These files (*.crt) do not contain private keys and you cannot generate PFX from them. You need to acquire private key first. Where it is? It depends on how you requested certificate. It should be somewhere on your computer. Can you open certificate store and check whether there is anything in the LocalMachine\Request and CurrentUser\Request folders in the Certificates MMC? – Crypt32
Two days ago I created a new certificate request with IIS. I used it to request a certificate reissue from Network Solutions to make sure everything was being done on the same machine. I must have went through it twice as there are two Certificate Enrollment Requests under MMC Certificates (Local Computer) and none under Certificates - Current User. Those requests do have private keys in them. I received the new crt files from Network Solutions, imported the three intermediate certificates with MMC, then used IIS again to Complete Certificate Request with the 4th crt file. – RJBreneman
Again, the completed certificate has the proper path but apparently still no key as I cannot export PFX. Was there something that was supposed to merge the private keys of the request with the imported crt files from Network Solutions? Thanks for your help. Crypto sure appears to be its own field. – RJBreneman

2 Answers

2
votes

The problem you are having is with the actual SSL Certificate that Network Solutions issued. I worked with Microsoft on this for a while, but Network Solutions refuses to believe it is a problem.

Azure Websites rely on the AIA (Authority Info Access) attribute to be correct when issuing the certificate chain to clients. In the new SHA-2 certificates that Network Solutions is issuing, this is the value in the AIA element

[1]Authority Info Access Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2) Alternative Name: URL=http://crt.netsolssl.com/NetworkSolutionsOVServerCA2.crt [2]Authority Info Access Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1) Alternative Name: URL=http: //ocsp.netsolssl.com

If you note the URL for the first element, that should point to the first intermediate certificate in your chain. However that url throws a 404. In contrast, here is the AIA value from one of their older SHA-1 certificates

[1]Authority Info Access Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2) Alternative Name: URL=http://www.netsolssl.com/NetworkSolutions_CA.crt [2]Authority Info Access Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1) Alternative Name: URL=http: //ocsp.netsolssl.com

This URL is valid, and as such, the certificate chain can be successfully loaded by your clients.

So the only fix is for Network solution to put the NetworkSolutionsOVServerCA2.crt file in the location that their certificates say it is in. I have opened numerous tech support tickets with NetSol, and tried to convey this issue through a number of other means, but can never get to someone who acknowledges the issue, or is willing to kick it up the chain to someone with enough know-how to resolve the issue.

0
votes

There was something messed up in my certificate stores. I used MMC to delete all related certificate requests, intermediate certificates and completed certificates. Then I created a new certificate request and got a reissue from Network Solutions. Then I used MMC to import the intermediate .crt files into Intermediate Certificate Authorities. Then I used IIS to complete Certificate Request. Then I was finally able to export from MMC Personal certificate using Yes, Export the private key and Personal Information Exchange with Include all certificate in the certification path if possible and Export all extended properties. Alas, Azure website still reports no issuer chain was provided even though OpenSSL PEM file export from the PFX file uploaded to Azure clearly shows the four certificates in the chain! Now I have umbrage with Azure but that is another topic. My vote is clearly with the guy who stated, "OVER ENGINEEERED! IT DOESN'T HAVE TO BE THIS COMPLEX!". Sheesh, what were they thinking?