How to Protect E-Mail Confidentiality in Regulated Industries

On This Page

Introduction
Helping to Protect E-Mail Confidentiality Scenario
Summary

Introduction

All organizations are facing significant legal and regulatory challenges in such areas as information security, privacy, and reliability. These challenges can require major changes to systems and processes across an organization. Businesses must react to and plan for the increasing structure and regulation around accountability and control to meet many legal and ethical objectives. Compliance means meeting all of the legal and business requirements that an organization faces and must demonstrate during the course of operations and in doing business. Compliance also means understanding the legal framework in which judicial and corporate requirements operate. Becoming compliant involves every business department and every employee. Compliance cannot be achieved through the implementation of a single solution or process; it must be built into every business section of an organization.

The regulatory environment is increasingly complex. Compliance is often not a simple process, and regulations vary in the specificity of their requirements. An organization must, therefore, conduct a full assessment of risks and impacts.

The scope of this paper is to describe some of the processes and technologies that you can use to help standardize and streamline regulatory compliance efforts in the area of e-mail confidentiality. This paper presents resources and options that many small to medium businesses encounter while trying to comply with laws and regulations. This paper is not a roadmap to regulatory compliance, nor does it provide legal advice on any of these issues. Readers must consult with their own advisors and attorneys prior to enacting any compliance program or process.

Who Should Read This Guide

The intended audience for this guide includes IT professionals who are responsible for the installation, maintenance, and administration of an e-mail service based on Microsoft® Exchange Server 2003 in their network environments.

The information in this guide applies to small to medium businesses that must deliver confidential e-mail messages on their network.

Overview

Although message security features have been available in Microsoft Exchange Server since the first version of the product, typically only customers that have specialized security requirements and security staff have used these features. Only security specialists and those with cryptography backgrounds needed to understand e-mail message security concepts. With the increased support for Secure/Multipurpose Internet Mail Extensions (S/MIME) in Exchange Server 2003 and the need for regulatory compliance, administrators began to need to understand these principles and concepts.

The Messaging and Security Feature Pack for Windows Mobile 5.0 offers support for S/MIME certificates on smart phones. In addition, Microsoft Exchange Server 2003 Service Pack 2 (SP2) offers support for S/MIME in Microsoft Outlook® Web Access (OWA).

This paper presents an introduction to S/MIME and its related concepts and provides prescriptive guidance on how to implement S/MIME. No background in security is needed. This paper explains general S/MIME concepts so that you can apply the concepts specifically to Exchange Server.

S/MIME Benefits

Before S/MIME, administrators used a widely accepted e-mail protocol to transfer messages, Simple Mail Transfer Protocol (SMTP), which was inherently less secure. Or administrators used more secure but proprietary solutions. In essence, they were forced to choose a solution that emphasized either security or connectivity. With S/MIME, administrators now have an e-mail option that helps provide greater security than SMTP, enabling widespread and secure e-mail connectivity.

S/MIME provides two security services:

  • Digital signatures

  • Message encryption

These two services are the core of S/MIME-based message security. All other concepts related to message security support these two services. Although the full scope of message security may seem complex, these two services are the basis of message security.

Digital signatures and message encryption are not mutually exclusive services. Each service addresses specific security issues. Digital signatures address authentication and repudiation issues, and message encryption addresses confidentiality issues. Because each service addresses different issues, a message security strategy requires both, often at the same time. These two services are designed to be used in conjunction with one another, because each separately addresses one side of the sender-recipient relationship. Digital signatures address security issues related to senders, whereas encryption primarily addresses security issues related to recipients.

When digital signatures and message encryption are used together, users benefit from both services. Employing both services in messages does not change the handling or processing of either service.

Digital Signatures

