Today, online shopping is about as popular as driving to the mall was a few years ago, and registering for a class or seminar is much easier to do online instead of by telephone. But honestly, don't you always hesitate for a second before you enter your credit card number and personal information? So what's behind that HTTP Secure (HTTPS) Internet connection between your browser and the online site's server? Most likely, the online site is using either the Secure Sockets Layer (SSL) protocol or Transport Layer Security (TLS) protocol.

SSL was initially developed by Netscape and in 1999 was standardized by the Internet Engineering Task Force (IETF) in Request for Comments (RFC) 2246 and named the Transport Layer Security (TLS) protocol. Today, SSL/TLS protocol support comes bundled with many Web servers, such as Microsoft Internet Information Services (IIS). Let's look at some of the hidden traps you might encounter when you configure SSL/TLS for secure Web communications.

How It Works
SSL sits between the application and transport layers of the TCP/IP networking stack and provides security services to a wide range of application-level protocols, such as HTTP for secure Web communications, SMTP for secure mail transfer operations, and Network News Transfer Protocol (NNTP) for secure news operations.

SSL/TLS can provide the following security services:

  • Data confidentiality and integrity services—SSL provides channel encryption services (also known as secure channel services) that secure traffic exchanged between an SSL-enabled client and server.
  • Server authentication—SSL-enabled applications use an X.509 server certificate to authenticate a server.
  • Client authentication—SSL uses an X.509 client certificate to authenticate a client. Client authentication is an optional SSL service and isn't used often because it requires a user to obtain a client certificate.

