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

Question

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?

Answer 1

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.

Answer 2

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?