SSL Transparent Proxy Authentication using LDAP
When the first URL is an HTTPS site, authentication fails.  However, if the first URL is an HTTP site, authentication works correctly.

This document will walk you through the steps needed to setup SSL transparent proxy authentication using LDAP authentication.

PREREQUISITES:

1. A valid "Authentication Realm" and "Transparent Proxy Method" is already created, configured and functioning on the ProxySG.
2. Valid and functional "Web Authentication Layer" exists in the Visual Policy Manager (VPM).

The document uses the following as examples:

• Authentication realm:  LDAP
• Transparent Authentication mode:  Cookie/Session
• IWA Realm names:  SSL_Auth and nonSSL_Auth
• Virtual URL base name:  bluecoat
• SSL Authentication port:  4433

CONFIGURATION:

1. Enable two service ports in the Management Console
   1. Go to the Configuration tab > Services > Service Ports > New
      • Protocol = SSL
      • Port = 443
      • Click on the OK button
   2. Click on the "New" button
      • Protocol = HTTPS Reverse Proxy
      • Port = 4433
      • Attribute = Explicit
      • Click on the OK button
2. Enable SSL detection for SSL Proxy
   1. Go to the Configuration tab > Services > SSL Proxy
   2. Check all three (HTTPS, SOCKS, TCP Tunnel)
   3. Select "Default" certificate, or if you created your own certificate for use, select that one instead.  Make note of which certificate you used.
   4. Click on the "Apply" button.
3. Create an authentication realm for HTTPS
   1. Go to the Configuration tab > Authentication > LDAP
   2. In LDAP Realms, click on "New".
   3. Give it a unique realm name, such as SSL_Auth.  Select what kind of LDAP server this is (AD, eDirectory, iPlant, or Other) and enter the server's IP address that can respond to LDAP queries.  Click OK and then Apply.
   4. (Optional)  Click on the LDAP Server tab and enter an "Alternate Server Host IP address" in case the server given in step 3c above is down.  Click Apply to save your changes.
   5. Click on the LDAP DN tab.  For realm name, select the new realm name that you gave it in step 3c above (i.e. SSL_Auth).  You will want to add a base DN (or multiple base DNs) here.  You may want to check what is in the nonSSL_Auth realm and see what base DN(s) are in that realm.  Make sure they are the same.  Click Apply.  NOTE:  For eDirectory, make sure the server listed and the base DN(s) exist as actual replicas on that server.  Don't point the ProxySG to an eDirectory that only has sub-refs.
   6. Click on the LDAP Search and Groups tab.  View the contents that are in the nonSSL_Auth realm and copy them to your SSL_Auth realm.  NOTE:  If you are not performing anonymous binds on your system, make sure you enter a password using the "Enter Password" button on the interface.  Failure to do so will cause SSL LDAP searches to fail.  Click Apply.
   7. Select "LDAP General" tab.
      1. In the "Realm Name" drop down list, select the realm you just created (SSL_Auth).
      2. In the "Virtual URL" section, enter an "HTTPS" URL, such as https://bluecoat:4433 . 
      3. This URL may have a different name, but it MUST be "https" and it must use port 4433.
      4. This URL (bluecoat) must be resolvable to the ProxySG's IP address, either by DNS or hosts file.
      5. NOTE:  If you are using IWA for non-SSL traffic, then you will have at least two realms created.
         • SSL_Auth - Which will have an "https" virtual URL
         • nonSSL_Auth - Which will have an "http" virtual URL
      6. NOTE:  You will also be creating two separate rules in policy (step 8 below).  One for each realm triggering off of the destination port.  If you can be more inventive or have different needs, then the policy below can be modified.  Just make sure that your policy works for what you want to do.
4. Verify Transparent Proxy Setup
   1. Go the Configuration tab > Authentication > Transparent Proxy
   2. The actual authentication method here is your preference as either will work.  However, this example uses "cookie" and "session" as it is more secure than IP.  Be sure to remain consistent with your choice throughout the setup.
