Tutorial

Using S/MIME in Microsoft Outlook

S/MIME can be a little daunting for end users, because it relies heavily on algorithms and protocols that can charitably be described as complex. Microsoft has done its best to simplify the interface and behavior in Outlook while still giving power users lots of knobs to adjust.

 
You are reading tip #5 from "8 tips in 8 minutes: A Microsoft Outlook email security tutorial," excerpted from Chapter 13 of Secure Messaging with Microsoft Exchange 2003 by Paul Robichaux, copyright 2004, published by Microsoft Press.

Managing certificates for Microsoft Outlook 

Before you can do much of anything with S/MIME, you'll need an X.509v3 certificate that is flagged for use with email (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 for Microsoft Outlook

    Requires Free Membership to View

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 set up 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 (as you read in Chapter 12, "Secure Email") 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 email 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 shown in Figure 13-6. 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.

 

Figure 13-6 Pick the certificate source you want to use for your request

 

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 certificate authority (CA) for Microsoft Outlook

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 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 Global Address List (GAL) for Microsoft Outlook

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:

 

  1. 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.)

     

  2. Use the Tools | Options command to open the Options dialog box, then click the Security tab.

     

  3. 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 Email 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 for Microsoft Outlook

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 shown in Figure 13-7. 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.

 

Figure 13-7 You can use Outlook's import/export feature to move or copy your certificates between machines, but be careful not to unnecessarily expose them to compromise.

 

Note: You can also import an existing certificate from your own or a third-party CA; as long as it has the flags indicating that it's usable for email encryption and signatures, you'll be able to use it with Outlook.

Setting S/MIME options for Microsoft Outlook

Figure 13-8 shows the Security tab of Outlook's Options dialog box. The Encrypted Email control group on this tab allows you to set the defaults you want Outlook to use for S/MIME traffic. You can choose to sign, encrypt, or sign and encrypt outbound messages by selecting the appropriate check boxes. In addition, you can choose whether signed messages should be clear-signed or opaque-signed and whether or not you want your messages to include requests for signed return receipts.

 

Figure 13-8 Use the Encrypted Email control group on the Options dialog box Security tab to control Outlook's S/MIME behavior.

 

The most interesting control in this group is the Default Setting drop-down list and the associated Settings button; that's because these settings control the algorithms and message format you use when sending secure mail. When you click Settings, the Change Security Settings dialog box, shown in Figure 13-9, opens. Each security settings object contains your preferences for the certificate you want to use for signing and encrypting messages and the algorithms you prefer for each use. The controls in the dialog box are self-explanatory, so instead of reiterating what they do, it's more useful for me to explain why they're there in the first place.

 

Figure 13-9 Create groups of security settings for use with different certificates or recipients.

 

Remember that a certificate is just a credential. We all carry around multiple credentials: my driver's license isn't useful at the video store, and my bank card isn't useful when I want to board an airplane— each credential has its own purpose and set of attributes. Likewise, it's increasingly common for organizations that deploy PKIs to issue separate certificates for different purposes: every user might get one for signing email, but only the legal and merger departments might need one for encryption, and only the IT department gets certificates that can be used to sign macros or Office objects. This partitioning means that it might be useful to specify different algorithms or certificates for signatures and encryption, or even to maintain different "work" and "home" settings for users with business and personal certificates. That's one reason Outlook supports multiple sets of credentials, the other being its support for security labels (part of the DMS support included in Outlook).

Signing or encrypting a message

Actually signing or encrypting messages is easy with Outlook. You can always sign or encrypt individual messages, either using the Outlook toolbar or by opening the message properties; you can also tell Outlook to sign or encrypt all messages by default.

Encrypting or signing a single message

To secure a message as you're composing it in Outlook 2003, click the Options button in the toolbar; when the Message Options dialog box appears, click the Security Settings button and you'll see the Security Properties dialog box, shown in Figure 13-10. The Encrypt Message Contents And Attachments and Add Digital Signature To This Message check boxes do just what you'd expect; you can select either or both of them to add protection to your message when it's sent. When signing a message, you have two additional options: you can clear-sign the message (so that non-S/MIME-aware mail software can display the message contents), and you can request a signed return receipt—this proves that the recipient opened the message at a particular date and time, because it's signed with the recipient's private key.

