Windows Server 2012 : Scalable and elastic web platform (part 3) - Centralized SSL certificate support

3/15/2014 2:03:17 AM

3. Centralized SSL certificate support

Cloud hosting providers that need to host multiple HTTPS websites on each server in their web farms can also benefit from other SSL-related improvements in IIS 8. These improvements help make the IIS platform more scalable and manageable for hosting secure websites.

Managing SSL certificates on servers in web farms running earlier versions of IIS was time-consuming because the certificates had to be imported into every server in the farm. This made scaling out your farm by deploying additional servers a difficult chore. In addition, replicating certificates across servers in a farm was complicated by the need to ensure manually that certificate versions were in sync.

IIS 8 now makes managing SSL certificates on servers in web farms much easier by introducing a new central certificate store that lets you store all the certificates for your web servers in a file share on the network instead of in the certificate store of each server.

In addition to enhanced SSL manageability, IIS 8 includes significant improvements in the area of SSL scalability. For example, in previous versions of IIS, the certificate for an HTTPS website is loaded into memory (a process that could take considerable time) upon the first client accessing the site, and the certificate then remains in memory indefinitely. Hosting only a few SSL sites on an IIS server, therefore, could lead to large amounts of memory being wasted for secure sites that were rarely accessed.

In IIS 8, however, once a certificate is loaded into memory, it can now be unloaded automatically after the secure site has been idle for a configurable amount of time. In addition, certificates now load into memory almost instantaneously, which eliminates the delay often experienced by clients accessing secure sites for the first time in earlier versions of IIS. (Only the certificates for HTTPS requests are loaded, instead of all the certificates.) This change means that fewer certificates are kept in memory, which means that more memory is available on the server for other uses, such as running worker processes.

These scalability and manageability improvements mean that instead of hosting fewer than 500 secure sites on a single server, you can now host more than 10,000 SSL sites on one IIS 8 server. And as the next section discusses, configuring a central store for SSL certificates also increases the elasticity of your web farms.

Configuring a central store

To configure IIS to use a central store for storing SSL certificates, you first need to add the Centralized SSL Certificate Support feature. You can do this by starting the Add Roles And Features Wizard from Server Manager:

Once this feature has been enabled on your server, opening IIS Manager will show a Centralized Certificates node in the Management section of your server’s configuration settings:

Selecting the Centralized Certificates node displays a message saying that a central certificates location has not yet been set:

Clicking Edit Feature Settings opens a dialog box that lets you enable this feature and configure the path and credentials for the shared folder on the network where SSL certificates should be stored:

Note that the certificate password is necessary when you have created PFX files with a password that protects the private key. In addition, all your PFX files in the shared certificate store must use the same password. You cannot have a different password for each PFX file.

You can then group your SSL certificates in the Centralized Certificates pane by Expiration Date, or Issued By, to manage them more easily:

Once you’ve copied your SSL certificates to the central store, you can configure SSL websites to use the central store when you add them in IIS Manager:

Note that you don’t need to select your certificate by name when you add a new SSL site in IIS Manager. If you had to do this for each new secure site and you had hundreds or thousands of certificates in your store, this would make configuring SSL sites too difficult. Instead, you simply make sure that the name of the certificate matches the host header name for the secure site that uses it. This dynamic configuration of certificates for SSL sites means that adding an SSL central store to your web farms makes your farms more elastic.

CCS and private key file naming convention

CCS is based on a provider model, so it is definitely possible to use this feature with other CCS providers. Out of the box, IIS is shipping a file-server-based provider with a specific naming convention to locate the corresponding SSL certificate on a file system.

The naming convention, loosely, is “<subject name of a certificate>.pfx,” but how does the IIS provider deal with wildcard certificates and certificates with multiple subject names? Let’s consider the following three cases.

Case 1: Certificate with one subject name

This is simple. If the subject name is www.contoso.com, then the IIS provider will simply look for www.contoso.com.pfx.

Case 2: Wildcard certificate

The IIS provider uses the underscore character (_) as a special character to indicate that it is a wildcard certificate. So, if the subject name in the SSL certificate is *.contoso.com, the administrator should name the file _.contoso.com.

It should be noted that the IIS provider will first try to look for a SSL certificate with the file name 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.

Case 3: Certificate with multiple subject names

In this case, the administrator should name the file as many times as there are subject names. For example, separate SSL certificates may have been issued for both www.contoso.com and www.example.com. Although the files are exactly the same, there should be two .pfx files: www.contoso.com.pfx and www.example.com.pfx.

Finally, it is easy enough to see the relationship between SNI and CCS, especially when it comes to how CCS uses the naming convention based on the host name. However, it is important to note that CCS does not have a hard dependency on SNI. If the administrator wishes to use CCS without relying on SNI, the secure site must be configured using a dedicated IP address, but the same naming convention can be used.

For example, consider the following configuration in IIS:

      <site name="mySNIsite" id="1" serverAutoStart="true">
      <application path="/" applicationPool="snidemocert0">
         <virtualDirectory path="/" physicalPath="C:\inetpub\wwwroot" />
      </application>
      <bindings>
         <binding protocol="https" bindingInformation="192.168.0.1:443:w
ww.mycontoso.com" />
      </bindings>
   </site>

With the following SSL configuration, this code is used:

Central Certificate Store         : 443
Certificate Hash            : (null)

In this case, if the client is SNI-capable, then the host name comes from the client as a part of SSL connection initiation. If the client is not SNI-capable, then IIS will look up the corresponding host name based on the IP address that the client has used to connect to the server. This is why the IIS configuration has both the IP address and the host name in this example (192.168.0.1:443:www.mycontoso.com).

Others

- Windows Server 2012 : Scalable and elastic web platform (part 2) - Server Name Indication

- Windows Server 2012 : Scalable and elastic web platform (part 1) - NUMA-aware scalability

- Setting Up Windows 8 Family Safety (part 7) - Viewing Family Safety Online Reports

- Setting Up Windows 8 Family Safety (part 6) - Viewing Family Safety Activity Reports

- Setting Up Windows 8 Family Safety (part 5) - Blocking and allowing Apps

- Setting Up Windows 8 Family Safety (part 4) - Controlling Windows Store and game play

- Setting Up Windows 8 Family Safety (part 3) - Setting time limits

- Setting Up Windows 8 Family Safety (part 2) - Setting Web Filtering

- Setting Up Windows 8 Family Safety (part 1) - Getting to the Family Safety page

- Windows 8 : Sharing and Securing with User Accounts - Managing Profile Properties and Environment Variables