Dear openssl group, could you solve this issue regarding mod_ssl? Michele Masè
On Thu, May 23, 2013 at 10:11 AM, Michele Mase' <michele.m...@gmail.com> wrote: > 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 > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
