Build Your Skills: Set up secure e-mail with Exchange

Learn how to make your Exchange e-mail more secure.

More companies are learning how important it is for remote employees to be able to send and receive secure e-mail without having to set up a Virtual Private Network (VPN) system. The only problem is that there isn’t a universally accepted set of instructions that can help you accomplish this goal. Recently, I encountered this problem when the director of information systems and technology for my company ordered all remote employee e-mail traffic to be made secure. In this Daily Drill Down, I’ll summarize what I learned from putting together bits and pieces of about 10 technical documents on Microsoft’s support Web site, and I’ll explain how you can make your Exchange e-mail more secure.

Where to obtain the certificate
First, you must make sure that your remote users are using either Outlook 2000 or Outlook Express 5. Earlier versions of both mail clients can’t use SSL, as Microsoft intended. (This fact is mentioned in some of Microsoft’s technical notes.) You should upgrade your remote users to the version of Outlook that you want them to use. That way, everything will run smoothly when you kick off your secure e-mail. To enable secure communication on your Exchange server, you must obtain the appropriate SSL certificate for your Exchange server. The three primary certificate authorities are VeriSign, Thawte, and CyberTrust. Of course, other CAs exist, but you must make sure that your users’ browsers will support their certificates. If not, then your users will have to install another certificate or service that allows them to establish an SSL connection to your Web site.

Make sure you allow plenty of time to obtain your certificate. Don’t expect the certificate issuer to give you a certificate as soon as you fill out the request. The CA must take time to check your background, confirm your company’s identity and make sure that you are who you say you are. This can take anywhere from a few hours to a week or more.

Before you obtain an SSL certificate, you must determine which level of encryption you need (basic or 128-bit encryption, etc.). Do you want additional services with the certificate? For instance, when you choose your CA and certificate, you may want something that will measure the performance of your Web site from several different cities.

As with most products, the cost for certificates varies from supplier to supplier. For this Daily Drill Down, I chose to use the certificate from VeriSign. I like VeriSign’s market share and the ease with which you can install the VeriSign certificate. The price for VeriSign’s certificate at the time this Daily Drill Down was written was $1,300.

Preparations for the CA application process
As mentioned in the Daily Drill Down “Using Secure Socket Layer with Outlook Web Access” (page 171), I went through a CA application process for my company not long ago. I encountered a couple of surprises, too. When we applied for our certificate, the CA checked our business information with Dun & Bradstreet, a common source of business-to-business information. Unfortunately, our address and contact information was incorrect because we had just moved. The application process for the SSL certificate was delayed for several weeks while I filled out the form again on Dun & Bradstreet’s Web site. Then, I had to make a phone call before the changes could go into effect.

I quickly bumped into another problem. After applying for our certificate, I discovered that VeriSign requires a fully qualified DNS name for the server that it’s going to issue the certificate for. VeriSign won’t issue an SSL certificate if you only list an IP address for it. You must have a DNS record for the server, and the record must list the server’s IP address along with its name.

So we hit another snag because of a problem at the ISP that hosts our DNS. The primary DNS server showed the information, but information about our e-mail server (which I needed to distribute) wasn’t showing up on the secondary DNS server. A couple of calls to the ISP resolved this problem. Still, this example makes a good case for handling DNS services on your own system.

The administrative and technical contacts for your DNS records are very important. The CA uses this information to determine who to send the certificate to when it’s ready. Assuming that all information checks out, VeriSign mails 40-bit SSL certificates to whoever requested them. Therefore, you should make sure that your certificate doesn’t accidentally go to your ISP e-mail account. It needs to go to your company e-mail server. VeriSign will send 128-bit certificates only to the administrative or technical contacts for a domain. So, if you’re hosting your own DNS servers, you’ll want to make sure that you’re listed as the administrative or the technical contact for those Internet domains for which you’ll be receiving SSL certificates.

The last thing you should check is your Exchange server. To do so, select Start | Programs and look for the NT 4.0 Option Pack listing. If you see this menu option, both IIS 4.0 (one of the requirements for using OWA) and the Outlook Web Access component of Exchange have probably been installed on the Exchange server. If you don’t see this listing, you’ll need to install IIS, reapply the NT Service Pack, run the Exchange setup program again, add the Outlook Web Access component, and reapply the Exchange service pack. (You should be using at least Exchange SP 2.)

Finally, make sure you have the latest Service Packs on your server. I recommend that you use at least Service Pack 5 for NT. Service Pack 5 and later include some fixes for some NT SNMP-level problems.

Initiating the certificate process
As we also explained in “Using Secure Socket Layer with Outlook Web Access,” you must first generate a certificate-signing request (CSR). The CSR will create a text file that you can cut and paste into a form on the CA’s Web site. Then, the CA will start the process of generating an SSL certificate for you. Now, start the Internet Service Manager (non-html version). Doing so will bring up the Microsoft Management Console (MMC).

When the splash screen disappears, right-click the Web site’s name and select Properties. When the Web site properties page appears on the screen, right-click the Web site to which you want to add the certificate. Click the Directory Security tab and look for the Secure Communications box. Then, click the Key Manager tab to start the file creation process. When the Key Manager screen appears, select the service for which you want to install SSL. Highlight and right-click the SMTP. Then, highlight and click the Create New Key option. A Create New Key wizard will guide you through the process of creating a certificate request.

Unless you’re going to be your own certificate authority (which you should do only if you’re looking for SSL services on a corporate intranet), go through the wizard to create a text file. Then, cut and paste that text file into VeriSign’s Web site when you apply for your SSL certificate. When the wizard first appears, the default location and file name is c:\NewKeyRq.txt. Unless you have a compelling reason for moving the location of this file, click Next to continue. The next screen will ask you to choose a name for the key. (The name for the key will become important if you have more than one certificate on your server; you’ll want to be able to identify which certificate is being used for what purpose.)

