This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(275.2, 1%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ER6%3C/text%3E%3C/svg%3E)
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.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(300.8, 20%, 39%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAX%3C/text%3E%3C/svg%3E)
Hi anonymous user ,
It's been a while, is there any update?
If the above suggestion helps, please click “Accept as answer” to mark helpful reply as an answer. Your action would be helpful to other users who encounter the same issue and read this thread.
I think we're running in a misunderstanding again.
Let me explain again what I mean:
Let's assume, I've excluded the ExplicitO365Endpoint for Outlook autodiscover. My autodiscover record is a CNAME that points to autodiscover.outlook.com. My mailbox has already been migrated to Exchange Online. I will now try to add my mailbox in Outlook from an external device. Outlook will try to contact autodiscover.mydomain.com. Because this is a CNAME pointing to autodiscover.outlook.com, it will contact this host. Based on our discussion, this would lead to a certificate error, because autodiscover.mydomain.com is not listed as a subject (alternate) name on Microsoft's certificates.
I checked, that autodiscover.outlook.com is not accessible via HTTPS/443. Because Outlook cannot contact the autodiscover service via HTTPS, it falls back to the HTTP redirect method on HTTP/80. From there, it gets a HTTP 302 redirect to something like autodiscover-s.outlook.com. Outlook will then try to contact this URL via HTTPS/443 and because this is a "real" redirect (no CNAME), Outlook will validate, that autodiscover-s.outlook.com is present on the certificate. The initial autodiscover.mydomain.com doesn't even matter, because the request was redirected. Outlook normally would then present a warning that the autodiscover URL has been redirected and prompts the user to accept this redirection.
Because of the registry key "RedirectServers", this message will never be shown, because these servers are already somehow "accepted" to be redirected to.
Ok, no it wont throw an error, because the end point autodiscover.outlook.com that the CNAME was pointing has a cert and that subject name on it.
You should have the cert subject name or wildcard cert for your autodiscover.domain.com, Microsoft has theirs.
If you controlled and owned both autodiscover.outlook.com, and autodiscover.youdomain.com, then you would need to have certs on each end point.
For simplicity, any FQDN that clients could potentially connect to on 443 should have a subject name on the cert. You can only do this for the certs and FQDN you control of course.
Why would it not throw an error?
It throws an error if my cname "cname.domain.com" points to "notmyowneddomain.com".
Whats different to the autodiscover scenario?
The DNS resolution should take place before it attempts to contact the host name the CNAME is pointing to. - so no error
How did you test it when it threw an error?
I created a CNAME in my external DNS zone => cname.mydomain.com with a value of notmydomain.com
I typed cname.mydomain.com in my browser and got a certificate error. If I type notmydomain.com, I don't get the certificate error.
it should resolve and redirect the browser notmydomain.com. is it not doing that
It does not redirect, the address remains in my. Browser Bar.
Why should it redirect, when it's just a simple DNS resolution and no HTTP redirect?
Redirect once DNS resolves the CNAME to the host its pointing to., yes
Maybe test with a hosts file local instead.
I just did another test.
In my DNS Zone I created a CNAME autodiscover.mydomain.com to point to autodiscover.anotherdomain.com (on-premise Exchange where I have a mailbox). Trying with remote connectivity analyzer, I can see that my autodiscover request is routed to autodiscover.anotherdomain.com. When it comes to certificate validation, I get an error that "autodiscover.mydomain.com" doesn't match the certificate on the target system. So it really seems, that CNAME only works, when the presented certificate presents the original requested hostname.
Hi anonymous user ,
Yes, that's right.
For example, your domain is contoso.com, you create a CNAME record for autodiscover.contoso.com.
The name in the CNAME record must match a name in a certificate.
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
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.
Yea, the Cname will refer to the host its referring to , then the DNS lookup will be against that host.
so domain2.com would need to be on the cert.
Typically you add all those subject names to one cert.
or use a wildcard...
This is strange. I just did a small test.
cname.mydomain.com points to anotherwebsite.com, which has a valid certificate for that name. However, when I browse to cname.mydomain.com I get a certificate error.
is that on the cert subject name ? cname.mydomain.com ?
No, it's not. That was my initial question. Does the CNAME (cname.mydomain.com) have to be present on the certificate on the target system (anotherdomain.com).
From your answers I understood, that this doesn't need to be the case.
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.
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.