There are three methods of SSL proxying on the ACE; SSL Initiation, SSL termination and end-to-end SSL. In this article I am covering SSL termination.
This method makes the ACE do the heavy lifting. Extra CPU cycles to encrypt/decrypt SSL traffic are offloaded to the ACE. In the tests that I have done in our development environments–it has given us, on average, a 10% overall performance increase vs. doing end-to-end SSL encryption with IIS 7.
In this case, the backend servers (IIS, Apache, etc.) do not have certificates on them. They are running port 80 (or any other cleartext port) behind the ACE. The default gateway will be either the ACE (one-arm mode) or the firewall (bridged mode) for your hosts.
NOTE: Some applications will send redirects out to the web-clients. If these redirects are not intercepted by the ACE and changed to HTTPS, it will redirect your clients to a port that is most likely not open on the firewall. I wrote an article that covers that issue here.
The only caveats with this methodology is that your clients do not have requirements against traffic being clear-text on the local network. No un-encrypted traffic traverses the Internet, but some customers and certifications do not allow any clear-text transmission of data.
Do all your serverfarms need SSL or do just a few need SSL? Take note of what needs SSL at this point. For my example my SSL serverfarm is as follows:
serverfarm host FARM-SSL rserver SRVR1 inservice rserver SRVR2 inservice rserver SRVR3 inservice rserver SRVR4 inservice
Generate & Import Certificates
I covered how to do this on a previous post. You can find it here.
Create a VIP for SSL Traffic
What IP will you NAT on the firewall for SSL traffic? Pick one now.
class-map match-any CLASS-IP-SSL 2 match virtual-address 10.100.1.100 tcp eq https
Create SSL Proxy
You created your key, imported your certs and configured your chaingroup already right? If not follow the steps above.
ssl-proxy service SSL-PROXY key MYKEY cert My-CERT-2012 chaingroup MYCHAIN ssl advanced-options CIPHER
Easy right? I find this easier than Windows once you get the hang of it.
Create Policy to match Serverfarm
Now you want to create a policy that defines what serverfarm(s) are going to be behind the SSL proxy. In our case we only want one. If you had multiple you would simply add the class-maps under this policy.
policy-map type loadbalance first-match POLICY-SSL class class-default serverfarm FARM-SSL
Put it all together
Write your policy-map that puts everything together that you can assign to an interface.
policy-map multi-match VIP-SSL class CLASS-IP-SSL loadbalance vip inservice loadbalance policy POLICY-SSL loadbalance vip icmp-reply
Assign it to an Interface
In my case I have VLAN interfaces for bridged mode. So I assign it to both, one so the firewall can NAT it and one so the clients can hit the VIP.
interface vlan 100 description Server Side VLAN bridge-group 1 access-group input PERMIT-ALL service-policy input VIP-SSL no shut interface vlan 200 description FW Side VLAN bridge-group 1 access-group input PERMIT-ALL service-policy input VIP-SSL no shut interface bvi 1 ip address 10.100.1.253 255.255.255.0 description ACE IP Address no shutdown
That’s it! Now you should be able to hit your VIP IP from your server subnet and it should load the site with SSL. If it doesn’t, check your serverfarms, gateways, listening ports on the hosts, etc.