Digital signatures are the more commonly used service of S/MIME. As the name suggests, digital signatures are the digital counterpart to the traditional, legal signature on a paper document. As with a legal signature, digital signatures provide the following security capabilities:

  • Authentication. A signature serves to validate an identity. It verifies the answer to "who are you" by providing a means of differentiating that entity from all others and proving it’s from a mutually trusted source. Because there is no authentication in SMTP e-mail, there is no way to know who actually sent a message. Authentication in a digital signature helps solve this problem by enabling a recipient to know that a message was sent by the person or organization who claims to have sent the message.

  • Non-repudiation. The uniqueness of a signature helps prevent the owner of the signature from disowning the signature. This capability is called non-repudiation. Thus, the authentication that a signature provides gives the means to enforce non-repudiation. The concept of non-repudiation is most familiar in the context of paper contracts: A signed contract is a legally binding document, and it is more difficult to disown an authenticated signature. Digital signatures provide the same function and, increasingly in some areas, are recognized as legally binding, similar to a signature on paper. Because SMTP e-mail does not provide a means of authentication, it cannot provide non-repudiation. It is easy for a sender to disavow ownership of an SMTP e-mail message.

  • Data integrity. An additional security service that digital signatures provide is data integrity. Data integrity is a result of the specific operations that make digital signatures possible. With data integrity services, when the recipient of a digitally signed e-mail message validates the digital signature, the recipient helps to assure that the e-mail message that is received is, in fact, the same message that was signed and sent and has not been altered while in transit. Any alteration of the message while in transit after it has been signed invalidates the signature. In this way, digital signatures are able to help provide an assurance that signatures on paper cannot, because it is possible for a paper document to be altered after it has been signed.

Message Encryption

Message encryption provides a solution to information disclosure. SMTP-based Internet e-mail does not secure messages. An SMTP Internet e-mail message can be read by anyone who sees it as it travels or views it where it is stored. S/MIME helps to address these problems through the use of encryption.

Encryption is a way to change information so that it cannot be read or understood until it is changed back into a readable and understandable form.

Although message encryption is not as widely used as digital signatures, it does address what many people perceive as the most serious weakness in Internet e-mail. Message encryption provides two specific security services:

  • Confidentiality. Message encryption helps serve to protect the contents of an e-mail message. Only the intended recipient can view the contents, and the contents remain confidential and cannot be known by anyone else who might receive or view the message. Encryption helps provide confidentiality while the message is in transit and in storage.

  • Data integrity. As with digital signatures, message encryption helps provide data integrity services as a result of the specific operations that make encryption possible.

S/MIME Requirements

To provide e-mail confidentiality, your environment requires particular software components. This section outlines those components.

Public Key Infrastructure (PKI)

S/MIME solutions require a PKI to provide digital certificates with public key/private key pairs and enable certificate mapping in the Active Directory® directory service. The S/MIME standard specifies that digital certificates used for S/MIME conform to the International Telecommunications Union (ITU) X.509 standard. S/MIME version 3 specifically requires that digital certificates conform to version 3 of X.509. Because S/MIME relies on an established, recognized standard for the structure of digital certificates, the S/MIME standard builds on that standard's growth and thus increases its acceptance.

You can implement a PKI to support S/MIME in one of two ways: provision the internal certificate infrastructure to an external organization, or use Certificate Services in Microsoft Windows Server™ 2003.

For more information about Certificate Services in Windows Server 2003, see the Public Key Infrastructure for Windows Server 2003 Web site, at www.microsoft.com/windowsserver2003/technologies/pki/default.mspx.

The PKI must have a mechanism that deals with certificate revocation. Certificate revocation is necessary when a certificate expires or when an attacker could have compromised a certificate. By revoking a certificate, an administrator denies access to anyone who uses the certificate. Each certificate includes the location of its certificate revocation list (CRL).

For more information about how to manage certificate revocation, see the Manage Certificate Revocation topic at https://technet2.microsoft.com/WindowsServer/en/Library/de0ae267-14e6-46f8-bcc7-8ac480889b951033.mspx

Certificate Templates

Windows Server 2003 provides specific certificate templates to issue digital certificates for use with S/MIME. Three multi-function user certificate templates can be used to issue certificates for secure e-mail:

  • Administrator. Allows an administrator to use a certificate for authentication, Encrypted File System (EFS) encryption, secure e-mail, and certificate trust list signing.

  • User. Allows a user to use a certificate for authentication, EFS encryption, and secure e-mail.

  • Smart card user. Allows a user to log on with a smart card and sign e-mail. In addition, this certificate provides client authentication.

