Skip Menu |

This queue is for tickets about the Mozilla-CA CPAN distribution.

Report information
The Basics
Id: 69091
Status: open
Priority: 0/
Queue: Mozilla-CA

People
Owner: Nobody in particular
Requestors: ezyang [...] mit.edu
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Old versions of OpenSSL cannot handle CA files with multiple certificates
It appears to be the case that old versions of OpenSSL (known broken 0.9.8g, known fixed 0.9.8o) do not properly handle certificate authority files that contain multiple certificate authorities. Here is an example (no Perl involved, but it illustrates the bug): ezyang@dr-wily:~$ head Public/cacert.pem ## ## lib/Mozilla/CA/cacert.pem -- Bundle of CA Root Certificates ## ## Certificate data from Mozilla as of: Thu Apr 7 03:47:06 2011 ## ## This is a bundle of X.509 certificates of public Certificate Authorities ## (CA). These were automatically extracted from Mozilla's root certificates ## file (certdata.txt). This file can be found in the mozilla source tree: ## '/mozilla/security/nss/lib/ckfw/builtins/certdata.txt' ## ezyang@dr-wily:~$ grep Entrust Public/cacert.pem Entrust.net Secure Server CA Entrust.net Premium 2048 Secure Server CA Entrust Root Certification Authority ezyang@dr-wily:~$ curl --version curl 7.18.2 (i486-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.8 libssh2/0.18 Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz ezyang@dr-wily:~$ curl --cacert Public/cacert.pem --capath /dev/null https://graph.facebook.com curl: (60) SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). The default bundle is named curl-ca-bundle.crt; you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option. ezyang@dr-wily:~$ cat test.pem Show quoted text
-----BEGIN CERTIFICATE----- MIIE2DCCBEGgAwIBAgIEN0rSQzANBgkqhkiG9w0BAQUFADCBwzELMAkGA1UEBhMCVVMxFDASBgNV BAoTC0VudHJ1c3QubmV0MTswOQYDVQQLEzJ3d3cuZW50cnVzdC5uZXQvQ1BTIGluY29ycC4gYnkg cmVmLiAobGltaXRzIGxpYWIuKTElMCMGA1UECxMcKGMpIDE5OTkgRW50cnVzdC5uZXQgTGltaXRl ZDE6MDgGA1UEAxMxRW50cnVzdC5uZXQgU2VjdXJlIFNlcnZlciBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTAeFw05OTA1MjUxNjA5NDBaFw0xOTA1MjUxNjM5NDBaMIHDMQswCQYDVQQGEwJVUzEUMBIG A1UEChMLRW50cnVzdC5uZXQxOzA5BgNVBAsTMnd3dy5lbnRydXN0Lm5ldC9DUFMgaW5jb3JwLiBi eSByZWYuIChsaW1pdHMgbGlhYi4pMSUwIwYDVQQLExwoYykgMTk5OSBFbnRydXN0Lm5ldCBMaW1p dGVkMTowOAYDVQQDEzFFbnRydXN0Lm5ldCBTZWN1cmUgU2VydmVyIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MIGdMA0GCSqGSIb3DQEBAQUAA4GLADCBhwKBgQDNKIM0VBuJ8w+vN5Ex/68xYMmo6LIQ aO2f55M28Qpku0f1BBc/I0dNxScZgSYMVHINiC3ZH5oSn7yzcdOAGT9HZnuMNSjSuQrfJNqc1lB5 gXpa0zf3wkrYKZImZNHkmGw6AIr1NJtl+O3jEP/9uElY3KDegjlrgbEWGWG5VLbmQwIBA6OCAdcw ggHTMBEGCWCGSAGG+EIBAQQEAwIABzCCARkGA1UdHwSCARAwggEMMIHeoIHboIHYpIHVMIHSMQsw CQYDVQQGEwJVUzEUMBIGA1UEChMLRW50cnVzdC5uZXQxOzA5BgNVBAsTMnd3dy5lbnRydXN0Lm5l dC9DUFMgaW5jb3JwLiBieSByZWYuIChsaW1pdHMgbGlhYi4pMSUwIwYDVQQLExwoYykgMTk5OSBF bnRydXN0Lm5ldCBMaW1pdGVkMTowOAYDVQQDEzFFbnRydXN0Lm5ldCBTZWN1cmUgU2VydmVyIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MQ0wCwYDVQQDEwRDUkwxMCmgJ6AlhiNodHRwOi8vd3d3LmVu dHJ1c3QubmV0L0NSTC9uZXQxLmNybDArBgNVHRAEJDAigA8xOTk5MDUyNTE2MDk0MFqBDzIwMTkw NTI1MTYwOTQwWjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAU8BdiE1U9s/8KAGv7UISX8+1i0Bow HQYDVR0OBBYEFPAXYhNVPbP/CgBr+1CEl/PtYtAaMAwGA1UdEwQFMAMBAf8wGQYJKoZIhvZ9B0EA BAwwChsEVjQuMAMCBJAwDQYJKoZIhvcNAQEFBQADgYEAkNwwAvpkdMKnCqV8IY00F6j7Rw7/JXyN Ewr75Ji174z4xRAN95K+8cPV1ZVqBLssziY2ZcgxxufuP+NXdYR6Ee9GTxj005i7qIcyunL2POI9 n9cd2cNgQ4xYDiKWL2KjLB+6rQXvqzJ4h6BUcxm1XAX5Uj5tLUUL9wqT6u0G+bI= -----END CERTIFICATE----- ezyang@dr-wily:~$ curl --cacert test.pem --capath /dev/null https://graph.facebook.com ezyang@dr-wily:~$ grep MIIE2DCCBEGgAwIBAgIE Public/cacert.pem MIIE2DCCBEGgAwIBAgIEN0rSQzANBgkqhkiG9w0BAQUFADCBwzELMAkGA1UEBhMCVVMxFDASBgNV The upshot is that if you're using new versions of libwww-perl that do certificate authority checking, and you have old versions of OpenSSL, you will get spurious failed certificate validation errors. This is a definitive problem for distributions like Debian Lenny, which are still using old versions of the OpenSSL library which have this bug. It would be lovely if Mozilla::CA could work around this problem by having a certificate directory rather than file.
Subject: Re: [rt.cpan.org #69091] Old versions of OpenSSL cannot handle CA files with multiple certificates
Date: Sat, 25 Jun 2011 21:32:20 -0700
To: bug-Mozilla-CA [...] rt.cpan.org
From: Ask Bjørn Hansen <ask [...] perl.org>
This would be a problem with curl then, too. Isn't 0.9.8g 4 years old and full of other bugs, too? Is this also an issue with 0.9.8r? Both 0.9.9 and 1.0.0 are out now. - ask
From: ezyang [...] mit.edu
Almost. It is a problem if you tell Curl not to use a directory based certificate store and only use a single Mozilla style CA file. However, by default, Curl knows where to look for a directory of SSL certificates, so it manages to successfully find the certificate it needs. In some ways, Mozilla::CA is going about fixing the problem of CA the wrong way: a better approach would simply be to hook into whatever the system default location is (which is nontrivial, since every distro has their own certificate store.) It is true that 0.9.8g is quite old. I'm not sure if this is an issue with 0.9.8r, but it wouldn't be too difficult (if a little annoying) to test, if you want me to. Debian Lenny will be supported until 2012-04.
On Wed Jun 29 08:20:06 2011, ezyang wrote: Show quoted text
> In some ways, Mozilla::CA is going about fixing the problem of CA > the wrong way: a better approach would simply be to hook into whatever > the system default location is (which is nontrivial, since every distro > has their own certificate store.)
Mozilla::CA is meant to be the final fallback when the application can't find the system default location. I believe Mozilla::CA should stay simple like it is and then a new module with heuristics about where to find stuff should be created.
From: ezyang [...] mit.edu
On Wed Jun 29 13:54:22 2011, GAAS wrote: Show quoted text
> Mozilla::CA is meant to be the final fallback when the application can't > find the system default location. I believe Mozilla::CA should stay
simple Show quoted text
> like it is and then a new module with heuristics about where to find stuff > should be created.
Well, it certainly does not seem like this SSL library cluster is managing to find the system default location in any sort of reliable way, so if that means we need a new module to sniff system defaults, that might be a good contribution.
Subject: Re: [rt.cpan.org #69091] Old versions of OpenSSL cannot handle CA files with multiple certificates
Date: Wed, 29 Jun 2011 19:21:25 -0700
To: bug-Mozilla-CA [...] rt.cpan.org
From: Ask Bjørn Hansen <ask [...] perl.org>
On Jun 29, 2011, at 19:15, Edward Z. Yang via RT wrote: Show quoted text
> Well, it certainly does not seem like this SSL library cluster is > managing to find the system default location in any sort of reliable > way, so if that means we need a new module to sniff system defaults, > that might be a good contribution.
That's what Gisle is suggesting. :-) LWP would use this new module (if available) and then just fallback to Mozilla::CA if that module isn't there or couldn't find the CAs. - ask
From: ezyang [...] mit.edu
On Wed Jun 29 22:21:34 2011, ask@perl.org wrote: Show quoted text
> That's what Gisle is suggesting. :-)
Excellent. I wasn't sure if Gisle was claiming this was the current situation or not. Show quoted text
> LWP would use this new module (if available) and then just fallback to > Mozilla::CA if that module isn't there or couldn't find the CAs.
Sounds sensible.