Type the name that you want to use for the key request and choose a password that will control the installation of the SSL certificate. Keep this password handy. You’ll need it later when you install the SSL certificate from VeriSign. Click Next. Now, you’ll be asked for some information that will help you differentiate this certificate from others that you may have. Supply the requested information and click Next. Then, you’ll need to enter the country, state, and city in which you’re located. After you type the appropriate information, click Next. The next screen will request your name, e-mail address, and telephone number. That way, VeriSign can contact you if there are any problems with your request. Click Finish to complete the key request file. Now, you should see a key entry below the WWW label on the Key Manager screen.

After you receive your certificate
Open Notepad or WordPad and open the key request file that you just created. Once you’ve answered the appropriate questions on VeriSign’s Web site, cut and paste the key request file (in its entirety) into the designated part of the form. As we mentioned above, VeriSign will do a background check on your organization and issue the certificate. The process will take anywhere from a few hours to a few days.

When you receive your certificate, go back into the Internet Service Manager (also known as the MMC or Microsoft Management Console). Select Start | Programs | Windows NT 4.0 Option Pack | Microsoft Internet Information Server | Internet Service Manager. In the left pane, right-click the default Web site upon which you want to enable SSL and select the Properties menu option. Click the Directory Security tab. Then, click the Edit button in the Secure Communications box.

On the Secure Communications screen, click the Key Manager button, as shown in Figure A. Highlight the key request that you just created and right-click the certificate request. Then, highlight and click Install Key Certificate. Now, find the certificate file that you received from VeriSign and highlight and double-click the filename. Enter the password that you created earlier.

Figure A
You can manage your SSL certificates with Key Manager.

When the Server Bindings screen appears, you won’t need to do anything unless you’re running multiple Web servers on the Exchange server. If you want to isolate the SSL certificate to operate only with a particular IP address, click the Add button, enter the IP address and port number that you want to use for this SSL certificate and click OK. After you’ve restricted the SSL Certificate, click OK to continue from the Server Bindings screen. Even if you didn’t restrict the certificate, click OK.

When you return to the Key Manager screen, you’ll see the status for the SSL certificate. The Key Manager should show the certificate's status as Complete And Useable. Click OK to return to the main MMC console screen.

SSL is now enabled on the SMTP portion of your exchange server. To use SSL on the mail retrieval portion of the POP3 protocol, you must install the certificate on that protocol, too. Highlight the certificate that you just installed on the SMTP protocol and click the Key menu option of the Key Manager that’s already open, as shown in Figure B.

Figure B
You must install the certificate on your server’s POP protocol, too.

Highlight and click the Export Key option and the Backup Key option. That way, you can back up the key that you already installed on the SMTP protocol, and you’ll be able to import it onto the POP3 protocol. Once you’ve saved the file (and noted where you saved it), you’re ready to import the SSL certificate into the POP3 protocol. Click POP3 in Key Manager, click the Key menu option in Key Manager, and click Import Key. Select the Import Key option and restore from Backup Key. Once you’ve completed the process of importing the SSL certificate, you should see a key icon with the name that you assigned to the SSL certificate when you created the request under the SMTP protocol.

Finally, you must check with Exchange Administrator that authentication via POP3 and SMTP can be performed with SSL. Go to the protocols under your Exchange server in Exchange Administrator and verify that authentication via SSL (which should be performed by default). Don’t immediately revoke users’ ability to authenticate to SMTP and POP3 without SSL. First, make sure that all of the clients have been reconfigured to handle their communications with the Exchange server via SSL. Once you’ve verified that all clients can use SSL, you can change the SMTP and POP3 settings.
There’s another method of enabling the SSL certificate under the POP3 protocol, but I don’t recommend it. It involves creating a certificate request—just like you did when you submitted the initial request for the SSL certificate. This time, however, you would import the file that you already have. When I used this method, I received error messages on the client side that weren’t referenced in any of the documents on Microsoft’s support site. Using the method that I’ve described in this Daily Drill Down is far more effective and reliable.
Configuring Outlook Express 5 to use SSL
Setting up Outlook Express to communicate via SSL is pretty straightforward. First, you must start Outlook Express. Select Tools | Accounts And Mail. Click the mail account for which your copy of Outlook Express has been configured. Then, click Properties. When the properties screen appears for the mail server with which you’re working, click the Advanced tab, as shown in Figure C. Next, check the boxes below the Outgoing Mail and Incoming Mail server port numbers. Then, click OK to finish the SSL configuration process.

Figure C
After you’ve configured SSL on the server, enable it on your clients.

Until you’ve followed this procedure a few times, I recommend that you turn on just one side of the mail exchange process (SMTP or POP3) and attempt to receive and send mail that way. Once you’re satisfied that each part of the mail exchange process is working, move to the next step and disable the non-SSL portion of the POP3 mail exchange process on the Exchange server. If everything works properly, you’re ready to begin converting the Outlook Express or Outlook 2000 clients that you’ve deployed.

Before you disable the non-SSL authentication option in Exchange Administrator, however, think very carefully about the mail exchange process. Not all mail servers are set up in such a way that they can use SSL to exchange mail. Since SMTP is the primary method of exchange mail between mail servers, you need to leave the non-SSL option of authentication enabled so that you won’t cut yourself off from the outside world.

Ronald Nutter is a senior systems engineer in Lexington, KY. He's an MCSE, a Novell Master CNE, and a 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