Note   Microsoft strongly recommends that you upgrade a current Windows Server 2003 PKI to a Windows Server 2003 with Service Pack 1 (SP1) PKI to take advantage of enhanced security features.

For more information about certificate templates, see the Certificate Templates topic on Microsoft TechNet, at https://technet2.microsoft.com/windowsserver/en/library/7D82B420-10EF-4F20-A56F-17EE7EE352D21033.mspx.

Active Directory

Active Directory is a key component for the implementation of S/MIME certificates. To deploy certificates to users for use with e-mail services, an administrator can make use of the Group Policy autoenrollment feature of Active Directory. Also, Active Directory in Windows Server 2003 contains built-in support as the PKI directory for several Microsoft e-mail clients, including Outlook, Outlook Express, and Outlook Web Access (OWA) with S/MIME and the ability to map user accounts to certificates.

For more information about certificate mapping, see the Map certificates to user accounts topic at https://technet2.microsoft.com/WindowsServer/en/library/0539dcf5-82c5-48e6-be8a-57bca16c7e171033.mspx?mfr=true.

Exchange Server 2003

By providing support for a variety of e-mail clients, Exchange Server 2003 administrators can customize their deployment to meet their specific needs. Exchange Server 2003 S/MIME support for clients is similar to the overall support for clients in that customers can use any of the supported clients simultaneously. Thus, an Exchange Server 2003 S/MIME–based solution can support Outlook clients, OWA clients, and Outlook Express clients using POP3 all at the same time. However, because the e-mail client must support S/MIME version 3 and be a supported Exchange Server e-mail client, not all e-mail clients can be S/MIME clients.

S/MIME is also provided in Exchange Server 2000 and Exchange Server 2007.

E-Mail Clients

Exchange Server 2003 supports S/MIME clients through its existing support for client protocols. If a supported client also supports S/MIME, that client can be used with Exchange Server 2003. If the client does not support S/MIME version 3, that client can still be used to read clear-signed messages.

Microsoft Outlook 2003

Outlook supports Messaging Application Programming Interface (MAPI)–based connectivity to Exchange Server 2003. In addition, Outlook can connect by using POP3 and IMAP4. Exchange Server 2003 S/MIME can be used with any version of Outlook that supports X.509 v3 digital certificates. Full support in Outlook for X.509 v3 digital certificates was first introduced with Outlook 2000 Service Release 1 (SR-1).

POP3 and IMAP4 Clients

Exchange Server 2003 provides full support for S/MIME clients through the Internet e-mail standard protocols POP3 and IMAP4, if the e-mail client supports S/MIME version 2 or version 3. Any e-mail client that supports S/MIME version 2 or version 3, and either POP3 or IMAP4, can be used as an e-mail client in an Exchange Server 2003 message security system. Because any e-mail client that supports the S/MIME standard provides full support for all message security services, these clients can be used as full-featured e-mail clients. Microsoft provides S/MIME version 3 support in POP3 and IMAP4 clients in both Outlook Express 5.5 or later and Outlook 2000 SR-1a or later.

Note   Different Internet standards and e-mail clients have their own requirements and ways of handling X.509 v3 certificates. Be aware of these requirements and compatibility issues when deciding which e-mail clients will be supported.

Operational Considerations

After you implement and verify the elements of this solution, you should consider a number of ongoing activities to ensure that the solution will continue to operate successfully for protection of e-mail confidentiality.

Operational considerations include:

Helping to Protect E-Mail Confidentiality Scenario

The following procedure to protect e-mail confidentiality relates to small and medium business scenarios similar to the one shown in the following figure.

Cc875813.PECRI01(en-us,TechNet.10).gif

Figure 1. E-mail services in the medium IT environment

Specifically, e-mail users require confidentiality for e-mail sent to both internal and external locations. To help achieve this, you implement Exchange Server 2003 and the e-mail clients to support S/MIME.

Helping to Protect E-Mail Confidentiality

The following steps identify the configuration procedures that are necessary to help protect your e-mail confidentiality.

Before You Begin

Before you implement S/MIME in an Exchange Server 2003 environment, you must understand what will happen to messages if you have implemented any of the following:

  • Event sinks

  • Antivirus software

