Forum Discussion

Johnny_John_133's avatar
Icon for Nimbostratus rankNimbostratus
Sep 18, 2013

How does F5 LTM re-encrypt data with serverssl profile?



We have an F5 LTM in front of an apache node. Initially, the apache node (listens at port 443) was configured with SSLCertificate and SSLKey to do SSL Termination.


To offload this termination to the F5, the same SSLCertificate and SSLKey was configured in the clientssl on the F5 LTM.


However, our Security team wanted to encrypt traffic between the F5 and the apache node. So, we're now using the default serverssl profile for the virtual server with Server Certificate set to "ignore". So, with this setting, is it correct that we do not require the SSLCertificate and SSLKey on the apache now anymore as the F5 will no longer care about the apache node's identity - no certificate check? Also, with this setting, how does the F5 encrypt traffic to the apache node such that the apache node can decrypt this traffic?


Thank you and Regards Johnny John


3 Replies

  • It really depends on your requirement but leaving the setting to ignore means the system ignores certificates from the server if they present one. Leave it at ignore unless you Require that the server is presenting a valid certificate. If you server is listening on port 443 they still need the SSL server certificate loaded.


    The SSL server profile re-encrypts traffic to the pool acting as a SSL client over port 443. As long as the host name in the request to the VIP matches the Servers certificate it should work. But unless you have a need to inspect the client traffic to make a layer 7 decision or insert an HTTP header like X_Forwarded_For there is no need to terminate the SSL on the F5? You could pass it through your 443 VIP with no SSL client or server profile using a pool with nodes set for port 443.


  • So in short no you cannot remove the certificates from the Apache node. Setting a server SSL profile on the Virtual does not do the encryption for you it just tells the Virtual to expect encryption on the connection and allows for you to setup other options like enforcing certian Ciphers, disabling certian SSL Options or doing client authentication. The encryption of the connection is still dependent on the web server itself to handle the certificate and private key exchange. I am pretty sure that setting a certificate and key in the server SSL profile will send that certificate to the web server to do client authentication.


    In this portion of the connection you can think of the Big-IP as the client.


  • If I may add, an SSL connection always starts with a CLIENTHELLO message - the client's desire to start an SSL session. The client says "hello" and then lists all the ciphers it supports. The server subsequently responds with SERVERHELLO and chooses one of the client's ciphers.


    The server SSL profile, being the client to the Apache server, initiates the SSL session. During that handshake several attributes of the session are negotiated, including cipher strength, the ability to renegotiate, and how to handle various events. You do have some client side control over these decisions in the server SSL profile. There are two sections in the server SSL profile where you deal with certificates. The certificate and key in the main configuration specify the CLIENT certificate that the server SSL profile can send to the Apache server. This is a certificate/key pair installed on the BIG-IP and not the user's certificate/key pair, so it's value here is limited. Under Server Authentication, you can specify how to handle the server's certificate, which is passed from the server during the negotiation. A setting of ignore means that the server SSL profile doesn't attempt to validate the server's certificate (like getting the certificate trust nag screen in the browser). A setting of require means the profile will validate the server's certificate, and you need a Trusted Certificate Authorities certificate (or bundle) to build that trust chain. You can optionally check the server's certificate against a certificate revocation list (CRL).


    As afedden states, you only need the client and server SSL profile if you intend to inspect the layer 7 (HTTP) traffic, or perhaps do cookie persistence. You can otherwise remove both SSL profiles and let the client and Apache server negotiate direct SSL.


    You can also, optionally on v11 systems, do SSL "man-in-the-middle" where the client and Apache server negotiate SSL directly, but the BIG-IP has access to the layer 7 payload.