Tx. for the response. Now I try to explain what I should do ... 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 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! 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) 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 solution(s) - all put in or (exclusive mode): 1) hack mod_ssl or wait indefinitely somebody will do it :( 2) use mod_gnutls 3) put 2 virtualhosts under apache+mod_ssl using two different cacertifcatefile filename.pem (I must change the server name) 4) use IIS (fool) 5) change the issuer DN in CA's Some details: Unfortunately those (bad) CA's are provided by a thirdy part. They sign a tons of smart cards. 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? Michele Masè On Wed, May 15, 2013 at 2:28 AM, Dave Thompson <dthomp...@prinpay.com>wrote: > >From: owner-openssl-us...@openssl.org On Behalf Of Michele Mase' > >Sent: Monday, 13 May, 2013 05:33 > > >I'm testing a client authentication using [Apache with 1.0.0-fips] > >I have 2 CA's x509 pem files, bundled. > >CA1 signs client1 certificate files > >CA2 signs client2 certificate files > > >I should use two different CA with a similar issuer DN_OU > >in a bundle (file /path/to/pemfile.pem) > > >openssl x509 -noout -in one.pem -issuer > ><snip>/O=Example S.p.A./OU=CA Organization Unit/<snip> > >openssl x509 -noout -in one.pem -issuer > ><snip>/O=Example S.p.A./OU=CA organization Unit/<snip> > >The only difference between 2 CAs is the capital letter in OU field. > > You probably shouldn't. According to RFC 3280 and 5280, X.509 > or X.somethingrelated requires matching of Distinguished Name > including child-Issuer to parent-Subject be case-insensitive > and ignore insignificant (leading,trailing,multiple) spaces. > So what you actually have there is one CA with two certs, > presumably with different (public) keys. If so, certs issued > under one can't verify under the other. > > OpenSSL does cert (chain) lookup using canonicalized DN and > takes the first one found, so if you have "canonically-equal" > names like these (which both match) it can only use one. > > >When i try to use this configuration I receive a 403 error: > ><header>AH02261: Re-negotiation handshake failed: Not accepted by client!? > > That looks like a different error or at least a confusing message. > > >The only way it works is without [requiring client auth] or > >Using only one CA in the file (file /path/to/pemfile.pem) > > As expected, see above. > > >But I'm still unable to retrieve client cert data; I don't know > >if the client is authenticated or not. > > I don't know what if anything mod_ssl gives you if it receives > a client cert that doesn't validate. But I would focus on getting > client auth to work first, and then see if you have a problem > with getting the auth result. > > >The same configuration using openssl_server works, it seems like > >an uncorrect (or incomplete) mod_ssl openssl's implementation. > > Do you mean commandline s_server? That shouldn't verify a client cert > that mod_ssl doesn't with the same truststore, but it *will* proceed > with a session even if a cert fails to verify, whereas a proper SSL > application will refuse to continue or at least treat as unauthorized. > Look to see if s_server reported any "verify error:...". > > If you mean something else, you'll have to explain. > > >[If] The bundle file contains CA1 and CA2; client certificates > >signed by CA1 (client1) work, client certificates signed by CA2 > >(client2) don't work. [and if reversed the reverse] > > As expected, OpenSSL uses only the first matching CA cert. > > >The same site under iis works :( > > I don't know much about IIS but I would guess it uses the > same Windows logic for trust as browsers like IE and Chrome, > and I know those do find alternate chains in some cases > OpenSSL's method does not -- even for identical CA-name, > so I would expect also for canonically-equal CA-name. > > 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. > > >How could I solve it using apache? > > I doubt you can use those CAs with vanilla mod_ssl and openssl. > > You could build and use a hacked version of openssl that > does (more) exact lookup and match. If you want this to work > over time you'd have to periodically redo a new version. > I've not seen any CA that actually used the freedom to > make child.Issuer "insignificantly" different. > > I believe there is (still?) an option for httpd to use > GNUTLS instead of OpenSSL. I have no idea if that behaves > differently (nonstandardly) or if it can be made to. > > But better is to use clearly different names for your CAs. > Even if you can get programs to distinguish them, people > looking at these certs will have trouble. Most "real" (public) > CAs use long similar but (canonically) unequal names like > Fred and Tony's Super Premium Wonderful Certificates Class 45 Red Blue > Fred and Tony's Super Premium Wonderful Certificates Class 45 Blue Red > and I have often wasted time as a result of confusing them. > I'd much rather see "Left Client CA" and "Right Client CA" > or whatever your actual divisions/purposes are. > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >
actalis2013.pem
Description: Binary data
actalis2006.pem
Description: Binary data
