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

If autodiscover.subdomain.mydomain.com is what the cname is pointing to, then autodiscover.subdomain.mydomain.com has to be subject name ( or a widlcard) on the cert the client connects to that represents that FQDN.

in your second scenario, Microsoft has a cert with that subject name ( or wildcard in this case) set to that endpoint

Answer 2

Okay thanks, I always thought that a CNAME will only tell the client the IP address of the target system by maintaining the original name.

E.g., domain.com CNAME points do domain2.com - client would try to connect to domain.com and gets the IP address of domain2.com and therefore, domain.com must be in the SSL certificate because that's the original name to connect to.

Answer 3

Ok, sorry if I wasnt clear. I was focused on the what the CNAME was pointing to - ensuring that subject name is on the cert. In these scenarios, you def want all the possible name(s) on the cert or use a wildcard including the CNAME and the what the CNAME is pointing to.- if you control it of course. othrwise, if your autodiscover is pointing at Mcirosoft, then all you need is the initial CNAME on your cert, it gets resolved to 365 outlook and they own that cert.
Sorry, if that wasnt clear.

Answer 4

Maybe I also didn't explain well. But thanks, now I understand. So just to come back to my first post regarding the more special autodiscover scenario: because Microsoft won't have the customers autodiscover names on their certificate, how does this work?

Is this due to the HTTP redirect (because port 443 is not listening on autodiscover.outlook.com)? Because some Microsoft autodiscover URLs are also ncluded under the "redirect servers" in Windows registry.

Answer 5

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.