2 way SSL implementation

So by "client authentication" I assume you're talking about client certificate authentication, yes? If so, are you using Access Policy Manager (APM) or just LTM and the client SSL profile? In either case, do you have the client authentication setting set to "request" or "require"?

we are using client SSL profile and selfsigned certificate. on the client ssl profile, when we set the client authentication to "request" or "require", the result is ssl error.

when we set the client authentication to "request" or "require", the result is ssl error.

The self-signed certificate, I presume, is defined in the client SSL profile. This certificate is only really relevant to the client. When the client initiates an SSL session with the server (BIG-IP VIP), one of the first things the server does is send its certificate (the public certificate in the client SSL profile). The client (browser) must then decide if it trusts that certificate by way of a few checks:

1. Is the certificate valid (unexpired, valid attributes)?
2. Is the certificate trusted - can a complete chain from this certificate to a root certificate be established, and does the browser have access (and explicitly trust) the root certificate and potentially all CA certificates in between?

If you use an IP address to access an SSL site, you'll most often get a security warning in the browser that the certificate is not trusted. This is usually because you've violated check 1 above - the name you asked for didn't match the name in the certificate. If you don't have an explicit trust established with the CA that issued the server's certificate, that's another reason for a security warning. In your case, since you're using a self-signed certificate, you'd necessarily have to install that certificate in the browser's trust store to avoid the security warnings.

As for client certificate authentication, you need either the request or require options set in the client SSL profile to be able to prompt the user for a client certificate. They both, more or less, perform the same function - requesting a certificate from the client during the SSL negotiation. The most significant difference is how each deals with what the client sends. You can think of this process as a reverse of the server certificate and browser check process. In this case the server (BIG-IP) must be able to validate the certificate presented by the client. Is it a valid certificate? Can a chain of trust be established between the client's certificate and an explicitly trusted set of CA certificates? The require option is a definitive check. All of the tests must pass. The request option, however, is a "soft" check. It will generally not fail if any of the tests fail.

So given the above, please answer these questions:

1. Just to clarify, with a simple client SSL profile applied to the VIP, no client certificate authentication enabled, you can get to the application via HTTPS://, correct?

    

2. If yes above, do you get a security warning in the browser that the server certificate is not trusted? Or have you installed that certificate in the browser's trust store?

    

3. What specifically happens when you enable the request option in the client SSL profile?

    

4. Do you have any iRules applied to the VIP while testing that are looking for certificate attributes? Are you seeing anything in the LTM logs that may indicate a problem?

    

HI Kevin,

1. Yes, i can access it with client authentication(Client certificate set to "ignore")
2. Yes, at first i get security warning.
3. I stand corrected, if we use "request" we are directed to the application but if "required", it says "page cannot be displayed"
4. no irules and no logs regarding certificates

By the way, we use self-signed and ip address in accessing https://10.164.45.45

Thank you in advance! Ferdz

I stand corrected, if we use "request" we are directed to the application but if "required", it says "page cannot be displayed"

And that makes sense. The client is passing a certificate to the BIG-IP that the BIG-IP MUST be able to validate (given the require option). For the BIG-IP to be able to validate the client's certificate, you must obtain and specify a "CA bundle". If you're familiar with browser's trusted certificate store, this is a bucket of certificate authority public certs that the browser EXPLICITLY trusts - by virtue of their existence in the store. When a server sends its cert to the client, the client browser must validate trust by way of creating a chain from the server's certificate to the issuing CA of that certificate (and potentially the issuing CA of that certificate if multi-level) and terminating at a trusted root certificate. Your self-signed certificate only differs in that it is its own self-signed root, so the browser would NEVER trust this certificate unless it was specifically installed in the browser's trust store. For client certificate authentication, this process is reversed, and the BIG-IP performs the same validity and trust checks that the browser did for the server's cert. The BIG-IP, however, doesn't have a single CA trust store, so each client SSL profile must be given one. If you look in the client SSL profile, you'll see an option for "Trusted Certificate Authorities". This option allows you to select a single certificate (or bundle of certificates) that the BIG-IP can use to establish trust with the client's certificate. If, for example, the client certificate is issued by Verisign, you need Verisign's public CA certificate applied to the Trusted Certificate Authorities option. If you expect to accept clients with certificates issued from multiple CAs, then you can create a bundle file - a text file that contains the PEM/Base64-encoded value of each CA's certificate. Example:

-----BEGIN CERTIFICATE-----
MIIEgTCCA+qgAwIBAgIBAjANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzER
MA8GA1UEChMIdGVzdC5jb20xHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEUMBIGA1UEAxMLY2EudGVzdC5jb20wHhcNMTMwNTAxMDQyMzQ1WhcNMTYwMjE5
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
JIIEgTGGB+qgAwIBAgIBAjANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzER
FA9GB1UEChMIdGVzdC5jb20xHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEU8BIGA1UEAxMLY2EudGVzdC5jb20wHhcNMTMwNTAxMDQyMzQ1WhcNMTYwMjE5
...
-----END CERTIFICATE-----

Put those into a text file and import them like you would a single certificate.

In our case, client don't want to invest on signing certificate to any certificate authority, so what will be the configuration of or ssl profile?

Who has issued the client certificate(s)?

we only used selfsigned certificate of F5.and this certificate should be loaded to client's browser.

Then put that certificate in the Trusted Certificate Authorities option of the client SSL profile. Is it just one certificate for all users?

Yes it is only one certificate for all users.

So, our configuration will be, client authentication "required" then have to put the selfsigned certificate on Trusted Certificate Authorities?