Does any commercial CA still issue client certs? Most of them got out of this business because the liability for them outstrips the revenue benefit.
While it makes sense to have server certs issued by a commercial CA, why would you even want client certs signed by a commercial CA? When you are both the RA and the CA, you may control any opaque identifier you wish to bake into the cert. And you may have your own protocol for verification of identity, whereas the only thing the cert attests to in the case of a commercial CA is possession of the private key and binding to (usually) an email address, since that's how the workflow assures the identity. - M On Sun, Jun 26, 2011 at 11:39 AM, Leo Richard Comerford <leocomerf...@gmail.com> wrote: > Hello. > > I'm looking at setting up a service using OpenSSL with client certs > signed by one of the (fairly-)big-name "browser cabal" commercial CAs. > But (as normal) I only want to allow certain, authorised clients to > connect, not anyone with a valid certificate from the commercial CA. > So after verifying the client cert against the trusted CA cert(s) I > have to check that the client is in the subset of authorised clients. > Instead of having a second form of identification like a > username/password, I would like to use the client cert for this > authorisation step too. So I would like to make use of a whitelist of > the certs of authorised clients. > > What should I use to whitelist certificates by? Specifically, what can > I whitelist on to prevent false positives? For example, the obvious > thing seems to be Distinguished Name. But can I safely assume that any > two certificates issued by a big-name commercial CA to two different > entities will have different (full) DNs? More precisely, is it safe to > assume the same thing about any two certs, issued to different > entities, which *pass verification by the CA cert(s) of* that big-name > CA? - viz. the cross-signing "spaghetti of doubt" and so on. If the > answer is 'no' - if DN (or DN alone) won't guarantee uniqueness under > those circumstances - is there some other field, or combination of > fields, which would? DN plus Issuer? SubjectAltName? > > Obviously by using a commercial CA in this way I'm placing a certain > amount of trust in that commercial CA. I'm willing to take the gamble > that the CA won't deliberately betray me, and that it won't screw up > in some new and unexpected fashion. But if there's some way in which > big-name CAs are known to routinely screw up which makes > identification by DN (or whatever) unreliable then of course I'll have > to protect myself against that. > > Finally, I'd much rather avoid rolling my own if possible. If there's > some well-established utility or script (or even a cheat-sheet) for > doing what I'd like to do then I'll happily adopt that; I just haven't > been able to find any yet. Similarly, if what I'm trying to do is > impossible or too bloody hard then I'll happily take 'no' for an > answer. But at the moment I'm just at a bit of a dead end, unsure what > my options are (or aren't) - any advice would be much appreciated. > > Leo Richard Comerford. > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
