Designing and Implementing a PKI: Part IV Configuring SSL for Web Enrollment and Enabling Key Archival

First published on TechNet on Apr 06, 2011

 

The series:

 

• Designing and Implementing a PKI: Part I Design and Planning - Microsoft Community Hub

• Designing and Implementing a PKI: Part II Implementation Phases and Certificate Authority Installati...

• Designing and Implementing a PKI: Part III Certificate Templates - Microsoft Community Hub

• Designing and Implementing a PKI: Part IV Configuring SSL for Web Enrollment and Enabling Key Archiv...

• Designing and Implementing a PKI: Part V Disaster Recovery - Microsoft Community Hub

 

Chris here again. Today we are going to cover configuring SSL for the Web Enrollment website which will allow Windows Server 2008 and Windows clients to use the Web Enrollment website. We are also going to cover enabling Key Archival.

 

Configuring SSL for Web Enrollment

Windows Server 2008 (R2) requires SSL in order to connect to the Web Enrollment pages. The first thing that must be done after installing the Web Enrollment role is to enable SSL on the web site within IIS. To begin, I am going to go through the process to request an SSL certificate for my web server.

 

Requesting an SSL Certificate

In Part III I covered implementing certificate templates. The fictional company, Fabrikam, created a customized template for web servers called Fabrikam WebServer. This template was configured to construct the certificate subject information from Active Directory. When a server requests a Fabrikam Webserver certificate from the CA, the CA will place the DNS name of the server in the Subject of the issued certificate. Below are the steps to follow in order to request a certificate based on the Fabrikam WebServer template.

Requesting an SSL Certificate

 

In Part III I covered implementing certificate templates. The fictional company, Fabrikam, created a customized template for web servers called Fabrikam WebServer. This template was configured to construct the certificate subject information from Active Directory. When a server requests a Fabrikam Webserver certificate from the CA, the CA will place the DNS name of the server in the Subject of the issued certificate. Below are the steps to follow in order to request a certificate based on the Fabrikam WebServer template.

 

1. Click Start button, then Run, and enter MMC in the Run box and click OK .

2. Click on File from the menu bar and select Add/Remove Snap-in…

3. Select Certificates and click the Add button

4. When prompted for the context that the Certificates MMC should run in select Computer Account , and then click Next , then Finish .

5. Click OK , to close the Add or Remove Snap-ins page.

6. Expand Certificates (Local Computer) , right-click on Personal , and select Request New Certificate… from the context menu.

7. This starts the Certificate Enrollment wizard. Click Next to continue.

8. Select the Fabrikam WebServer certificate template, and then click Next to request the certificate.

9. As seen below, the certificate has been successfully requested. Click Finish to close the wizard.

 

 

Enabling SSL

Now that the certificate has been requested, the next step is to bind the certificate to the default web site in IIS.

To enable SSL for the Web Enrollment site on the CA server:

 

1. Launch the IIS Manager MMC located in Administrative Tools.

2. Expand the server name, then Sites, and then select Default Web Site.

 

 

3. In the Actions menu, select Bindings…

4. The Site Bindings settings will open. Click Add…

 

 

5. Select https for Type , and select the appropriate certificate from the SSL certificate drop down. Review the settings, and click OK .

 

 

6. Click Close to commit the changes to IIS. The selected server authentication certificate is now bound to port 443 on the IIS server.

 

 

The Web Enrollment website is now configured to support HTTP over SSL connections via the fully qualified domain name. Since the site is accessed via FQDN, the server, in this example https://fabca01.fabrikam.com, must be added to the list of trusted sites in Internet Explorer of clients that will attempt to access this page. This is so that so that user credentials are automatically passed to the Web Enrollment site. For domain clients, this can be done via Group Policy (see Site to Zone Assignment List policy).

Key Archival

Next, we’ll look at setting up Key Archival . There are two parts for setting up Key Archival. The first is designating a Key Recovery Agent for the CA. The second is configuring the Certificate Template for archival which we touched on in the previous part, Configuring Certificate Templates.

 

Key Archival is important for certificates that are used for encryption. If a user’s encryption private key is lost for some reason, any encrypted data can be recovered by extracting the archived private key from the CA database and returned to the user.

Designating a Key Recover Agent (KRA)

In the previous part, we configured the CA to issue KRA certificates. Specifically, we added the default KRA template to the list of certificate templates available on the CA, and set the permission on template to allow members of the Fabrikam KRA security group enroll. The next step is to have at least one member of that group request the KRA certificate.

 