Event Sinks and Digitally Signed Messages

Event sinks can perform actions on e-mail messages when the Exchange Server handles them. For example, some event sinks alter the content and headers of an e-mail message for the purpose of filtering the message. A valid digital signature indicates that a message has not been altered in transit. An event sink that alters the e-mail message invalidates digital signatures. When the recipient receives the message and processes the digital signature, the digital signature will be invalid because the event sink changed the message after the sender signed it.

Antivirus Software and S/MIME Messages

When using a server-based antivirus solution, encryption that helps protect the confidentiality of the message body and any attachments from unauthorized users also prevents server-based antivirus software from inspecting the message and attachments for viruses. Because the antivirus software cannot inspect the message, an encrypted message could include a virus as an attachment. You should determine how to address this risk in accordance with your security policy.

Also, if an antivirus program detects a virus in a digitally signed e-mail message and cleans the message, this action can render the digital signature invalid, because the antivirus program has altered the message while in transit. Although the alteration is not malicious, from the perspective of the digital signature, the message is changed, and the message will be identified as altered.

How to Configure Exchange Server 2003 to Help Provide E-Mail Confidentiality

When Exchange Server stores S/MIME e-mail messages, the only requirement is that the message store is configured to handle S/MIME signatures. Because S/MIME messages can be held in user mailboxes and in public folders, both public stores and mailbox stores can be configured to hold messages with S/MIME signatures.

  1. Log on by using an account that is a member of both of the following:

    • The Administrators group on the local computer

    • A group to which at least the Exchange View Only Administrators role has been applied at the Administrative Group level

  2. Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager. The Exchange System Manager (shown in the following screen shot) will display.

    Exchange System Manager

  3. Click Servers, click <servername> , click Storage Group, right-click the Mailbox Store, and then click Properties.

    On the Properties page, select the Clients support S/MIME signatures check box as shown in the following screen shot.

    Mailbox Store

How to Deploy Digital Certificates for S/MIME Using Autoenrollment

Autoenrollment allows clients to automatically submit certificate requests to a certification authority (CA) and retrieve and store issued certificates. Microsoft Windows® XP and Windows Server™ 2003 clients can participate in autoenrollment for both user and computer certificates. Autoenrollment reduces the total cost of ownership (TCO) by reducing the costs associated with the certificate enrollment and renewal process.

To enable autoenrollment settings

  1. Log on with Administrator rights.

  2. From Administrative Tools, open Active Directory Users and Computers.

  3. In the console tree, right-click the domain where you want to implement the autoenrollment settings, and then click Properties.

    For autoenrollment, the Group Policy object (GPO) must be linked to either the domain or the organizational unit where the user or computer accounts exist.

    Group Policy object

  4. In the DomainName Properties dialog box, on the Group Policy tab, click Open to open the Group Policy Management Console.

  5. Create a GPO linked to the domain.

  6. In the Group Policy Object Editor, in the console tree, expand User Configuration.

  7. In the console tree, expand Windows Settings, expand Security Settings, and then click Public Key Policies as shown in the following screen shot.

    Public Key Policies

  8. In the details pane, double-click Autoenrollment Settings. In the Autoenrollment Settings dialog box, ensure that the following settings are selected as shown in the following screen shot:

    • Enroll certificates automatically. This setting enables autoenrollment of certificates for the organizational unit where the GPO is linked.

    • The Renew expired certificates, update pending certificates, and remove revoked certificates check box. This setting enables certificate autoenrollment for certificate renewal, issuance of pending certificates, and removal of revoked certificates from the subject's certificate store.

    • The Update certificates that use certificate templates check box. This setting enables autoenrollment for superseded certificate templates.

    Autoenrollment Settings

  9. Click OK.

Autoenrollment is now enabled for the organizational unit where the GPO is linked.

The autoenrollment settings are applied the next time that the GPO is applied to the user. User autoenrollment is triggered when the user performs an interactive log on and at Group Policy refresh intervals.

You can manually refresh the GPO settings at a client running Windows XP or Windows Server 2003 by forcing Group Policy update. You can refresh the GPO settings by running GPUpdate /force at a command prompt on the target workstation.

