Troubleshooting an Autodiscover Certificate Error

One of the best things about being a Microsoft MVP is being part of the MVP community. Many extremely smart, opinionated, and experienced people belong to that community, and they present each other with a lot of great opportunities to learn things. Recently I learned a good bit about Microsoft Office Outlook 2007 and Exchange Server 2007's Autodiscover service from following a conversation on an MVP mailing list that the Exchange Server product group maintains.

The original problem, posed by Michael B. Smith, was a simple one: A test environment that worked fine with Outlook produced errors when tested with the Exchange Remote Connectivity Analyzer (ExRCA; I wrote about this tool back in January 2009). The error seemed straightforward on its face: ExRCA reported that the common name of the SSL certificate used for the connection didn't match the server name provided for mutual server authentication. Given how difficult it is to get Exchange certificates properly issued and installed, this error isn't uncommon, and most of the time Outlook 2007 is finicky about these kinds of name mismatches.

The reason for this problem turns out to be both interesting and subtle. A quick review of certificate lingo is in order first. An X.509 certificate can have only one common name, or CN, attribute. The CN is almost always the public Fully Qualified Domain Name (FQDN) of the computer to which the certificate was issued. A single certificate can have zero or more subject alternative names, or SANs. For example, a certificate whose CN is mail.contoso.com might have SANs of public-cas, public-cas.contoso.com, and slc-cas01.northamerica.contoso.com.

The situation that led to ExRCA producing errors arises because of the interaction between Outlook, Windows, and Exchange. Outlook 2007 profiles have a check box that lets you restrict connections to hosts that present a specific name in their certificate. Exchange sends configuration information in Autodiscover responses that Outlook uses to decide which server it should attempt to connect to; that information is manually specified by the administrator as part of the Outlook Anywhere configuration in Exchange.

In this case, the Outlook profile was set to connect to the remote procedure call (RPC) proxy server named oa.somecompany.com and to accept only the certificate name oa.somecompany.com. One of the SANs in the certificate was oa.somecompany.com, but the CN on the certificate was webmail.somecompany.com. Windows versions prior to Vista SP1 don't check the mutual authentication string against SANs in the presented certificate. (I was unable to verify if this is the case with Windows Server 2008.) If the mutual authentication string specified doesn't match the certificate CN, the check fails. Notice that the name of the RPC proxy server isn't important in this case; what matters is the correspondence between the "only connect to" string and the CN of the certificate.

So, which result was right: Outlook or ExRCA? One of the authors of the ExRCA tool, Brad Hughes, said that ExRCA is right—and I tend to believe him. In this case, the Exchange Autodiscover service is sending the value specified on the ExternalHostName attribute on the OutlookAnywhere object. The suggested fix is to either set the CertPrincipalName attribute on the Outlook provider so that it matches the CN of the certificate, or to get a new certificate with a different CN.

Related Reading: