>From: owner-openssl-us...@openssl.org On Behalf Of Ztatik Light
>Sent: Friday, 16 August, 2013 03:31
>From stackoverflow:
>"These hash values will comes from the Subject DN of each
>CA certificate (since the aim is to look for a CA certificate
>with the subject matching the issuer of the certificate to verify).
>You can either usec_rehash as documented, or get the Subject DN's
>hash using openssl x509 -subject_hash -noout -in cacert.pem
>and rename the file/link accordingly."
That most likely explains the "unable to get local issuer cert"
because 1.0.0 and later changed the subject hashing from 0.9.8,
so either the existing (0.9.8) certs dir needs to be rehashed,
or you need to create a separate -CApath using 1.0.0 hash,
or just put the CA cert(s) you want in a -CAfile instead.
But it doesn't explain cipher NONE, which should only occur if
the handshake fails, and it's pretty odd for that to occur
after (receiving and) validating the server cert.
>On Thu, Aug 15, 2013 at 12:01 PM, Andrew H
><andrew_ya...@hotmail.com> wrote:
> I have two version of OpenSSL on my OSX file system,
>the default 0.9.8r and 1.0.1e.
> For the later I'm having trouble getting the syntax
>of the command correct, I think.
> When I used this (in 1.0.1e's directory, /opt/localbin):
> ./openssl s_client -connect foo.foo.foo.foo:443 ( replace the foo's
).
> I get responses that included the Cipher is NONE and
>'unable to get local issuer certificate' messages.
> Without the ./, using the default openssl, this works fine,
>the cipher is populated and no local issuer messages.
> I tried variations of the CApath argument with no success:
> -CApath /System/Library/OpenSSL/certs/
> That's the system path from 'openssl version -d'
> I messed around with similar values in the verify argument.
You can't use "similar" values, -verify takes a number (indicating
depth) and isn't really implemented anyway (the callback ignores
it entirely unless there's already another verification error,
and then it sets a variable that isn't used!)
> There's obviously a fundamental misunderstanding on my part
>regarding the proper usage of these arguments.
These arguments for s_client haven't changed, although some
other options were added. 1.0.1 newly implements TLSv1.1 and
1.2 and defaults to the highest available. 1.2 in particular
has been known to cause problems with some (lame) servers. If
you still can't connect after fixing CApath as above, try adding
-no_tls1_2 or more restrictively -tls1 or -ssl3 . If that makes
the difference and you want to understand what the exact problem
is, show us *all* the output for a 1.2 attempt.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
