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?
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.
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.).
Introduction This article will help you understand the steps on how to
download the UCS licenses from the Cisco Systems website and then
installing it on the UCS. The redacted (blue lines) just covers up
certain numbers for privacy please do not take them...
Introduction This article will help you understand and educate the
customer on how to clear their "expired licenses"
(license-graceperiod-expired) from their UCS-M. If a customer just
purchased a license and needs a step by step guide on how to download
==================== VIC FNIC driver does not support Virtual Volumes (
second level LUN ID ) An enhancement request has been created to track
this feature - CSCux64473 UPDATE - 12-14-2016 We made some traction on
the enhancement request - The Fix is in t...