I want to understand how a F5 Load balancer decrypts the SSL traffic received from a client say a browser and then re-encrypts it before sending/forwarding the same to an Application Server in an enterprise network. The reason for asking this question is that, In our internal network the communication between the load balancer and the application server is secure. Recently we renewed the Certificate on the application servers. It was a self signed certificate. Ideally a Client e.g. F5 LB will at least need the Root CA of this Certificate to be able to trust and communicate to the endpoint like Application Server over SSL. This is how I have seen mostly in all the Client-Server communication over SSL so far. Surprisingly F5 LB was able to communicate to the Application Server over SSL, even when there was no Root CA present in the Trusted Store of F5. So how is this possible and how F5 does the re-encryption of traffic before sending it over a secure network ?
The client-ssl profile manages the SSL settings between the client and the Big-IP, and the server-ssl profile manages the SSL settings between the Big-IP and the server. The default server-ssl profile ignores SSL certificate warnings, which is why you were able to use a self-signed certificate on your server. You can create a custom server-ssl profile if you wish to accept valid certificates only.
There are multiple ways to do that on the Big-IP, but in most cases you probably want the valid certificate and its matching private key on the Big-IP, and then you can have a valid or self-signed certificate and its matching private key on the backend server.
Encryption between the client and the Big-IP will use the certificate hosted on the Big-IP, and encryption between the Big-IP and the backend server will be done using the certificate on the backend server. In this scenario the Big-IP acts both as a server and a client.
The client ssl profile manages the communications between the users and the F5 virtual server. It's that side's configuration that the users will see, so you'll want a valid certificate for that profile with it's corresponding issuer certificate. On that profile the F5 plays the role of server to the users.
The server ssl profile manages the communications between the F5 and the pool members. On that profile the F5 becomes the client and the pool members act as the servers. The default serverssl profile will ignore certificate warnings (issuer, expiration, common name mismatches) by default.
Since both profiles (clientssl, serverssl) are independent from the other, you can adjust the settings to whatever scenario you're dealing with.