We recently encountered a strange issue with a customer running Outlook 2010 in an Exchange 2007 environment. Some users (not all) would randomly get certificate warning pop-ups in Outlook. The certificate warnings indicated the Fully Qualified Domain Name (FQDN) "autodiscover.customerdomain.com" wasn’t on the certificate. The certificate warning was legitimate; that FQDN was not on the certificate because this customer didn't have a UCC certificate.
However, all the autodiscover SCP records had been changed via Powershell to point the autodiscover URL to "webmail.customerdomain.com" which WAS on the certificate. All the PCs were joined to the Active Directory domain so the SCP lookup should have had precedence over any other autodiscover method. Doing an autodiscover check via the Outlook system tray icon indicated the certificate warning pop-up and all the values returned by the test were all correct.
The question was why were these PC's even contacting "autodiscover.customerdomain.com"? After much troubleshooting, we found that even though the domain SCP records were correct, some Outlook clients were also doing DNS lookups for "autodiscover.customerdomain.com" in parallel with the SCP lookup. Checking DNS there was an "autodiscover.customerdomain.com" A record and pointed to the IP address of the Exchange server; however, since that FQDN wasn’t a subject alternate name on the certificate, it would have legitimately generated the certificate warning.
The resolution was to simply remove the "autodiscover.customerdomain.com" A record from DNS and we added SRV records for good measure. It doesn’t seem like having that A record in DNS would have mattered since the autodiscover priority shouldn’t have ever used it, but from now on we will use DNS SRV records and SCP exclusively for Exchange autodiscover.