Blue Coat - SSL reverse proxy for Exchange Active Sync

(with client certificates)

I've recently had the pleasure of setting up a reverse SSL proxy for Exchange Active Sync (EAS) with the
requirement of SSL on both sides of the connection, with client certificates for mobile devices.
After some coffee, some 'what have I done to deserve this' moments and a bit of reading - it's actually not
quite as painful as you might imagine. There's a good amount of documentation on how to achieve this
with Microsoft ISA / TMG but not much for other vendors. Here's how I set it up with a Blue Coat Proxy
SG running SGOS 6.4.2.1.

1. To make things a bit easier, you'll need all of your certificates in PEM format (Base 64 encoded - the
ones if you open in a text edit start with ===BEGIN CERTIFICATE/KEY===). If you generate them from
your Microsoft enterprise CA you'll most likely be given them in PFX or P12 unless you want to generate
CSRs from the Blue Coat device. You'll need to use openssl to convert them into a PEM file containing
the unencrypted private key and the certificate.
You will need the certificates for your enterprise CA, exchange server if not issued by your CA and one
for the Blue Coat device itself to identify to the clients (issued by your enterprise CA).

2. Add the certificate for the Blue Coat device to your proxy as a keyring (configuration -> SSL ->
Keyrings). This should be the only certificate with a private key contained in the PEM file.

3. Add the other CA certificates to the proxy in CA certificates section (configuration -> SSL -> CA
certificates). This will ensure the proxy trusts any certificates issued by your enterprise CA (clients and the
Exchange server). It's quite common for Exchange to use a self-signed certificate - if this is the case you'll
need to export this certificate and add this to the Blue Coat as well (otherwise you'll need to add policy
later on to ignore the fact it's issuer isn't trusted.

4. Create a new CA Certificate list and add in the CA certificates you created above. We'll use this shortly
on our proxy service listener.
 5. Under Configuration -> Services -> Proxy Services, create a new service
group and named it 'Reverse proxy'. (this is optional but keeps things more organised). Create a new and
fill in the details as below.
Name: Something meaningful to you
Service group: Group you created above
Proxy: HTTPS Reverse Proxy
Keyring: This is the keyring for the Blue Coat appliance you created previously (the one with the private
key).
CCL: This is the CCL you created in step 4. This will make sure the proxy only accepts certificates which
were issued by your enterprise CA.
SSL versions: Enable whatever you require here - but make sure you tick Verify Client and don't enable
Forward Client Cert (it's impossible to forward the actual client certificate so the Blue Coat forwards some
information from the certificate in the HTTP headers. This doesn't work for our goal which is why we're
using KCD).
ADN: unticked - it's not relevant here.
Listeners: This is the address that you will NAT from your firewall (or a public address if your proxy is
deployed in that way). This will be where clients connect. You can use an IP that isn't in use by the proxy
so long as you add it as a Virtual IP.

6. Join the proxy to your domain (you'll need a domain administrator account for this). Under
Authentication -> Windows Domain create a new domain and then join it. Make a note of the name you
join to the domain with as you'll need this for the KCD settings. If you have problems joining - make sure
the DNS on your proxy is pointing toward your Active Directory server. Once joined, go to Authentication -
> IWA -> IWA servers and make sure under Client Authentication Modes - 'Kerberos credentials' is ticked.

7. Create a certificate authentication realm under Authentication -> Certificate. Then under Certificate
Main, configure the extractors so the proxy is able to obtain the username from the clients certificate.
 Your certificates might vary so you might need to
try a few options to find what works for you. Our AD / CA setup is mostly standard so far as I know so
these settings should work. You'll get errors in the event and access logs saying 'unable to extract
username' if these settings aren't relevant to your environment. The options on the other tabs can be left
at default.

8. Over to your AD setup for a moment now to enable your Blue Coat device to perform KCD for
authentication to your Exchange server. In the AD 'Users And Computers' view - find the new device
representing the proxy (the name you chose in step 6)and edit the properties. Under the delgation tab,
configure your options as in the screenshot.

For the user / computer options which are blanked out in the screenshot - this needs to be the object for
your Exchange server. Click apply / OK and close this window.
9. Back to the proxy now. Go to configuration -> Forwarding -> Forwarding Hosts and create a new
forwarding host. This needs to have the below settings.
Host: IP address of your Exchange server
Type: Server
Ports: 443
Others left unticked as per the default.

10. Open up the VPM via Configuration -> Policy -> Visual Policy Manager.
For the purpose of this guide - I'll be working with a totally blank policy to keep things simple. The policy
layers should be setup as below.

Layer 1 - Web Authentication Layer.

Destination: Request URL object. Simple match - value should be the DNS name clients will be
accessing for your reverse proxy. Eg, activesync.mydomain.co.uk
Action: Combination object containing an Authenticate Object (Realm should be your certificate
authentication realm from step 7. Mode: Auto) and a Kerberos Constrained Delegation object.
(Authentication type should be origin, IWA Realm should be the IWA direct realm from step 6. Service
Principal Name should be 'host/' then the exact name of your Exchange server without the domain).

Layer 2 - Web Access Layer.

Source: Authenticated user (no configuration for this object)

Destination: Request URL object (Advanced match - scheme any, Path "/Microsoft-Server-ActiveSync").
This will ensure only EAS connections are allowed to this reverse proxy connection.

Layer 3 - SSL Access Layer

NOTE: This layer isn't strictly necessary but it's useful to troubleshoot SSL problems whilst you're setting
up. The destination is the IP of your Exchange server and the Action is an SSL certificate validation action
to ignore untrusted issuer.

Layer 4 - Forwarding Layer

Source: Authenticated User (no options again)

Destination: Server URL object (simple match again with the DNS name of your reverse proxy
connection).
Action: Select Forwarding Object. Move the object name you created in step 9 into the right hand column
and then ok.

11. We're done! Install the VPM policy and then you're ready to test. Make sure the client certificates you
deploy contain the full certificate chain or you'll get SSL errors when your devices try connecting to the
proxy. If you use Active Directory to issue user certificates you'll probably find they're in PFX format. In
this case, they should contain the full chain by default.

http://www.root9.net/2013/05/blue-coat-ssl-reverse-proxy-for.html