Lesson 2:Configuring SSL for IIS

---

The most common use of SSL is to authenticate Web servers and to encrypt communications between Web browsers and Web servers. SSL, when used to protect HTTP, is referred to as Hypertext Transfer Protocol Secure (HTTPS). HTTPS is used by virtually every e-commerce Web site on the Internet to protect private information about end users and to protect end users from submitting private information to a rogue server impersonating another server.

Internet Information Services (IIS) 6.0, included with Windows Server 2003, supports both server and client SSL certificates. Configuring these certificates is simple when you are managing a single Web site with a single server certificate. However, managing certificates can be complicated when a server has multiple certificates or when you are using client certificates for authentication.

After this lesson, you will be able to

• Describe how to use SSL to protect Web communications.

• Create, assign, and renew SSL Web server certificates.

• Use client certificates to control access to a Web site.

• Troubleshoot problems with SSL certificates.

Estimated lesson time: 45 minutes

Using SSL Certificates with a Web Site

You can use SSL certificates to allow users to verify the identity of your Web site and to encrypt traffic sent between the client and the Web site. It is important to understand that an SSL certificate identifies a Web site, and not a Web server. A single Web server can host multiple Web sites. Alternatively, a single Web site can be hosted on multiple Web servers to provide redundancy and scalability.

For example, an Internet service provider (ISP) that hosts Web sites for 20 customers on a single Web server needs 20 SSL certificates to allow each site to use encryption. Alternatively, if an ISP stores a copy of a Web site on 10 different servers to allow the Web site to remain online in the event of a hardware failure, the same certificate can be installed on all 10 servers.

SSL certificates use the fully qualified domain name (FQDN) to identify the Web site. When the client retrieves the site's SSL certificate, the client checks the FQDN of the Web site against the subject name, also known as the common name, listed in the certificate. Checking the name used to identify the site against the name listed in the certificate prevents a rogue Web site from intercepting traffic destined for a different site.

Security Alert 

SSL certificates help reduce the risk of attacks against Domain Name System (DNS). For example, an attacker could compromise your DNS server and add a DNS record for the FQDN www.microsoft.com so that it resolved to the IP address of a rogue Web site. When you went to visit http://www.microsoft.com, your requests would actually be sent to the rogue Web site. The rogue Web site could then collect any information you intended to send to www.microsoft.com, which might include personal information or credit card numbers.

However, if you visited http://www.microsoft.com, the rogue Web site would have to return an SSL certificate to your Web browser. The rogue Web site could return a certificate with the common name www.microsoft.com, but no trusted CA would issue such a certificate. Therefore, your Web browser would warn you that the CA was untrusted. Alternatively, the rogue Web site could perform a true man-in-the-middle attack and forward your Web browser www.microsoft.com's actual certificate. However, the rogue Web site would not be able to establish an SSL session with your browser, because it would not have the private key associated with the public key in the certificate.

Though you assign SSL certificates to individual Web sites, you can configure SSL to help protect confidential data on a URL-by-URL basis. One part of the Web site might require encryption of data transmissions with SSL (by specifying HTTPS in the URL), and another part of the Web site might allow unencrypted data transmission (by specifying HTTP in the URL). This flexibility in security configuration allows you to provide encryption of confidential data as required, while not incurring the performance penalty inherent in encryption and decryption.

To better understand how this is used, visit your favorite e-commerce Web site. While browsing the catalog, you will notice that the URL uses the http:// protocol. Next, attempt to purchase an item. At some point during the purchase process, you will begin to use SSL, and the URL will show that the https:// protocol is being used. E-commerce sites typically use HTTPS only when exchanging private information, because this reduces the burden of public key cryptography and encryption on their Web servers.

Real World

One way you can reduce the processing overhead of using SSL is to use a hardware SSL accelerator. A hardware SSL accelerator is a fast, hardware-based encryption/decryption mechanism that outperforms software-based implementations. If you don't have a hardware SSL accelerator, your server will use its main processor to perform the SSL calculations required for authentication and encryption. As a result, the computer will have less processing power available for serving Web pages. Accelerators offload all encryption/decryption work to the on-board CPU, similar to the way 3-D video cards take on complex graphic computations to save the main CPU for other tasks.