5. Download a ProxySG certificate as a CA certificate and import it into your web browser.
   1. Go to the Statistics tab > Advanced > SSL > Download a ProxySG Certificate as a CA Certificate
   2. Click either "default" or the keyring you chose to use and create.  Whatever you choose, it must be the same one as the one that you chose in step 2c above.
   3. Choose Open and follow the prompts to import the certificate into your browser.  NOTE:  This step is to avoid getting a prompt concerning an untrusted CA from the web browser.  Since this CA is generated by the ProxySG, the browser will not automatically trust it.  Once installed into your browser, you can push this CA to all your clients via workstation manager.  It will work without this step, but users will get prompted about the CA.  You can use your discretion.  You can import a trusted certificate to the proxy and use that in the configuration.  The idea is to be sure the web browsers trust the certificate and do not prompt the users.
6. Create an SSL Intercept Policy
   1. Go to the Configuration tab > Policy > Visual Policy Manager > Launch
   2. Click on Policy > Add SSL Intercept Layer..."
   3. Right click "Action" and choose "Set" and then click "New".
   4. Set SSL Forward Proxy
   5. Intercept as HTTPS
   6. Issuer keyring (either "default" or the one that you used in step 2c above.
   7. DO NOT select "Intercept only on exception".
   8. Click on OK > OK > Install Policy
7. Create an SSL Access Layer
   1. With the VPM still open, click on Policy > Add SSL Access Layer..."
   2. Right click "Action" and choose "Set" then click "New".
   3. Server Certificate Validation
   4. Disable Server Certificate Validation
   5. Click on OK > OK > Install policy.
   6. NOTE:  Disabling server certificate validation is an optional step and is suggested for initial testing as a way to simplify deployment by avoiding issues with server certificates.  You may change this later once you have validated everything is working as expected.  Then if you do have failures, you can focus on server certificates as the most probable cause.
8. Add a rule to the Web Authentication Layer
   1. Click "Add Rule"
   2. Right click "Destination" and choose "Destination Host/Port" and then enter 443 for the port.
   3. Click on Add > Close > OK.
   4. Right click "Action" and choose "Set" and then click "New" and "Authenticate".
   5. Select your realm (SSL_Auth) and change the mode to "Origin Cookie Redirect", or "Origin IP Redirect", if you have chosen to use IP as your Transparent Authentication Method.
   6. NOTE:  This document assumes you have a working LDAP realm for "non-SSL" traffic (the nonSSL_Auth realm in this example).  However, you may need to modify this rule to be sure to intercept and authenticate with the correct realm.
      1. Be sure the destination portion of the rule is set to intercept only non-SSL traffic.
      2. HTTP example
      3. Click on "Add Rule"
      4. Right click "Destination" and choose "Destination Host/Port" and then enter 80 for the port
      5. Click on Add > Close > OK
      6. Right click "Action" and choose "Set" and then click "New" and "Authenticate".
      7. Select your realm (nonSSL_Auth) and change the mode to "Origin Cooke Redirect, or "Origin IP Redirect", if you have chosen to use IP as your Transparent Authentication Method.
   7. Install Policy
   8. You will not have two rules that look similar to the following....

<Proxy>
url.port=80 authenticate(nonSSL_Auth) authenticate.force(no) authenticate.mode(origin-cookie-redirect)
url.port=443 authenticate (SSL_Auth) authenticate.force(no) authenticate.mode(origin-cookie-redirect)

9.  Be aware of other devices that may need to be modified for use with port 4433, such as WCCP.  Also, if the ProxySG is behind a firewall, port 4433 will need to be opened.
10. TEST!

SSL AUTHENTICATION WITH BYPASSED SITES

This is the example policy that needs to be in place if you are bypassing certain sites for SSL interception and are doing SSL authentication.  The key elements are in blue.  This is an example that shows bypassing sites categorized with "financial services".  Your specific policy may vary, but hopefully this will provide some idea of what needs to be done.