- Home
- Exchange
- Exchange Team Blog
- Common Trust, Encryption and Digital ID Troubleshooting – for Microsoft Outlook and Microsoft Exchange users
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Some of the most common issues the Exchange Client-Server Integration team sees regarding S/MIME issues with Outlook and Exchange are:
- Trust Failures - the Trusted Root Certification Authority certificate is not installed on the client or server.
- Encryption Issues – not sent with intended cipher strength.
- Errors - “Your digital ID name could not be found by the underlying security system.” and “Microsoft Outlook had problems encrypting this message because the following recipients had missing or invalid certificates or conflicting or unsupported encryption capabilities”
- The Publish to GAL feature in Outlook – usage and issues related to it.
Trust Failures
Trust and encryption issues can impact users using OWA, Outlook (including RPC over HTTP), Exchange ActiveSync and OMA in a number of scenarios.
Secure Mime (S/Mime) is generally used to ensure the sender of a message can be Trusted, i.e., the sender is who they say they are. Microsoft Internet Explorer contains a pre-configured list of Trusted Root Certification Authorities. To view this list, open Internet Explorer, click Tools, click Internet Options, click Content, click Certificates and click the Trusted Root Certification Authorities tab.
If you install a Certificate Authority in your network – either the Microsoft Windows Certificate Server or a third-party server – or obtain a client or web server certificate from an authority on the web, you should verify that the Root Certificate is listed here. If it is not, the certificate for your Certificate Authority must be provided to clients or placed in a location where the certificate it can be retrieved by users. If you are working with your own Certificate Server, an Extension within issued certificates for the Certificate Authority, called the Authority Information Access (AIA) can be configured.
In Outlook 2003, when you receive a digitally signed message from someone who’s Certificate Authority you do not trust, you are prompted with the following:
Certificate Authority Information
Your message was digitally signed with a certificate issued by a Certificate Authority.
The signature is invalid because you have either distrusted or not yet chosen to trust the following Certificate Authority.
Issued by: <authority>
Valid From: <validity period>
For more information about the Certificate used to digitally sign the message, click Details.
This is followed by a View Message button and a Details button. Below these buttons, you see more text:
Trusting the Certificate Authority
Trusting a Certificate Authority means that you trust mail that is digitally signed by certificates issued from that Certificate Authority.
Do you want to trust this Certificate Authority?
If you choose Trust, you must also click Yes on the Root Certificate Store dialog that follows to add the certificate to your system.
Warn me about errors in digitally signed e-mail before the message opens.
If this box is unchecked you will not be warned about errors in the future (not desirable). If you click Trust, and click Yes for the Root Certificate Store dialog, the authority will be trusted on your system.
With older versions of Outlook, you received a warning, but were not presented with a Trust dialog. You could navigate to and install the Certificate Authority or trust each individual certificate.
With web servers, if you receive a message stating “This certificate was issued by a company that you have not chosen to trust”, your computer is not configured to trust the root certification authority that issued the certificate. See the following article from the Microsoft Knowledge Base:
297681 Error message: This security certificate was issued by a company that you have not chosen to trust
For additional information, visit the following Microsoft web site:
Particularly with RPC over HTTP or when using the Outlook Web Access (OWA) S/MIME control on a client, the root certificate must be installed on the web server as well as the client. Not installing the certificate on the web server leads to different behaviors between OWA and RPC over HTTP. When using OWA to create SSL connections to a web site, you constantly encounter trust warnings when connecting and are prompted on whether to continue or cancel the connection. In RPC over HTTP configurations, proper installation of the web server and root certification authority certificates are required for correct functionality. RPC over HTTP does not return certificate-related errors on the client side, but simply fails to connect. In RPC over HTTP configurations, proper installation of the web server and root certification authority certificates are required for correct functionality.
Some good references from the Knowledge Base are:
319574 HOW TO: Use Certificates with Virtual Servers in Exchange 2000 Server
823024 How to Use Certificates with Virtual Servers in Exchange Server 2003
Encryption Issues
Encryption strength issues can be due to the method Outlook uses to determine a recipient’s capability to decrypt a message.
For example, the sender wants to send using 3DES (168-bit), but sends a 40-bit encrypted item, and doesn’t understand what happened. In a directory, two attributes of a user object, UserCertificate and UserSMIMECertificate, determine cipher strength. In many environments, UserCertificate has no user-specific attributes, meaning it cannot be configured. Thus, the cipher strength returns to a default – 40-bit encryption.
There is a certificate extension which can contain a SMIME Capabilities listing the encryption algorithms. Outlook will look at that as a last resort before falling back to 40-bit encryption.
UserSMIMECertificate, on the other hand, is a user-published value defining the user’s capabilities. In an Exchange Server 5.5 or Active Directory environment, you can use the “Publish to GAL” feature in Outlook to publish to UserSMIMECertificate. This ensures that people looking up your GAL entry will know your capabilities and can send using 3DES if they wish.
NOTE: With Outlook 2003 the new default is 3DES, so Outlook will fall back to 3DES and not 40-bit.
With LDAP directories, where UserSMIMECertificate is not present, or the SMIME Capabilities extension is not included certificate in the UserCertificate attribute, the 40-bit encryption issue can be an issue. Outlook cannot publish to UserSMIMECertificate on LDAP servers.
In environments with LDAP servers or where users do not use the “Publish to GAL” feature in Outlook to publish their digital ID, the default 40-bit behavior can be overridden by a registry value and is discussed in the following Knowledge Base article:
318589 OL2002: You Cannot Send Encrypted Mail to an LDAP Recipient
It is important to note this registry key can have an unintended consequence. If a user does not have a client configured to support 168-bit encryption, they will be unable to read your e-mail.
Errors
The error “Your digital ID name could not be found by the underlying security system.” is typically caused by one of the following reasons:
- Your digital certificate is damaged or corrupted in Windows. This is rare and has not been successfully reproduced, though the problem has been observed in some deployment scenarios. In reproduction attempts non-imaged systems or systems with a different image version in the same environment had no problems. Reinstallation of the digital ID has resolved the issue
,in most cases.
- The sender of an encrypted message uses a Public Key for the recipient (the person opening the item) that is not installed on the recipient's computer. This could be due to an old or incorrect digital ID is listed in a directory (LDAP, Exchange 5.5 directory or Active Directory) or the sender’s Outlook Contact for that recipient. When the sender addresses the item, resolves against the LDAP server or Contact and encrypts, the recipient can’t open the item. The message is encrypted for a digital ID that the recipient does not have installed.
An example of this issue is where UserA has previously used the “Publish to GAL” feature, but has since received a new Digital ID. That user or someone else working on UserA’s system removed the Private Key for the old (but still valid) digital ID. As the old digital ID’s Public Key is published in UserSMIMECertificate, this is the ID used – UserSMIMECertificate is the preferred value.
When you receive the error “Microsoft Outlook had problems encrypting this message because the following recipients had missing or invalid certificates or conflicting or unsupported encryption capabilities”, the problem is usually that:
· You do not have a copy of the Public Key for the person you are trying to send to – either in a Contact or in an accessible directory (Global Address List or LDAP).
· The recipient has an expired Public Key in the GAL, Contact or LDAP directory.
This is documented in the following Knowledge Base article:
884738 You receive an error message when you try to send an encrypted e-mail message to another user who is in the same Exchange organization in Outlook 2002
Another issue is where a valid certificate is listed in the GAL, Contact or LDAP directory, but it is issued by a Certificate Authority that is not trusted. Thus the cert is considered invalid. Installing the Certificate Authority’s certificate on the client will resolve the issue.
< /o:p>
Publish to GAL
The “Publish to GAL” functionality of Microsoft Outlook (2000 and later) is sometimes the key to many issues regarding the use of secure e-mail. This is, as stated above, the process of placing a user-signed blob in the directory that publishes a user’s Public Key with a full description of capabilities.
It is important to select the correct “Security Settings” when publish to the directory. To establish a Security Profile in Outlook, click Tools, click Options, click Security and note the contents of the Security Settings box. A name will be displayed “Default Security Settings”, or a custom name if you have so chosen. When you click Publish to GAL, this is the digital ID that is pushed to the directory.
If you need to change this (such as if you receive a completely new digital ID), or create a new Security Settings configuration, click the “Security Settings” button, click New and type a name for the setting – “My ID”, etc – then click the Choose button and select the digital ID you wish to use in this configuration.
When you use “Publish to GAL”, it is important to remember that – when your digital ID expires or is renewed – the old digital ID remains in the UserSMIMECertificate value in your user object in the directory until you republish.
The Exchange Server 5.5 or 2000 Key Management Server (KMS) server enrollment process involves a GAL publishing step (which includes UserSMIMECertificate), but there is no “automated” method of using the “Publish to GAL” functionality with a Windows or third-party Certificate Server. See the following documents for more information on resolving problems of this type:
Exchange Server 2003 Message Security Guide, Appendix C: Digital Certificates Cleanup Script
822504 Outlook 2003 continues to use old certificates after you migrate from Key Management Server to Public Key Infrastructure
You can also clean up using the following steps from Outlook:
- Remove all Security Settings via Tools, Options, Security, Settings
- Click Publish to GAL
Outlook will delete all the certificates from the GAL. This should be used with caution.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.