Okay, openssl works, but mod_ssl doesn't. Is this a real problem? Instead try hacking mod_ssl code ... Could I ask for a bug/improvement so that mod_ssl could finally work?
Michele MAsè On Thu, May 23, 2013 at 1:22 AM, Dave Thompson <dthomp...@prinpay.com>wrote: > >From: owner-openssl-us...@openssl.org On Behalf Of Michele Mase' > >Sent: Tuesday, 21 May, 2013 04:16 > > I was wrong! > > >"Does it work with client=Firefox using client certs under both CAs? > >I would expect at least one to fail. Note that s_server -verify > >doesn't *require* client cert, it only *allows* it; how did you > >check Firefox is actually using your client cert(s)?" > > >I've tested it with both smart card > > I went back and set up a (modified) test and ... I was wrong! > The lookup as such does use the canonical DN and returns only one, > sometimes the wrong one. But I didn't realize X509_STORE_get1_issuer > hiddenly caches *all* the matches and tries them, and (given you > have AKI) *does* select the correct one. So actually your earlier > tries should have worked, or at least not failed for this reason. > > >"The certificates you attached are CA roots and have no AKI. <snip> > >pardon, my mistake, I forgot to send the clients certs :( > > >As attachment, there are the client certificates I used. > > And those do indeed have AKI (correctly matching the roots). > > >"I don't know what "exclusive mode" means here." > >virtualhost1 has the ca's bundle made with all certificates + ca1 (for > smart card1) > >virtualhost2 has the ca's bundle made with all certificates + ca2, (for > smart card2); > >the or (exclusive) means you can try virtualhost1 with smart card1 > >or virtualhost2 with scard2 > > Okay. > > >RFC3280 - is it correct? > <snip 4.1.2.4 about case-insensitive and space-insignificant> > > Actually, 3280 has been superseded by 5280, which has more > complicated rules to handle internationalization using > Unicode and IDN, but for this simple (ASCII) case > boils down to the same thing. > > But, as above and contrary to what I said before, openssl *should* > work for this case after all, which means you don't need the CA > to change, which is probably good. (I think it's still confusing > to people to have almost-identical DNs, but since most people won't > even know how to look at a certificate, that's less of a problem.) > > >s_server.out is the output of the openssl s_server command. > > The only error this shows is that one client cert (and card) -- > I assume client2006.pem -- is rejected for cert expired. > Which it is; the notAfter is Oct 12 23:59:59 2011 GMT. > > >In order to convince the ca's supplier to change the old scard I should: > >1) Show him the rfc > >2) Inform all scard users to stop using the old scard > >3) Give all scard users the new scard > >Are there some better argumentations to persuade the sa's supplier? > > If it were necessary I'd say probably yes, but as above > I don't think it's necessary. Try using cards (certs) > that are under the old "2006" root but NOT expired, > and (now) I'll bet they do work. > > Sorry for the unnecessary alarm and confusion. > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >
