>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
