Condividi tramite

Central Certificate Store (CCS) with IIS 8 (Windows Server 2012)

  • Articolo

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:

                  · SSL Scalability with IIS 8

                  · SNI with IIS 8

In the first post I mentioned that scalability was achieved in IIS via Server Name Indication (SNI) and Central Certificate Store (CCS). In my second post linked above I discussed how scalability was achieved via SNI.

In this article I’ll discuss CCS in detail and also its functionality.

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 to

Installing CCS on Windows Server 2012:

· Launch Server Manager.

· Under Manage menu, select Add Roles and Features:

        image

· In "Add Roles and Features Wizard" click "Next".

· Select "Role-based or Feature-based Installation" and click on Next.

· Select the appropriate server (local is selected by default) and click on Next.

· Select Web Server (IIS):

        image

· No additional features are needed for IIS, so click "Next".

· Click on Next again.

· By default, Centralized Certificates is not selected. Expand Security and then select "Centralized SSL Certificates Support" and click on Next.

        image

· Click on Install and wait until the installation completes.

· Upon successful installation the wizard would reflect the status:

        image

Installing CCS on Windows 8:

· Go to run prompt, type "appwiz.cpl", and hit Enter key.

· This would launch the Programs and Features Console.

· Click on "Turn Windows features on or off".

· Select "Internet Information Services" and expand the tree.

        image

· Go to World Web Wide Services->Security

· Select "Centralized SSL Certificate Support" and click on ok.

         image

· Centralized Certificates is installed successfully.

Configuring Central Certificate Store

1. Launch IIS Manager.

2. Under "Connections" select <MachineName>.

                image

3. In the middle-pane, under "Management", double-click on "Centralized Certificates"

    image

4. Under "Actions" pane select Edit Feature Settings:

    image

5. Select the check box "Enable Centralized Certificates" and provide the following details:

    image

Element Name

Description

Enable Centralized Certificates

Select the Enable Centralized Certificates check box if you want to create a central certificate store for your web farm. Otherwise, clear the check box.

Physical path

Type the physical path to the directory on the central certificate store server where you want the certificates stored.

User name

Type the name of the user account to use when accessing the central certificate store.

Password

Enter the password for the User Account

Confirm password

Enter the password for User Account again to confirm.

Private Key Password (Optional)

· This is optional. If the certificates do not have password, leave this empty.

· If the certificates have one global password, enter that password here.

6. Centralized SSL Certificate Support feature is now ready to be used.

7. One manageability feature that is noteworthy is the ability to group the certificates by their expiration dates:

  image

8. The webserver is setup to use Centralized Certificate Store.

How CCS works?

Below steps outline, how the SSL handshake works with a CCS binding on the IIS 8 web server:

  1. The client and the server establish a TCP connection via TCP handshake.
  2. The client sends a Client Hello to the server. This packet contains the specific protocol version, list of supported cipher suites along with the hostname (let’s say www.outlook.com provided its a SNI compliant browser). The TCP/IP headers in the packet contain the IPAddress and the Port number.
  3. The server checks the registry (legacy bindings) to find a certificate hash/thumbprint corresponding to the above combination of IP:Port.
  4. If there is no legacy binding for that IP:Port, then server uses the port number from the Client Hello to check the registry for a CCS binding for this port. The server checks the below key to find the binding information: HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslCcsBindingInfo
  5. If the above step fails i.e., if the server couldn’t find a corresponding CCS binding for that port, then it would fallback to the legacy binding. (If this is absent then the SSL handshake would fail).
  6. If Step 4 succeeds. The hostname (from Client Hello) is used to generate a filename like hostname.pfx. The filename is passed as a parameter along with the other details (CCS Configuration) to the crypto API’s which in turn call the File System API's to retrieve the corresponding certificate from the Central Certificate Store (File Share) . The retrieved certificate is cached and the corresponding certificate without private key is added to the Server Hello and sent to the client.
  7. If it cannot find a filename, then it falls back to Step 5.

File Naming Convention

Centralized Certificate Store follows a specific naming convention for the 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 match, 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>

But how does IIS handle Wild-Card & SAN Certificates. What is the naming convention for such certificates? Below is the solution:

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

Configuring a website to use CCS Bindings

1. Open IIS Manager.

2. Under Connections pane, right click "Sites" and select "Add Website… "

3. Fill the details as shown below

a. Site name: CentralSSL0

b. Physical path: C:\inetpub\wwwroot\CentralSSL0\

c. Type: https

d. Hostname: CentralSSL0

· In Windows Server 8, host name must be specified when using CCS. (New )

· The value depends on the certificate being used.

e. Require Server Name Indication: Selected

f. Use Centralized Certificate Store: Selected

NOTE: There is no need to select a specific certificate.

g. 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.

image

h. Click on "OK".

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:

· The certificates are stored centrally on a file share.

· Host name has to be specified for SSL site when using CCS.

· SSL binding is not managed explicitly 1-to-1. They are loaded on-demand.

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

