Autodiscover CNAME

Question

Hello,

I want to better understand the autodiscover process when using a CNAME. I have some assumptions, but are they correct?

First scenario:
-autodiscover.mydomain.com is a CNAME and points to autodiscover.subdomain.mydomain.com (reverse proxy with certificate)
-The certificate must have autodisciver.mydomain.com as the subject name, right? Because this is the address which is requested. The autodiscover.subdomain.mydomain.com doesn't have to be included in the certificate?!

So the flow would be: Outlook queries autodiscover.mydomain.com and gets the IP address of autodiscover.subdomain.mydomain.com. Outlook connects to this IP and gets the certificate for autodiscover.mydomain.com and can post the request.

Second scenario:
-autodiscover.mydomain.com is a CNAME and points to autodiscover.outlook.com
-The certificate will not have any of my autodiscover names included.

Here, the process would be: Outlook queries autodiscover.mydomain.com and gets the IP address of autodiscover.outlook.com. Because port 443 is not listening there, outlook checks for redirect options and is redirected to autodiscover-s.outlook.com. Because this is a redirect, the requestet hostname now is autodiscover-s.outlook.com and the certificate name only must match this address.

Answer 1

It should simply resolve in DNS and contact the CNAME that is being pointed to.
In the event it tries to contact the on-prem servers and they are not accessible on 443, it will try each of these URLs listed in the linked doc below:
However, with a CNAME ,it really shouldnt:
There is more info on the CNAME recommendation here:
https://learn.microsoft.com/en-us/Exchange/architecture/client-access/autodiscover?view=exchserver-2019#autodiscover-in-dns

Note:
Outlook 2016 and above will favor connecting to Exchange Online first: (Direct Connect)

You can change that behavior:
ExplicitO365Endpoint

https://learn.microsoft.com/en-us/outlook/troubleshoot/profiles-and-accounts/unexpected-autodiscover-behavior

So by default, the on-prem Autodiscover is not consulted.

Answer 2

I feel as though Renard, Robert's (Renard, Robert) explanation on "Jan 31, 2022, 2:59 PM" is correct. The discussion from that point on starts to get squirrely and stops involving Exchange Online.

I can't seem to @ mention him, so hoping he comes back to clarify if that explanation turned out to be invalid. But considering non-Hybrid customers, the direction when setting up your tenant is to point your Autodiscover CNAME to Autodiscover.outlook.com, you would have to assume that the entire world would be getting certificate errors. Yet they are not. So again, that explanation seems like the correct one, and I don't see anywhere else on the internet, certainly not Microsoft's docs/learn explaining it in that much detail.

Key points:

• CNAME Autodiscover which points to an HTTPS-listening other FQDN, requires the CNAME's own FQDN to be present in the cert. Example Autodiscover.domain1.com has a CNAME with points-to: autodiscover.domain2.com, which listens on HTTPs/443. In this case Autodiscover.domain1.com needs to be in the Subject Alternate Names or Subject of the certificate.
• CNAME pointing to a HTTP-only other FQDN does NOT require the CNAME's own FQDN to be in the certificate. This scenario assumes that the HTTP-only FQDN is doing redirect, and redirecting to an HTTPS-listening other FQDN. In this case, the HTTP-only FQDN needs to be present in the final HTTPS-listening FQDN's cert (Subject Alternative Name or Subject). Finally, in this case, the HTTPS-listening FQDN should be present in the client's registry under HKCU\Software\Microsoft\Office##.#\Outlook\AutoDiscover\RedirectServers to avoid the redirect allow/deny prompt (which is different from the certificate warning).