2 Way SSL implementation

Sure.

1. Install the chain (subordinate CA) certificate
2. Install the web server certificate and private key
3. Create the client SSL profile
   • Certificate Key Chain: web server cert and private key. You can optionally include the chain cert if you want the F5 to pass this CA cert to the client during the TLS handshake, to help the client do validation in case the client doesn't have this CA cert. This only works for subordinate CA certs.
   • Client Authentication - Client Certificate: request or require. The difference is that request makes the request but fails open if validation fails. Require fails closed.
   • Client Authentication - Trusted Certificate Authorities: select the chain cert. This subordinate CA is used to validate/trust the client's certificate
4. Bind the client SSL profile to a virtual server

This is the absolute simplest and minimal requirements for 2-way (mutual) TLS authentication.

I think you didn't understand me. I have a virtual server ex. 10.0.0.10. I have 2 sites on it. I configure one way ssl for my VS:created sslclient profile, added certificate, key, chain and bind it to my VS. Now I want to configure 2 way ssl for this VS, when we need the public certificate only. customer sent me a certificate and chain certificate - 2 files only. (we need only client authentication with certificate, where it is not required the Key, because we need to trust only the public certificate that client send to us the key (private key) remains always to the certificate owner, never exchange them) What Must I do with those certificates, how to configure them, web site certificate and chain certificate

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.

Thank you for your support!

Hi Kevin, please provide me one more help :). How to do below steps: 1.Install the chain (subordinate CA) certificate 2.Install the web server certificate and private key

Point 2 refers to the 2 way ssl only or is it general requirement?

Thank you!