Networking

Using Secure Socket Layer with Outlook Web Access

You can set up encrypted communications between browsers and your Exchange Server. In this Daily Drill Down, Ron Nutter examines the process of enabling SSL on Exchange OWA.


Keeping passwords secure is an important issue for many companies. Accessing e-mail remotely may involve using the Microsoft Outlook Web Access (OWA) component of Exchange. This approach has one small problem: OWA offers no security in terms of keeping the password secure.

With a little bit of work, you can bring the SSL (Secure Socket Layer) technology to Exchange OWA and keep your passwords and e-mail more secure. By using a special file from VeriSign, you can set up encrypted communications between browsers and your Exchange Server. In this Daily Drill Down, I’ll take you through the process of enabling SSL on Exchange OWA. I’ll also demonstrate the process of getting an SSL certificate from VeriSign.

Getting the certificate
The main three certificate authorities (CA) are VeriSign, Thawte Consulting , and CyberTrust . Other CAs are available. Just be sure to verify that the certificate will be supported by the browsers you intend to support. If it isn’t, users will have to install a certificate or other service so they can establish an SSL connection to your Web site.

First, you must decide which level of encryption you need (basic encryption, 128-bit, etc.) and whether you need additional services. You can expect the cost to range from $125 to around $1,300 for one year.

Getting an SSL certificate for your Exchange Server is not something you should put off until you really, really need it. Depending on the CA you use and the level of encryption/service you want, it could take anywhere from a couple of hours to a week or more to get your certificate. One factor affecting the length of time is the amount of background checking the CA must do to confirm your identity.

Preparing for the CA application process
I recently went through this process for my company and had a couple of surprises along the way. We had just moved into new offices and found out that one of the verification steps taken by VeriSign was to check our business information with Dun & Bradstreet, a common source of business-to-business information. The problem we ran into was that our address and contact information was incorrect as a result of our move. The application process for the SSL certificate was delayed for several weeks while we filled out the form twice on Dun & Bradstreet’s Web site and then had to follow up with a phone call before getting the changes made.

Just as we started the application process, we found that VeriSign refuses to create an SSL certificate for a site if you don’t have a fully qualified DNS name for the server in question. This means that you must have a DNS record for the server, listing its name and the IP address. VeriSign will not issue an SSL certificate if you have only an IP address. We hit another snag here: The primary DNS server showed the information, but the information we needed to have distributed concerning our e-mail server wasn’t showing up on the secondary DNS server. A couple of calls to the ISP hosting our DNS resolved this problem.

VeriSign will send 40-bit SSL certificates to the requesting party, assuming the information you supply checks out. Don’t ask to have the certificate mailed to your ISP e-mail account; it will need to go to your company e-mail server. VeriSign will send 128-bit SSL certificates to the administrative or technical contacts for the domain. So if you’re hosting your own DNS servers, be sure you’re listed as either the administrative or technical contact for the Internet domain(s) for which you’ll be getting SSL certificates.

Finally, check the Exchange Server itself. Choose Programs from the Start menu and look for the option NT 4.0 Option Pack. If you see this option, that’s a good indication that IIS 4.0 has been installed on the Exchange Server (one of the requirements for using OWA) and that the Outlook Web Access component of Exchange has probably been installed as well. If you don’t see this option, you will first need to take the following steps:
  • Install IIS.
  • Reapply the NT Service Pack.
  • Rerun the Exchange setup program.
  • Add the Outlook Web Access component.
  • Reapply the Exchange Service Pack (you should be at Exchange SP 2 at a minimum).

I recommend that you use at least Service Pack 5 for NT to avoid some SNMP-level problems.

Starting the certificate process
The first step is generating a certificate-signing request (CSR). This involves creating a text file that you can cut and paste into a form on the CA’s Web site so it can begin the process of generating an SSL certificate for you. You start your journey by opening the Internet Service Manager (non-HTML version) to bring up the Microsoft Management Console (MMC).

Once the splash screen disappears, right-click on the Web site name and click the Properties option. Once the Web site properties page appears, right-click on the Web site you want to add the certificate to. Select the Directory Security tab and click the Secure Communications box. Now, select the Key Manager tab to start the file-creation process. Choose the service for which you want to install SSL (and you thought that SSL was only for HTTP?). Click the Web site to select it and then right-click it. Then, click the Create New Key option. The Create New Key wizard will guide you through the process of creating a certificate request.

Unless you plan to be your own certificate authority (normally only a good idea if you’re looking for SSL services on a corporate intranet), you’ll go through the wizard to create a text file. You’ll then cut and paste that text file into VeriSign’s Web site when you apply for the SSL certificate. When the wizard first appears, the default location and filename is C:\NewKeyRq.txt. Unless you have a compelling need to change the location of this file, click the Next button to continue.