Although hardware SSL accelerators do outperform software SSL accelerators, you might never see the benefit. Unfortunately, you wouldn't know that from examining the vendor's marketing material. Their marketing material will show you dramatic improvements in performance, which in theory will lead to improved scalability and a better end-user experience.

However, these statistics are misleading. Every piece of marketing material I've seen shows the performance gains in terms of new SSL sessions established, but new SSL sessions are usually established only when a new user connects to the Web site. As mentioned in Lesson 1, establishing an SSL session involves using public key cryptography, which is extremely processor-intensive. However, maintaining an SSL session involves only shared key encryption, which is not nearly as processor-intensive. Therefore, highlighting the benefits of hardware SSL accelerators by showing a large number of new SSL sessions does not reflect real world benefits.

You should investigate hardware SSL accelerators only if your Web site is currently processor limited. Specifically, if the processor time averages greater than 30 percent utilization during peak times. Even then, you should compare the cost of hardware SSL accelerators against the cost of upgrading the processor, adding an additional Web server, or optimizing your code. These other methods of adding processing capability allow all aspects of your Web site to benefit-not just SSL session establishment. When accounting for the cost of the hardware SSL accelerators, be sure to factor in the cost of managing an additional device, and the risk associated with adding an additional point of failure to your Web site.

The Web Server Certificate Wizard

Using HTTPS on an IIS Web server requires the server to have a certificate installed and configured. The exact process you will use to configure the certificate varies depending on the source of the certificate; however, you will always use the Web Server Certificate Wizard to perform the configuration.

To launch the Web Server Certificate Wizard:

1. Click Start, click Administrative Tools, and then click Internet Information Services (IIS) Manager.

2. Expand the computer name, and then expand Web Sites. Right-click the Web site for which you want to configure an SSL certificate, and then click Properties.

   Tip 

   You can configure an SSL certificate only for a Web site, not for an entire Web server or for individual virtual directories. However, you can configure individual virtual directories to require SSL.

3. Click the Directory Security tab, and then click the Server Certificate button.

   The Web Server Certificate Wizard appears.

You can use the Web Server Certificate Wizard to request a new certificate, assign an existing certificate, renew a certificate, and delete a certificate, as described in the following sections.

Requesting a new certificate

To request a new certificate by using the Web Server Certificate Wizard, follow these steps:

1. On the first page of the Web Server Certificate Wizard, click Next.

   The Server Certificate page appears.

2. Click Create A New Certificate, and then click Next.

3. If you need to send the certificate request to an offline CA, click Prepare The Request Now, But Send It Later. If you want to enroll by using an enterprise CA and there is one present in your domain, click Send The Request Immediately To An Online Certification Authority. Click Next.

4. On the Name And Security Settings page, type a name for the new certificate that will help you remember its purpose. Generally, you should leave the Bit Length setting at its default unless you have determined specifically that a greater bit length is required. Click Next.

5. On the Organization Information page, type a description in the Organization and Organizational Unit boxes. Click Next.

6. On the Your Site's Common Name page, type the common name for the computer. This should be the name that other computers will use to find the server on the intranet or Internet. Click Next.

7. On the Geographical Information page, select your Country/Region, State/Province, and City/Locality. Click Next.

8. If you chose Prepare The Request Now, But Send It Later in step 3, type a name for the file. If you chose Send The Request Immediately To An Online Certification Authority in step 3, select the CA from the Certification Authorities list.

9. Click Next twice, and then click Finish.

If you chose Prepare The Request Now, But Send It Later in step 3, submit the certificate request to a CA. You can use a public CA, in which case, they will provide a process for you to submit the certificate request. If you are submitting the request by using Web-based enrollment on a Windows Server 2003 CA, follow these steps:

