Forum Discussion
danA
Altostratus
AltostratusSSL certificate validation for "virtual" command or "LB::reselect virtual"
If the "virtual <virtual name>" or "LB::reselect virtual <virtual name>" commands are used, my understanding is that there needs to be a client SSL profile on the destination virtual if there are any iRules that might inspect the content.
In that case, are there any trust validations that are done on the SSL cert which is being presented? By observation, it seems like an expired cert is rejected, but is there any certificate name or CA validation? Or will pretty much any cert work? Can that be controlled?
- Kevin_Stewart
Employee
Can you elaborate? Under normal conditions there would not be a client SSL profile applied to the internal target virtual server. The "virtual" command is the "VIP target" function to pass traffic between VIPs on the same box. The target VIP is typically of type "internal" (but doesn't have to be), and would not be performing any decryption (that happens at the external VIP).
danAIn this situation, there is an iRule on the target VIP which has an HTTP_REQUEST event defined. Per https://support.f5.com/csp/article/K95905533, it needs (and has) a client SSL profile. I'm trying to understand how the cert attached to the client SSL profile is (or is not) validated.
- Kevin_Stewart
Well, a client SSL profile on the internal target VIP is the server side of the TLS session. If you have a server SSL profile on the outer VIP, then it's the outer VIP's server SSL negotiating with the inner VIP's client SSL. In a typical one-way-auth TLS handshake, only the client is doing any validation here, so the outer VIPs server SSL profile would be doing that. In other words, you can do whatever you want. The "default" behavior of a default server SSL profile is to ignore validation errors. Look under the Server Authentication section of the server SSL profile to define how it handles server cert validation. If you really want, you can apply a real cert/key at the client SSL profile of the inner VIP, and have the outer VIP's server SSL do full CA trust validation of that cert (with a CA bundle).
But I would possibly suggest that you don't need to do this. VIP targeting is an internal process that can be used for many different scenarios. For example, we often use VIP targeting to get around filter ordering in the BIG-IP proxy hud chain. Access happens before HTTP in the hud chain, so a VIP target would let you do HTTP on the outer VIP (first) before the Access on the inner VIP. Or Access before WAF, etc. Or we use VIP targeting to do traffic steering, where the outer VIP steers traffic to one of multiple inner VIPs performing some unique function. VIP targeting is super flexible and solves A LOT of challenges. That said, it's not generally optimal to do decryption on a target VIP, especially if you're also doing it at the outer VIP. It's better to offload decryption at the outer VIP, steer unencrypted traffic to inner VIPs, and then let the inner VIPs optionally re-encrypt to pool members.
client (HTTPS) -> outer VIP (HTTP) -> inner VIP (HTTPS) -> pool
And in this case, your inner VIP can simply apply its HTTP iRules without needing to worry about TLS.
