Forum Discussion

Anurag_384242's avatar
Anurag_384242
Icon for Nimbostratus rankNimbostratus
Feb 20, 2019

F5 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 ?

 

BIG-IP
BIG-IP DNS
security

4 Replies

Sort By
  • Stephane_Viau's avatar
    Stephane_Viau
    Icon for Nimbostratus rankNimbostratus
    Feb 20, 2019

    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.

     

  • Anurag_384242's avatar
    Anurag_384242
    Icon for Nimbostratus rankNimbostratus
    Feb 20, 2019

    Thanks 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's avatar
    Stephane_Viau
    Icon for Nimbostratus rankNimbostratus
    Feb 20, 2019

    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.

     

  • wlopez's avatar
    wlopez
    Icon for Cirrocumulus rankCirrocumulus
    Feb 21, 2019

    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.