cancel
Showing results for 
Search instead for 
Did you mean: 

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

Danny_Arroyo
Cirrus
Cirrus

Hi.

We have a HA pair of i2600 LTMs running 15.1.2.1.  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 6

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.

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

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.

Thanks for this information Stephan.  I was not aware of this either.  I will read through the link you provided and get this implemented.

However, based on the standard configuration of our VIPs on the BigIP (that I listed in my last reply), are we still doing end to end encryption?  I am concerned because currently, we dont add the self-signed certificate to the BIG-IP's "Trusted Certificate Authorities".  And from what @Rodrigo_Albuque mentioned it means that the self signed cert is not trusted.  Therefore is our traffic from the BigIP to our Pool members secure?

I guess, you don´t have activated the setting of Server Authentication : Server Certificate == require in your serverssl profile. So the ca-bundle.crt in the Trusted Certificate Authorities setting will be simply ignored.

It would be required to add the self signed server certificates to a certificate bundle and use it at Trusted Certificate Authorities. If you now modify Server Authentication : Server Certificate from "ignore" (default) to "require" you should be safe.

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.