The following is tip #14 from "20 Tips on securing Outlook in 20 minutes," excerpted from a chapter in Paul Robichaux's book, Secure Messaging with Microsoft Exchange Server 2003 © 2004, published by Microsoft Press. Return to the main page for more tips on this topic.
Accordingly, certificate management is the logical place to start.
Getting a New Certificate
Outlook happily uses any properly constructed X.509v3 certificate for which you have the private key, provided you can get the certificate into your local user profile on the machine you are currently using. Depending on whether you're setting up a complete (or outsourced) public-key infrastructure (PKI) or whether individual users want certificates, you can enroll users through the Exchange 2000 Server Key Management Service (KMS), manually or automatically enroll through a Windows Server 2003 CA, or manually request individual certificates from a third-party CA.
If you are not using a Windows Server 2003 CA to automatically or manually enroll a certificate, you tell Outlook to request your new certificate by launching Outlook, choosing the Tools | Options command, clicking the Security tab, and clicking Get A Digital ID. What happens next depends on whether you're requesting a certificate through the Exchange KMS or from an external CA. For more information on how to setup and utilize certificate auto-enrollment with Windows Server 2003, refer to the white paper.
Getting a Certificate from an Internal Certificate Server
The most common way for enterprise users to get a certificate is through the Windows Server 2003 Certificate Services component, which takes the place of the Exchange 2000 Server KMS. The preferred deployment model now in a Windows XP and Windows Server 2003 environment is to use user certificate auto-enrollment, but support for Exchange KMS advanced security using the Exchange tools included in the Active Directory Users and Computers snap-in is still available. Although the new model is easiest with little or no user interaction, from the legacy Outlook and KMS side, the manual process is still simple; it begins when clients use Outlook to generate a temporary key, which is then used to protect the initial client-to-CA exchange. You can provide the token in an e-mail message or using another (presumably more secure) offline channel; either way, the user must have the token before proceeding.
After you click Get A Digital ID, you'll see the dialog box. This dialog box only appears for accounts that have been enrolled in Advanced Security; if you don't see it, the logged-in profile's account needs to be enrolled before proceeding. Because you want a certificate issued by the local Exchange organization's certificate server, choose the Set Up Security For Me On The Exchange Server option and click OK.
Outlook asks you to pick a name for this digital ID and enter your token, then you are asked to assign a password. Note that this password is completely separate from your Windows account password—and it should be different, so that compromising one doesn't affect the other. At this point, your request is sent to the certificate server, which approves or rejects it (usually fairly quickly). First, though, you have to close the Outlook Options dialog box; you will eventually receive a signed status message from the CA indicating either that your enrollment was rejected or accepted. For requests that are accepted, you'll be prompted to enter your password so that Outlook can publish your certificate in the Global Address List (GAL) for you (you can do so manually, too, as you'll see later).
Using an External CA
Individual users can always request their own certificates from an external CA and install them in Outlook. Presuming that you choose a widely known CA, this might be an attractive alternative to setting up your own PKI, particularly for small numbers of users. Certificates are available from various sources. For example, Thawte offers a free end-user certificate that's adequate for many individuals' uses; various professional, social, and government organizations either are or will soon be issuing certificates to their members.
If you click Get An S/MIME Certificate From An External Certification Authority, Outlook takes you to a page associated with an external CA. By default, the page you get is one hosted at the Microsoft Office Assistance Center (currently http://office.microsoft.com/marketp lace/PortalProviderPreview.aspx?AssetID=EY010504841033) that lists third-party CAs that you can use. The CAs listed there offer personal certificates; each one has slightly different enrollment and certification procedures. However, using the policy controls I discuss subsequently, you can send your organization's Outlook users to whatever CA you prefer. Once you've enrolled with the remote CA and received your certificate, you'll need to import it, as discussed in the section "Importing and Exporting Certificates" later in the chapter.
Publishing Your Certificate in the GAL
If you're using an enterprise CA, newly issued certificates are published in the GAL. However, users who go out and get their own certificates will find that their certificates aren't in the GAL. If Alice and Bob want to exchange encrypted messages, and neither has a certificate in the GAL, Alice must first send Bob a signed message. When Bob opens it, his Outlook client adds Alice's certificate to the local store, at which point he can use it to send her an encrypted reply. This requirement is a hassle, so Outlook provides a way for you to publish arbitrary certificates that you control as attributes for your user account; this, in turn, makes them visible in the GAL. The steps required to publish your certificate are simple:
- Launch Outlook while logged in with the account you want the certificate associated with. (Of course, you have to have access to the desired certificate in some form, either in the local machine certificate store or on a smart card or other portable token.)
- Use the Tools | Options command to open the Options dialog box, then click the Security tab.
- Click Publish To GAL. Outlook warns you that it's about to publish your default certificate (the one identified in the Default Setting field of the Secure E-Mail command group, which is described in the next section) to the GAL; click OK if you want it to do so.
Importing and Exporting Certificates
Once you have a certificate, it's not necessarily tied to a single machine. CryptoAPI allows whoever generates the key to specify whether a key can be exported or not; by default, most certificates generated by the Windows Certificate Service or third-party CAs come from private keys that are marked as exportable. As long as the private key is exportable, you can use Outlook to export the key pair and associated certificate to a file, which can then be imported on another machine. For example, I can receive a certificate on my desktop machine, then export it and import it on my laptop so I have access to encrypted mail (and other resources) from both machines.
You export and import certificates from Outlook using the Import/Export button on the Security tab of Outlook's Options dialog box. Clicking that button produces the Import/Export Digital ID dialog box. Use the two options to select whether you want to import or export; the associated controls in each group let you specify where the file containing the certificate is located and what the associated password is. The Delete Digital ID From System check box is worth special mention: when selected, after exporting your private key to the file Outlook removes it. Use this option when you want to migrate a certificate from one machine to another; leave it cleared if you want to copy the key material.
Get more "20 Tips on securing Outlook in 20 minutes!" Return to the main page.
About the author: Paul Robichaux is a partner at 3sharp LLC, author of several books on Exchange, Windows, and security, a Microsoft MVP for Exchange Server and a frequent speaker and presenter at IT industry conferences. He's written software for everyone from the U.S. National Security Agency to scientists flying their experiments aboard the Space Shuttle, fixed helicopters in the desert, and spent way too much time playing video games.