[Bug 738383] perl-Mozilla-CA: stop shipping own certificate bundle

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=738383

--- Comment #2 from Tomas Hoger <thoger at redhat.com> 2011-09-16 03:52:02 EDT ---
(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 at 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).

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.