How to: Configure Central Certificate Store (CCS) with IIS 8 (Windows Server 2012)

How to: Configure Central Certificate Store (CCS) with IIS 8 (Windows Server 2012)

There are a few things you might run across as you try to develop a web farm that has to share SSL Certificates, one of them is the Central Certificate Store.

What is CCS?

Central Certificate Store or Centralized SSL Certificate Support is a feature which allows certificates to be stored on a central location like a file share. This feature is very similar to Shared Configuration, where the certificates are stored on a file share and the servers in farm load them on demand.

In CCS the files are exported along with the private key (in .pfx format) and stored centrally on a file share. Files are named specifically using a naming convention and stored in the file share which are loaded on demand basis for an incoming SSL request. CCS uses the Server Name Indication information from the Client Hello for functionality.

 

How does CCS improve manageability of Certificates?

Prior to IIS 8, IIS always picked up the certificates store (Personal store of MY Computer account) which is local to every machine. In case of a stand-alone server this is not a problem. However, consider a web-farm scenario with 2 or more servers in the farm. If one has to configure a site to use SSL, the certificate has to be installed on all the servers along with the private key. If the certificate expires, again the same step has to be repeated on all the servers. So there was lot of manual work involved. If there were more servers in the farm or if you were to introduce another SSL site, it would be a bigger headache for the server admins.

In the server farm, we configure all the servers to use the CCS binding which reads from this Central Certificate Store. Now IIS picks the certificate from the file share and not the local certificate store. The server admins have the task simplified and they need to install/renew the certificate on a single location i.e., the file share.

How do I use the Central Certificate Store?

Well, as always step 1 is to deploy the feature through the Add Roles & Features menu in Server Management. This particular feature obviously is under IIS under Web Server > Security > Centralized SSL Certificate Support. Once installed then in the IIS management tool at the Server level you can see a new option titled “Centralized Certificates” right under the Management section. Double click it and then once you are in go to the Actions pane and select “Edit Feature Settings…”

At this point you just configure your shared SSL location, credentials, and as a good practice all the certificates must be protected by password. Here comes the list of things you need to keep in mind:

I. Protect your Private Keys via a Password

You should protect all your private keys via a password you can specify when you create the PFX file. The best practice here is to use the same password for all the certificates as the CCS would only allow you to provide one password for all the files.

II. Naming Convention

For Centralized Certificate Store to correctly map a certificate to a site you need to name it accordingly. Below is the naming convention you need to follow. Keep in mind that for a multiple SAN certificate you are going to have to create multiple copies of the same certificate with different names for it to work:

SL NO	Description
1	Certificate with single Subject Name         If the subject name is “www.contoso.com” then the IIS provider will look for www.contoso.com.pfx).
2	Wildcard certificate         The IIS provider uses the underscore character (“_”) as a special character to indicate that it is a wildcard certificate. If the subject name in the SSL certificate is *.contoso.com, then the file name should be “_.contoso.com.pfx“. NOTE: IIS provider would first try to search for a SSL certificate with the filename that exactly matches the domain name of the destination site. For example, if the destination site is www.contoso.com, the IIS provider first tries to locate www.consoto.com.pfx.  If that is unsuccessful, then it tries to locate _.contoso.com
3	SAN Certificates   In this case, the certificate must be duplicated with the file names matching Subject names in the certificate. For example, if the certificate is issued for “www.contoso1.com” & “www.contoso2.com“, then the file names should be www.contoso1.com.pfx & www.contoso2.com.pfx, respectively. So if the SAN Certificate is issued for 3 hostnames then there would be 3 files for those 3 hostnames respectively. NOTE: A SAN Certificate is like a global set. It can also be a wild card certificate

III.  Configure each site’s bindings

You need to go into the bindings of each site and select the options: Require Server Name Indication and Use Centralized Certificate Store. The system will find the appropriate certificate based on the naming convention of the certificate files and the Host Name specified on the bindings page.

IV. Know where the settings reside

When you are using the CSS store the bindings are loaded during run time so netsh won’t return you any information on them and because they are loaded during run time the registry key that enumerates the bindings will be empty (HKLMSYSTEMCurrentControlSetServicesHTTPParametersSslCcsBindingInfo). The applicationhost.config file does have a section titled CCS bindings where you can see all the bindings you have configured in the application. An important thing to keep in mind is that when you use shared configuration the applicationhost.config file is shared across the instances sharing the bindings but the settings regarding where to find the Centralized Certificate Store are stored in the registry (HKLMSOFTWAREMicrosoftIISCentralCertProvider)so they are machine specific and not shared via the Shared Configuration module. Below are the SSL flags used in the applicationhost.config file:

Using CCS	Using SNI	sslFlags	Description
0	0	0	Legacy SSL binding. Neither uses SNI nor CCS
0	1	1	SSL binding using SNI.
1	0	2	SSL binding uses CCS, but SNI is not enforced.
1	1	3	SSL binding uses CCS, but SNI is enforced.