Ran into an issue where this Outlook 2010 SP2 client, build 14.0.7113.5000, was throwing up unexpected certificate errors for the domain. This is the Tailspintoys.ca domain.
User-1@tailspintoys.ca was complaining about the below certificate error:
Looking at the error message, the fact that it is the domain (tailspintoys.ca), and not a FQDN is a hint. More on that later…
All of the Exchange URLs are correctly configured. All of the certificates on Exchange match the configured URLs. Autodiscover is set correctly. Since this is a domain joined machine, the user is located in the same domain, and the machine is on the corporate network why was it looking at the root domain?
Where is this coming from?
Outlook 2010 Diagnostic Logging
After enabling Outlook Diagnostic logging and restarting Outlook 2010, the %TEMP%OLDISC.log showed the following entry for the client trying to get to the domain root:
7692 0x886F6FC4 02/09/15 14:56:28 Autodiscover to https://tailspintoys.ca/autodiscover/autodiscover.xml starting
7692 0x886F6FC4 02/09/15 14:56:28 AutoDiscover doing Pre-Auth with saved data.
7692 0x886F6FC4 02/09/15 14:56:28 AutoDiscover PRE-AUTH pcreds->dwAuthScheme:
7692 0x886F6FC4 02/09/15 14:56:28 <NONE>
7692 0x886F6FF3 02/09/15 14:56:28 GetLastError=12175; httpStatus=0.
Autodiscover is clearly trying to hit the root of the domain to get Autodiscover information, but why?
Location, Location, Location
This mailbox had been moved to Office 365. As part of the MRS migration process. the TargetAddress has been set on the user object, and it is this which keys Exchange on-premises to redirect the Outlook client to Office 365. Whilst the Outlook client will initially do the SCP lookup, on-premises Exchange cannot answer for Office 365 mailboxes. Outlook then goes off and does the DNS chase down to find the Office 365 Autodiscover URL.
Part of this is the lookup to domain root, in this case Tailspintoys.ca. For a full example of the Office 365 Autodiscover process see this article.
Why does this cause the above error?
DCs & IIS Bindings
Tailspintoys.ca resolves internally to the DCs IP. No surprise there. Normally there are no SSL listeners/bindings on DCs. However in this case, there just so happened to be a SSL binding on that server with an expired certificate.
The binding was then updated to remote the TCP 443 listener on the DC as in this case it was no longer required.
In production, DCs really should not have additional components installed. In addition the Outlook Autodiscover process can be tuned, to remove the root domain lookup.
Outlook 2013 initially had an issue with this scenario for on-premises mailboxes which was corrected in one the first Outlook 2013 updates. As mentioned before, don’t overlook Outlook when it comes to patching!
Cheers,
Rhoderick
