On Sun June 26 2011, Leo Richard Comerford 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. >
Duh... I don't think directly from what any client has vs what some client might have. But you also seem to post that you want something easy to maintain without doing all the heavy lifting yourself. Why not make your "whitelist" a list of acceptable to you clients which hold an OpenID that is on the whitelist? If you haven't used OpenID yourself, here is a one-of-many examples: One time sign-up, free, with option that IDs both holder and browser copy: https://pip.verisignlabs.com/ You might want to use the "learn more" link. If you don't have an OpenID (from any provider) - get one to see the process. So you sweet talked your site user into getting an OpenID from someone - Now the first time an "acceptable to you" client uses your site, go through whatever is an appropriate "registration" procedure for you. Accept __only__ an OpenID from the client registering, add to whitelist. Each additional time a potential client wants to access your site, accept only the input of an OpenID (looks like an e-mail address). Check if that OpenID is on your whitelist - If so, do the logic to pass off the verification of this person to one of the OpenID servers - The response from that server will tell you if the client is an authorized user of that OpenID or not. Grant access to your site/service based on the OpenID server response. Note: All you do is: Run a one-time client "registration"; Maintain a "whitelist" of the OpenID of registered clients; Pass off authentication of client to OpenID server; Grant/Deny site/service access based on server response. Note 2: Many common site packages accept OpenId and can be set to require OpenId __only_ (for other than registration). All you have to do is track the "whitelist" of registered OpenIDs (which some site packages already have those tools for you). Mike > 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