Caution: When you're connected to your Exchange server, as soon as you add an attachment to a message in Outlook, it begins uploading the attachment in the background to the server. That conversation isn't encrypted (unless you've turned on RPC encryption, discussed later in the chapter), so be aware that an adversary might see some of your attachment if he or she can sniff traffic on the network.

 

Figure 13-10 To sign or encrypt a message, just select the check boxes that correspond to the desired security features.

 

You can also use this dialog box to choose a set of S/MIME parameters for the message; your choices are taken from the sets of S/MIME settings you defined on the Security tab of the Options dialog box, as discussed in the preceding section. You can also set a security label from this dialog box, but you won't be able to do so unless you're using a policy module, and there aren't any widely available ones except those used with DMS.

Tip: If you want to use security labeling, you can implement your own policy module; see http://msdn2.microsoft.com/en-us/library/aa140148(office.10).aspx for details.

Steps to update the Outlook Toolbar

Outlook's Standard toolbar includes toolbar buttons for encrypting and signing the current message, but they're not visible by default. Fortunately, you can customize the toolbar to include the icons—just use the Tools | Customize command, which displays the Customize dialog box. Here's what to do:

 

  1. Open a message (new or old, it doesn't matter). If the toolbar you want to put the buttons on isn't visible, make it visible with the View | Toolbar submenu.

     

  2. Choose the Tools | Customize command. When the Customize dialog box opens, click the Commands tab.

     

  3. Select Standard in the Categories list. The Commands pane lists the available toolbar buttons. Near the bottom of the Commands list, you'll see two icons: Encrypt Message Contents And Attachments and Digitally Sign Message.

     

  4. Drag the icons to the desired positions on the toolbar.

     

  5. Click Close.

Applying policy settings for Microsoft Outlook

It's all well and good to provide users a way to create signed and encrypted messages when they want to, but in many environments it's necessary to force or restrict a particular set of security settings. One little-noticed change in Outlook 2003 is that it incorporates a broad set of policy settings that allow centralized administrative control of encryption and security behaviors. These settings are available through Group Policy templates; the settings described in Table 13-3 are applied under the HKEY_CURRENT_USER\Software\ Policies\Microsoft\Office\10.0\Outlook\Security key.

 

Table 13-3: Policy Settings for Outlook Cryptographic Features

 

Value Name Data Type Supported Values Notes
AlwaysEncrypt DWORD 1: All outgoing messages are encrypted. 0: Default; outbound messages are only encrypted by user request. If Outlook cannot find a certificate for a recipient, you'll see an error dialog box like the one shown in Figure 13-11.
AlwaysSign DWORD 1: All outgoing messages are signed.
0: Default; outbound messages are only signed by user request.
x
ClearSign DWORD 1: All outbound messages include the message in cleartext, with a separate signature part.
0: Messages are signed with a combined signature/message block; the message is not present in cleartext.
Clear-signed messages allow recipients who aren't using S/MIME-capable clients to read the message, even though they cannot verify the signature.
RequestSecureReceipt DWORD 1: All outbound messages contain a signed receipt request; compliant clients will automatically return signed receipts when the message is opened.
0: Receipts must be individually requested.
S/MIME receipts are digitally signed, as is the request. The S/MIME specification requires compliant clients to honor receipt requests, without including an option to suppress receipts like Outlook does for ordinary messages.
ForceSecurityLabel DWORD 1: Every outbound message must be given a security label before it's sent.
0: Unlabeled messages can be sent.
This option is only useful if you're using a security labeling policy module.
ForceSecurityLabelX Binary All messages sent automatically include this administrator-defined label. Label must be stored as an ASN.1-encoded string. If you don't know what that means, you probably won't benefit from this feature.
SigStatusNoCRL DWORD 1: If the certificate revocation list (CRL) for a signing certificate cannot be found, treat it as an error.
0: Treat the missing CRL as a warning.
This option gives you control over whether users can accept messages with missing CRLs as valid or not.
SigStatusNoTrustDecision DWORD 2: "No trust" decisions are treated as errors.
1: "No trust" decisions are treated as warnings.
0: "No trust" decisions are allowed.
This value controls what Outlook does when the signatures and certificates on a message don't chain upward to a trusted root. Setting this value to zero can lead to malicious spoofing if you are not careful. See the Microsoft white paper.
PromoteErrorsAsWarnings DWORD 1: Treat level 2 errors as warnings
0: Treat level 2 errors as errors
Level 2 errors occur when the message signature appears to be valid, but something else is wrong (for example, no CRL can be found, the CRL or certificate trust list [CTL] is out of date, or the issuer certificate is missing).
PublishToGALDisabled DWORD 1: Disables the Publish To GAL button.
0: Button functions normally.
x
FIPSMode DWORD 1: Force Outlook to FIPS 140-1 compliance mode.
0: Outlook is not forced to FIPS 140-1 mode.
As described in Chapter 2, FIPS 140 is the U.S. government standard for cryptographic algorithm performance and security. When Outlook is in FIPS 140-1 mode, the set of signing and encryption algorithms it can use is somewhat restricted.
WarnAboutInvalid DWORD 2: Never give users warnings when invalid or improper certificates or signatures are found.
1: Always show the Secure Email Problem dialog box when a problem occurs.
0: Ask the user each time whether a particular warning should be displayed.
By default, Outlook will warn users when a problem occurs in a secured message, along with displaying a Show And Ask check box that lets users ignore the problem and see the message anyway. This value controls whether users are given that choice when a problem message is encountered.
DisableContinueEncryption DWORD 1: Hide the Continue Encryption button.
0: Show the button.
When you send a message to multiple recipients, if for some reason you can't send to a particular recipient, Outlook displays a button that lets you continue encrypting the message to the remaining recipients. If you want to prevent users from sending unencrypted messages, you'll have to turn this off.
RespondToReceiptRequest DWORD 0: Always send signed receipts when requested; only prompt for a password if it's needed.
1: Always send signed receipts; always prompt for the password.
2: Never send signed receipts.
3: Force receipts to be sent.
Because signed receipts have to be signed, you'll have to enter your credentials to sign the receipt. If you cancel instead, the receipt won't be sent. Tweaking this value lets you control whether the receipt is sent or not.
NeedEncryptionString REG_SZ String that is displayed when the user tries to open an encrypted message for which he or she doesn't have an appropriate certificate. This message can be used to tell users where or how to get their certificates.
Options DWORD 1: Don't warn users when they try to open a signed message with an invalid x
MinEncKey DWORD Set to the minimum key length to be used when sending encrypted messages. Set this value to the key length you want to use: 40, 64, 128, or 168 bits. (Note that 40- and 64-bit encryption are too weak for most commercial applications.)
requiredCA REG_SZ Gives the name of the required CA; when this is set, Outlook won't sign or encrypt mail with certificates issued by any other CA. x
EnrollPageURL REG_SZ URL for the page that users should be sent to when they click Get A Digital ID. This string can contain three expansion variables: %1 is replaced with the user's display name, %2 is replaced with the user's SMTP address, and %3 is the code page ID for the user's preferred language.

 

Figure 13-11 Outlook complains if it cannot find a recipient certificate.

 


8 tips in 8 minutes: A Microsoft Outlook email security tutorial 

 Home: Introduction
 Tip 1: An overview of Microsoft Outlook email security features
 Tip 2: Customizing the Microsoft Outlook Security Update
 Tip 3: Customizing Outlook email security settings for end users 
 Tip 4: Setting up RPC over HTTP for Microsoft Outlook 
 Tip 5: Using S/MIME in Microsoft Outlook
 Tip 6: Using Information Rights Management in Microsoft Outlook
 Tip 7: Reaching into Microsoft Outlook's email security toolbox
 Tip 8: Related resources on Microsoft Outlook email security
 

 

  This chapter is an excerpt from Secure Messaging with Microsoft Exchange 2003 by Paul Robichaux, copyright 2004, published by Microsoft Press.

Click here for the chapter download or purchase the book here.

 

 

This was first published in May 2007

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: