I'm currently working at a customer's site where they use a web proxy with HTTPS inspection: for each HTTPS connection, the proxy acts as a man-in-the-middle by terminating the HTTPS channel, generating a new certificate using its own internal CA and presenting it to the client; of course, the client complains about the certificate being invalid: in order to avoid this, I've imported the proxy root certificate in my computer's local certificate store. I can succesfully browse HTTPS web sites and I receive no warnings; this includes OWA on my company's Exchange server.

However, Outlook Anywhere (which uses the exact same public name and certificate as OWA) doesn't work. Outlook gives no error messages, it simply doesn't connect at all.

Why? And How can I fix this?

  • In the Microsoft Exchange Proxy Settings (Outlook Anywhere) in Outlook, have you tried unchecking "Only connect to proxy servers that have this principal name in their certificate"? – 1.618 Apr 17 '13 at 13:12
  • That was my first guess. But it gets automatically checked again as soon as I launch Outlook. – Massimo Apr 17 '13 at 13:48
  • Is it being set by Group Policy? – 1.618 Apr 17 '13 at 14:35
  • No, there's no GPO configuring that; and anyway, my laptop is not even joined to the domain. – Massimo Apr 17 '13 at 14:44
  • Do you get any useful feedback using the downloadable client from www.testexchangeconnectivity.com ? I haven't used it in a while, but I think it supports Outlook Anywhere tests. – Jeremy Lyons Apr 18 '13 at 3:24

What is the proxy server they are using? I know with WinGate you can configure some pretty funky policies based on a number of things which may help you?

I would suggest you have a look through the proxy servers log files, it should give you a clue as to why it is failing.


The Outlook client is behaving exactly as designed--it is effectively protecting your Outlook Anywhere traffic from a 'man-in-the-middle' attack.

The 'Only connect to proxy servers that have this principal name in their certificate' option is likely being re-asserted by the client autodiscover process--again, as designed.

I believe your only options are to (1) work with the deep-packet-inspection-firewall administrator to modify policies within the proxy server to handle your Outlook Anywhere traffic as an exception and eliminate the 'man-in-the-middle' inspection (e.g. convince the admin to 'trust' traffic from your Exchange Client Access Server), (2) see if the client can provide you with access to a 'guest' network which bypasses the deep-packet-inspection MITM proxy server, or (3) resign yourself to using OWA to access your mailbox while on that client's network.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.