For SSL bridging, do HTTPS backends verify that the load balancer is using the same private key? If so, how?

We are using the F5 to perform load balancing. When using SSL bridging instead of termination, we generally use a wildcard on the front-end and a regular SSL cert on the HTTPS backend.

However, there's some belief among some colleagues that, for some applications like MS Exchange, we have to use the same private key in the backend and the load balancer.

I can't wrap my head around how the backend is able to check that what private key the load balancer used. I checked F5's documentation but cannot find anything relevant.

Can someone help me understand?

Update 1: I started with a strong suspicion that this is a misrepresentation of what is actually happening despite the accounts of a couple of colleagues. That suspicion has now been reaffirmed by others. I'll update when I find something conclusive. If anyone else has an idea, please submit.

Update 2: For VMware Horizon, I found a KB article explaining the error received when the certificates do not match. Can I conclude from this that Horizon is doing is implementing it's own check by comparing fingerprints in its protocol?

Solution 1:

So seems like this confusion stems from two places:

1. Some applications use their own method of verifying that any intermediate device (e.g., load balancer) is using the same certificate. For example, VMware's Horizon View sends the certificate fingerprint to the client who then does the verification. This is detailed in VMware's documentation.

2. There's also the case where the load balancer is performing SSL bridging and may be configured to expect the same certificate from the backends as the one it is currently configured to use.

So, in summary, this was just a misunderstanding of PKI and confusion with application enforced requirements and/or load balancer configuration.

Thank you to the folks in r/sysadmin who helped figure this one out.