SSL Warning Issue in Entourage 2008

Update 1: The fix for this issue has been released in the 12.1.2 Update for Office 2008 for Mac. See 'Improvements for Microsoft Entourage 2008 for Mac' section in KB 956344.

Update 2: The fix for a subsequent 'CNAME' entry issue discussed in the comments section of this blog post has been released in the 12.1.3 Update for Office 2008 for Mac. See 'Improvements for Microsoft Entourage 2008 for Mac' section in KB 958267.

In this post I wanted to quickly provide an update on an ongoing issue with some specifics to make sure our customers are well informed on its current status.

After installing Office 2008 for Mac Service Pack 1 (SP1) when Entourage 2008 users connect to their mailbox on an Exchange 2007 Server, they may see an error like this (you can substitute 'contoso' in the screenshot below with your own root domain):

If you click on 'OK', Entourage will continue to work and you won't see this error message again until the end of that session when you close Entourage. Clicking on 'Cancel' you may end up in 'Not Connected' state with your Exchange account. This error may also come up when:

1. You try to configure your Exchange account using 'Account Setup Assistant' which now uses Autodiscover Service on Exchange 2007 to automatically configure your account or

2. You use any 'Exchange Web Services' based feature in Entourage 2008, like OOF Assistant, Free/Busy Info pull-up, etc. as they also utilize Autodiscover feature or

3. Entourage tries to talk to Autodiscover Service while its running connected to your mailbox to see if any updates were made to Autodiscover Service on server side by your Exchange Administrator, this happens automatically in the background based on a pre-set interval which cannot be modified by user

This happens as Entourage 2008 tries to establish a secured connection to the first of the 2 default addresses (URLs) in its attempt to contact the Autodiscover Service on your Exchange 2007 Server. This is explained in the Autodiscover Whitepaper, see 'How the Autodiscover Service Works with Clients' section. Most organizations using Exchange 2007 do not publish Autodiscover Service thru the first URL mentioned over there, i.e. '', rather they use the other URL, i.e. ''. When Entourage finds an error (mostly its 'Common Name' mismatch) with the certificate published at the root of your domain (if there is one, many organizations do, but 'Common Name' on that certificate is '', not just '' and Autodiscover Service is not published thru that URL), it displays the above error. It does not move silently to try the other possible URL. Clicking 'OK' on above error makes it exactly do that and thus it finds the Autodiscover Service responding on the other URL and everything then works fine from there.

This issue can also happen in Entourage 2008 if Autodiscover Service is not configured properly as per the guidelines in Autodiscover Whitepaper. See 'Note' below on how to quickly check to see if Autodiscover Service is properly configured and published for users.

Microsoft is working to release a fix for this issue in an update for Entourage 2008 but a final release date is not available yet. I plan to update this post with new information in this regard when it becomes available.

We need to make sure that when Entourage looks for Autodiscover Service, the related URL as mentioned above in 'Cause' section is configured and published to respond to those requests. A quick way is to look up the A Record (a type of DNS record which is used to map a hostname or URL to the IP Address of the host) which you will have to register with your DNS provider.

A Working Example:
For Microsoft, the Autodiscover Service is configured and published at '', you can look it up using this URL in your browser:

You will see an IP Address is mapped to the URL for Autodiscover Service to respond to incoming requests.

Now, if I go and hit the URL for Autodiscover Service in my browser, i.e. ''

I will get a window to enter my user credentials (domain\username & password) and after that I will see the following lines in the main browser window:

<?xml version="1.0" encoding="utf-8" ?>
- <Autodiscover xmlns="">
- <Response>
- <Error Time="10:29:57.7332076" Id="59171512">
    <Message>Invalid Request</Message>
    <DebugData />

The response above says 'Error 600, Invalid Request' as the Autodiscover Service URL is not supposed to be accessed thru a browser. This is an expected response in this scenario and confirms the proper configuration and publishing of Autodiscover Service.

A Non-Working Example:
Let's use Contoso as a non-working example, the Autodisover Service should be configured and published at '', if you look it up using this URL in your browser:

You won't find an IP Address mapped to the URL for Autodiscover Service, instead you will see an error there saying 'server can't find'.