The user, Magnus Hedlund, is a member of the Fabrikam KRA group. Here’s how he’d request a KRA certificate.

 

1. Connect to the Web Enrollment site and select Request a certificate from the Web Enrollment webpage.

 

2. Select Create and submit a request to this CA .

3. From the Certificate Template drop-down, select Key Recovery Agent. Magnus should also make sure the option Mark keys as exportable is selected, but the rest of the default settings can be accepted.

4. Set the friendly name to KRA Cert , and click Submit .

5. The default Key Recovery Agent template is configured to require Certificate Manager approval (on the Request Handling tab), meaning that a Certificate Manager (a local Administrator on the server, by default) must manually issue the certificate. As such, Magnus will see a message stating that his request is in a pending state. Magnus then emails the Certificate Manager to get the request approved.

6. The Certificate Manger launches the Certificate Services MMC, selects Pending Requests , and locates Magnus’ request. She then right-clicks on the request and selects All Tasks from the context menu and then selects Issue .

7. In order to retrieve his issued certificate, Magnus must returns to the Web Enrollment site. This time he must select View the status of a pending certificate request . REQUIRED: Magnus must reconnect to the site using the same client he used to submit the request. The Web Enrollment pages use a cookie to record pending requests.

8. Magnus then clicks on his request that is identified by the date and time that it was submitted.

9. Magnus then has a link to Install this certificate .

10. Magnus is then presented with a Potential Scripting Violation error asking if the certificate should be added to the certificate store He clicks Yes to acknowledge the warning.

 

 

The Certificate is then successfully installed.

 

User’s with Key Recovery Agent certificates should take care to protect their certificates and keys. One way of doing that is exporting the KRA certificate and private key to a PFX file – deleting the private key stored on the client – and keeping that password protected file in a safe location. The KRA certificate and private key can then be imported as needed.

To do this, Magnus follows these steps:

 

1. Open the Certificates MMC targeted to his user account (Certmgr.msc).

2. Expand Personal , then Certificates . Locate the KRA Cert, and right-click on it. Select Export from the context menu.

3. This launches the Certificate Export Wizard . Click Next to continue.

4. On the Export Private Key page of the wizard, select Yes, export the private key , and click Next .

5. On the Export File Format page, select Delete the private key if the export is successful and make sure all the other options are deselected. Click Next .

6. Enter a password to secure the Private Key , and click Next .

7. On the File to Export page, click Browse… .

8. Browse to a secure location in the file system, give the PFX file a name, and click Save .

9. Click Next on the File to Export page.

10. Click Finish to complete the export.

11. He is then prompted that the export was successful, and clicks OK .

In a high security setting, one option may be to save the PFX file to removable media, and then secure that media in a locked safe until it is needed. Why are such measures necessary? Well, they may not be; it totally depends on your environment. What is important to realize is that Key Recover Agents can decrypt the encrypted key blob for any user with an archived key. The CA’s design tries to mitigate this risk somewhat by requiring a Certificate Manager to actually export the encrypted key blob from the CA database. A Key Recovery Agent can only decrypted the exported key blob, but he can’t actually export the key blob.

 

Enabling Key Archival

Now that we actually have a Key Recovery Agent published in Active Directory (any KRA certificate issued by the CA is published to the CN=KRA container in Active Directory), we can proceed to enable Key Archival on the CA.

 

To enable Key Archival:

 

1. Open the Certificate Services MMC. Right-click on the name of the CA in the tree-view pane and then select Properties from the context menu.

 

 

2. Select the Recovery Agents tab, and select Archive the key . In this case, we only have one Key Recovery Agent, so we’ll leave Number of recovery key agents to use at the default of 1. Click Add… to add the KRA certificate to the CA.

 

 

3. Select the appropriate KRA Certificate, and click OK .

 

 

4. Click OK to close the properties and commit the changes we’ve made to the CA.

 

 

5. When prompted to restart Certificate Services, click Yes .

 

 

Key archival is now enabled on the CA.

 

Additional information on the mechanics of Key Archival is available here: http://blogs.technet.com/pki/archive/2009/08/07/understanding-key-archival.aspx

Conclusion

And that’s it for this part of the series. Today, we configured the IIS server hosting our Web Enrollment pages to use SSL when serving the site. We also configured our CA with a Key Recovery Agent to enable Key Archival. Neither of these steps are required in order for the CA to issue certificates, but setting up the features properly will increase the usefulness of your PKI.

 

In the final segment in this series, I will cover Disaster Recovery Scenarios.

 

Chris "Ol' Dusty" Delay