Description of problem: perl-Mozilla-CA comes with certificate bundle generated from nss/mozilla certdata.txt. It's the same source that is used to build ca-bundle.crt form ca-certificates. We should not duplicate those bundles, as that makes it more difficult to deal with updates when some CA needs to be removed (think of recent DigiNotar). Additionally, Mozilla-CA upstream is not currently generating their bundle correctly and are adding certs that are flagged as untrusted in nss/mozilla: https://rt.cpan.org/Public/Bug/Display.html?id=70967 We should really consider making perl-Mozilla-CA require ca-certificates and use that bundle instead.
I had feeling the perl-Mozilla-CA database comes in different format Mozilla publishes. So it's not just a matter of symlink. Can you tell me what's canonical source of the certificate set? RPM package name and the file(s) in it.
(In reply to comment #1) > I had feeling the perl-Mozilla-CA database comes in different format Mozilla > publishes. So it's not just a matter of symlink. Right. Mozilla keeps they list for trusted CAs in certdata.txt file: http://mxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt C code is auto-generated from that file and compiled into libnssckbi.so. That's what can be used by applications using nss. perl-Mozilla-CA contains a certificate bundle generated from Mozilla certdata.txt, but converted to a PEM format usable by OpenSSL (and GnuTLS), generated using the script bundled with curl: http://curl.haxx.se/docs/caextract.html ca-certificates package does exactly the same - takes certdata.txt, extracts certificates and create certificate bundle file in PEM format. It uses a different script to extract the data, but the idea is the same. Additionally, it includes JKS (java key store) file usable by java applications and used by openjdk packages by default. Unlike bundle in Mozilla-CA, it contains full 'openssl x509 -text' output for each certificate, rather than description form certdata.txt (that's why you should see a lot of differences in diff). The idea is to replace cacert.pem in perl-Mozilla-CA with a symlink to /etc/pki/tls/certs/ca-bundle.crt and require ca-certificates. Those files are in the same format. Of course, alternative is to change SSL_ca_file to always return /etc/pki/tls/certs/ca-bundle.crt and not package cacert.pem at all. For the sake of completeness, I did compare of the bundle from Mozilla-CA 20110914 and ca-certificates 2011.78. Mozilla-CA has these CAs which are not in ca-certificates: C=CH, O=SwissSign AG, CN=SwissSign Platinum CA - G2 C=DE, ST=Baden-Wuerttemberg (BW), L=Stuttgart, O=Deutscher Sparkassen Verlag GmbH, CN=S-TRUST Authentication and Encryption Root CA 2005:PN C=FI, O=Sonera, CN=Sonera Class1 CA C=HU, L=Budapest, O=NetLock Halozatbiztonsagi Kft., OU=Tanusitvanykiadok, CN=NetLock Minositett Kozjegyzoi (Class QA) Tanusitvanykiado/emailAddress=info C=US, O=VeriSign, Inc., OU=Class 1 Public Primary Certification Authority C=US, O=VeriSign, Inc., OU=Class 1 Public Primary Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized use only, OU=VeriSign Trust Network C=US, O=VeriSign, Inc., OU=Class 2 Public Primary Certification Authority C=US, O=VeriSign, Inc., OU=Class 2 Public Primary Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized use only, OU=VeriSign Trust Network C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 1999 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 1 Public Primary Certification Authority - G3 C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 1999 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 2 Public Primary Certification Authority - G3 C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Client Authentication and Email C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Network Applications C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Object CN=ComSign CA, O=ComSign, C=IL As far as I can see, all these are marked as only trusted for email and/or code signing in NSS and not for server identification (the use case for Mozilla-CA / LWP).
Second what Tomas says. Just have the function always return "/etc/pki/tls/certs/ca-bundle.crt" here, and stop shipping a duplicate copy of the database.
Created attachment 523529 [details] Patch redirecting to ca-certificates file
It seems the patch will require re-diffing for every new upstream release, as $version is part of the diff context. However, there are likely to be few upstream changes that touch CA.pm, rather than cert file.
Good catch. Unfortunately the CA.pm VERSION changes with each Mozilla-CA tar ball release. I will put sed script into spec file to update the version string in patch text.
Created attachment 523542 [details] Patch redirecting to ca-certificates file The same patch with context excluding the VERSION string.
Created attachment 523543 [details] Spec file adjustments
perl-Mozilla-CA-20110914-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/FEDORA-2011-12740
Package perl-Mozilla-CA-20110914-2.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-Mozilla-CA-20110914-2.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/perl-Mozilla-CA-20110914-2.fc16 then log in and leave karma (feedback).
perl-Mozilla-CA-20110914-2.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.