Re: Similar issuer dn mod_ssl client authentication issue
Dear openssl group, could you solve this issue regarding mod_ssl? Michele Masè On Thu, May 23, 2013 at 10:11 AM, Michele Mase' 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 > 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. >> >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? >> >> >> 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 Listopenssl-users@openssl.org >> Automated List Manager majord...@openssl.org > > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Similar issuer dn mod_ssl client authentication issue
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 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. > >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? > > > 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 Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
RE: Similar issuer dn mod_ssl client authentication issue
>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. >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? 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Similar issuer dn mod_ssl client authentication issue
"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 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
RE: Similar issuer dn mod_ssl client authentication issue
>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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Similar issuer dn mod_ssl client authentication issue
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 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 > >/O=Example S.p.A./OU=CA Organization Unit/ > >openssl x509 -noout -in one.pem -issuer > >/O=Example S.p.A./OU=CA organization Unit/ > >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: > >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
RE: Similar issuer dn mod_ssl client authentication issue
>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 >/O=Example S.p.A./OU=CA Organization Unit/ >openssl x509 -noout -in one.pem -issuer >/O=Example S.p.A./OU=CA organization Unit/ >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: >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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
