Exchange 2010, Autodiscover, CName record, Name Mismatch issue

Posted on 2013-11-05
Last Modified: 2013-11-15
So I searched for a while and can't seem to find an answer that applies to me through here or even with my best google-fu.

My issue is as follows:

I have an Exchange 2010 server that hosts a few dozen completetly different domains. At one point I used to add those domains to a UCC cert. I would add to the certificate plus the DNS record for to point at my CAS server. Everything worked great.

One day I found that Office 365 was using a simple CName record to redirect to For those Office 365 hosted exchange users, they worked great. I have never seen a certificate name mismatch prompt on their side.

Here is where I am at now:
I have setup the same CName record of and pointed it at my Exchange 2010 CAS server. The cname entry for is to my external, let's call it, That name is on my SSL certificate. Autodiscover tests from fail due to certificate name mismatch. My Outlook users get a popup regarding the same, certificate name mismatch issue. I have verified all CAS based web directories internal and external for OAB, Autodiscover, ECP, EWS, etc point to my external DNS name that is on my SSL certificate.

HOWEVER, I continue to get a prompt about a name mistmatch. Running the autodiscover test from Outlook returns all expected values. There isn't an internal (.local) URL entry there.

I suppose finally, my question is how to resolve this. I have found 3 or 4 references here that were of no help. Adding them to the UCC defeats the purpose as the ease of usage is missing when I had new domains, which I do frequently.
Question by:LSeven
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 2
  • 2
LVL 58

Expert Comment

by:Cliff Galiher
ID: 39625478
There is no way around it. The certificate name must match the domain name that Outlook uses. CNAME records *do NOT* redirect. They provide an alternate name, but if you use that alternate name then the certificate must still contain that alternate name.
LVL 63

Assisted Solution

by:Simon Butler (Sembee)
Simon Butler (Sembee) earned 333 total points
ID: 39626999
What Office365 is doing is a HTTP redirect, not a HTTPS redirect.
The HTTP host name redirects to the actual source of the Autodiscover information. You can do similar with SRV records.

If you want to do a HTTP redirect you need to have a unique IP address, which has no HTTPS services bound to it.

This article on the Exchange WIKI at Microsoft explains how to set it up:


Author Comment

ID: 39638679
Sembee2, thanks for the response. I will try this out and see how I fair.
Raise the IQ of Your IT Alerts

From IT major incidents to manufacturing line slowdowns, every business process generates insights that need to reach the people required to take action. You need a platform that integrates with your business tools to create fully enabled DevOps toolchains.

You need xMatters.


Author Comment

ID: 39639563
Sembee2, are you saying for every O365 Hosted Exchange solution they offer, MSFT uses a completely unused (HTTP/HTTPS) IP address?!
LVL 58

Accepted Solution

Cliff Galiher earned 167 total points
ID: 39639615
O365 does not allocate a unique IP address per host, no. But they don't JUST use CNAME records either. Being hosted in Azure, they can leverage the entire virtual network that azure offers, and they use a bit of reverse proxy magic to make sire initial https autodiscover requests fail, so clients fall back to HTTP. Then the http autodiscover request issues an HTTP redirect (not a cname, not DNS), and the subsequent request is done via https and proxies to a service with a certificate that matches.

A third party hosted could replicate this behavior, but it'd take an intelligent reverse proxy setup, and ideally separate dedicated IIS machines for the HTTP redirect. Provisioning new clients would also not be trivial, and some custom automation would likely be desired to avoid easy mistakes.
LVL 63

Assisted Solution

by:Simon Butler (Sembee)
Simon Butler (Sembee) earned 333 total points
ID: 39641702
"Sembee2, are you saying for every O365 Hosted Exchange solution they offer, MSFT uses a completely unused (HTTP/HTTPS) IP address?! "

No, that is not what I am saying.

You need two IP addresses - one for HTTP and one for HTTPS.
They point everything for Autodiscover using the CNAME and HTTP redirection method at the HTTP IP address.

The key point being that HTTP address doesn't listen to HTTPS as well.


Author Comment

ID: 39652029
It seems a srv record works as expected. Add in a note to tell them to uncheck the pop up box is, while not the cleanest, probably the easiest solution.

Featured Post

NEW Veeam Agent for Microsoft Windows

Backup and recover physical and cloud-based servers and workstations, as well as endpoint devices that belong to remote users. Avoid downtime and data loss quickly and easily for Windows-based physical or public cloud-based workloads!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This article explains how to install and use the NTBackup utility that comes with Windows Server.
In-place Upgrading Dirsync to Azure AD Connect
This tutorial will walk an individual through the steps necessary to install and configure the Windows Server Backup Utility. Directly connect an external storage device such as a USB drive, or CD\DVD burner: If the device is a USB drive, ensure i…
how to add IIS SMTP to handle application/Scanner relays into office 365.

696 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question