SharePoint Certificate Authority and Root Certificate
To properly understand the out-of-the-box configuration of the SharePoint local Security Token Service and the SharePoint Services host, it’s important to understand the SharePoint certificate authority and collection of certificates created by default in a farm. When connecting to SharePoint 2007 shared Web services via HTTPS (via the Office Shared Web Services host), a single self-signed certificate was used. In 2010, a root certificate authority self-signed certificate is created and stored in the configuration database; this certificate is used to sign several other certificates used across the farm. To get a look at the root certificate (minus the private key), issue the following PowerShell command:
The private key is in fact stored in the configuration database along with the certificate, but is not accessible publicly.
The certificates created for SharePoint use are stored on each farm server in the LocalMachine\SharePoint store. To see these certificates in PowerShell, issue the following command:
The SharePoint Security Token Service and SharePoint Security Token Service Encryption certificates are utilized by the local SharePoint STS for signing and encrypting security tokens issued to principals. The SharePoint Services certificate is used by the Web Services Host for SSL identification. The Web Services host is the IIS Web Site which hosts all endpoints for Service Applications. By default, it listens on port 32843 (HTTP), 32844 (HTTPS), and 32845 (net.tcp). To get information on the Services Host, use Get-SPServiceHostConfig. If you use IIS Manager (inetmgr) to check the bindings for the Services Host site, you’ll see that the HTTPS binding doesn’t indicate the actual certificate in use. IIS only shows certificates stored in the Personal (My) certificate store. One way to see the underlying binding is to issue the following PowerShell command:
(Get-Item ‘IIS:\SslBindings\0.0.0.0!32844’) | Format-List IPAddress, Port, Store, Thumbprint
The local IIS Web Site identifies the certificate to use based on the store name and certificate thumbprint. This certificate and corresponding thumbprint will be different on each server, even within a single farm, because each server uses a unique certificate with its own NetBIOS name.
Open up Certificate Manager on a SharePoint server (Start>Run>mmc.exe, File>Add Snapin, choose Certificate Manager, choose to manage Local Machine) and open up the SharePoint store. Double-click the SharePoint Services certificate, click the Details tab, and select the Subject Alternative Name attribute. You’ll see the certificate identifies this server by the names “localhost” and the NetBIOS name. The names listed in this certificate are the only ones which will be valid for connecting to service applications via HTTPS.
Changing the Services Host Certificate
There are two ways to change the certificate used by the Services Host HTTPS binding. The first is to use the Rename-SPServer PowerShell cmdlet. One of the effects of this cmdlet is to reissue the SSL certificate used on the effected server with the new name. This is useful if you want to be able to connect to the servers via FQDN instead of NetBIOS. A simple example of this command is the following, which causes a server to be identified by its FQDN:
Rename-SPServer -Identity SERVER05 -Name server05.domain.local
The second way of changing the certificate is to create your own certificate and replace the certificate on the existing binding. In a production environment, you should request new certificates from an existing, trusted CA (not the SharePoint CA). In a test environment, you can consider using the SPServiceHostCertificate module included with this article. In any case, you will likely need to create and replace the certificate on each server in the farm. You will also need to manually change the certificate on any new servers added to the farm, and monitor your certificates for expiration and replacement. One way to change the default certificate is to place a new certificate appropriate for SSL identification into the LocalMachine\My store, then use IIS to associate this certificate with the Serivces Host HTTPS binding. Another way is to use the following PowerShell script, replacing $certHash with the thumbprint of your certificate. This script allows you to specify a store other than My for the certificate (here I’ve defaulted to the SharePoint store).
(Get-WebBinding -Name “SharePoint Web Services” -Protocol https).RemoveSslCertificate()
(Get-WebBinding -Name “SharePoint Web Services” -Protocol https).AddSslCertificate($certHash, “SharePoint”)
The benefit of this method is you can store your custom certificate in the SharePoint store to better consolidate SharePoint configuration elements.
For the sake of completeness, I must mention two parameter sets available on the Set-SPServiceHostConfig cmdlet which allow you to refer to a single certificate across the entire farm for use with the Services Host. The clear benefit of such a setup is that you will not need to manage certificates on each server separately, and you will not need to add new certificates for new servers added to the farm. However, because all of the OOTB service applications use a load-balancing algorithm which relies on the individual NetBIOS names of the farm servers, it seems impossible to use a single certificate across all servers in the farm, and therefore I have yet to find a useful practical application of these parameter sets. If you do find such a scenario, however, consider using one the following two cmdlets, replacing $filepath with a path to a certificate file, and/or $certHash with a specific certificate thumbprint:
$cert = Get-PfxCertificate $filepath
Get-SPServiceHostConfig | Set-SPServiceHostConfig -ImportSslCertificate $cert
$cert = Get-PfxCertificate $filepath
Get-SPServiceHostConfig| Set-SPServiceHostConfig -SslCertificateThumbprint $certHash -SslCertificateStoreName “SharePoint”
In this post we’ve discussed the SharePoint Certificate Authority, individual SharePoint certificates, how to change the OOTB certificates for the Services Host HTTPS binding, and a module for creating your own test certificates. These are key foundational concepts necessary for a complete understanding of SharePoint infrastructure, particularly the Service Application Framework and load balancing.