Missing policy for CA certificates

Bug #103074 reported by V S
This bug affects 2 people
Affects Status Importance Assigned to Milestone
ca-certificates (Ubuntu)
Fix Released

Bug Description

Binary package hint: ca-certificates

The ca-certificates package doesn't have a proper security policy. The process of adding certificates to the list of trusted root CAs doesn't require any sort of objective attestation of the trustability of the CA, as witnessed by the inconsistent certificate list with some 3rd party audited CAs missing and some unaudited CAs available. Quoting the README.Debian:

 - submit *GPG signed* bug report to ca-certificate with severity normal.
   the bug report should include
     - description of the CA
     - how to obtain CA cert pem or paste it in the bug report
     - license of the CA certificate
     - fingerprint and/or hash value of the cert
 - get 2 or 3 recommendation ("seconded" mail) from other people to
   the bug report, GPG signed.

As the PKI security systems that the Internet rests on ultimately break down to how trustable the CAs are, this very seriously undermines any pretense of secure communications.

Related branches

Revision history for this message
V S (th-deactivatedaccount-deactivatedaccount) wrote :

Perhaps the mozilla ca certificate policy, reviewed and developed by the Mozilla community for over a year, would be a good starting point for Ubuntu:


Revision history for this message
Paul Bryan (pbryan) wrote :

Though 9 months late, I'd like to express the same concern in this bug report. While there's a nice disclaimer in the package description (from Debian), users are ignorant of the security ramifications of inclusion.

I too suggest there should be a secure, objective inclusion critera. Continuing to include untrustable certificate authorities puts the security of communications at significant risk.

At the very least, can we have a stronger disclaimer, which properly informs the users of the risks of installing this package on their system? Something like:

"As the trustworthiness of the included CAs has not been established, the installation of this package on your system could result in a compromise in SSL/TLS secure communications. Install this package at your own risk."

Revision history for this message
Andrea Corbellini (andrea.corbellini) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

Changed in ca-certificates:
assignee: nobody → andrea-bs
status: New → Incomplete
Revision history for this message
Paul Bryan (pbryan) wrote :

Yes, this is still an issue.

Revision history for this message
Andrea Corbellini (andrea.corbellini) wrote :

Thanks for the information.

Changed in ca-certificates:
assignee: andrea-bs → nobody
status: Incomplete → Confirmed
Revision history for this message
Philipp Kern (pkern) wrote :

Actually I intend to move to only having a selected set of CAs enabled by default. (I.e. Mozilla's and maybe some of Debian's because we want our users to be able to surf onto our SSL-protected sites. I can understand if you dislike the latter but we could also look for an Ubuntu-only change on this. And I want to ask debian-devel at some point about their opinion.) I target this for Karmic+1, though.

Revision history for this message
Till Ulen (tillulen) wrote :

Philipp, this didn't make it into Lucid, did it?

Revision history for this message
giff gill (giffgilll-deactivatedaccount) wrote :


The recent incident with the UTN-USERFirst-Hardware certificates as reported in Bug #741729 shows again how important it is that this is getting addressed.
Comodo got to know about the problem on March 15th , Google blocked the fraudulent signatures on 16th, Mozilla and Microsoft followed. However to my knowledge, all Linux distributions, certainly those that use the debian ca-certificate still trust these certificates.
Any damage most likely already has been done. Even the next day response from Google likely had come to late and there certainly was a window of a few days between issuing the certs and Comodo being aware of the intrusion.

It's not the first time UTN-USERFirst-Hardware came up...

Now Mozill, Google and MS blacklisted the known compromised certificates. All other certificates they signed are still trusted. Any bets and guesses when the next incident involving a comodo reseller will occur?

to Paul C. Bryan, #2:
>At the very least, can we have a stronger disclaimer, which properly informs the users of the risks of installing this package on their system?

It's preinstalled on a default desktop installation of Ubuntu.
I'm not sure what the best course of action should be. I think it's clear the mentioned fraud certs should be blacklisted asap (I mean Microsoft beat you to it...). Apart from that maybe we should think about disabling these known "problematic" CAs.
I'd suggest still shipping them in the package but disabled by default so the user can make a conscious decision about trusting them or not.

Revision history for this message
Michael Shuler (mshuler) wrote :

Pending upload, README.Debian now includes the following in the collab-maint git repository:

How certificates will be accepted into the ca-certificates package

 - Get it included into Mozilla's trust store.
 - File a bug against ca-certificates stating this fact.

With the exception of SPI (http://www.spi-inc.org/) and CAcert
(http://www.cacert.org/), only those CAs included in the Mozilla trust
store will be included in the ca-certificates package in Debian.

Kind regards,
Michael Shuler

Changed in ca-certificates (Ubuntu):
status: Confirmed → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ca-certificates - 20130906

ca-certificates (20130906) unstable; urgency=low

  * Add ca-certificates-local source package example to documentation
  * Update local certificate handling in README.Debian.
    Closes: #718173, LP: #487845
  * Update CA inclusion policy for ca-certificates in README.Debian. With
    the exception of SPI and CAcert, only those CAs included in Mozilla's
    trust store will be included in ca-certificates in Debian.
    Closes: #647848, LP: #103074
  * Clarify that not all software that uses SSL uses ca-certificates in
    README.Debian. Closes: #664769
  * Add mozilla/nssckbi.h to source, since certdata.txt no longer contains
    a version number.
  * Update debian/copyright to "Copyright: Mozilla Contributors" for
  * Update mozilla/certdata.txt to version 1.94
    Certificates added (+) and removed (-):
    + "CA Disig Root R1"
    + "CA Disig Root R2"
    + "China Internet Network Information Center EV Certificates Root"
    + "D-TRUST Root Class 3 CA 2 2009"
    + "D-TRUST Root Class 3 CA 2 EV 2009"
    + "PSCProcert"
    + "Swisscom Root CA 2"
    + "Swisscom Root EV CA 2"
    + "TURKTRUST Certificate Services Provider Root 2007"
    - "Equifax Secure eBusiness CA 2"
    - "TC TrustCenter Universal CA III"

 -- Michael Shuler <email address hidden> Fri, 06 Sep 2013 11:31:06 -0500

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

Other bug subscribers

Remote bug watches

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