Comments (24)

  1. Chris says:

    The 12.1.2 did not fix mine.  I’m getting the error that specifies a domain name, rather the the Exchange server name – which seemed to be the indicator that this was the exact error I was experiencing.

  2. Amir Haque [MSFT] says:


    As I mentioned above in ‘Cause’ section, this issue can also happen in Entourage 2008 if Autodiscover Service is not configured properly as per the guidelines in Autodiscover Whitepaper (linked above). Did you use the info in ‘Note’ section to check if Autodiscover Service is properly configured and published by your server administrators?

  3. Mitchll says:

    I too am still getting this SSL error. Autodiscover service is configured properly as in Note

  4. Brooks says:

    Same here, The 12.1.2 did not fix ours as well.

  5. Amir Haque [MSFT] says:

    Mitchll & Brooks,

    You guys then need to contact Microsoft Professional Support at 1-800-936-4900 (;EN-US;OfferProPhone)
    so that we can see what’s going on.

  6. annette says:

    Did not fix mine either ~ ugh.  I called the support number above. They said they would look into it for a a fee of $259.  Or I can go to the support website for free help.


  7. Amir Haque [MSFT] says:


    If you have already run the 2 tests in my blog above (‘Notes’ section) and you get proper response (be really sure about it, talk to your Exchange Server Admin about Autodiscover Service setup, if you are not one yourself), then either you can get support thru the above paid option (keep in mind that charge is refunded later if the issue is concluded as a bug in Microsoft product) or you can post on Forum (free) at:, where MVPs can try to help you out.

  8. Vincent K. says:

    12.1.2 did not fix our problem, either.

  9. Vincent K. says:

    We are using a DNS Service Location (SRV) record to locate the Exchange Autodiscover service on another hostname per the AutoDiscover whitepaper.  It works great for Microsoft Outlook.  Is this also supported for Entourage?  It is not working.  It would be great it this could be supported so that it doesn’t automatically come up with the warning for all of our Entourage users.

  10. Amir Haque [MSFT] says:

    No, SRV Record will not work for Entourage 2008. Only Outlook 2007 has the capability to read the SRV record. Entourage just goes and looks for (as I mentioned above in my post), so you will need to put in an A Record for the host which is running Autodiscover Service (Exchange 2007 CAS) and then you can supplement that with a CNAME
    entry pointing the above URL for Autodiscover Service to the FQDN of CAS or do it in a way more appropriate for your org setup and infrastructure. In the end, Entourage users should be able to hit the above URL thru a browser (like Safari), get a credentials
    prompt, enter their domain credentials (username, password & domain) and get the ‘600 Invalid Request’ error as I mentioned in my post above. After that they will not see the ‘SSL Warning’ issue.

  11. Vincent K. says:

    But I would expect it to still give a hostname mismatch between the server and certificate…  replacing our domain name with contoso – We have our CAS NLB set up as  This is where autodiscover needs to point.  If I set up a CNAME entry pointing to … since our certificate is for, I imagine entourage will complain that when it’s looking for a certificate it is only finding a certificate (I will have to try this later to verify).  We could buy another certificate, but would really rather not (it wasn’t in the budget).  The other thing I’m not sure about, and I want to set up a network traffic sniff, is what order entourage is checking for things.  If it is checking the root domain first of, it is going to find a certificate for, hence another name mismatch.

  12. Daniel Charnock says:

    Hmm, the update hasn’t allowed the autodiscover to work with us. Outlook 2007 work with autodiscover, but I tried the auto activation of our Entourage 2008 users and no go ;-(  

    Certainly say that it is frustrating.  

    For example if you ping you get (pointing to our CAS servers).

    Now if we run the test that Amir has provided ( and I substitute my domain name and then
    logging in with my domain/username and password shows the link: and of course the following:

    <?xml version="1.0" encoding="utf-8" ?>

    – <Autodiscover xmlns="‘>"&gt;

    – <Response>

    – <Error Time="10:29:57.7332076" Id="59171512">


       <Message>Invalid Request</Message>

       <DebugData />




    Because of our hosted environment is the domain of our Exchange organization.  In this case our customers don’t host the Exchange server and web services.  However, they do create the A record and that works
    fine with Outlook 2007.  We even allow them the opportunity to use a proxy which is if they haven’t configured their A record.  All this works without a hitch in Outlook 2007.  However, the way Entourage is configured it appears
    as if it is still trying the

    and not the second way.  I’m lost as to what we need to do.  It would be fantastic to tell a user just to plug in their e-mail and let the autodiscover work from there.  Unfortunately, OOF and other web services don’t work.  A real shame.

  13. Amir Haque [MSFT] says:


    Yes, you are right, and to address that you can use the Unified Communications Certificate (a certificate that supports multiple DNS names) with an entry for Autodiscover URL in SAN (Subject Alternative Name) field, read the Autodiscover Whitepaper (linked above) for details on that & other possible options. You other concern has already been taken care of with the fix for this issue, read the Cause section above.

  14. Amir Haque [MSFT] says:


    I am looking into your scenario currently. Are you sure that your customers are creating an A Record or a CNAME entry which should have a mapping of Autodiscover URL for your customer’s domain to your domain, like we require our customers of Exchange Labs Exchange Hosting, see:

  15. Fred Mez says:

    I am now getting the error. I am using Intermedia exchange hosting and have been working fine until today. I now get the cert error. I have been running 12.1.2 since it released. SO 12.1.2 is not addressing this issue for me.

  16. Amir Haque [MSFT] says:

    Daniel and Fred,

    To confirm at this point it looks like that Entourage is not able to handle CNAME based records or redirects properly and you may be seeing the ‘SSL Warning’ related to the domain to which CNAME Record redirects your domain’s Autodiscover Service URL. We are looking into it right now. Also, this is a different issue than the original ‘SSL Warning’ issue discussed in this blog post, which has been properly fixed in 12.1.2 Update.

  17. Bill Fox says:


    I am going through the frustrations with Entourage 2008 and Exchange 2007 SP1. When I open up Entourage I keep getting a pop up  "Unable to establish a secure connection to because the the correct root certificate is not installed." I go through Key Chains and add the certificate but I still keep getting this message. This is very frustrating no help from Microsoft.  

  18. Amir Haque [MSFT] says:


    Did you run the tests above in ‘Note’ section, what were the results. If you are not the Exchange Admin then you need to contact your Admin and point him to this post to make sure he has published Autodiscover Service properly as per the instructions in
    the whitepaper linked above. The only scenario which is not working (currently being investigated) as I confirmed in my last comment is one which involves a CNAME mapping, like the one in this case:

  19. jimsoxz says:

    We started getting an error message of the type in your original example when we applied SP1. Our email is shared exchange hosted by Intermedia. I worked with their technical support to resolve this problem. They had me create a CNAME record with the autodiscover alias pointed to their autodiscovery host.  At that point, we started to get two error messages about the SSL certificates: the original one plus one for the autodiscovery alias. Intermedia then declared that the problem was on the Microsoft side. Their technical support page still asserts that the issue with the certificate is a Microsoft problem.

    With 12.1.2, we are back to just the original error message. Your latest post indicates that with the CNAME setup the certificate issue is not fixed, but it implies that this issue was not one introduced with SP1. The CNAME record seems correct because a Windows based computer can use it to autoconfigure an Outlook 2007 client. This autodiscovery setup will not however configure an Entourage 2008 client.

    My purpose in this post is to be clear on what problems Microsoft still owns and what problems, if any, we have to work through with Intermedia. Thanks for your efforts on this problem.

  20. Amir Haque [MSFT] says:


    The CNAME problem was discovered after 12.1.2 release, which we are currently working to investigate & resolve. The earlier issue discussed in the post above has been resolved. The difference between the two is that SSL Warning message now displays the URL which is mapped to your domain’s Autodiscover Service URL (CNAME mapping based issue). Both of these issues are Entourage related and have nothing to do with Hosting Service Providers. Outlook 2007 working fine with your current setup is the best evidence that there is no issue with your or Intermedia’s setup.

  21. jimsoxz says:

    I may not be understanding you correctly, but the error message received now is identical to the error message we received after applying SP1.

    It is the same message you show in our original blog entry with replace with just our No reference is made to the autodiscovery service URL. As I noted before, we had been receiving a second error message of the form above with the URL of the autodiscovery service, but that complaint went away with 12.2.2.

  22. Amir Haque [MSFT] says:


    In that case, could you please call in at 1-800-Microsoft and create a support case with PSS, I think your scenario needs to be investigated further as you have already gone thru the checks above in the blog post. There won’t be any charge to you if it comes to be a bug in any of Microsoft’s products.

  23. Fred Mez says:

    it has been a month since my last post about the CNAME issue with Entourage, and Intermedia.

    Is there any update on the issue? i have delayed migrating entourage users to the service until this issue is addressed.

    thank you.

  24. Anonymous says:

    Some Entourage users are continuing to see the following warning error after updating to 12.1.3. Unable to establish a secure connection to because the server name or IP address does not match the name of IP address on the server’s certificate.

Skip to main content