Exchange 2010 external autodiscover certificate issue in Outlook

Hi there, have Exchange 2010 set up working internally and externally, with one exception: External users off VPN connecting via Outlook get a certificate warning for the internal mail server on startup, but works fine if they press 'yes' to bypass it.

When viewing the cert, it's pulling our corporate web server cert and not the one attached to our autodiscover/mail server. For the latter, we're using a UCC cert which includes autodiscover.domain.com, mail.domain.com, and mail.domain.local.

Our corporate web server responds with a 404 for the https://domain.com/autodiscover/autodiscover.xml url, and the Microsoft Remote Analyzer comes back able to get itself connected. I've also tried throwing a 302 redirect from the corporate web server over to autodiscover.domain.com, but that doesn't seem to help.

Any ideas how to get the certificate error to stop appearing? I don't want to add our internal mail server to our corporate web server's certificate if I don't have to. I do have the root domain (ie "domain.com") in the corporate web server's SAN list.

I should mention we still have TMG in front of it as well.

Thanks!
LVL 1
GonthaxAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

davorinCommented:
That is the normal autodiscover procedure order for outlook.
If outlook is not able to connect to domain and use SCP for autodiscover, the next step is try to connect to https://domain.com...

http://enterpriseit.co/microsoft-exchange/outlook-autodiscover-order/

While there is an registry option to disable SCP lookup, I'm not aware that there exists an option to ignore step 2 - try to connect to https://domain.com/...

As you have pointed your external root domain to your web server and your web server responds to https your external users are seeing this problem.

First of all, I do not understand why lots of web site designers insists that root domain is pointed to web server (mostly just because is the user forgets to type www while browsing). On my opinion this is not so good practice.
Per example after 1st of november 2015 you will not be able to use public certificates with .local domain. There will a lot of companies change their internal domain names to public domain name and they will have split DNS configuration. And in AD DNS the root domain must be pointed to domain controllers if you want the domain to function.

To solve your problem my preferred option would be to remove domain.com from external DNS server (or to point it to your exchange server). Other options are to disable https at your web server (probably not possible) or to install correct certificate on your web server, so when outlook will see, there is nothing for it, it will continue with autodiscover procedure at autodiscover.domain.com address.
Simon Butler (Sembee)ConsultantCommented:
"First of all, I do not understand why lots of web site designers insists that root domain is pointed to web server (mostly just because is the user forgets to type www while browsing). On my opinion this is not so good practice."

Unfortunately you are in a minority there. The overwhelming practise now is to have the root of the domain pointing to the public web site because most people will not enter the www and advertising material is dropping it. What Microsoft need to do is realise this and stop using the root of the domain for Autodiscover.

On the original problem, having the root of the domain on a public web site is not normally a problem as long as Autodiscover is not present there. Where these problems usually occur is because the web host is using one of the control panels that wants to use Autodiscover for itself, so has https://example.com/Autodiscover/Autodiscover.xml working. If that works, then you get the SSL prompt.
Get the web host to turn Autodiscover off for the domain - they can do it but first line support may not know how so you will have to persevere.

Simon.
GonthaxAuthor Commented:
Gentlemen, thank you both for your responses.

I tend to agree with Simon regarding the root domain in modern practices. It behaves that way for customers unfortunately. If I had my druthers, I don't think the root domain should be for web or Exchange use, but I am but a tiny voice in a large chorus. :)

Regarding my root domain, I don't have anything there autodiscover related. If I curl -I https://mydomain.com/autodiscover/autodiscover.xml, I get a 302 redirect (to www.mydomain.com/autodiscover/autodiscover.xml), which returns a 404 page (and a 404, not 200 like some company 404 pages!).

I do have an autodiscover.mydomain.com, which pass the MS Connectivity Remote Analyzer tests, and it shows my root domain failing as expected due to a 404 error. Since clients can successfully get their e-mail, I can only assume they are resolving to the autodiscover.mydomain.com subdomain  (but they just get that annoying certificate message...). The autodiscover sub-domain has an appropriate certificate associated with it if I go there with a web browser (aka https://autodiscover.mydomain.com/autodiscover/autodiscover.xml)

I do have control of our DNS and web settings (we run everything through AWS) and don't have anything special enabled except an autodiscover A record. Any other ideas?

Again, thank you guys.
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

Simon Butler (Sembee)ConsultantCommented:
I am pretty sure this is the problem:

"https://mydomain.com/autodiscover/autodiscover.xml, I get a 302 redirect"

Outlook is expecting a 404, not a 302 redirect.

Simon.
GonthaxAuthor Commented:
Hi Simon, sadly it didn't fix it. I just wrote a RewriteCond to omit autodiscover/autodiscover.xml and it returns a 404:

~ curl -I https://mydomain.com/Autodiscover/Autodiscover.xml
HTTP/1.1 404 Not Found
Date: Mon, 06 Jul 2015 22:54:41 GMT
Server: Apache

Open in new window


Ran the Test Analyzer again and it reports a 404 for the root now too, and ran Outlook and it brought up the website cert warning again. So weird...
Simon Butler (Sembee)ConsultantCommented:
If you look at the certificate, is it one you recognise?

Simon.
GonthaxAuthor Commented:
Yep - it's the certificate for our company webserver (the one at mydomain.com)
davorinCommented:
I'm pretty sure that when-ever web server responds to https request, it uses its certificate to identify itself. It does not matter if it has autodiscover.xml on it or not. If it would have the xml, it probably would first get security prompt about web server certificate and then:
- or outlook will be confused and misconfigured with wrong autodiscover.xml
- or it will recognize that there is something wrong with the xml and outlook will try with autodiscover.domain.com
But that's just guessing.

Exactly what error do you get at certificate warning?

I agree, that also Ms should stop using root domain as every other should stop - but I think nobody will stop doing it.
But if we want to use Ms products we will have to stick to Ms rules and we will also pay them to be able to stick to their rules. It is easier to change DNS record that outlook coding. Well the second one is also against the eula :)
GonthaxAuthor Commented:
Hi guys, hope you had a great weekend.

In Windows, it reads:

Security Alert
mail.mydomain.internal

Information you exchange with this site cannot be viewed
or changed by others. However, there is a problem with
the site's security certificate.

[Green check] The security certificate is from a trusted certifying authority.
[Green check] The security certificate date is valid.
[Red X] The name on the security certificate is invalid or does not match the name of the site.

Do you want to proceed?
[Yes] [No] [View Certificate...]

Clicking View Certificate shows the web server's certificate.

Interestingly, it seems to pop up after Outlook says "All folders are up to date." and "Connected To: Microsoft Exchange" in the status bar. It doesn't pop up on startup - it pops up after everything is already connected and synched, maybe a minute or two after startup. Wonder if there's a connection there?
Simon Butler (Sembee)ConsultantCommented:
If it is referencing your internal domain, then one of the URLs within Exchange is not correct.
http://semb.ee/hostnames2010

Simon.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Exchange

From novice to tech pro — start learning today.