Re: Confused: different results on different OSs
No, look at your output: the certificate chain is identical. What differs is the result of verification against each system's truststore, which is the set of CA (root) certs it trusts. Since you didn't specify -CAfile or -CAdir on s_client, it's using (whatever is in) the default truststore, which can be set by environment variables SSL_CERT_FILE/DIR and otherwise defaults to a file or subdirectory in OPENSSLDIR which is set at build time. If you installed openssl on your dev system (Fedora) as a package, that package may have installed some well-known CA certs in your default store, or you may have installed some other package that does so (I've heard curl does, and I think there are others). Or if this system is shared, someone else did. If your app is calling SSL_CTX_set_default_verify_paths it is defaulting similarly. For your target system you might first check whether there is a package that includes, or adds, well-known CA certs. If this is not the same package or packager as openssl, be sure they agree on the location of OPENSSLDIR. To do it yourself you should either put whatever CA certs you decide are trusted -- or someone else you trust has decided are trusted, such as Microsoft (Windows/IE) or Oracle (Java) -- in its default truststore, if that is a location you can write. Or, change your app to call SSL_CTX_set_verify_locations specifying your own file and/or directory into which you similarly put whatever CA certs you decide are trusted. Thanks a lot - that really helps. Calling openssl with the -CApath pointing to the certificate store resolves this issue, so it's definitely related to this. However, there seems to be a problem with the default settings. On my Fedora box this all just works without needing to specify -CApath. The built-in OPENSSLDIR contains the certificates. I copied this dir across onto my target device and put it in the OPENSSLDIR for the target (/usr/local/ssl), but it only works if I specify this explicitly via -CApath. Fedora system: openssl version -d OPENSSLDIR: /etc/pki/tls ls /etc/pki/tls cert.pem certs misc openssl.cnf private Target system openssl version -d OPENSSLDIR: /usr/local/ssl ls /usr/local/ssl cert.pem certsmisc openssl.cnf private Is there any way to have openssl spit out where it's looking for the certificate store? Ideally I don't want to have to specify any parameters in my client program since the code is mostly automatically generated by gSOAP. On my Fedora box it just picks up the defaults and works smoothly. I want the same behaviour on my target board. Thanks a lot, Ben
RE: Confused: different results on different OSs
From: owner-openssl-us...@openssl.org On Behalf Of Ben White
Sent: Monday, 10 September, 2012 06:17
snip my previous advice, can't easily reformat
Calling openssl with the -CApath pointing to the certificate
store resolves this issue, so it's definitely related to this.
However, there seems to be a problem with the default settings.
On my Fedora box this all just works without needing to specify
-CApath. The built-in OPENSSLDIR contains the certificates.
I copied this dir across onto my target device and put it in
the OPENSSLDIR for the target (/usr/local/ssl), but it only works
if I specify this explicitly via -CApath.
snip: commandline version -d on each
That's odd. s_client without -CApath should use the same dir as
-CApath OPENSSLDIR/certs (and similarly file OPENSSLDIR/cert.pem)
unless envvars SSL_CERT_{FILE,DIR} are set (confirm they aren't)
or something weird was done in the openssl build.
If the openssl build you're using on target isn't known/certain to
be from official (unpatched) source, and you can rebuild from source,
that might be worth a try. I presume you have the cross tools already
for your app, although openssl is a pretty complicated build and it
may need something your app doesn't; and you need a correct set of
flags (compiler,linker,etc) which you may have to create yourself.
You said openssl is 1.0.1c on both systems, so this isn't the issue
of the hashnames in a CApath changing between 0.9.8 and 1.0.0.
Is there any way to have openssl spit out where it's looking for the
certificate store? snip
Not specifically. If you can run under a debugger on your target
(hopefully with source) I'd try that. Or you may have OS-level tools
like strace that can do this (but often with a lot of clutter).
Otherwise you may be reduced to 1960-style batch debugging, by
changing the source to include printf or similar and rebuilding,
which in turn requires you can rebuild from source (see above).
Good luck.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: Confused: different results on different OSs
From: owner-openssl-us...@openssl.org On Behalf Of Ben White Sent: Friday, 07 September, 2012 13:01 snipusing gSOAP with opensslsnip Everything works fine on my build system (Fedora 17 x64), but when I run the cross compiled version on my target device (ARM/Montavista 5), I get the following error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed I have run the following command on both (the IP address is google.com): openssl s_client -showcerts -connect 173.194.67.104:443 -verify 9 The outputs on the different machines are listed below. I am running openssl 1.0.1c in both cases. In particular the target (ARM) system seems to receive/interpret a different certificate chain. No, look at your output: the certificate chain is identical. What differs is the result of verification against each system's truststore, which is the set of CA (root) certs it trusts. Since you didn't specify -CAfile or -CAdir on s_client, it's using (whatever is in) the default truststore, which can be set by environment variables SSL_CERT_FILE/DIR and otherwise defaults to a file or subdirectory in OPENSSLDIR which is set at build time. If you installed openssl on your dev system (Fedora) as a package, that package may have installed some well-known CA certs in your default store, or you may have installed some other package that does so (I've heard curl does, and I think there are others). Or if this system is shared, someone else did. If your app is calling SSL_CTX_set_default_verify_paths it is defaulting similarly. For your target system you might first check whether there is a package that includes, or adds, well-known CA certs. If this is not the same package or packager as openssl, be sure they agree on the location of OPENSSLDIR. To do it yourself you should either put whatever CA certs you decide are trusted -- or someone else you trust has decided are trusted, such as Microsoft (Windows/IE) or Oracle (Java) -- in its default truststore, if that is a location you can write. Or, change your app to call SSL_CTX_set_verify_locations specifying your own file and/or directory into which you similarly put whatever CA certs you decide are trusted. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
