certdata2pem.py doesn't handle CKT_NSS_MUST_VERIFY_TRUST

Bug #1207004 reported by Christian Heimes on 2013-07-31
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ca-certificates (Debian)
Fix Released
ca-certificates (Ubuntu)

Bug Description


I'm a Python core developer and hobbyist security researcher. While I
was working on my own parser for Mozillas certdata.txt [1] I found
an issue in curls mk-ca-bundle.pl script. Today I found the same issue in
Debian's and Ubuntu's script.

The Python script ./mozilla/certdata2pem.py of ca-certificates-20120623
 doesn't handle the flag CKT_NSS_MUST_VERIFY_TRUST.
The flag was introduced in revision 1.84 of certdata.txt, see [2]

The PKCS#11 glue documentation [3] of the freedesktop.org project has
some background information on the flag, too. Quote:
The certificate is not a trusted anchor (even if a later trust record
in another PKCS #11 module says this cert should be trusted). If the
marked certificate is self-signed, then this is semantically
equivalent to CKT_NSS_NOT_TRUSTED, except NSS will return a different
error code (unknown CA for CKT_NSS_MUST_VERIFY_TRUST versus untrusted

May I suggest that you reverse the check and distrust any certificate
unless it was explicitly flagged as a trusted delegator and root CA
cert? In the context of cryptography and TLS it more secure to omit a
root CA cert than to wrongly ship a bogus cert. By the way Adam
Langley [4] uses the same approach [5].

My Ubuntu box has files like Verisign_Class_1_Public_Primary_Certification_Authority.pem
in the /etc/ssl/certs/ directory. According to my script "Verisign Class 1 Public Primary Certification Authority"

$ LC_ALL=C apt-cache policy ca-certificates
  Installed: 20120623
  Candidate: 20120623
  Version table:
 *** 20120623 0
        500 http://de.archive.ubuntu.com/ubuntu/ quantal/main amd64 Packages
        100 /var/lib/dpkg/status

$ LC_ALL=C lsb_release -a
LSB Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch
Distributor ID: Ubuntu
Description: Ubuntu 12.10
Release: 12.10
Codename: quantal


[1] https://bitbucket.org/tiran/storeroom/
[2] http://lists.debian.org/debian-release/2012/11/msg00411.html
[4] https://www.imperialviolet.org/2012/01/30/mozillaroots.html
[6] https://bitbucket.org/tiran/storeroom/src/e24eef16ff64041ab7792a907f0d69f7b19cd624/certdata/certs.py?at=default#cl-4411

Christian Heimes (heimes) wrote :

curl has updated their script today. I notified the developers a couple of weeks ago.


SuSE's certdata.txt parsing script handles the flag correctly


Marc Deslauriers (mdeslaur) wrote :

Thanks for the bug report, I'll investigate this issue.

Changed in ca-certificates (Ubuntu):
assignee: nobody → Marc Deslauriers (mdeslaur)
Marc Deslauriers (mdeslaur) wrote :

So, I've looking into this. The relevant code in certdata2pem.py is:

        trust[obj['CKA_LABEL']] = True
        trust[obj['CKA_LABEL']] = True

In Debian and Ubuntu, ca-certificates is not only used for web certificates, but also for email certificates.

Even if Verisign_Class_1_Public_Primary_Certification_Authority.pem is marked as CKT_NSS_MUST_VERIFY_TRUST for CKA_TRUST_SERVER_AUTH, it is marked as CKT_NSS_TRUSTED_DELEGATOR for CKA_TRUST_EMAIL_PROTECTION, which is why it is included.

I believe omitting certs that are valid for CKA_TRUST_EMAIL_PROTECTION will break email S/MIME verification.

information type: Private Security → Public Security
Christian Heimes (heimes) wrote :

I had long discussion with Marc-Andre Lemburg about the issue. He maintains the eGenix pyOpenSSL distribution which also contains root CA certs. He did some tests with TRUST settings but apparently OpenSSL ignores them. Eventually we came up with the idea to split the CA bundle into multiple files: a separate file for each purpose. See http://www.egenix.com/products/python/pyOpenSSL/

Marc Deslauriers (mdeslaur) wrote :

I've filed an upstream bug with Debian.

Changed in ca-certificates (Ubuntu):
status: New → Confirmed
Changed in ca-certificates (Debian):
status: Unknown → New
Changed in ca-certificates (Ubuntu):
assignee: Marc Deslauriers (mdeslaur) → nobody
Christian Heimes (heimes) wrote :

Please request a CVE number for this issue.

Changed in ca-certificates (Debian):
status: New → Fix Committed
Changed in ca-certificates (Debian):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.