Managing certificates |
 |
By Paul Robichaux
17 May 2004 | SearchExchange.com |
 |


|
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.
Before you can do much of anything with S/MIME, you'll need an X.509v3 certificate that is flagged for use with e-mail
(either as a signing certificate, an encryption certificate, or a dual-use certificate).
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.
');
// -->
|
 |
|
 |