Q&A: how do I fix the "Unable to establish a secure connection …" issue in Entourage:Mac?

From my open question thread:

When opening my inbox from an Exchange 2007 SP1 server with Entourage 12.2.3 I get a dialog saying "Unable to establish a secure connection to example.com because the correct root certificate is not installed."

There's a few things that you can do to get rid of this dialog.

One option is to ask your admin for a root certificate. After you receive that certificate from your admin, you can install it. If that solves the problem some but not all of the time, open the Microsoft Certificate Manager application (it's in the Office folder) and import the certificate there.

Another option is to uncheck the "This DAV service requires a secure connection (SSL)" box. It's on the Advanced tab in your Account Settings for that Exchange account.

If you're feeling particularly techy, you can check to see if your Exchange server's autodiscover service is set up properly. Amir wrote up some instructions in his blog post SSL warning issue in Entourage 2008. Look down to the note for the instructions that you as a user (and not an Exchange admin) can take to see if it's set up properly. If your autodiscover service isn't set up properly, you can at least inform your Exchange admin about it and ask them to fix it. There's a whitepaper for setting up the Exchange 2007 autodiscover service which has plenty of details for how your Exchange guys can get it set up properly.

For additional troubleshooting without calling Microsoft tech support (for which you get two free calls with your purchase of Office 2008) or any internal tech support that you might have, you might want to try the Entourage public forum.

Comments (7)
  1. David Buxton says:

    Hi Nadyne, thank you for answering my original question.

    In my case the exchange server accepts mail for 2 domains: example.net and example.com. The AD domain itself is example.net, but some users have example.com as their primary email address. While autodiscover is configured correctly for the AD domain example.net, it is not configured correctly for example.com.

    For a user jenny who has jenny@example.com as her primary email address (even though her actual login is EXAMPLE.NETjenny) Entourage appears to check example.com before it checks autodiscover.example.com, which is a problem because the web server at example.com has a self-signed certificate (very annoying but I cannot get that changed).

    Am I wrong about the order of DNS names Entourage tries to resolve? Would creating an appropriately configured autodiscover.example.com entry short-circuit the discovery process so that Entourage does not contact example.com? I could configure a SRV record for example.com but Amir’s comments in that blog post also suggests that Entourage does not use SRV records.

  2. Hmmm, let me check with someone else, since you’re now past my Exchange expertise.  I doubt I’ll get an answer before next week, since some lazy people seem to think that they get both holidays AND weekends off. 😉

  3. noggin says:

    hmmm…Let me try this one because I am having the same problem "Unable to establish a secure connection" with my server. Thanks!

  4. David Buxton says:

    I did a packet capture with Microsoft Entourage EWS 13.0.0 running on Mac OS X 10.5.8 and observed the following DNS lookups when my primary email address is in the example.com domain:

    – example.com A

    – autodiscover.example.com A

    – _autodiscover._tcp.example.com SRV

    So I think Entourage _does_ use SRV records, but in my case that does not help because it contacts the server with the self-signed certificate before it then looks for the autodiscover records.

  5. David Buxton says:

    This discussion in the Entourage support forum is pertinent: http://www.officeformac.com/ms/ProductForums/Entourage/5019

    The question is "Is there an override/workaround for manually configuring autodiscover on the


  6. NathanHerring says:

    Admittedly, if you’re getting an "Unable to establish a secure connection" message, you’re already falling back from using TLS to using an insecure communication mechanism. However, just disabling SSL, in case it wasn’t obvious, doesn’t actually fix the inherent security problem — that now, people inbetween you and your server who are reading network packets (including those not addressed to themselves) can pry into your e-mail or LDAP directory searches, etc., etc. If you are fine with that, then I highly suggest omitting personal information in any of your e-mail, including passwords, credit card #s, bank account data, etc., because you’re one malignant sniffer away from identity theft. Personally, I would try figuring out the correct root certificates to install, and install them.

    From an Exchange administrator’s perspective, getting the root certificate story right is incredibly important. Having the Exchange server not use either (1) a self-signed cert, which is guaranteed not to work on your box, nor (2) a cert whose root is not one of the standard commercial roots.

    This latter one is a real gotcha, and has happened here at Microsoft. Originally, we had (and still have for some applications) a Microsoft corporate root certificate. This signed a series of Microsoft intermediate certificates, which in turn signed many Microsoft server identity certificates. Since the Microsoft root is not shipped with Mac OS X, none of these certificates would get trusted. Since also Microsoft servers no longer support the SSL/TLS standard correctly in certain circumstances, you’d not even know what root was the problem, since you would not get the full chain of certificates. A double whammy of badness. Instead, now we have a secondary Microsoft "root" which is actually an intermediate signed by a commercial root. Certs signed using this certificate are all now verifiable on all OSes that keep up with commonly accepted certficate roots.

  7. David Buxton says:

    Hello Nathan,

    In our case the misconfigured server is not providing LDAP or any other Exchange service. It is not the Client Access server. The troublesome domain name is used as an email alias for staff but otherwise has nothing to do with our directory structure.

    If the order of autodiscover lookups were reversed (i.e. check the most specific entry first, _autodiscover._tcp.example.com) or if there were a way to explicitly set the autodiscover server address or if there were a way to disable the autodiscover behaviour altogether then I could avoid the misconfigured server completely.

    Autodiscover for our primary domain works perfectly.

    Having a way to disable or override the autodiscover behaviour would be great.

Comments are closed.

Skip to main content