Forum Discussion

Danny_Arroyo's avatar
Jul 13, 2022

Does the F5 LTM communicate securely to a pool member that has a self signed certificate?


We have a HA pair of i2600 LTMs running  We want to ensure end to end encryption for all our Websites.  We currently have our F5 presenting Trusted public certificates client side.  On the server side, we have 10-year self-signed certificates (generated on each pool member - not on the F5).  The idea is that our pool members do not face the internet and are not contacted (by clients) directly, so a self-signed certificate should be enough.  Before 10 years, we wouldve rebuilt the pool member on an updated OS and also to avoid having to update each pool member's certificate yearly.

That said, i have some questions about the scenerio described above.

1. Currently for all our VIPs serverside communication, the F5 is communicating to the pool member(s) over the secure port (mostly 443, 8443 and some other random ports based on the application).  Is this traffic from the F5 to the pool member(s) actually encrypted and secure?

2. Is this common practice? 

3. Should I be handling this a different way?  If so, can someone provide a more secure scenerio

Thanks in advance

6 Replies

  • 1. Yes, it is encrypted and secure.
    2. Yes, it is common and much better than plain text if you need some server-side protection. The TLS algorithms already provide a good level of security even if someone is able to get hold of the encrypted traffic.
    3. I'm not sure about your set up but when you configure an HTTPS monitor, you attach a Server SSL profile to it. You can then add your self-signed certificate to BIG-IP's  "Trusted Certificate Authorities" so BIG-IP can trust your self-signed server certificate and set "Untrusted Certificate Response Control" to "drop". Set "Server Certificate" to "Require" so that BIG-IP can validate your server certificate and add your server's CN to "Authenticate Name". For more information you can check this link here. I also have an article on TLS authentication mostly for client side but the fields are quite similar with examples so you can understand it more in-depth.

    Let me know if you need further help.

    • Danny_Arroyo's avatar
      Icon for Cirrus rankCirrus

      Rodrigo_AlbuqueThanks for your response.  I should've included how we create our VIPs.  This is a standard VIP that we configure:
      1. We configure an HTTP and HTTPS VIP.  The HTTP VIP has a policy to redirect to HTTPS
      2. We configure the HTTPS VIP as a Standard VIP with a ClientSide HTTP Profile, Clientside SSL Profile and ServerSide SSL Profile.  We use "Auto Map" and all other settings are default.
      3. The Clientside SSL Profile has a custom profile with the "clientssl" set for the parent profile, Trusted certificate with a custom cipher group.  The ServerSide SSL Profile has a custom profile with the "serverssl" set for the parent profile, "Default" for the cipher suite and "Trusted Certificate Authorities" set to "ca-bundle.crt".  We do not add any of our self-signed certs to the Big-IPs "Trusted Certificate Authorities".
      4. On the "Resources" tab, we have the pool (configured to use the SSL port on the pool member), Default persistence Profile is "cookie", fallback persistence Profile is "Source_Addr"

      So given our setup, are we still secure?

      I did not know about item #3 you listed.  I will look into implementing this in a test VIP to see how it works and then go from there.  What will this actually do for us that is not happening today?

      • StephanManthey's avatar
        Icon for MVP rankMVP

        As mentioned in my previous answer, it is important to setup the https monitoring properly.

        It might happen, that your (bigd) https monitor marks the poolmember as up while the (tmm) traffic breaks.

        This comes by the default monitoring behaviour (handled by bigd) which is not validating the server (poolmember) certificates, even if you assign a specific serverssl profile.

        Please make sure to enable the In-TMM monitoring for proper server cert validation.

  • In addition to the reply of Rodrigo_Albuque (👍) I would like to point out the usage of a serverssl profile in a https monitor.

    For using SNI and certificate validation it will be required to enable the In-TMM monitoring as described in K11323537: Configuring In-TMM monitoring 

    Without (globally) activated In-TMM monitoring the default serverssl profile settings apply and your server certificate will not be properly validated.