How to Configure Outlook 2003 to Help Provide E-Mail Confidentiality

To successfully send an encrypted e-mail message, the recipient must already have a digital certificate. If you attempt to send an encrypted e-mail message to a user who does not have a digital certificate, you will receive an error. Make sure that you have followed the instructions in the "How to Deploy Digital Certificates for S/MIME Using Autoenrollment" topic earlier in this paper for all your test users before sending e-mail messages to them.

To configure Outlook for e-mail confidentiality

  1. Log on to your domain as a member of the Domain Users group.

  2. Click Start, point to All Programs, point to Microsoft Office, and then click Microsoft Office Outlook 2003.

  3. Click Tools, and then click Options. The following dialog box will display.

    How to Configure Outlook 2003 to Help Provide E-Mail Confidentiality

  4. Click the Security tab, and then click Settings.

  5. Outlook populates the Change Security Settings dialog box with default information. Click OK to accept the default values as shown in the following screen shot.

    Change Security Settings

  6. Click OK to close the Options dialog box.

At this point, you have configured Outlook for e-mail confidentiality.

To send a digitally signed message using Outlook

  1. Log on to your domain as a member of the Domain Users group.

  2. Click Start, point to All Programs, point to Microsoft Office, and then click Microsoft Office Outlook 2003.

  3. To compose a new message, click New.

  4. Add a recipient for the test message and fill out the message fields.

  5. Ensure that the Add digital signature to this message button is selected. Because you want to test only digital signing, ensure that that the Encrypt message contents and attachments button is not selected.

    Add digital signature

  6. Click Send.

At this point, your digitally signed message has been sent to the recipient, who can then verify the digital signature.

To send an encrypted message using Outlook

  1. Log on to your domain as a member of the Domain Users group.

  2. Click Start, point to All Programs, point to Microsoft Office, and then click Microsoft Office Outlook 2003.

  3. To compose a new message, click New.

  4. Add a recipient for the test message and fill out the message fields.

  5. On the toolbar, ensure that the Encrypt message contents and attachments button is selected. Because you want to test only encryption, ensure that the Add digital signature to this message button is not selected.

    Encrypt message contents and attachments

At this point, your encrypted message has been sent to the recipient, who can open and read it.

How to Configure Outlook Express to Help Provide E-Mail Confidentiality

To successfully send an encrypted e-mail message, the recipient must already have a digital certificate. If you attempt to send an encrypted e-mail message to a user who does not have a digital certificate, you will receive an error. Make sure that you have followed the instructions in the "How to Deploy Digital Certificates for S/MIME Using Autoenrollment" topic earlier in this paper for all your test users before sending e-mail messages to them.

To send a digitally signed message using Outlook Express

  1. Log on to your domain as a member of the Domain Users group.

  2. Click Start, point to All Programs, and then click Outlook Express.

  3. If prompted, type the user's password.

  4. To compose a new message, click Create Mail.

  5. To add a recipient from Active Directory, click To.

  6. Under Type name or select from list, click Find. The following dialog box will display.

    Add a recipient from Active Directory

  7. In the Look in list, click Active Directory, in the Name box, type the name of the recipient, and then click Find Now.

  8. Select the name, and then click To.

  9. Click OK to close the Select Recipients box.

  10. On the toolbar, there are two new icons: one to encrypt messages, and one to sign messages. Ensure that the Sign button is selected as shown in the following screen shot. Because you want to test only digital signing, ensure that the Encrypt button is not selected.

    Select Recipients

  11. Click Send.

At this point, your digitally signed message has been sent to the recipient, who can verify the digital signature.

To send an encrypted message using Outlook Express

  1. Log on to your domain as a member of the Domain Users group.

  2. Click Start, point to All Programs, and then click Outlook Express.

  3. If prompted, type the user's password.

  4. To compose a new message, click Create Mail.

  5. To add a recipient from Active Directory, click To.

  6. Under Type name or select from list, click Find.

  7. In the Look in list, click Active Directory, type the name of the recipient in Name, and then click Find Now.

  8. Select the name, and then click To.

  9. Click OK to close the Select Recipients box.

  10. On the toolbar, ensure that the Encrypt button is selected as shown in the following screen shot. Because you want to test only encryption, ensure that the Sign button is not selected.

    Encrypt

  11. Click Send.

