Bug 738383 - perl-Mozilla-CA: stop shipping own certificate bundle
Summary: perl-Mozilla-CA: stop shipping own certificate bundle
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: perl-Mozilla-CA
Version: rawhide
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ---
Assignee: Petr Pisar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-14 16:59 UTC by Tomas Hoger
Modified: 2011-09-30 19:23 UTC (History)
4 users (show)

Fixed In Version: perl-Mozilla-CA-20110914-2.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-09-30 19:23:50 UTC


Attachments (Terms of Use)
Patch redirecting to ca-certificates file (2.11 KB, patch)
2011-09-16 09:41 UTC, Petr Pisar
no flags Details | Diff
Patch redirecting to ca-certificates file (2.07 KB, patch)
2011-09-16 11:10 UTC, Petr Pisar
no flags Details | Diff
Spec file adjustments (1.99 KB, patch)
2011-09-16 11:23 UTC, Petr Pisar
no flags Details | Diff

Description Tomas Hoger 2011-09-14 16:59:53 UTC
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.

Comment 1 Petr Pisar 2011-09-15 06:30:24 UTC
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.

Comment 2 Tomas Hoger 2011-09-16 07:52:02 UTC
(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@netlock.hu
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).

Comment 3 Joe Orton 2011-09-16 08:01:49 UTC
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.

Comment 4 Petr Pisar 2011-09-16 09:41:51 UTC
Created attachment 523529 [details]
Patch redirecting to ca-certificates file

Comment 5 Tomas Hoger 2011-09-16 10:03:32 UTC
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.

Comment 6 Petr Pisar 2011-09-16 11:01:11 UTC
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.

Comment 7 Petr Pisar 2011-09-16 11:10:00 UTC
Created attachment 523542 [details]
Patch redirecting to ca-certificates file

The same patch with context excluding the VERSION string.

Comment 8 Petr Pisar 2011-09-16 11:23:55 UTC
Created attachment 523543 [details]
Spec file adjustments

Comment 9 Fedora Update System 2011-09-16 11:40:10 UTC
perl-Mozilla-CA-20110914-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/FEDORA-2011-12740

Comment 10 Fedora Update System 2011-09-17 19:33:57 UTC
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).

Comment 11 Fedora Update System 2011-09-30 19:23:38 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.