>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