At this point, your encrypted message has been sent to the recipient, who can open it and read it.

How to Verify That a User Has a Digital Certificate for S/MIME in Active Directory

You can use Active Directory Users and Computers to verify that an Active Directory user account has a digital certificate for S/MIME.

To verify that the certificate has been added to a user's Active Directory account

  1. Log on to your domain as a member of the Certification Authority Administrators group.

  2. Click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

  3. Click View, and then click Advanced Features as shown in the following screen shot.

    Active Directory Users and Computers

  4. In the left pane, click the Users folder.

  5. In the right pane, double-click one of the test users.

  6. Click the Published Certificates tab.

  7. In the List of X509 certificates published for the user account list (shown in the following screen shot), you will see the user's digital certificate from the Windows CA along with any other digital certificates stored for this user in Active Directory.

    Published Certificates

At this point, you have verified that the certificate has been added to the Active Directory user account.

How to Verify That Exchange Server Is Configured to Help Provide E-Mail Confidentiality

You can use Exchange Server System Manager to verify that your Exchange Server has been configured to support clients that use S/MIME.

  1. Log on using an account that is a member of both of the following:

    • The Administrators group on the local computer.

    • A group to which at least the Exchange View Only Administrators role has been applied at the Administrative Group level.

  2. Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.

  3. Click Servers, click <servername> , click Storage Group, right-click either the Mailbox Store or the Public Folder Store, and then click Properties.

  4. On the Properties page, verify that the Clients support S/MIME signatures check box on the General tab is selected as shown in the following screen shot.

    Properties

At this point, you have verified that Exchange Server is configured to support e-mail confidentiality.

How to Verify That Outlook 2003 Can Receive E-Mail Configured to Help Provide Confidentiality

You can use Outlook 2003 to verify that you can receive e-mail messages configured for digital signatures and encryption.

To view a digitally signed message using Outlook

  1. Log on to your domain as a member of the Domain Users group.

  2. Click Start, point to All Programs, point to Microsoft Office, and then click Microsoft Office Outlook 2003.

  3. In the Inbox, locate the digitally signed test message, and then double-click it.

  4. When the message opens, click the Verify signature button (shown in the following screen shot) to verify the signature.

    Verify signature

    After you click the Verify signature button, the Digital Signature dialog box displays (shown in the following screen shot), indicating that the digital signature is valid.

    Digital Signature

At this point, you have verified the digital signature of the message.

To view an encrypted message using Outlook

  1. Log on to your domain as a member of the Domain Users group.

  2. Click Start, point to All Programs, point to Microsoft Office, and then click Microsoft Office Outlook 2003.

  3. In the Inbox, locate the encrypted test message, and double-click it.

  4. When the message opens, click the Verify encryption button (shown in the following screen shot) to verify the encryption.

    Verify encryption

  5. After you click the Verify encryption button, the following Message Security Properties dialog box displays, indicating that the encrypted message is valid.

    Message Security Properties

At this point, you have verified the encryption of the message.

After you complete these steps, you will have tested all elements of using S/MIME in Outlook 2003. This information lets you see how an S/MIME system that uses Outlook will function for your users.

How to Verify That Outlook Express Can Receive E-Mail Configured to Help Provide Confidentiality

You can use Outlook Express to verify that you can receive e-mail configured for digital signatures and encryption.

To view a digitally signed message using Outlook Express

  1. Log on to your domain as a member of the Domain Users group.

  2. Click Start, point to All Programs, and then click Outlook Express.

  3. If prompted, enter the user's password.

  4. In the Inbox, locate the digitally signed test message and double-click it.

  5. When the message opens, Outlook Express displays the following message explaining digital signatures. Select the Don't show me this Help screen again check box, and then click Continue.

    Help

  6. To verify the signature, click the Verify signature button.

    After you click the Verify signature button, the following Testing Digital Signature dialog box displays, indicating that the digital signature is valid.

    Testing Digital Signature

