Reassigning the correct SSL certificate to SharePoint 2010 Web Services IIS Site

Posted by Rik Hepworth on Thursday, January 7, 2010

Prologue

This post is about assigning an SSL certificate to an IIS 7.5-hosted website which is not located in the Personal Certificate store. The steps shown are not SharePoint-specific, however. Hopefully this post will save you the large amount of time I spent hunting down the information on how to do this.

The usual background

I’ve been installing and configuring a SharePoint 2010 system that we can use here at Black Marble for our demo sessions. I hit a nasty wall just after lunch which turned out to be caused by the SSL certificate being used by the ISS web site hosting the SharePoint web services.

I’d spent a while carefully wiring up the user profile service to our AD, getting synchronisation working and dealing with the creation of a new MySite host. That in itself is a fairly involved process right now, so when I hit errors I naturally assumed it was related to my work on the user profile service.

When trying to manage the User Profile Service I was seeing errors that Central Administration could  not access the service.

The automatic Health Analyzer in SharePoint was telling there was an error with the Security Token Service:

The Security Token Service is not available. The Security Token Service is not issuing tokens. The service could be malfunctioning or in a bad state. SPSecurityTokenService (SecurityTokenService)

In the Application Event Log I was seeing EventID 8306: An exception occurred when trying to issue security token: Could not establish trust relationship for the SSL/TLS secure channel with authority 'localhost:32844'..

Naturally, I checked the bindings through IIS Manager to see what certificate was in use. An IIS self-issued certificate for the server was listed, which I though should have been valid…

I looked in the Local Computer Certificate Store using the MMC snapin and I discovered a folder called SharePoint which had three certificate in it, all issued by the Sharepoint Root Authority:

  • SharePoint Security Token Service
  • SharePoint Security Token Service Encryption
  • SharePoint Services

That sounded interesting – perhaps one of these was the certificate which should be used and the configuration had got changed. The trouble now was how I assigned those certificates. IIS Manager only shows you the certificates in the Personal store – I couldn’t select the certificate I  needed anywhere.

Being one to tinker before turning to the web I looked in applicationhost.config – the xml file which contains the configuration details for the IIS sites. It listed the protocol bindings but not the certificate. So I turned to Bing.

The first site of note was (of course) on IIS.Net – How to setup SSL on IIS 7.0

This listed a whole heap of things to do in order to set up SSL, but none of it told me how to assign a certificate from a specific store, at least without turning to WMI (and that wasn’t clear).

I then found a detailed MSDN How To: Configure a Port with an SSL Certificate

This was really useful (if hard to find). It detailed how to configure a certificate using netsh. This required a key bit of information which I didn’t have – the certificate hash. However, the article linked to another, telling me that the has is in fact the Thumbprint attribute, accessible through the certificate MMC snapin (MSDN – How To: Retrieve the Thumbprint of a Certificate).

I tried the appropriate netsh command and it failed. I then realised that when I queried the ssl bindings the certificate store name was listed, showing where cert was. There was no information in that article on how to specifiy this.

Bing to the rescue again. A non-MS site listing the parameters of the netsh add sslcert command.

The actual solution

In an elevated command prompt enter the following command to list the current SSL bindings:

netsh http show sslcert

You’ll get something that looks suspiciously like the image below. Note that there may be more than one binding listed; note also that the details below are for a working web services site.

Output from netsh http show sslcert
Output from netsh http show sslcert

You need to get some information for the SSL binding on port 32844, used by the SharePoint Web Services. The relevant section, as show above, will list the IP:Port as 0.0.0.0:32844. Mark and copy the the Application ID GUID. Interestingly, I’ve checked two different SharePoint 2010 installs on different servers and the Application ID is the same for both.

You also need to find the certificate hash (thumbprint) for the SharePoint Services Certificate. Load up MMC and add the certificate snapin, connecting to the Local Computer store. You should see a store named SharePoint with three certificates in, as per the image below:

Certificate console showing SharePoint store
Certificate console showing SharePoint store

Double-click the SharePoint Services certificate and select the Details tab. Scroll down and find the Thumbprint property and copy it’s contents to the clipboard.

Certificate properties showing Thumbprint
Certificate properties showing Thumbprint

Paste the text into notepad and trim out the spaces before you use it in the commands below.

I removed the SSL binding first using the command below, although I’m not sure if this step is necessary:

netsh http delete sslcert ipport=0.0.0:32844

Once that’s done, enter the command below, using the thumbprint from your certificate and (if it’s different) the correct appid for your website.

netsh http add sslcert ipport=0.0.0:32844 certhash=<thumbprint> appid={4dc3e181-e14b-4a21-b022-59fc669b0914} certstorename=SharePoint

Finish off with another netsh http show sslcert to make sure the changes have been made, and then perform an iisreset, just to be sure.

The annoying bit

When you’ve done all this, don’t be fooled when you examine the bindings in IIS manager. If the certificate isn’t in the Personal store (i.e. IIS Manager doesn’t show it in the list) then the certificate is listed as Not Selected, which is very misleading. One to poke the guys in the IIS team about, I think.