Re: Confused: different results on different OSs

2012-09-10 Thread Ben White
>
>
>
> 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


Confused: different results on different OSs

2012-09-07 Thread Ben White
Hi,

The background to this story is that I'm using gSOAP with openssl for some
SOAP/WSDL application development. The final application has to be cross
compiled for an embedded ARM device.

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 started looking at OpenSSL to see if I could narrow this down - there is
definitely different behaviour on my build system vs my embedded system
that is causing the verification to fail.

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.

Please help! I have no idea why the output is different.. can somebody
explain how I might be able to get my target device verifying the
certificate correctly in the same way as my build machine.

Thanks muchly,
Ben


OUTPUT FROM BUILD (Fedora) MACHINE:
---

verify depth is 9
CONNECTED(0003)
depth=2 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary
Certification Authority
verify return:1
depth=1 C = ZA, O = Thawte Consulting (Pty) Ltd., CN = Thawte SGC CA
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN =
www.google.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
   i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
-BEGIN CERTIFICATE-
[REMOVED FOR BREVITY]
-END CERTIFICATE-
 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority
-BEGIN CERTIFICATE-
[REMOVED FOR BREVITY]
-END CERTIFICATE-
---
Server certificate
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
---
No client certificate CA names sent
---
SSL handshake has read 1907 bytes and written 299 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1
Cipher: RC4-SHA
Session-ID:
C05953342AC01E9AB63CF0BABBE942B4E29061AA4904C3F1393EBBB1548B0254
Session-ID-ctx:
Master-Key:
38B97C0CC2795AD1D3EEACAE244E33F1E5A0988AE9182AC85DFFF5B6BFAE6585E6BCF763E1E0EB300CD38B87CC0F2501
Key-Arg   : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
[REMOVED FOR BREVITY]
Start Time: 1347036912
Timeout   : 300 (sec)
Verify return code: 0 (ok)


--
OUTPUT FROM TARGET (ARM) MACHINE


verify depth is 9
CONNECTED(0003)
depth=1 C = ZA, O = Thawte Consulting (Pty) Ltd., CN = Thawte SGC CA
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=1 C = ZA, O = Thawte Consulting (Pty) Ltd., CN = Thawte SGC CA
verify error:num=27:certificate not trusted
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN =
www.google.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
   i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
-BEGIN CERTIFICATE-
[REMOVED FOR BREVITY]
-END CERTIFICATE-
 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority
-BEGIN CERTIFICATE-
[REMOVED FOR BREVITY]
-END CERTIFICATE-
---
Server certificate
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
---
No client certificate CA names sent
---
SSL handshake has read 2130 bytes and written 443 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-RC4-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-RC4-SHA
Session-ID:
AA9E7D7AD223F18241A210D224B8BEF4A441572C1A9719BF3504FB03297D85DE
Session-ID-ctx:
Master-Key:
7A15F2071D50C076C0524AAD45857C5683212370582AD7D9F882B64104F0A0A8C2948B8B85C1EC19015C
51CAC30D4A05
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
[REMOVED FOR BREVITY]

Start Time: 1347036508
Timeout   : 300 (sec)
Verify return code: 27 (certificate not trusted)


unexpected non-continuation byte 0x67

2006-12-06 Thread Ben White
Hello,

I have googled around and have not been able to find a suitable answer for
an error received when "make errors" is attempted when trying to build and
install openssl-0.9.8d. Sorry if I am being to newbie-ish.

First I use config like this:

env CONFIG_SHELL=/bin/sh /bin/sh
./config --prefix=/usr/local --openssldir=/usr/local/openssl shared no-hw

Then:

make errors

results in this:

