IIS 8: Better certificate management

  • Article

The IIS 8 central certificate store can simplify the process of using multiple certificates on multiple servers.

Jason Helmick

It’s refreshing when there’s a brilliantly simple solution to a complex problem. That’s just how the new central certificate store (CCS) in IIS 8 stacks up. With earlier versions of IIS, you could install certificates in a Web farm using Windows PowerShell Remoting. This is a useful process if you’re working with IIS on older servers. If you’re one of the lucky ones that can upgrade to IIS 8, then you’ll soon see how the process of working with certificates is a breeze.

Mind the store

The CCS is based on a truly simple concept. Store all the certificates in a Windows File Server share, then have the Web site bindings use those instead of locally installed certificates. Not only does this reduce the chaos of installing certificates on multiple servers, it greatly reduces the management time and effort locating certificates that are about to expire.

The first step is to create a share on a file server that will hold your certificate .pfx files. You can do this on any file server, regardless of the OS. It seems preferable to do it on a clustered file server to prevent a single point of failure. You don’t want to lose access to these certificates.

If you’re working in a Web farm, you probably already have a clustered file server—or Distributed File System (DFS)—available for your shared configuration. This is a great place to create another share for your certificates. Create a user account with read permissions to the share and you’re all set.

CCS works by using the host name of the Web site binding to locate a certificate in the store with the exact same file name plus the .pfx extension. For example, if there are two Web sites with host names www.WebBikez.com and www.MyCompany.com, the certificates should be named:

Note: You should ensure that wildcard certificates (*.MyCompany.com) use an underscore to replace the wildcard character (_.MyCompany.com.pfx).

You can add certificates to this share any time you add Web sites. You no longer need to install the certificates on your Web servers. The next step is to install and configure CCS on your IIS 8 Web servers to be able to use those certificates.

Install CCS

The installation process is simple. You can do this with graphical management tools or Windows PowerShell. Here’s the process of installing CCS on a local Web server. The last section describes how to perform these tasks on remote Web servers, including Windows Server 2012 Core.

You must install the Centralized SSL Certificate Support feature on your Web server before continuing. You can use the Server Manager graphical tools or the Install-WindowsFeature cmdlet in Windows PowerShell:

PS> Install-WindowsFeature Web-CertProvider

When you’ve successfully installed the new feature, a new icon will appear under the Management section of the IIS Manager (see Figure 1).

The CCS icon in the IIS Manager Management section.

Figure 1 The CCS icon in the IIS Manager Management section.

Click on the icon to open a form to configure CCS (see Figure 2). Enable CCS, then supply the share UNC and user account with read privileges to the share.

You can graphically configure the central certificate store.

Figure 2 You can graphically configure the central certificate store.

Notice at the bottom of the form you can specify a private key password if you exported the .pfx with one. Typically, you would export the certificates with a password, so it’s entered in the previous example.

Using these graphical tools is simple enough if you need to enable and configure CCS on a single local server. If you want to automate the process, you can also use Windows PowerShell. When you install CCS in this way, there will be six new cmdlets added:

  • Clear-WebCentralCertProvider
  • Disable-WebCentralCertProvider
  • Enable-WebCentralCertProvider
  • Get-WebCentralCertProvider
  • Set-WebCentralCertProvider
  • Set-WebCentralCertProviderCredential

The cmdlets are fairly self-explanatory and have help files. Here’s an example of using the Enable-WebCentralCertProvider cmdlet to enable and configure CCS on a local Web server:

PS> Enable-WebCentralCertProvider -CertStoreLocation \\serverdc\certstore -UserName company\certuser -Password P@ssw0rd -PrivateKeyPassword P@ssw0rd

Create Web site bindings

The last step in the process is to create, modify or add a new binding to your Web site that uses the CCS (see Figure 3). Note there is now a new option to select “Use Centralized Certificate Store.”

Binding your Web site to the central certificate store is the final step.

Figure 3 Binding your Web site to the central certificate store is the final step.

Here’s an example of how to use Windows PowerShell to create a new Web site with the correct SSL binding. The trick is the –SslFlags parameter on the New-WebSite cmdlet. SSLFlags determines where the certificate you’ll use for the binding is located. For CCS, you want option two or three, depending on whether you’re using Server Name Indication (SNI). Here are the options:

  • 0 – Regular certificate in Windows certificate storage
  • 1 – SNI certificate
  • 2 – CCS
  • 3 – SNI certificate in CCS

Here’s how to create a new application pool and Web site using an SNI certificate in CCS:

PS C:\> New-WebAppPool -Name WebBikez_pool PS C:\> New-Website -Name WebBikez -HostHeader www.WebBikez.com -PhysicalPath c:\inetpub\wwwroot -ApplicationPool webbikez_Pool -Ssl -port 443 -SslFlags 3 -force

Do this if you just need to add a binding to an existing Web site:

PS C:\> New-WebBinding -Name "WebBikez" -Protocol https -Port 443 -HostHeader www.WebBikez.com –SslFlags 3

Install CCS on remote Web servers

You can run all these commands using Windows PowerShell Remoting. It’s easy to connect and install the CCS feature to remote servers including Windows Server 2012 Core.

Create a remote session using the New-PSSession cmdlet:

PS C:\> $Sessions=New-PSSession -ComputerName server2,server3

Install the CCS feature on the remote computers:

PS C:\> Invoke-Command -Session $sessions {Install-WindowsFeature Web-CertProvider}

Here’s where it gets tricky. The Enable-WebCentralCertProvider cmdlet has a parameter—CertStoreLocation—that accepts a network share for the certificate location. The problem is that the cmdlet attempts to verify the share location before it writes the information to the registry.

In Windows PowerShell Remoting, this causes a multi-hop issue. You’re connected to a remote computer that’s trying to connect to a remote computer. At some point, the IIS team will most likely fix the cmdlet. Until they do, here’s a way around the problem. You can just add the entries to the registry manually.

To enable CCS:

Invoke-Command -Session $sessions {Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\IIS\CentralCertProvider\ -Name Enabled -Value 1}

To set the share location of the certificates:

Invoke-Command -Session $sessions {Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\IIS\CentralCertProvider\ -Name CertStoreLocation -Value \\ServerDC\CertStore}

You can’t set the username and password directly to the registry, but the Set-WebCentralCertProvider cmdlet will take care of the rest:

Invoke-Command -Session $sessions {Set-WebCentralCertProvider -Password P@ssw0rd -UserName Company\certuser -PrivateKeyPassword P@ssw0rd}

At this point, you can add Web bindings to your Web sites for HTTPS using Windows PowerShell Remoting, and you’re done. If you haven’t had the chance to try IIS 8, perhaps learning how the CCS works will give you a good business reason to take a look. It’s just one of the new features in IIS 8 that you should consider moving forward.

Jason Helmick

Jason Helmick is the director of Windows PowerShell technologies for Interface Technical Training, based in Phoenix, Ariz. He’s a speaker, author, teacher and inadvertent IIS administrator.

Related Content