SSL and TLS are based on symmetric and asymmetric cryptographic protocols (also known as public key cryptography) and X.509 certificates. From an operations viewpoint, SSL/TLS is a client-server handshake protocol. You can set up an SSL/TLS connection between a browser and a Web server by following these steps:

  1. A client browser connects to a Web server by using a secure URL (i.e., one that begins with https://).
  2. The Web server sends a server certificate (containing the Web server's public key) to the browser for server authentication. The browser logic checks the server name in the certificate against the name that was provided in the URL.
  3. Optionally, the browser sends the Web server the client certificate ( containing the client's public key) for client authentication.
  4. The browser and Web server negotiate the cryptographic ciphers to be used for authentication, integrity, and confidentiality protection during the SSL/TLS exchange.
  5. The browser and Web server establish a set of cryptographic keys that will be used for SSL channel encryption. The cryptographic mechanisms that establish these keys are based on a cryptographic key agreement protocol, such as the RSA cipher or the Diffie-Hellman protocol.
  6. The browser and Web server exchange HTTPS data by using the previously established keys (i.e., the server's public key, the client's public key, and the cryptographic keys).

Setting up SSL/TLS on an IIS 6.0 Web server typically includes the following steps:

  1. Generating a server certificate request file.
  2. Generating a server certificate.
  3. Installing a server certificate on the Web server.
  4. Configuring SSL on a Web server.
  5. Optionally, generating, acquiring, and installing client certificates.
  6. Ensuring that SSL clients trust the CA certificate.

Before you begin setting up SSL/TLS, you might want to familiarize yourself with the process of requesting and generating an SSL/TLS server certificate for your IIS Web server. You can issue a test certificate from your internal Windows Public Key Infrastructure (PKI) or request a test certificate from a commercial certificate provider such as VeriSign. (To request a test certificate from VeriSign, go to https://www.verisign.com/cgibin/clearsales_cgi/leadgen.htm?form_id=5191&toc=w44740044735191002&ra=156.153.255.126&email=.)

Generating a Server Certificate Request File
The easiest way to generate an SSL/TLS server certificate request is to use the IIS Certificate Wizard. This wizard guides you through the certificate request file-generation process. Start the wizard from the Microsoft Management Console (MMC) IIS Internet Services Manager (ISM) snap-in by right-clicking the Web site on which you want to set up SSL/TLS. Select Properties and the Directory Security tab, then click Server Certificate, as Figure 1 shows.

Using the online or offline option. Figure 2 shows that two options are available on the wizard's Delayed or Immediate Request window that you can use to generate a server certificate request file offline or online: Prepare the request now, but send it later or Send the request immediately to an online certification authority, respectively.

Use the offline option if you want to request an SSL/TLS server certificate from a commercial certification authority (CA—e.g., VeriSign or Thawte) or from a non-Active Directory (AD) integrated internal CA (this Windows CA type is also known as a standalone CA). An offline certificate request is not automated, which means you must save the request to a file (by default, this file is named certreq.txt), submit the request file to a CA, then install the resulting certificate on your Web server.

Use the online option if you want to send the request immediately to an online CA. After you select the online option, the wizard generates and sends the certificate request file and automatically installs the certificate. This option works only if you have an operational Windows enterprise CA in your IIS environment. A Windows enterprise CA is an AD-integrated CA published in AD.

Entering certificate-related information. In the IIS Certificate Wizard, you must enter the following certificate-related information:

  • Name and security settings—name of the certificate and encryption key length.
  • Organization information—AD organization name and organizational unit (OU) that will appear in the certificate.
  • Your site's Common Name—the Common Name that will appear in the certificate (this term is explained below).
  • Geographical information—the country code, state or province, and city or locality information that will appear in the certificate.

Specifying the Common Name. A certificate's Common Name is the X.509 term for the name that uniquely identifies an SSL/TLS server certificate and links the requested certificate to your organization. The Common Name in the server certificate must match the name a browser uses to securely connect to a Web site. If it doesn't, the browser generates an SSL error message.

You can use wildcards in the certificate's Common Name, which lets you reuse the SSL/TLS certificate for different physical Web sites: for example, w*.mydomain.com or *w.mydomain.com. Using a Common Name with wildcards is an interesting option for Web farms in which the only differences between farm members are the machines. However, you should never use wildcards in your organization's domain name because this would compromise SSL/TLS server authentication. For more information about how Microsoft uses wildcards, see the article "Accepted Wildcards Used by Server Certificates for Server Authentication" at http://support.microsoft.com/?kbid=258858.

Generating an SSL Server Certificate
After you've generated an SSL/TLS server certificate request file by using the offline certificate request option in the IIS Certificate Wizard, you can use the server certificate request file to request a Web server certificate from an internal Windows CA (i.e., either a standalone or an enterprise Windows 2000 or Windows Server 2003 CA) or an external commercial CA.

If you use an internal Windows CA, the easiest way to submit your SSL server certificate request file is to use the CA's Web interface. To do so, connect to the CA's Web site from your browser by using the http://servername/certsrv URL. On the CA's Web site, select the following:

  • On the CA's Welcome page, select Request a certificate.
  • On the resulting certificate request page, select Submit an advanced certificate request.
  • On the resulting page, select Submit a certificate request by using a base64-encoded CMC or PKCS#10 file or Submit a renewal request by using a base64-encoded PKCS#7 file.
  • On the resulting page, paste the base64-encoded content of your certificate request into the Saved Request field by selecting and pasting the text that starts with—BEGIN NEW CERTIFICATE REQUEST—and ends with—END NEW CERTIFICATE REQUEST—from the SSL/TLS server certificate request file. You can also use the Browse for a file function on the Submit a Certificate Request page or the Renewal Request page to search for a certificate request and insert the certificate request content.

To manually submit your SSL/TLS server certificate request file to a commercial CA, you must follow the enrollment instructions the CA provides. Most CAs publish their enrollment instructions on their Web site. Enrollment instructions vary among commercial CAs and for different SSL server certificate types.

Another way to obtain an SSL server certificate is to use the SelfSSL Internet Information Server Resource Kit command-line tool, which generates self-signed certificates so that you don't need a CA or PKI to generate a certificate. Also, SelfSSL doesn't require the Web server to generate a certificate request file; rather, the tool generates and installs the certificate right away. Use self-signed SSL certificates only for test purposes or for protecting Web resources that are for internal use. I recommend that you always run SelfSSL with the /T switch. This switch directs SelfSSL to add the self-signed certificate to the list of trusted certificates in the local machine's certificate store.

Installing the Server Certificate
To install an SSL/TLS Web server certificate on your Web server, you can use the IIS Certificate Wizard, the IIScertdeploy.vbs script in the resource kit, or the certreq.exe command-line utility. The Certreq utility is automatically installed on your server when you install Windows 2000 or Windows Server 2003 Certificate Services.

If you use the IIS Certificate Wizard to install a Web server certificate, select Process the pending request and install the certificate in the Pending Certificate Request window. Then, the wizard will prompt you to enter the location of the certificate file.

To accept a newly generated Web server certificate (e.g., ssl.cer) and install it on your Web server by using the Certreq utility, type the following Certreq command at the command line:

Certreq accept ssl.cer

This command opens the Open Request File dialog box that allows you to browse for the certificate file.

Configuring SSL/TLS on a Web Server
You can configure SSL/TLS in the ISM snap-in. In the Secure communications section of the Directory Security tab, click Edit. Note that the Edit button is enabled only if you have successfully installed a server certificate on the server.

Figure 3 shows the Secure Communications dialog box. Use it to select the following security attributes for your Web site:

  • Require secure channel—click this check box to enable SSL/TLS for a Web site.
  • Require 128-bit encryption—click this check box to provide extra protection for Web sites that have sensitive personal and financial information.
  • Client certificates section—select Ignore client certificates if you don't want to use client certificate-based authentication. Both the Accept client certificates and Require client certificates options require you to deploy a certificate to your browser clients. Select Accept client certificates if you want clients to be able to access your Web site even though they don't have an SSL client certificate installed. However, the client must use another HTTP authentication method. Select Require client certificates if you want to allow users to access your Web site only if they have an SSL client certificate installed. As with SSL/TLS server certificates, you can acquire SSL/TLS client certificates from an internal CA or from an external commercial CA.
  • Enable client certificate mapping—click this check box if you want to map a client certificate to a Windows user account during authentication. See "Using certificate mapping" later in this article for more information.
  • Enable certificate trust list—click this check box if you want to use certificate trust lists (CTLs). Web server administrators use CTLs to define a set of CAs that must be trusted by all of the server's SSL users. For more information about CTLs, see the Microsoft article "Configure Certificate Trust Lists in Internet Information Services 5.0" (http:// support.microsoft.com/?kbid= 313071).

Configuring the SSL/TLS port. You can configure the port to be used for SSL/TLS communications. In the ISM snap-in, right-click the Web site, select Properties, and go to the Web Site tab (which Figure 4 shows). The default SSL/TLS port is 443. The SSL port field is enabled only if you have installed an SSL/TLS server certificate on your Web server. Note that different Web sites can use the same SSL/TLS port provided they have different IP addresses.

Using certificate mapping. To facilitate Web server access control enforcement, you can map IIS certificates to Windows security identities. Use certificate mapping if you want to apply authorization settings defined for Windows security identities to users that used a certificate to authenticate to IIS.

You can define certificate-mapping attributes in AD or in the IIS metabase (i.e., the IIS configuration database). To use IIS-metabase mapping, you must select the Enable client certificate mapping check box in the Secure Communications dialog box and define the mappings in the ISM Account Mappings dialog box (which Figure 5 shows). You can set up one-to-one mapping or many-to-one mapping:

  • One-to-one mapping means that IIS looks at the contents of the SSL client certificate to map it to a Windows security identity.
  • Many-to-one certificate mapping is based on rules. In this case, IIS looks at particular attributes of the SSL client certificate (as defined in the rules) to map the certificate to a Windows security identity. This is a less secure certificate-mapping mode and shouldn't be used in environments requiring a high level of security.

IIS uses the Windows directory service mapper to define certificate mappings in AD. AD-based mapping is an interesting option if you have multiple Web servers that require certificate mappings to be defined. Instead of defining the mappings on individual Web servers, you can define the certificate-mapping attributes once in the central AD repository. Use the MMC Active Directory Users and Computers snap-in to define the AD-based mapping. Select the Name mappings option on the account object's context menu. This option is available only if the snap-in is in the Advanced Features viewing mode. AD-based mapping allows only one-to-one mapping. You enable AD-based mapping or the Windows directory service mapper from the Properties dialog box of the Web Sites container in ISM.

Generating SSL/TLS Client Certificates
If you also want to strongly authenticate your SSL/TLS clients by using certificates on the browser side, you should deploy SSL/TLS client certificates to your users' browsers. Not all organizations want to do this. A typical scenario requiring SSL/TLS client certificates is a secure extranet Web site.

As with server certificates, you can request a client SSL/TLS certificate from an internal or external CA. If you're using a Windows Server 2003-rooted PKI, users can request certificates by using their MMC Certificates snap-in or the CA's Web interface (e.g., http://servername/certsrv). Administrators can also automatically enroll users for SSL/TLS certificates by using the Autoenrollment Group Policy Object (GPO) settings.

Ensuring That SSL Clients Trust the CA Certificate
An important, but often forgotten last step is to make sure that your clients trust the certificate from the CA that issued the client and server SSL/TLS certificates. In Windows, this means making sure that the CA's certificate is stored in the client's trusted root certificate store. To look at the contents of a certificate store, open the Certificates snap-in.

Trust isn't a concern when you're using certificates issued by a commercial-CA. The CA certificates of commonly used commercial CAs (e.g., VeriSign and Thawte) come with the Windows OS software and by default are trusted. CA certificate trust is an issue if you're using certificates generated by an internal PKI that's run by your company or a partner organization. In this case, you can use one of three methods to add server and client certificates to a user's trusted root certificate stores:

  • Use the Internet Explorer Administration Kit (IEAK) to create an IE installation kit that adds a CA certificate to the trusted root certificate store.
  • Put the CA's certificate on a publicly accessible Web site where users can download it.
  • Distribute the CA's certificate by using the Trusted Root Certification Authorities GPO setting.

Although support for SSL/TLS is a common feature provided with today's Web servers and browsers, as you can see, setting it up correctly isn't a trivial task.