2 Way SSL implementation

I believe I understood you.

You're correct, that the client possesses a public certificate and private key, and the private key is never exposed. 2-way (client certificate) authentication involves 3 additional messages in the TLS handshake:

• The server says, "Certificate Request"
• The client responds with , "Certificate",which contains the certificate and public key)
• The client follows that with, "Certificate Verify", which is digitally signed hash (a hash encrypted with the client's private key).

The server uses the client's public key to validate the hash, thus authenticating the user. Server authentication always happens, and is a basic function of the TLS handshake. To configure 2-way TLS on a BIG-IP, you simply need the following:

• A standard client SSL profile with the server cert and key
• Client Authentication in that client SSL profile set to 'request' or 'require'
• Trusted Certificate Authorities in that client SSL profile set to the issuer (i.e. chain) CA of the client's cert. This certificate, or certificate bundle, is used to validate/trust the client's certificate and is absolutely required.

The tricky part is going to be doing 1-way and 2-way TLS on the same VIP. Normally you can apply multiple client SSL profiles with different certs and Server Name (SNI) values, but those profiles can't have different client authentication settings. It'd be far easier to separate this into separate VIPs, each with a different client SSL profile. Otherwise, if you're making the SSL auth decision based on the source address, you can switch the client SSL profiles in an iRule. If you have to make the decision based on the hostname, it gets more complicated.