Forum Discussion
Anurag_384242
Nimbostratus
NimbostratusF5 LB : Decryption and Re-Encryption of Traffic to Application Server
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 ?
Stephane_ViauThe 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.
Anurag_384242Thanks Stephane !
So, is it that the BIG-IP uses the public certificate presented by the Server to re-encrypt the traffic and then pass it on to the Server ?
- Stephane_Viau
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.
wlopezCirrocumulus
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.