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.

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.

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.

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.