Troubleshooting Certificate Mismatch Warnings in Outlook 2007 Clients on Small Business Server 2008
[Today’s post comes to us courtesy of Shawn Sullivan]
An issue experienced by our customers from time to time is when Outlook 2007 generates a certificate name mismatch error while trying to connect to SBS 2008. This is almost always caused by a configuration error in either public or private DNS where the wrong records are present for the type of certificate you have, or the records point to some other destination IP. The purpose of this post is to provide a few steps to help you resolve the issue.
A couple rules to follow when configuring DNS when it comes to Autodiscover and SBS:
If you plan on using the SBS certificate generated by the Internet Management Address Wizard (IAMW), do not register an Autodiscover A record in either DNS on the SBS server or DNS at your internet registrar.
Important: Some DNS registrars will create a wildcard or “catch-all” record for your public zone that will resolve any prefix, including Autodiscover, to an IP address in the registrar’s public range. You may or may not receive a certificate warning from Outlook; however the connection will still fail. If this applies to you, contact your DNS registrar to have this changed.
An SRV record should be used with the certificate generated by the IAMW. It will allow Outlook 2007 SP1 and later clients to contact your SBS server using the proper host name that will match the subject name on the certificate.
You can register an Autodiscover A record only if you have purchased a wildcard or Unified Communications certificate or if you chose “autodiscover” as your domain prefix during the IAMW.
Note: In SBS 2008, the IAMW creates a zone for the public name of your domain in internal DNS along with a Host A record that points to the server’s internal IP. Unless you are hosting your own public DNS records, there should be no other public name records on the server itself.
Note: If you choose to allow a partner registrar to manage your domain for you during the IAMW, then the necessary DNS records, including the SRV record, will be created and updated for you automatically. More information on this process can be found in part 2 and 3 of our IAMW blog post.
Straying from these rules can cause the following scenarios to occur.
SCENARIO 1: You incorrectly have an Autodiscover Host A record registered and you are using the SBS certificate generated by the Internet Management Address Wizard (IAMW) when configuring your domain manually. This certificate does not support the use of an Autodiscover Host A record since does not register Autodiscover as a Subject Alternative Name. If the A record points to the public IP address of the SBS server, the domain name and suffix will match while the prefix will not match.
To resolve this, register a public SRV record that points the Autodiscover service to the public fully qualified domain name that you chose for your server during the IAMW. You can use KB 940881 as a guide to creating this record. Remove any Autodiscover Host A record that you have configured in either private or public DNS and/or verify that a wildcard record is not registered for your domain.
You can use nslookup to verify the SRV record for your domain:
C:\Users\admin>nslookup
> set type=srv
> _autodiscover._tcp.contoso.com
_autodiscover._tcp.contoso.com SRV service location:
priority = 1
weight = 10
port = 443
svr hostname = remote.contoso.com
remote.contoso.com internet address =x.x.x.x
SCENARIO 2: You have installed a trusted certificate on the SBS server that supports the use of an Autodiscover A record, such as a Unified Communications or wildcard certificate. You have an Autodiscover A record registered for the domain, but it points to the wrong public IP. If the server at that IP is publishing an SSL site, you will receive a certificate warning:
Clicking “View Certificate” reveals that this is a completely different certificate than what is installed on the SBS server.
To resolve this, you need to update the host A record to point to the correct IP. You can launch nslookup from any machine that can query both external and internal DNS to check the IP address that the autodiscover record points to:
C:\Users\admin>nslookup
> autodiscover.contoso.com
Name: autodiscover.contoso.com
Address: x.x.x.x
You should query both the SBS server and an external forwarder to and compare the results; it is possible that the public zone is registered in both places. Also make sure there is no conflicting wildcard record registered for you domain.
SCENARIO 3: This scenario can occur internally with domain joined clients. A problem communicating with the Autodiscover virtual directory on the SBS 2008 server causes the client to seek the service elsewhere using DNS, where the above two scenarios can then occur.
The client initially queries Active Directory and retrieves the proper URL, but there is a communication problem with the directory itself. A recent example experienced by a customer occurred when the Autodiscover virtual directory was incorrectly configured to require client certificates during authentication, triggering the failure. The client then resolved an Autodiscover record on the internet that should not have been registered, and they received the mismatch error.
Resolving the DNS configuration in this scenario is the same as in the above scenarios. Fixing the communication problem with the virtual directory will involve troubleshooting both IIS and Exchange to varying degrees of depth and may require the help of Microsoft Product Support Services.
One tool that you can use is the “Test E-mail AutoConfiguration” feature that is built into Outlook 2007. It will generate a debug log of each connection attempt and the result. To access it, right-click the Outlook icon in your notification area (it will only launch if you have an Outlook profile configured already).
Using this log, we can see exactly how Outlook attempts to locate and connect to the Autodiscover URL. In the example specified above, the correct URL that Outlook found in Active Directory returned 0x80072F0C (ERROR_INTERNET_CLIENT_AUTH_CERT_NEEDED). Then it failed back to check domain.com and autodiscover.domain.com for the service using SSL, which is where the certificate warning was received because an Autodiscover Host A record was registered publicly:
Comments
Anonymous
January 08, 2010
The comment has been removedAnonymous
January 15, 2010
I'm wondering if my issue below is related to your article above? I had Small Business Server 2008 setup with a self signed cert. Everything was working, 3 Blackberry Internet Service (BIS) users connecting and working fine. The client wanted a public cert so we bought the cert and replaced the self signed cert with the public cert. Now none of the BIS users can connect. The 2 ActiveSync users are not having any issues before or after. The URL is https://remote.domain.com/owa but when put in IE the browser changes it to https://remote.domain.com/owa/auth/logon.aspx?replaceCurrent=1&url=https%3a%2f%2fremo te.domain.com%2fowa. I put the connection info for each user into BIS manually but it says it cannot connect. Perhaps the BIS interface is having an issue with the URL above? Nothing in this document helps either: http://www.blackberry.com/btsc/viewContent.do?externalId=KB02858&sliceId=1#12 As a last resort are there instructions for going back to a self signed cert? HELP!Anonymous
March 26, 2014
Here are the top Microsoft Support solutions for the most common issues experienced when using MicrosoftAnonymous
July 21, 2014
Here are the top Microsoft Support solutions for the most common issues experienced when using Windows