"If these are the roots you attached -- with names that differ only in case of one letter -- they should have gotten the same hashvalue (with suffixes .0 and .1); did they?" yes
"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 "The certificates you attached are CA roots and have no AKI. AKI can/should be on the *child* certs i.e. your client certs. (The root has *SKI*, which the child AKI normally uses.) But as I said AKI won't fix this with openssl, which uses AKI only as an added check not as a way to select among parent certs." pardon, my mistake, I forgot to send the clients certs :( "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 RFC3280 - is it correct? 4.1.2.4 Issuer ... This specification requires only a subset of the name comparison functionality specified in the X.500 series of specifications. Conforming implementations are *REQUIRED* to implement the following name comparison rules: (a) attribute values encoded in different types (e.g., PrintableString and BMPString) MAY be assumed to represent different strings; (b) attribute values in types other than PrintableString are case sensitive (this permits matching of attribute values as binary objects); (c) *attribute values in PrintableString are not case sensitive* (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and (d) attribute values in PrintableString are compared after removing leading and trailing white space and converting internal substrings of one or more consecutive white space characters to a single space. As attachment, there are the client certificates I used. s_server.out is the output of the openssl s_server command. 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? Best regards Michele Masè On Sat, May 18, 2013 at 12:20 AM, Dave Thompson <dthomp...@prinpay.com>wrote: > >From: owner-openssl-us...@openssl.org On Behalf Of Michele Mase' > >Sent: Friday, 17 May, 2013 10:04 > > >What I did: > > >openssl: > >Commandline for the openssl s_server (sorry for my typo) > >before starting www server: > >c_rehash /some/path #where I've put 2 pem encoded CA's certificates > > If these are the roots you attached -- with names that differ only > in case of one letter -- they should have gotten the same hashvalue > (with suffixes .0 and .1); did they? > > >start the simple www server > >openssl s_server -www -key /some/path/file.key -cert > >/some/path/www.example.com.crt -CApath /some/path -state -verify 10 > > >and testing it with any client (ie firefox) it finally works! > > 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)? > > >apache + mod_ssl > >No one version worked for me: 2.2.x - 2.4.x (openssl 0.9.8.x - > >openssl 1.x) in various linux configurations (centos[56], ubuntu 13.04) > > Not surprising. This logic hasn't changed in openssl for a long time, > and is the same no matter what program calls it unless the caller > overrides openssl's lookup and/or chain validation. > > >apache + mod_gnutls (have to try it) > > >"It could also be using AKI in chain build, if you have it in > >your certs (I didn't try to go through your script to see). > >OpenSSL *checks* AKI if present but doesn't use for lookup." > > >I attach the original certificates; AKI seems to be ok. > >But this not solves my problem. > > The certificates you attached are CA roots and have no AKI. > AKI can/should be on the *child* certs i.e. your client certs. > (The root has *SKI*, which the child AKI normally uses.) But > as I said AKI won't fix this with openssl, which uses AKI only > as an added check not as a way to select among parent certs. > > >The solution(s) - all put in or (exclusive mode): > > I don't know what "exclusive mode" means here. > > >1) hack mod_ssl or wait indefinitely somebody will do it :( > > The chain validation logic is in openssl. You or someone > would have to change openssl, or else change mod_ssl to > replace (override) at least the lookup logic in OpenSSL > and probably the whole chain validation (because I think > the lookup logic uses already canonicalized DN). > > >2) use mod_gnutls > > If, as I said, GNUTLS can handle the name-matching differently > and nonstandardly. I don't know if it does. > > >3) put 2 virtualhosts under apache+mod_ssl using two different > >cacertifcatefile filename.pem (I must change the server name) > > Different virtualhosts each with one CAroot would work. > > Remember for name-based virtualhosts with SSL your clients must > support SNI (ServerNameIndication), and you must not have a very > old mod_ssl or openssl (about 2 years ago IIRC). For IP-based > you need multiple addresses *or* you must get at least one part > of your clients to use a nondefault port. > > And for any virtualhost approach you need DNS entries, and your > users must use/select the correct servername (for their CA). > > >4) use IIS (fool) > > Some people like IIS, but YMMV. > > >5) change the issuer DN in CA's > > For a root cert the issuer and subject must be the same, > thus both must change together. But: > > >Some details: > >Unfortunately those (bad) CA's are provided by a thirdy part. > >They sign a tons of smart cards. > > If it's someone else's CA(s), and their roots, only that party > can make the change. This look like a new generation (2012-2032 > superceding 2006-2018) and you might point out to them that > established major CAs like GeoTrust Verisign Thawte use > distinct names for new generations. You might also check if > cabforum or similar authority has anything to say about this. > But even if the CA changes now, there's presumably some population > of certs (and cards) already in existence; see your next points. > > >Sould I ask (force) them to make new brand smart card using another CA? > >Could I oblige them to replace all the wrong smart card? > > If you can get the users/clients to have and use smartcards > issued by a CA with a distinct name, that solves the problem. > Depending on the smartcard that may or may not be a new card; > it may be possible to issue a new cert to an existing card. > > Whether you have authority or power to force the CA(s) or card > issuer(s?) to do new/updated cards, I have no idea. You can > probably persuade users to get and use a new or updated card > if it's free or very cheap and convenient; if it is costly or > inconvenient it depends on what control or influence you have. > > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >
client2006.pem
Description: Binary data
client2013.pem
Description: Binary data
s_server.out
Description: Binary data
