How to stop Entourage/Autodiscover fromlooking up the bare domain with invalid certificate

[emcnally]

Version: 2008 Operating System: Mac OS X 10.6 (Snow Leopard) Processor: Intel Email Client: Exchange Entourage 13.0.3 / Exchange 2010

Every time I launch Entourage I get the following error:
"Unable to establish a secure connection to domain.com because the correct root certificate is not installed." After clicking OK, entourage proceeds to connect and work properly. This is with Entourage external to the corporate network, so it is using public DNS.

Looking at the log, I see that it is trying to connect to
"Entourage Exchange Auto Configure: Querying https://domain.com/autodiscover/autodiscover.xml"

The problem is that "domain.com" resolves to a hosted web site which offers the client a certificate that is indeed incorrect as it is not intended to be used for anything but web site hosting and is not something I can change.

"autodiscover.domain.com" is correctly setup via public DNS and on our Exchange server, and Entourage will configure itself properly _after_ presenting the error from "domain.com".

External Outlook 2007 clients have no problems and no errors. I assume Outlook will accept _either_ domain.com or autodiscover.domain.com, but Entourage will only check autodiscover.domain.com _after_ checking domain.com.

So the big question is what to do to keep the error from displaying in Entourage? I have to say, it seems rather dumb to assume that the bare domain record will always be configurable for a certificate and autodiscover directory, so I assume I just don't know the full picture.

I can confirm that this is an Entourage autodiscover lookup problem rather than an Exchange configuration problem by editing the hosts file and making domain.com resolve to autodiscover.domain.com. In this case I get no errors.

Thanks for any advice!

 

[William Smith [MVP]]

Every time I launch Entourage I get the following error:
"Unable to establish a secure connection to domain.com because the
correct root certificate is not installed." After clicking OK, entourage
proceeds to connect and work properly. This is with Entourage external
to the corporate network, so it is using public DNS.

Looking at the log, I see that it is trying to connect to
"Entourage Exchange Auto Configure: Querying
https://domain.com/autodiscover/autodiscover.xml"

The problem is that "domain.com" resolves to a hosted web site which
offers the client a certificate that is indeed incorrect as it is not
intended to be used for anything but web site hosting and is not
something I can change.

"autodiscover.domain.com" is correctly setup via public DNS and on our
Exchange server, and Entourage will configure itself properly _after_
presenting the error from "domain.com".

External Outlook 2007 clients have no problems and no errors. I assume
Outlook will accept _either_ domain.com or autodiscover.domain.com, but
Entourage will only check autodiscover.domain.com _after_ checking
domain.com.

So the big question is what to do to keep the error from displaying in
Entourage? I have to say, it seems rather dumb to assume that the bare
domain record will always be configurable for a certificate and
autodiscover directory, so I assume I just don't know the full picture.

You can't disable this. It's a security feature.

If you're indeed using a hosted service that has an incorrect
certificate then your provider should install a correct SSL certificate.

Outlook users probably don't have this issue because they are using RPC
over HTTP and not connecting with Exchange Web Services.

I would say if the certificate won't get corrected and you've suppressed
the message by editing your hosts file then that's you're best solution.

--

bill

Entourage Help Page <http://entourage.mvps.org/>
Entourage Help Blog <http://blog.entourage.mvps.org/>
YouTalk <http://nine.pairlist.net/mailman/listinfo/youtalk>
Twitter: follow <http://twitter.com/meck>

 

[emcnally]

bill,

Thanks for the answer! I was hoping for a different way to do this other than the hosts file, but it's good to get confirmation that there isn't a better way.

I suppose this would be a case where Microsoft's recommendation to split DNS (use different domains for internal AD/DNS and external DNS) would be of benefit. Still I question the wisdom of forcing a sort of infrastructure check on Exchange admins--especially having the client check every time even after the client is fully configured and working. Oh well, thanks again.

Evan