question on SSL mutual authentication on CSS

cvancampenhout · ‎03-02-2010

Hi,

I have currently an urgent request from a customer to setup an SSL content with mutual (also called client) authentication.

From the documentation, I can find out how to activate the client authentication on the SSL server, how to setup trusted CA certificates in the CSS, how to forward certificate items into the header towards the backend server, which actions to take if authentication fails,etc,etc...

However, what is not documented (and I can not find any configuration/command example eiter) is how the CSS identifies a particular client from another. I do not want to accept any client that has a valid (and trusted) certificate, only the specific clients that I know of. Is there any kind of "whitelist" configuration possible to obtain this behavior, or is the CSS not able to do real client (mutual) authentication?

thanks,

Carl Van Campenhout

PS current webns version sg0820303

Gilles Dufour · ‎03-02-2010

Client authentication is the process of certifying a client is really who he claims to be.

This is done by validating the certifacte of the client with the certificate authority.

What you want is some client "filtering" function.

This is not possible on any loadbalancer I know of.

You should see if the server can use the info inserted in the http header to determine the client and decide to accept the connection or not.

Gilles.

cvancampenhout · ‎03-02-2010

Hi Gilles,

thanks for your reply so far.

So if I understand correctly: 2 webclients, each with their own valid certificate (and signed by a CA that I trust, not being expired, valid key-pairs,etc, etc) can access my site? Correct?

It also effectively means that I can not limit access for one, and allowing it for the other at the same time, without doing additional checks (via http header insertion) on the backend server? Correct?

Are there no possibilities by using CRL lists (some kind of inverse logic with wildcards to "deny all" and "exceptions" to allow only specific certificates )?

Or would the following work ?

- the client would create a CSR

- I would sign it with my own private CA and return the cert to the client

- client installs the cert in his application (not sure if he would need to trust my CA for any reason, otherwise he can install my CA cert in his trusted list?)

- I would trust my private CA on the CSS

In this case, I would presume that this would be the only client that is able to connect, as it passes the "CA trust test" on the CSS?

Note that this is a specific deployment for a bank, with very few clients, so above scenario would be manageable to deploy.

thanks,

Carl.

Sean Merrow · ‎03-02-2010

Hi Carl,

Just to add to Gilles comments.

If you are using a public CA on the CSS, such that any Internet user can get a certificate issued from, then any of those Internet users will successfully authenticate using mutual authentication. This is how SSL authentication is designed in that it doesn't care what the user (or Subject) name is. It is all based on trust.

One thing you may be able to do is to have the fields of the SSL certificate inserted into the backend HTTP header, then use one or more backend clear-text content rules each with a unique header-field group under the content rule to look for a specific Subject Name. If the Subject Name does not match any of the header-groups, then it will not be load balanced. However, this will not scale well at all and would only be practical if maybe you had a small number of clients (ie. proxy servers) making the connections to the VIP, rather than many end users.

If you are using a private CA to issue client certificates, then you would also be able to maintain a CRL containing a list of certificates that have been revoked. The CSS can check the CRL for revoked client certs and this way only allow those that haven't been.

Another option would be to do what Gilles suggested, which would be to have the CSS verify trust and that the client's cert hasn't been revoked, but leave it up to the server to authenticate the actual username against some sort of database (ie. Active Directory, LDAP, etc.).

Hope this helps,

Sean