Using ServerSSL Profiles

If you want to use HTTPS on the backend, you'll need to set up your web servers to allow for https traffic and set up a certificate on them. Then you'll need the serverssl certificate set on the F5 (and pool members to use port 443).

If you want, you could use self-signed certs internally or a cert from a CA. For the serverssl profile, you could simply assign the default serverssl cert, or you'd have to install an additional one and create a new serverssl profile to use.

The server need to have certificates on them, however they do not need to be same certificates that you use in the SSL client profile.

When you do SSL offload and you have and you want to use SSL between the F5 and the servers there are 2 SSL connections:

END USER <--- SSL1 ----> F5 <--- SSL2 ---> Web Server

Between the End User and the F5 the F5 will use the SSL client profile. Here you should use a certificate that is signed by a well known CA.

Between the F5 and the Web server you can use the same certificate, or you could use a self signed certificate. No matter what you do the Web server will need the private and public part of the certificate installed on it. One advantage of using a self signed certificate is that you can make the expiration date as far out in the future as you want and thus you don't need to replace/update the certificate that often if ever.

In reality, are there any benefits to letting the F5 perform all these functions? Why not just put certs on the servers themselves and let the F5 acts as a pass through?

Some benefits: Certificate management and its cpu intensive. Hence the need to offload to a F5 server.

One benefit of this, shown through the recent flood of SSL-related security vulnerabilities, is that a lot of applications, legacy applications in particular, could not handle these situations quickly enough, if at all; with SSL-bridging on the F5, you can just fix it on the client side on the F5 through a vendor hotfix or an upgrade to close off the holes, allowing plenty of time and options for yourselves to decide what to do with those applications.

One simple way to understand how this works is to think like this:

1.

The end-user connects to F5 as the server, and F5 has to present an SSL certificate to prove its identity to the end-user. You need to do everything right here to offer top security.

2.

The F5, as a client, connects to the application server, and the application needs to present an SSL certificate to prove its identity to fulfill the requirement of the SSL protocol.

There is a lot of flexibility in 2, depending on your security requirement. If all you need is only encrypted traffic, you can just use a self-signed certificate on the application server. The default serverssl profile on F5 is configured to ignore certificate checking.

Passthrough and ASM:

For any intelligent use of ASM, you need to have visibility to Layer 7 traffic on the client requests (and responses).

In case of ssl encrypted traffic from the clients, you need to terminate the client ssl connection at the BIG-IP for the ASM to be able to see the Layer 7 traffic - and function as an application level firewall/protection device. You can the re-encrypt the traffic at the server side of the BIG-IP to the servers if required. Return traffic goes just the reverse.

If you just do the passthrough without ssl termination at the BIG-IP, the ASM cannot see Layer 7 stuff and you could as well revert to use normal L2-4 firewall instead of the ASM application level firewall.