At this point, you have verified the digital signature of the message.

To view an encrypted message using Outlook Express

  1. Log on to your domain as a member of the Domain Users group.

  2. Click Start, point to All Programs, and then click Outlook Express.

  3. When prompted, type the user's password.

  4. In the Inbox, locate the encrypted test message and double-click it.

  5. When the message opens, Outlook Express displays the following message explaining encryption. Select the Don't show me this Help screen again check box, and then click Continue.

    Help

  6. To verify the signature, click Verify encryption.

    After you click the Verify encryption button, the following Testing Encryption dialog box displays, indicating that the encrypted message is valid.

    Testing Encryption

At this point, you have verified the encryption of the message.

After you complete these steps, you will have tested all elements of using S/MIME in Outlook Express. This information lets you see how an S/MIME system that uses Outlook Express will function for your users.

How to Troubleshoot E-Mail to Help Provide Confidentiality

This section discusses a number of common issues that occur in an Exchange Server 2003–based S/MIME system. Although this list is not exhaustive, it does provide information about issues that might occur in your deployment, as well as recommendations about how to address those issues.

Problem: Cannot Verify a Sender's Digital Signature

This issue can occur when the sender's root CA digital certificate or intermediate CA digital certificate is not present in the Local Computer certificate store of the recipient's Exchange Server.

Resolution

To resolve this issue, import the digital certificate for the sender's root CA or the sender’s intermediate CA into the Trusted Root Certification Authorities folder in the Local Computer certificate store of the recipient's Exchange Server. Importing the digital certificate for a root CA inherently grants trust to every digital certificate issued by the hierarchy of the root CAs. Those organizations for whom this granting of trust is prohibited by their security policy will want to explore cross-certification strategies as an alternative. For information about how to implement cross-certification when using Windows Server 2003 CA, see Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003 at https://go.microsoft.com/fwlink/?LinkId=17806.

To import the digital certificate for the sender's root CA into the Trusted Root Certification Authorities

  1. Log on to the recipient's Exchange Server by using an account that is a member of the local Administrators group.

  2. Click Start, click Run, type mmc and then click OK.

  3. Click File, and then click Add/Remove Snap-in.

  4. On the Standalone tab, click Add.

  5. Select Certificates, and then click Add. When prompted, select Computer account, and then click Next.

  6. On the Select Computer page, select Local computer (the computer this console is running on), and then click Finish.

  7. In MMC, expand Certificates – Local Computer, and then expand Trusted Root Certification Authorities.

  8. In the details pane, right-click and point to All tasks, and then click Import.

  9. On the first page of the Certificate Import Wizard, click Next.

  10. In the File name dialog box, type the name and location of the file containing the root CA's digital certificate, and then click Next.

  11. On the Certificate Store page, click Place all certificates in the following store, ensure that the Certificate store dialog box shows Trusted Root Certification Authorities, and then click Next.

  12. On the final page of the wizard, click Finish.

After importing the digital certificate for the sender's root CA, Exchange Server will be able to validate the sender's digital certificate on behalf of the recipient.

To import the digital certificate for the sender's intermediate CAs into the Intermediate Certification Authorities

  1. Log on to the recipient's Exchange Server by using an account that is a member of the local Administrators group.

  2. Click Start, click Run, type mmc and then click OK.

  3. Click File, and then click Add/Remove Snap-in.

  4. On the Standalone tab, click Add.

  5. Select Certificates, and then click Add. When prompted, select Computer account, and then click Next.

  6. On the Select Computer page, select Local computer (the computer this console is running on), and then click Finish.

  7. In MMC, expand Certificates – Local Computer, and then expand Intermediate Certification Authorities.

  8. In the details pane, right-click and point to All tasks, and then click Import.

  9. On the first page of the Certificate Import Wizard, click Next.

  10. In the File name dialog box, type the name and location of the file containing the root CA's digital certificate, and then click Next.

  11. On the Certificate Store page, click Place all certificates in the following store, ensure that the Certificate store dialog box shows Intermediate Authorities, and then click Next.

  12. On the final page of the wizard, click Finish.

After importing the digital certificate for the sender's intermediate CAs, Exchange Server will be able to successfully validate the sender's digital certificate on behalf of the recipient.

