Adventures in Networking

Main menu:

Blue Coat SSL Reverse Proxy Setup

Conceptual Overview:

This document describes the steps necessary to deploy a new web application via a reverse HTTPS proxy on the Blue Coat Proxy SG. It involves setting up a virtual IP address on the Blue Coat that is servicing the web servers, and using the proxy to terminate an SSL connection from the client to that address. It will then forward the request to the servers themselves, in a load balanced manner. In order to provide full acceleration from other locations, we will need to set up a SSL intercept on each remote proxy, causing it to intercept the connection and forward it across the ADN to the master that is actually servicing the (virtual) website.

Set up Virtual IP (VIP) Address on Servicing Blue Coat Proxy:

  • Use the Infoblox Grid Manager to choose an unused IP address in the app server subnet, and add a host record with that address and the corresponding URL for your virtual host, such as virtualserver.example.com
    • (I will add a link here to the Infoblox instructions when I post them.)
  • Configuration -> Network -> Advanced -> VIPs
  • Click New, enter the virtual IP address
  • Click OK and Apply to save the configuration
  • You should now be able to ping the virtual IP address by DNS name (ping virtualserver.example.com)

Set up Forwarding Hosts:

  • Configuration -> Forwarding -> Forwarding Hosts -> New
  • Enter the following values:
    • Alias: a simple descriptive name, such as the host name (webserver1)
    • Host: the fully qualified host name (webserver1.example.com)
    • Ports: check HTTP and enter the host server port (in this case, we use 7778 since the web site is hosted on Oracle HTTP server)
  • Click OK
  • Repeat the above steps for each host that will service this virtual host
  • Click Apply to save

Set up Forwarding Group:

  • Configuration -> Forwarding -> Forwarding Groups -> New
  • Enter a descriptive group name
  • Select each host server that will service the website and click Add
  • Click OK and Apply to save

Set up SSL Access Policy in VPM:

  • Configuration -> Policy -> Visual Policy Manager -> Launch
  • Click on SSL Access Layer tab. If this did not already exist, you would add one by:
    • Click on Policy -> Add SSL Access Layer
    • Give it a descriptive name (SSL Access Layer, for example)
    • Click OK
  • Click Add Rule
  • If necessary, use the Move Up or Move Down buttons to change the order of this rule
  • Right-click on the word Any under the Destination column in the rule you just added and select Set
  • Click New, select Server URL
  • Set up your matching parameters and click Add, Close, OK
    • In our current example, we’d use Simple Match, and enter the virtual host URL, virtualserver.example.com
    • Note: You could also create a new Combined Destination Object to create a list of URLs
  • Right-click on the word None under the Action column in the rule you just added and select Set
  • Select Allow and click OK to save

Set up Forwarding Policy in VPM:

  • If not already in the VPM, go to Configuration -> Policy -> Visual Policy Manager -> Launch
  • Click on the Forwarding Layer tab. If this did not already exist, you would add one by:
    • Click on Policy -> Add Forwarding Layer
    • Give it a descriptive name (Forwarding Layer, for example)
    • Click OK
  • Click Add Rule
  • If necessary, use the Move Up or Move Down buttons to change the order of this rule
  • Right-click on the word Any under the Destination column in the rule you just added and select Set
  • Select the same Destination URL that you added under the SSL Access Policy and click OK
  • Right-click on the word Send Direct under the Action column in the rule you just added and select Set
  • Click New, select Select Forwarding
  • Enter a descriptive name (no spaces)
  • Under Forward to:, select the forwarding group you created earlier and click Add, OK, OK
  • Click Install Policy, then close the VPM

SSL Notes:

You have two options to create the SSL private key and your certificate signing request (CSR). The Blue Coat interface is easier to understand, but openSSL is sometimes more compatible. (NOTE: iManager would not issue a wild card certificate from a CSR generated on the Blue Coat, requiring me to use openSSL.)

Create New Keyring and Generate Private Key:

These instructions assume you are creating the key with the Blue Coat management interface.

  • Start by creating a new keyring: Configuration -> SSL -> Keyrings -> Create
  • Enter a keyring name.
    • For all of our internal web apps, we are using a wildcard certificate for (*.example.com), so we use something like wildcard.example.com-key as the keyring name.
  • If you want to back up the private key or use it on any other device, select Show key pair or Show key pair to director. For greatest security, leave it set to Do not show key pair.
  • For all internal purposes, we use 2048 bits.
    • 1024 bits is virtually unbreakable without a supercomputer or large cluster of computers, so it is not insecure, we just use the same number of bits as the default SSH keys on SuSE.
    • If you will be requesting a certificate from a recognized certificate authority, the number of bits should correspond to the certificate product you will order.
  • Click OK, then Apply to save the new keyring.

Generate Private Key with openSSL:

  • (I will insert a link when I post these instructions.)
  • Create a new keyring as described above, but instead of creating a new key, select Import
  • Copy and paste in your private key generated with openSSL

Generate Certificate Signing Request (CSR):

These instructions assume you are creating the CSR with the Blue Coat management interface.

  • Click on the new keyring and click Edit
  • Under Certificate Signing Request, click Create
  • Fill out the fields similar to the following:
    • State/Province: Nevada
    • Country Code: US
    • City/Locality: Las Vegas
    • Organization Name: Examples-R-Us, Inc.
    • Unit: IT Department
    • Common Name: virtualserver.example.com
    • Challenge: (Blue Coat requires an entry, openSSL does not, since this is optional)
    • Email Address: mail@example.com
    • Company: Examples-R-Us
  • Click OK, Close and then Apply. This will save the new keyring and generate the CSR.
  • Click on the keyring and click Edit.
  • Copy the contents of Certificate Signing Request box and save to a file (virtualserver.example.com, for example).

Generate CSR with openSSL:

  • (I will insert a link when I post these instructions.)
  • It is possible to import your CSR into the keyring if desired. This would be handy if you wanted to use the same CSR later to generate another certificate (perhaps with a new expiration date).

Issue Certificate from iManager and Import:

  • (I will insert a link when I post these instructions.)

Set Up SSL Intercept Service:

  • Configuration -> Services -> Proxy Services -> New Service
  • Enter a Name for your service, such as Example SSL Proxy
  • Under Service Group, select the group (this is just for organizational purposes, it’s not a critical step)
  • Under Proxy settings, Proxy, select HTTPS Reverse Proxy from the drop-down
  • Under the Keyring drop-down, select the keyring you created above
  • At the bottom, click New to create a new listener
  • Choose Destination host or subnet
  • Enter the virtual IP address (VIP) you created in the beginning
  • Click OK, OK, Apply to save

If you have done everything correctly, you should now be able to open a web browser and type in https://virtualserver.example.com/ and get your website!

Optional – Set Up URL Rewriting:

The Blue Coat Proxy allows you to re-write the request URL. So for example, you can allow the user to enter a “pretty” URL, and hide the actual request string that is sent to to the host server.

  • Install the re-write policy by going to Policy -> Policy Files -> Install Local File From -> Text Editor-> Install
  • Sample rewrite policy:
  • define action virtualserver_example_com_portal
    rewrite(url, “^https://virtualserver.example.com/$”,”https://virtualserver.example.com/prod/”)
    end

    define action force_uncompressed
    delete(request.header.Accept-Encoding)
    end

    <Proxy>
    url.host=virtualserver.example.com action.virtualserver_example_com_portal(yes)

    <Cache>
    action.force_uncompressed(yes)

Comments

Comment from Alejandro Loza
Time: May 10, 2013, 7:58 am

Great piece!
Your article helped to set up my ACTIVESYNC service.

Thanks

Comment from Dan O'Barr Jr.
Time: May 13, 2013, 7:38 pm

Glad to know I could help. I should get back in the swing of things and post more how-to’s.

Comment from Gustavo
Time: March 11, 2016, 12:29 pm

Good post, and very clear instructions.
I have a question: Can I configure two separate services using two different SSL Certificate? I mean, can I use a wildcard certificate to serve services like http://www.mydom.com, mail.mydom.com and educ.mydom.com using a wildcard certificate, and to serve shop.mydom.com with a named certificate?

Each web service is running on separate servers.

Thank you

Comment from Dan O’Barr Jr.
Time: March 13, 2016, 12:14 am

Yes, that should be no problem at all. Just remember of course that the SSL has to be hosted on separate IP addresses, since at the beginning of the negotiation the host name is not known.