1. Start Internet Explorer.

2. In the address bar of Internet Explorer, type http://ca-name/certsrv. Click Go.

3. If you are not automatically authenticated, provide your user name and password when prompted, and then click OK.

4. Click Request A Certificate.

5. Click Advanced Certificate Request.

6. Click Submit A Certificate Request By Using A Base-64-Encoded CMC Or PKCS #10 File, Or Submit A Renewal Request By Using A Base-64-Encoded PKCS #7 File.

7. Open the certificate request file that you saved earlier in Notepad. Copy the contents of the certificate request file and paste it into the Saved Request box in Internet Explorer.

8. Click the Certificate Template list, and then click Web Server. Click Submit.

9. Click DER Encoded, and then click Download Certificate. Save the file to your local computer.

10. Start the Web Server Certificate Wizard again.

11. On the Welcome To The Web Server Certificate Wizard page, click Next.

12. On the Pending Certificate Request page, click Process The Pending Request And Install The Certificate. Click Next.

13. On the Process A Pending Request page, select the certificate file, and then click Next.

14. On the SSL Port page, leave the default port of 443 selected, and then click Next.

15. Click Next again, and then click Finish.

By default, IIS will accept both unencrypted HTTP and encrypted HTTPS requests after a certificate is configured. If you do not want to allow unencrypted requests, open the Web site properties dialog box, click the Directory Security tab, click the Edit button, and then select the Require Secure Channel check box, as shown in Figure 11.3. Optionally, you can select the Require 128-Bit Encryption check box. Today, most clients will support 128-bit encryption, which is very difficult for an attacker to break. If you do not select the Require 128-Bit Encryption check box, clients that support 128- bit encryption will still use 128-bit encryption.

Figure 11.3: Requiring HTTPS for a Web server

Off the Record 

Requiring HTTPS encryption isn't all that useful because browsers don't automatically try to connect by using HTTPS. So if a user types just your Web server's domain name into a browser, as most users will do, the browser will attempt to connect with unencrypted HTTP. If you don't allow unencrypted HTTP, IIS returns a fairly complicated error message. Some users will read the message and follow the instructions to connect to the Web site by using https:// in the URL, but others will simply think the Web server is down.

A better way to require HTTPS is to set up a separate Web site in IIS to redirect standard HTTP requests to HTTPS. That way, when a user types just your domain name in a Web browser, your Web server will automatically redirect them to your Web site using HTTPS.

Assigning an existing certificate

If a suitable certificate is already present on the local machine authority on the server because you have created a certificate by using Web enrollment, the Certificates snap- in, or through a public CA, follow these steps:

1. On the first page of the Web Server Certificate Wizard, click Next.

   The Server Certificate page appears.

2. Click Assign An Existing Certificate. Click Next.

3. On the Available Certificates page, click a certificate, and then click Next.

4. On the SSL Port page, leave the default port of 443 selected, and then click Next.

5. Click Next again, and then click Finish.

Renewing a certificate

You can also use the Web Server Certificate Wizard to renew certificates. You can renew at any time; you do not need to wait for the certificate to expire or even approach expiration. To renew a certificate, make sure you have a certificate installed, and then follow these steps:

1. On the first page of the Web Server Certificate Wizard, click Next.

   The Modify The Current Certificate Assignment page appears.

2. Click Renew The Current Certificate. Click Next.

3. If you need to send the certificate request to an offline CA, click Prepare The Request Now, But Send It Later. If you want to enroll by using an enterprise CA and there is one present in your domain, click Send The Request Immediately To An Online Certification Authority. Click Next.

4. If you chose Prepare The Request Now, But Send It Later in step 3, type a name for the file. If you chose Send The Request Immediately To An Online Certification Authority in step 3, select the CA from the Certification Authorities list.

5. Click Next twice, and then click Finish.

If you chose Prepare The Request Now, But Send It Later in step 3, submit the renewal request to a CA. If you are using a public CA, they will provide a process for you to use to submit the renewal request. You will then return to the Web Server Certificate Wizard to install the renewed certificate.