[EMAIL PROTECTED] openssl-0.9.8d]# make errors
/usr/bin/perl util/mkerr.pl -recurse -write
Malformed UTF-8 character (unexpected non-continuation byte 0x67,
immediately after start byte 0xf6) in pattern match (m//) at util/mkerr.pl
line 252,  line 5.
Malformed UTF-8 character (unexpected non-continuation byte 0x67,
immediately after start byte 0xf6) in pattern match (m//) at util/mkerr.pl
line 252,  line 5.
Malformed UTF-8 character (unexpected non-continuation byte 0x67,
immediately after start byte 0xf6) in pattern match (m//) at util/mkerr.pl
line 252,  line 5.
Malformed UTF-8 character (unexpected non-continuation byte 0x67,
immediately after start byte 0xf6) in pattern match (m//) at util/mkerr.pl
line 252,  line 5.
Malformed UTF-8 character (unexpected non-continuation byte 0x67,
immediately after start byte 0xf6) in pattern match (m//) at util/mkerr.pl
line 262,  line 5.
Malformed UTF-8 character (unexpected non-continuation byte 0x67,
immediately after start byte 0xf6) in pattern match (m//) at util/mkerr.pl
line 262,  line 5.
Malformed UTF-8 character (unexpected non-continuation byte 0x67,
immediately after start byte 0xf6) in pattern match (m//) at util/mkerr.pl
line 262,  line 5.
Malformed UTF-8 character (unexpected non-continuation byte 0x67,
immediately after start byte 0xf6) in pattern match (m//) at util/mkerr.pl
line 262,  line 5.
Malformed UTF-8 character (unexpected non-continuation byte 0x67,
immediately after start byte 0xf6) in pattern match (m//) at util/mkerr.pl
line 252,  line 5.
Malformed UTF-8 character (unexpected non-continuation byte 0x67,
immediately after start byte 0xf6) in pattern match (m//) at util/mkerr.pl
line 252,  line 5.
Malformed UTF-8 character (unexpected non-continuation byte 0x67,
immediately after start byte 0xf6) in pattern match (m//) at util/mkerr.pl
line 252,  line 5.
Malformed UTF-8 character (unexpected non-continuation byte 0x67,
immediately after start byte 0xf6) in pattern match (m//) at util/mkerr.pl
line 262,  line 5.
Malformed UTF-8 character (unexpected non-continuation byte 0x67,
immediately after start byte 0xf6) in pattern match (m//) at util/mkerr.pl
line 262,  line 5.
Malformed UTF-8 character (unexpected non-continuation byte 0x67,
immediately after start byte 0xf6) in pattern match (m//) at util/mkerr.pl
line 262,  line 5.
DSO:No new error codes
ENGINE: No new error codes
OCSP:   No new error codes
EC: No new error codes
BN: No new error codes
UI: No new error codes
DH: No new error codes
CONF:   No new error codes
EVP:No new error codes
SSL:No new error codes
OBJ:No new error codes
ECDH:   No new error codes
ECDSA:  No new error codes
BUF:No new error codes
PKCS7:  No new error codes
X509V3: No new error codes
ASN1:   No new error codes
STORE:  No new error codes
DSA:No new error codes
X509:   No new error codes
PEM:No new error codes
COMP:   No new error codes
CRYPTO: No new error codes
RSA:No new error codes
BIO:No new error codes
PKCS12: No new error codes
RAND:   No new error codes
(cd engines; make PERL=/usr/bin/perl errors)
make[1]: Entering directory
`/usr2/notary/OpenSS/openSSL/openssl-0.9.8d/engines'
set -e; for l in 4758cca aep atalla cswift gmp chil nuron sureware ubsec; do
\
/usr/bin/perl ../util/mkerr.pl -conf e_$l.ec \
-nostatic -staticloader -write e_$l.c; \
done
CCA4758:No new error codes
AEPHK:  No new error codes
ATALLA: No new error codes
CSWIFT: No new error codes
GMP:No new error codes
HWCRHK: No new error codes
NURON:  No new error codes
SUREWARE:   No new error codes
UBSEC:  No new error codes
make[1]: Leaving directory
`/usr2/notary/OpenSS/openSSL/openssl-0.9.8d/engines'
/usr/bin/perl util/ck_errf.pl */*.c */*/*.c


Any help would be greatly appreciated.

Thanks,

Ben W

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]