3

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?

Massimo
  • 72,827

2 Answers2

0

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.

Jase
  • 21
0

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.

jnaab
  • 983