Problem: Cannot Access the CRL

This issue can occur when the certificate revocation list (CRL) distribution point specified in the digital certificates is accessible only through a firewall, or when the user's Exchange Server lacks rights to access the CRL distribution point.

Resolution

To resolve this issue, do one of the following:

  • Download the CRL from the CRL distribution point manually, and import it into the Local Computer certificate store of the user's Exchange Server.

  • Install and configure a firewall client for the appropriate protocols on the recipient's Exchange Server.

  • Explicitly grant permission for the LocalSystem account of the user's Exchange Server to access the CRL distribution point, or reconfigure the CRL distribution point so that it does not require authentication.

To manually import a CRL

  1. Log on to the recipient's Exchange Server by using an account that is a member of the local Administrators group.

  2. Download the CRL from the CRL distribution point specified in the digital certificate.

  3. Right-click the .cer or .crl file, click Install Certificate or Install CRL, and then click Next.

  4. When the Certificate Import Wizard opens, click Automatically select the certificate store based on the type of certificate.

Problem: Different Certificates Used When Using Different E-Mail Clients

This issue can occur because there are two attributes in Active Directory where the S/MIME digital certificates can be stored: the userCertificate attribute and the userSMIMECertificate attribute. By default, Outlook looks first to the userSMIMECertificate attribute and uses any viable S/MIME certificate found in that attribute. Other e-mail clients, including OWA, may look first to the userCertificate attribute, and use any viable S/MIME certificate found in that attribute.

If different digital certificates are stored in the userCertificate and userSMIMECertificate attributes, it is possible for Outlook and OWA to use different digital certificates, because they each refer to different Active Directory attributes.

Resolution

To resolve this issue, ensure that the same certificates are stored in both the userCertificate and userSMIMECertificate attributes. For more information, see the "Outlook 2003 Continues to Use Old Certificates After You Migrate from Key Management Server to Public Key Infrastructure" article at https://go.microsoft.com/fwlink/?linkid=3052\&kbid=822504.

Problem: Outlook Express Automatically Attempts to Sign E-Mail Messages

By default, when a user replies to or forwards a signed message when using Outlook Express, Outlook Express enables digital signing for that message. If the user then attempts to send the message and does not have a valid signing certificate, Outlook Express displays a "You do not have a digital ID." error message and does not send the message.

Resolution

To resolve this issue, disable digital signing for that message. For more information, see the "You Receive an Error Message When You Try to Forward or to Reply to a Digitally Signed E-Mail Message" article at https://go.microsoft.com/fwlink/?linkid=3052\&kbid=816830.

Summary

With the growth of the Internet in recent years, e-mail has fundamentally changed. It is no longer only an internal organizational tool. Instead, it now unites people across companies and countries/regions and has even enabled people on earth to share information with people in space, as if they were in the same building. E-mail has arguably become the single most important benefit of the Internet to date. As people and companies increasingly integrate e-mail into their lives, its importance increases daily.

The unprecedented growth of e-mail has been enabled by the worldwide adoption of the underlying protocol or language of Internet e-mail: SMTP. The SMTP standard makes it possible for different e-mail systems connected to the Internet to exchange information with one another.

However, despite all of the benefits that SMTP has brought to the Internet, it has an inherent problem. The SMTP standard was originally developed to carry brief, relatively unimportant messages on a closed network, not to carry critical and sensitive information in an interconnected world. No one who developed SMTP imagined that it would play the role it plays today. Because of that, SMTP was not designed to protect the type of information that it carries across the networks that it crosses today. It was designed to carry simpler information across simpler networks, hence the name Simple Mail Transfer Protocol. For example, SMTP sends information across the Internet in a way that allows anyone to read the message.

Fortunately, S/MIME has emerged as a standard to help enhance SMTP e-mail messages with security capabilities. Using S/MIME, encryption helps protect the contents of e-mail messages, and digital signatures help verify the identity of a purported sender of an e-mail message.

Implementing S/MIME for e-mail requires a solution that spans multiple products and technologies.

Download

Get the How to Protect E-Mail Confidentiality in Regulated Industries paper