Wrong certificate store used? about sslyze

[GoogleCodeExporter]

Weird... I get "Certificate is NOT Trusted" on Ubuntu and Windows.
Are you using the Mac's default OpenSSL library or did you build your own ?

I know that Apple has changed the OpenSSL library that comes with Mac OS X to 
automatically use Apple's trust store whenever an SSL connection is made (!!). 
However it doesn't seem like CACert is part of that trust store anyway 
(http://wiki.cacert.org/InclusionStatus). I'll investigate; thanks for the 
feedback.

Original comment by [email protected] on 28 Mar 2012 at 5:21

• Changed state: Accepted

[GoogleCodeExporter]

I'm using the default Python, so I guess that will be the Apple OpenSSL library.

If you want to validate with the Mozilla CA store only, you probably need to 
explicitly disable built in trust anchors. It would be quite useful if sslyze 
could report trust with the default OS CA store and Mozilla independently. 

Original comment by [email protected] on 28 Mar 2012 at 7:00

[GoogleCodeExporter]

Yeah default trust stores should definitely be disabled as the current result 
is misleading and wrong. That's something I'll fix.

Validating the server cert against the OS store seems a bit annoying to 
implement. The location of the OS's CA store will be quite specific to the OS 
(and it also changes between Linux distros I think). Writing specific cases for 
each platform and OS would be too much work and I don't think it's a feature 
that lots of users will want to have ? 

Original comment by [email protected] on 29 Mar 2012 at 2:16

[GoogleCodeExporter]

Turns out there's not much I can do. Apple patched/hacked the OpenSSL lib that 
ships with Snow Leopard. They changed X509_verify_cert() to automatically fall 
back to the OS trust store if the cert verification failed. This is an issue of 
Snow Leopard, and it would not be trivial to "fix" it within SSLyze. 

Relevant links:
http://bugs.ruby-lang.org/issues/3150
http://www.opensource.apple.com/source/OpenSSL098/OpenSSL098-27/src/crypto/x509/
x509_vfy_apple.h

Original comment by [email protected] on 7 Apr 2012 at 11:58

• Changed state: WontFix