Client Certificates

Although Basic, Digest, and Integrated Windows authentication are the most common ways to authenticate users, you can also authenticate users with certificates. In anonymous environments, where many requests go unauthenticated, client certificates are not a good solution. Client certificates require an administrator to have access to the IIS server and to each client that will be connecting to it. This is not feasible in many Internet solutions, in which clients from just about anywhere can be used to attempt a connection. On the other hand, client certificates are the only way to connect to IIS when all other authentication methods-Anonymous, Basic, Integrated, Digest, and Passport-are disabled on the server.

Although the simplest way to authenticate users with certificates is to allow any user with a valid certificate to access the site, this does little to provide security for your organization. By default, your IIS server will trust certificates issued by any trusted root CA, including public CAs that issue user certificates to people you might not want accessing your site.

Important 

IIS cannot process client certificates unless you have previously installed a server certificate and enabled HTTPS.

There are two ways to improve the security of client certificates. First, you can use client certificate mapping to restrict access to users with specific certificates. (You can also use client certificate mapping to control authorization by mapping the certificates to existing user accounts.) Second, you can configure a certificate trust list (CTL) to reduce the number of root CAs that can issue certificates to your users.

One-to-one client certificate mapping

Client certificate mapping has two modes: one-to-one and many-to-one. One-to-one certificate mapping relates a single exported certificate to an Active Directory user account, as shown in Figure 11.4. When Web users present the certificate, they will be authenticated as if they had presented a valid user name and password.

Figure 11.4: Configuring one-to-one certificate mapping

To add one-to-one certificate mappings, first export the user's certificate. Then perform these steps:

1. View the properties for the Web site, click the Directory Security tab, and click the Edit button in the Secure Communications box.

2. Select the Enable Client Certificate Mapping check box, and then click the Edit button.

3. Click the 1-1 tab, and then click the Add button.

4. Select the exported certificate, and then click Open.

5. Complete the Map Name, Account, and Password boxes, and then click OK.

6. Confirm the password when prompted, and then click OK again.

Many-to-one client certificate mapping

Many-to-one certificate mapping uses wildcard matching rules that verify whether a client certificate contains specific information, such as the issuer or subject. This mapping does not identify individual client certificates; it accepts all client certificates fulfilling the specific criteria. If a client gets another certificate containing all the same user information, the existing mapping will still work. Certificates do not need to be exported for use in many-to-one mappings.

To add many-to-one certificate mappings, follow this procedure:

1. View the properties for the Web site, and then click the Directory Security tab.

2. Click the Edit button in the Secure Communications box.

3. Select the Enable Client Certificate Mapping check box, and then click the Edit button.

4. Click the Many-1 tab, and then click the Add button.

5. On the General page, type a name for the rule in the Description box. Click Next.

6. On the Rules page, click New to add a rule.

   The Edit Rule Element dialog box appears, as shown in Figure 11.5.

   
   Figure 11.5: Editing rule properties for many-to-one client certificate mappings

7. In the Edit Rule Element dialog box, click the Certificate Field list to choose either Issuer or Subject. Select Issuer to filter based on the CA that issued the certificate. Choose Subject to filter based on who the certificate was issued to. After completing the rule element, click OK.

   Security Alert 

   When creating certificate mapping rules, keep in mind how easy it is to create your own root CA. Attackers could easily create their own root CA using your domain names. To prevent this type of impersonation, use certificate mapping along with a certificate trust list.

8. To add an additional rule, return to step 6.

9. Click Next.

10. On the Mapping page, click Refuse Access to reject logons that match the criteria, or click Accept This Certificate For Logon Authentication to map matching certificates to a user account. If you choose to accept the certificate, complete the Account and Password boxes. Click Finish. If prompted, confirm the password and then click OK.

