In IIS 8 many new features were added. One of them was the Centralized Certificate Store. This is available on Windows Server 2012 or higher and Windows 8 or higher.
In my previous posts on IIS 8, I discussed how scalability was achieved in IIS 8 via SNI.
Below are the links to previous posts:
As I discussed in my earlier posts, scalability was achieved in IIS 8 via Server Name Indication (SNI) and Central Certificate Store (CCS). In the second post mentioned above I discussed in how scalability was achieved via SNI.
In this article I’ll discuss CCS in depth.
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.
Why do we need CCS when we already have SNI?
While SNI addressed only the SSL scalability problem with IIS, CCS addresses both SSL scalability and manageability of the certificates.
Also consider a hosting scenario where typically there are close to 1000 sites. If all of these were SSL enabled, then there would be close to 1000 SSL bindings. These explicit bindings are specific to a site and are loaded in memory during start-up of IIS Services. In case of CCS there exists only binding and the certs are loaded on demand and cached for future use, this way the memory consumption is lesser and there is a slight performance gain.
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.
Installing CCS
Unlike SNI, CCS is not pre-installed it has to be installed separately. It is shipped as a native module and has to be installed via the Server Manager console on Windows Server 2012 & via Programs & Features on Windows 8. Below are instructions:
Installing CCS on Windows Server 2012:
Installing CCS on Windows 8
Configuring Central Certificates Store
Centralized SSL Certificate Support feature is now ready to be used. One manageability feature that is noteworthy is the ability to group the certificates by their expiration dates
How CCS works?
Below steps outline what happens on the server side during a SSL handshake when a CCS binding is configured on IIS 8:
HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslCcsBindingInfo
File Naming Conventions
Centralized Certificate Store follows a naming convention for certificates. When the client sends a Client Hello, IIS uses the hostname available from SNI to construct a filename (hostname.pfx), and searches the File share to find this file. Once it finds the file, it loads it in memory and responds to the client with a Server Hello.
For IIS to find the exact file, a naming convention has to be used while storing certificates on the CCS file share. As per naming convention the name of the certificate should be:
Filename Syntax: <subject-name-of-cert.pfx>
For WildCard and SAN certificates refer the following table for naming convention
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".
|
|
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 corresponding to the 3 hostnames .
|
Configuring a website to use CCS bindings
Under Connections pane, right click "Sites" and select "Add Website…"
Fill the details as shown below
Site name: CentralSSL0
Physical path: C:\inetpub\wwwroot\CentralSSL0\
Type: https
Hostname: CentralSSL0
NOTE: In Windows Server 8, host name must be specified when using CCS. The value depends on the certificate being used.
Require Server Name Indication: Selected
Use Centralized Certificate Store: Selected
NOTE: There is no need to select a specific certificate.
With the use of SNI and the naming contract, the corresponding certificate is selected automatically. In this example, IIS tries to read CentralSSL0.pfx from the Centralized SSL Certificates file share.
You have successfully created a website using Centralized Certificate Store. The management experience is similar to that of Shared Configuration and traditional SSL. There are some differences though:
More on CCS Bindings
To view the CCS bindings we execute the same netsh command as earlier. Execute the following from an elevated command prompt:
netsh http show sslcert
NOTE: the first line in the output reads "Central Certificate store" and not "IP:Port", as in earlier versions of IIS. The "Certificate Hash" is "null" too. The null indicates that the certificates are loaded on runtime. |
The above command reads the following registry key and enumerates the values. Below is the location
HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslCcsBindingInfo
In IIS 8, a new attribute called SSLFlags was introduced. This attribute specifies whether the SSL binding is using SNI or CCS or both.
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. |
If the sslFlags attribute is set to either 2 or 3, then it is using the CCS bindings. If you check the applicationhost.config this is what the binding section would contain:
<bindings> <binding protocol="https" bindingInformation="*:443:centralssl0" sslFlags="2" /> </bindings>
However, you wont find the configuration for the CCS Module in applicationhost.config. Well, this information is not stored in any of the config files. It is stored in registry under the following node:
HKLM\SOFTWARE\Microsoft\IIS\CentralCertProvider
However, you wont find the configuration for the CCS Module in applicationhost.config. This information is not stored in any of the config files.
RESOURCES
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.