Error HRESULT: 0x80070520 when adding SSL binding in IIS

Today I will be discussing the very infamous error that is seen while adding a SSL binding in IIS 7 & higher. Below is a snapshot of the error message while trying to add the SSL binding in IIS.

Well, the error is definitely not descriptive enough, neither does it provide any vital information to troubleshoot the issue. However, if you look at the Event logs, you will find the clue and the reason why the error is seen.

The event logs should give you some clue regarding the problem. The primary reason for the above error is the problem in accessing the “Private Key” of the certificate due to a broken keyset.

For those who may not be following, Public Key Cryptography deals with “Public Key” & “Private Key”. The Public key is distributed to the clients, while only the Server has access to the Private key as it is used for decrypting the SSL Request. So “Private Key” is of utmost importance here.

There are few scenarios where we could see a problem accessing the “Private Key” of the SSL Cert. I will discuss a few in this article:

SCENARIO 1

The most common scenario is when the users use the IIS MMC to import a certificate and they uncheck the option “Allow this certificate to be exported”. This results in a broken keyset and thus results in the problem.

Solution:

There are 2 ways to fix this problem. Before we start off, delete/remove the existing certificate from the store.

1. If using IIS MMC to import the certificate, then ensure that the “Allow this certificate to be exported” is checked.
2. If making the private key exportable is not an option, then use the Certificates MMC to import the certificate. Please go through the following KB on how to import a certificate using the MMC: https://support.microsoft.com/kb/232137

SCENARIO 2

Another reason which can result in a broken keyset is due to missing permissions on the MachineKeys folder. This is the location where all the private keys are stored. The folder path (IIS 7 & higher) is as shown below: C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys

The default permissions on this folder are described in the following articles:

https://support.microsoft.com/kb/278381

https://msdn.microsoft.com/en-us/library/ee248638(v=vs.100).aspx

Solution:

Firstly, delete/remove the broken certificate from the store. Ensure the permissions are as per the articles mentioned above. So we need to permissions to the Administrators and Everyone account. Do remember to select the

After giving the necessary permissions, re-import the certificate as described in SCENARIO 1.

SCENARIO 3

There is another possibility, that the issue might occur even after ensuring the both mentioned above. I have observed this behavior typically on Windows Server 2008. This depends on the KeySpec property of the certificate.

The KeySpec property specifies whether the private key can be used for encryption, or signing, or both.

The following MSDN article describes KeySpec property:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa379020%28v=vs.85%29.aspx

In order to examine the KeySpec property of the certificate, use the following command:

NOTE: In the above command the thumbprint information can be found in the details tab of the certificate. The following are valid commands:

certutil -v -store my "32 b5 39 8e d3 c9 c6 f1 a3 50 bc d4 b5 14 eb b5 a4 5d 1f c6"

certutil -v -store my "32b5398ed3c9c6f1a350bcd4b514ebb5a45d1fc6"

certutil -v -store my 32b5398ed3c9c6f1a350bcd4b514ebb5a45d1fc6

Get the output of the above command in a notepad and then search for KeySpec, which is part of the CERT_KEY_PROV_INFO_PROP_ID section. The KeySpec is represented as a hexadecimal value.

As described above it can take three values:

So the issue is seen if the KeySpec value is set to anything other than 1. The issue is more likely to be occur when the CSR is generated using a custom template and the KeySpec is not specified.

Whenever the KeySpec attribute is not explicitly specified, it takes the default value of 2 i.e., it can be used for signing purposes only.

Solution:

So one thing that you need to remember is that the KeySpec attribute has to be specified explicitly.

1. If you are generating a certificate via the code, then ensure you are explicitly setting the KeySpec attribute to 1.
2. If using certreq.exe utility along with an inf file to submit a request to SAN, ensure that you explicitly specify the KeySpec attribute to be 1.
   • Refer the following article for this: https://support.microsoft.com/kb/931351
3. Remember the KeySpec attribute is specified while creating the Certificate Signing Request. This cannot be modified once the certificate has been issued. So remember to set the value appropriately.
4. Also compare the KeySpec with the Key Usage attribute and make sure that both match logically.
   For example, for a certificate whose KeySpec equals to AT_KEYEXCHANGE, the Key Usage should be
   XCN_NCRYPT_ALLOW_DECRYPT_FLAG | XCN_NCRYPT_ALLOW_KEY_AGREEMENT_FLAG.

     More Information: 

For further read on KeyUsage refer the below 2 links:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa379021%28v=vs.85%29.aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/aa379417%28v=vs.85%29.aspx

Configuring and Troubleshooting Certificate Services Client–Credential Roaming: https://technet.microsoft.com/en-us/library/dd277392.aspx

How to create a certificate request with CertEnroll (JavaScript): https://blogs.msdn.com/b/alejacma/archive/2009/01/28/how-to-create-a-certificate-request-with-certenroll-javascript.aspx

Generating a certificate (self-signed) using PowerShell and CertEnroll interfaces: https://blogs.technet.com/b/vishalagarwal/archive/2009/08/22/generating-a-certificate-self-signed-using-powershell-and-certenroll-interfaces.aspx

Hope this helps.

Comments

• Anonymous
  December 12, 2012
  Thanks, great help!

• Anonymous
  January 10, 2013
  Glad this helped you.

• Anonymous
  February 27, 2013
  YOU S A V E D my life :-)

• Anonymous
  February 28, 2013
  :)

• Anonymous
  October 10, 2013
  Great article, I had this very same problem and the only way I was able to bind my new cert was through IIS and not use MMC when importing the .PFX, works like a charm. Cheers!

• Anonymous
  January 22, 2014
  Turns out that "Cloning" a virtual (VMWare) server with a site already set up with SSL in it - produces the same issue. Fix: Remove the (pre) existing certificate, Import it again to you IIS and bind to your site.

• Anonymous
  January 23, 2014
  @nanneq.. Looks like there might be a concern with the way the cloning is performed. I'm not sure what is at fault here. This would need further investigation to narrow down the root cause.

• Anonymous
  April 09, 2014
  Thanks a lot, SOLUTION 1 fixed my problem !!!

• Anonymous
  April 15, 2014
  Great Info.. right on the target :) Thanks!!

• Anonymous
  July 24, 2015
  Thanks had tried everything then came accross your scenario 2 which worked......Great

• Anonymous
  September 24, 2015
  Thanks for the post, It really helped. When I install the certificate on server and run above Certutil command it shows Keyspec =0 while when same certificate installed on my local computer it shows Keyspec=1. I did checked the permissions and marked certificate as Exportable. Not getting a way to fix this. Please help.

• Anonymous
  November 13, 2015
  @Hiten Could you tell me what utility was used to generate certificate request ? and what are the version of windows for the server and your local computer?

• Anonymous
  September 23, 2016
  SCENARIO 1 is very usefull - great help! Thanks.

• Anonymous
  October 15, 2016
  thanks very much!

• Anonymous
  July 28, 2017
  This still happens on Server 2016. Since the first solution is to allow export of our certificate, is IIS manager deliberately designed to be less secure or is 5 years not enough time to fix the issue?

  • Anonymous
    October 04, 2017
    This seems to be something else. It would help if you can initiate a thread in IIS.NET. Any how, this has nothing to do with it being secure.

• Anonymous
  September 06, 2017
  thank you for your solutions, my scenario #3

• Anonymous
  November 03, 2017
  Nice article :)