Before you can authenticate users with client certificates, you must issue client certificates. If the users are members of an Active Directory domain and you are using an enterprise CA, autoenrollment is the most efficient way to enroll users. Web servers are often used to communicate with users outside of your organization, however. For these users, you should use Web enrollment. The exercise at the end of this lesson demonstrates the process of enrolling a user certificate by using Web enrollment and then authenticating that user to IIS.

See Also 

For more information about autoenrollment, refer to Chapter 7.

Certificate trust lists

You can use the Certificate Trust List Wizard to obtain and manage CTLs. A CTL is a list of trusted CAs for a particular Web site. By configuring your CTL, you can allow client certificates issued by a specific CA but deny client certificates issued from other CAs. CTLs are available only at the Web-site level and are not available for File Transfer Protocol (FTP) sites.

To use the Certificate Trust List Wizard, perform the following steps:

1. View the properties for the Web site, click the Directory Security tab, and then click the Edit button in the Secure Communications box.

2. Select the Enable Certificate Trust List check box.

3. Click the New button to open the Certificate Trust List Wizard, which allows you to select CAs from the local machine authority or an exported certificate file.

Troubleshooting SSL

Troubleshooting SSL-encrypted connections is difficult because, like IPSec connections, the traffic is encrypted. In some ways, troubleshooting SSL is even more difficult than troubleshooting IPSec because of the wide variety of Web browser clients that need to be able to analyze your public key certificate and establish an HTTPS connection to your Web server. Though the problems are much less frequent than they were in the late 1990s when the use of HTTPS was only beginning to gain popularity, you can run into problems when using a non-Microsoft browser that you would not experience when using Internet Explorer. Because you often have no control over what browser end users use, you might have to isolate the source of the problem to determine which component is not compliant with standards.

The SSL Diagnostic Utility for IIS, available from http://www.microsoft.com/technet/prodtechnol/windowsserver2003/downloads/ssldiags.asp, is helpful for isolating SSL- related problems. As shown in Figure 11.6, it provides a much more detailed analysis of HTTPS traffic than is possible by capturing SSL traffic by using Network Monitor.

Figure 11.6: The SSL Diagnostic Utility probing IIS

The SSL Diagnostic Utility has the capability to quickly create a self-signed SSL certificate. If you are experiencing problems with a certificate, you can create a self-signed certificate to determine whether the problem occurs with a different certificate. If the problem occurs with your original certificate but not with the certificate generated by the SSL Diagnostic Utility, you know the problem you are experiencing is related to a unique aspect of the original certificate. You can then quickly restore the original certificate to continue troubleshooting.

As shown in Figure 11.7, you can also use the SSL Diagnostic Utility to monitor client certificate-based authentication. If a user is experiencing problems authenticating with a client certificate, this tool will verify that the client's browser submitted a certificate, show you the certificate's subject and issuer, and report whether the authentication was successful.

Figure 11.7: The SSL Diagnostic Utility monitoring client certificates

Practice: Using Certificates for SSL

In this practice, you will use certificates to enable SSL encryption for Web communications. Additionally, you will learn how to use client certificates to authenticate Web users.

Exercise: Configure SSL for an IIS Server and Client

In this exercise, you will configure an IIS server to provide the communication security possible by requiring HTTPS and client certificates. After you complete this exercise, the only clients that will be allowed to access the Web site will be those with valid certificates. In the first process, you will configure the Web server with a server certificate and require HTTPS.

1. Log on to the cohowinery.com domain on Computer1 using the Administrator account.

2. Click Start, click Administrative Tools, and then click Internet Information Services (IIS) Manager.

3. Expand Computer1, and then expand Web Sites.

4. Right-click Default Web Site, and then click Properties.

5. Click the Directory Security tab.

6. Click the Server Certificate button.

   The Web Server Certificate Wizard appears.

7. Click Next.

8. Click Create A New Certificate, and then click Next.

9. Click Send The Request Immediately To An Online Certification Authority. Click Next.

10. Click Next again to accept the default settings for the certificate.