image

CCS Configuration

In my previous post I had mentioned a new attribute called sslFlags. This attribute specifies whether the SSL binding is using SNI or CCS or both. CCS Configuration

 

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>
NOTE: The IIS manager exposes the above settings via configuration API’s in the IIS UI. It is not recommended to change the registry values directly. You will have to start

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

image 

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

More Information:

· Microsoft Virtual Academy: IIS8 Centralized Certificate Store

· IIS 8.0 Centralized SSL Certificate Support: SSL Scalability and Manageability

·         Plan SSL Central Certificate Store

 

I’m not done yet. There are few things that I need to address like, if someone has all the 3 types of bindings then which cert would be served? I’m not going to answer it now.

I will do it in my next blog post. Until then Ciao! Smile

Comments

  • Anonymous
    August 12, 2013
    I installed Centralized Certificates on my IIS 8 web server. I browsed to my certificate and added it. But I get an alert saying "the system cannot find the file specified". If I double click on the certificate I can view the cert, but the grid display in Centralized Certificates has a red x and no information is displayed. I have my own CA and generate all of our Certs. What could be wrong? Thanks.

  • Anonymous
    August 12, 2013
    Could you share a snapshot of the error? Also could you share your certificate with me. Mail me the cert (kaushalp@outlook.com) I'll review the cert and get back to you.

  • Anonymous
    November 15, 2013
    If you enable CCS, what's the point of giving an option to "Require SNI" if CCS is using the server name from the Client Hello packet? By that logic isn't SNI always enabled if you check CCS in the bindings config?

  • Anonymous
    November 21, 2013
    @Stephen.. CCS doesn't have a hard dependency on SNI. So lets say we don't check SNI and have opted to use CCS. And then there is a client hello received by a NON-SNI compatible client. What happens is that since the Server name is missing, the IP Address is used by CCS. So it will try to look up for a certificate by the name <ipaddress>.pfx (This has to be present on the CCS Share) If the request comes from a SNI compliant client then it will use the server name, if not then use the IP Address provided by the client. I have been lazy enough to not add this explanation into this blog post. My bad. :)

  • Anonymous
    May 08, 2014
    Maybe it will help someone - how to change the user account that is used to access the central certificate using PowerShell

Import-Module WebAdministration $cred = Get-Credential $unsecurepassword = $cred.GetNetworkCredential().password $username = (Get-WebCentralCertProvider | select-string username).tostring().split('=')[1] if ($username -ne $cred.UserName) {    Set-WebCentralCertProvider -UserName $cred.UserName -Password $unsecurepassword }

  • Anonymous
    August 20, 2014
    How to configure a default web site for https using SNI and CCS Please check full article at forums.iis.net/.../2082994.aspx

  • Anonymous
    September 02, 2014
    Can anyone provide the steps required to actually create BOTH a CCS binding that doesn't require SNI AND an IP:Port binding?  Do I have to go through the old process of setting up the cert on the webserver in addition to setting up CCS if I need an IP:Port binding as well to support clients that don't support SNI?  Or is it as simple as putting a binding with IP:Port specified in the applicationhost.config with SSLFlags=0?  Just not sure of what steps we need to take to support both CCS and legacy bindings.

  • Anonymous
    September 07, 2014
    Hi Xinunix, IP:PORT binding is same as earlier, when you select to create a HTTPS binding with SNI and CCS unchecked and choosing an IP Address from the drop down list, this creates a legacy IP based SSL binding. This will create an entry in the applicationhost.config for the corresponding site with the SSLFlags set to 0. CCS is a server side concept and doesn't have dependency on the IP as such. I'm not clear on the question or may be I haven't understood it well. Could you simplify the question for me?

  • Anonymous
    March 23, 2015
    Hi, we have facing some issues regarding the CCS implementation. We have implemented the CCS on server lavel and it is working fine when we access the web site by changing the host file pointing to the particular server where the web site is hosted. but when we are are trying to access the web site via load balance its is not working. Note we are not using SNI here.

  • Anonymous
    April 02, 2015
    What is the best way to troubleshoot browser connection reset on 443 when you bring on a second node with CCS?

  • Anonymous
    April 06, 2015
    Start by checking if it works on HTTP. It is too big of a answer. I will try to come up with a post on how to troubleshoot CCS. Meanwhile check the file called bindinginfo.tmp under C:inetpubtempappPools to see if we have a binding created there.

  • Anonymous
    May 20, 2016
    Does CCS seriously only allow the use of one private key password for all certificates?!?!?! I've got 4 different certificates on a server and each has its own password. Does anyone one know a way around this?

  • Anonymous
    January 01, 2017
    Thanks for sharing.

  • Anonymous
    October 23, 2017
    The comment has been removed

    • Anonymous
      October 23, 2017
      And it's not a bug... Looks like the working without CCS technically is a bug. According to RFC 2818 (HTTP Over TLS) I am actually required to add a SAN to the wildcard or just get another certificate for domain name only version of the site.