Certificate Principal Mismatch

[This topic is intended to address a specific issue called out by the Exchange Server Analyzer Tool. You should apply it only to systems that have had the Exchange Server Analyzer Tool run against them and are experiencing that specific issue. The Exchange Server Analyzer Tool, available as a free download, remotely collects configuration data from each server in the topology and automatically analyzes the data. The resulting report details important configuration issues, potential problems, and nondefault product settings. By following these recommendations, you can achieve better performance, scalability, reliability, and uptime. For more information about the tool or to download the latest versions, see "Microsoft Exchange Analyzers" at https://go.microsoft.com/fwlink/?linkid=34707.]  

Topic Last Modified: 2011-01-26

The Microsoft Exchange Best Practices Analyzer Tool parses the Accepted Domains list in Microsoft Exchange Server 2007 to retrieve the URLs for the accepted SMTP domains. From each accepted SMTP domain, Analyzer tries to collect the SSL certificate that is associated with the particular domain. The tool examines each collected certificate to determine the value of the Principal attribute on the particular certificate. The value of the Principal attribute represents the common name (CN) of the certificate, and it appears next to Issued to on the certificate object.

If the common name of the certificate does not match the URL that Analyzer used to access the resource, the tool issues a Certificate Principal Mismatch warning message. This means that users may not be able to connect to their mailboxes by using Microsoft Office Outlook® Web Access for Microsoft Exchange Server 2003, for Outlook Anywhere for Exchange Server 2007, for Exchange Server ActiveSync, or for RPC over HTTP.

In this scenario, user may repeatedly be prompted for credentials when they try to connect to Exchange, or users may receive the following error message when they try to connect to the Exchange resource:

A Certificate Principal Mismatch error may occur if one of the following conditions is true:

• The certificate has an incorrect common name.

• The client accesses data on a server by using an incorrect URL if the server has more than one DNS name.

• Obsolete or incorrect Accepted Domain entries exist on the Exchange Transport server.

Exchange requires a certificate to run an SSL protocol such as HTTPS. You can use a certificate that supports subject alternate names (SAN) in Exchange 2007. This is to allow the certificate to support resources that have different names, such as Outlook Anywhere and the Autodiscover Web application.

However, when you use a SAN certificate, you receive the Certificate Principal Mismatch error if a mismatch occurs between the Principal ("Issued to") name and the FQDN that clients use to access the resource.

To resolve the certificate name mismatch

1. Determine the FQDN that the client uses to access the resource. For example, to verify the FQDN that is used by Outlook, follow these steps:

   1. Start Microsoft Outlook.

   2. On the Tools menu, click Account Settings.

   3. Click the E-mail tab, click the Exchange account, and then click Change.

   4. Click More Settings, and then click the Connection tab.

   5. Click Exchange Proxy Settings.

   6. Note the FQDN that is listed in the Only connect to proxy servers that have this principal name in their certificate box. For example, mail.contoso.com.

2. Use the Exchange Management Shell to determine the value for the CertPrincipalName attribute as follows:

3. Get-OutlookProvider

4. This command returns the results for the EXPR name. For example, the command returns the following:
   msstd:server1.contoso.com

5. Use the Exchange Management Shell to modify the CertPrincipalName attribute to match the FQDN that Outlook uses to access the resource. To do this, use the following command:

   Set-OutlookProvider EXPR -CertPrincipalName:"msstd:<FQDN the certificate is issued to>"
   

This error can also occur if the Analyzer tool detects Accepted Domain entries that apply to internal SMTP domains that no longer exist in Exchange.

To resolve this issue, you must delete the recipient polices that apply to SMTP domains that no longer exist or that are no longer used.

To view the accepted domains in Exchange

1. Start the Exchange Management Console.

2. Expand Organization Configuration, and then click the Transport server. For example, Hub Transport. For an Edge Transport server, click Edge Transport.

3. In the details pane, click the Accepted Domains tab. Examine the entries that appear in the Accepted Domain list to determine whether any of them should be removed.