11. In the Organization box, type Coho Winery. In the Organizational Unit box, type Information Technology. Figure 11.8 shows this dialog box completed. Click Next.

    
    Figure 11.8: Exporting a SQL Server certificate

12. On the Your Site's Common Name page, in the Common Name box, type computer1.cohowinery.com. Click Next.

    Note 

    If the common name doesn't match what appears in the user's browser, the browser will report an error. On the Internet, users will need to type a fully qualified domain name (FQDN). On your intranet, they can usually use either an FQDN or simply a host name.

13. On the Geographical Information page, type MA in the State/Province box, and then type Woburn in the City/Locality box. Click Next.

14. On the SSL Port page, click Next.

15. On the Choose A Certification Authority page, click the Certification Authorities list, and then click Computer1.cohowinery.com\Computer1. Click Next.

16. Click Next, and then click Finish.

17. In the Secure Communications box, click Edit.

18. Select Require Secure Channel (SSL), and then click Require Client Certificates.

19. Select the Enable Certificate Trust List check box, and then click the New button.

    The Certificate Trust List Wizard appears.

20. Click Next. On the Certificates In The CTL page, click Add From Store. Click the certificate for Computer1, and then click OK.

21. Click Next. In the Friendly Name box, type Coho Winery CAs. Click Next, and then click Finish.

22. Click OK three times to return to the Internet Information Services (IIS) Manager.

23. Expand Default Web Site. Right-click CertSrv, and then click Properties.

24. Click the Directory Security tab. In the Secure Communications box, click the Edit button.

25. Clear the Require Secure Channel (SSL) check box, and then click OK twice.

    You must disable this requirement for the CertSrv virtual directory to allow users to enroll for certificates.

Exercise: Enroll for a client certificate access

At this point in the exercise, you have configured IIS to require client certificates to access the default Web page. In the next process, you will enroll for a client certificate and access the Web site by using HTTPS.

1. Start Internet Explorer. In the Address box, type http://computer1/certsrv. Click Go.

2. When prompted, type the Administrator user name and password.

3. Click Request A Certificate.

4. Click User Certificate.

5. Click the Submit button, and then click Yes.

6. Click Install This Certificate, and then click Yes.

7. In the Address box, type http://computer1. Click Go.

   Internet Explorer shows a description of the HTTP 403.4 error message that IIS returned, as shown in Figure 11.9.

   
   Figure 11.9: IIS configured to require SSL

8. In the Address box, type https://computer1. Click Go. When warned, click OK.

9. The Security Alert dialog box appears, as shown in Figure 11.10, warning you that although the CA is valid and the certificate has not expired, the name on the security certificate is not valid. This error message appears because you entered Computer1 in the Address box but entered Computer1.Cohowinery.com in the Common Name box when requesting the certificate. Click No.

   
   Figure 11.10: The requested host name does not match the common name in the certificate

10. In the Address box, type https://computer1.cohowinery.com. Click Go. When warned, click OK.

11. The Client Authentication dialog box appears. Click Users, and then click OK.

    Internet Explorer displays the default Under Construction page, which proves that IIS successfully authenticated the user certificate.

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the 'Questions and Answers' section at the end of this chapter.

1. Which of the following scenarios are appropriate for using client certificates? (Choose all that apply.)

   1. To authenticate users returning to a public e-commerce site.

   2. To authenticate and authorize users at a partnering company that manages its own CA.

   3. To gather demographic information about the users who visit your Web site.

   4. To authenticate users on an intranet when an enterprise CA is present.

2. A user is having a problem authenticating with a client certificate. Which of the following is the best tool to troubleshoot this problem?

   1. Network Monitor

   2. IIS Manager

   3. Certificates snap-in

   4. SSL Diagnostics Utility

Lesson Summary

• You can use the Web Server Certificate Wizard to request, assign, renew, and delete SSL certificates.

• Although only the server requires an SSL certificate to establish an HTTPS session, you can use client certificates to authenticate users.

• The best tool for troubleshooting problems with SSL certificates is the SSL Diagnostics Utility.

---