The next window will ask you to supply a name for the key. This step can be important if you’ll have more than one certificate on your server. Naming the keys lets you easily identify what certificate is being used for what purpose. Enter the name that you want to use for the key request, then enter the password you want to use to control the installation of the SSL certificate. Keep the password handy—you’ll need it later when installing the SSL certificate. Click Next.

At this point, you have to supply some basic information to help differentiate this certificate from others you may have or others on the Internet. After entering the requested information, click Next. The next window will ask you for your country, state, and city. Enter the information as requested and click Next.

Now you’re asked to enter your name, e-mail address, and telephone number. This is so that VeriSign can contact you if there are any problems processing your request. Click the Finish button to finish generating the key request file. You should now see a key entry below the Web site label in the Key Manager window.

Using Notepad or Wordpad, open the key request file you just created. Once you’ve answered the appropriate questions on VeriSign’s Web site, cut and paste the contents of the key request file in its entirety into the appropriate part of the form. Within a few hours or days, you should receive an e-mail from VeriSign containing the SSL certificate.

Once the file is in your possession, return to the Internet Service Manager. Select Start | Programs | Windows NT 4.0 Option Pack | Microsoft Internet Information Server | Internet Service Manager. On the left-hand side, highlight the default Web site on which you want to enable SSL. Right-click, then select the Properties option.

When you see the properties window, click the Directory Security tab. Then, click the Edit button in the Secure Communications box. In the Secure Communications window, click the Key Manager button. Highlight the key request that you created earlier. Then, right-click on the certificate request and select Install Key Certificate. Browse to find where you placed the certificate file from VeriSign, and double-click the filename. Enter the password you used when submitting the SSL certificate request on VeriSign’s Web site.

When the Server Bindings window appears, you won’t need to do anything unless you’re running multiple Web servers on your Exchange Server. If you want to lock the SSL certificate down to operate only with a particular IP address, click the Add button. Then, supply the IP address and port number you want to use for this SSL certificate and click OK.

Regardless of whether you decided to restrict the SSL certificate to a particular address, you’ll need to click OK again to continue. Once you return to the Key Manager window, the status for the SSL certificate you just installed should now show as Complete and Useable. Click OK to return to the main MMC console window.

Configuring OWA to use SSL
You’ve almost finished setting up SSL for your Exchange Server. In the MMC console window, right-click on the directory IISadmpwd, then select the Properties option. In the IISadmpwd Properties window, select the Directory Security tab. Click the Edit button in the Secure Communications area. Then, select the options Require Secure Channel When Accessing This Resource and Accept Certificates (under Client Certificate Authentication).

Right-click on Exchange (it will have an icon to the left that looks like an open box with a piece of paper sticking out of it), then select Properties. In the resulting window, click the Directory Security tab. Click the Edit button under Secure Communications. Then, select the Require Secure Channel When Accessing This Resource and the Accept Certificates options. Click OK twice to return to the main MMC window. You can now exit MMC.

To achieve even greater security for OWA, you can install workstation-level SSL certificates and configure IIS to look for these. If you do this, OWA and SSL will work only if the user logs in from his or her PC, because an individual certificate is linked to an individual NT login account.

Testing the SSL link to OWA
Now that you’ve configured IIS to use SSL, you need to perform some tests. First, you must ensure that non-SSL communications will no longer work. In a Web browser, type http://mailserver.domain.com (use the actual host and domain name for your Exchange Server). If non-SSL access has been disabled, you should see an HTTP 403 window. The 403 error indicates that this resource requires the use of SSL for access. Next, reenter the same URL but this time start the URL with https instead of http. This time, everything should work fine.

You can also test the SSL functionality by replacing the IP address shown with the actual IP address of your Exchange Server. You may see a security alert from your Web browser indicating that the security certificate is valid but that the name on the certificate doesn’t match the name of the site. After clicking OK to answer this prompt, you should be able to get an HTTPS session to your Exchange Server via OWA.

Conclusion
In this Daily Drill Down, I walked you through the process of setting up your Exchange Server to handle SSL communications when using Outlook Web Access. Be sure you keep a copy of both the certificate request and the license file you receive just in case you have to replace the files. Good luck, and may all your sensitive information be encrypted!

Ronald Nutter is a senior systems engineer in Lexington, KY. He's an MCSE, Novell Master CNE, and Compaq ASE. Ron has worked with networks ranging in size from single servers to multiserver/multi-OS setups, including NetWare, Windows NT, AS/400, 3090, and UNIX. He's also the help desk editor for Network World. If you’d like to contact Ron, send him an e-mail. (Because of the large volume of e-mail that he receives, it's impossible for him to respond to every message. However, he does read them all.)

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks

Free Newsletters, In your Inbox