Extracting and/or documenting Firefox's trusted root certs

[Nelson Bolyard]

Previously I wrote that one can create a PEM file containing all of
Mozilla's trusted roots with a simple shell script.
One can get a simple text list of those root cert's nicknames.

Here's a simple (?) shell script to do it. It uses NSS's certutil
program. It first produces a text file containing a list of the
root cert's nicknames in alphabetical order, then it creates a PEM
file of matching contents.

certutil -L -h 'Builtin Object Token' -d DB | \
grep ' *[CcGTPpu]*,[CcGTPpu]*,[CcGTPpu]* *$' | \
sed -e 's/ *[CcGTPpu]*,[CcGTPpu]*,[CcGTPpu]* *$//' \
-e 's/\(.*\)/"\1"/' | sort > rootnicknames.txt

while read nickname; do echo ==== $nickname ====; \
eval certutil -d DB -L -n "$nickname" -a ; \
done < rootnicknames.txt > pemroots.txt 2>&1

if you remove the -a from that last command, it will give you a file
of pretty printed certs, from which you can extract subject names or
serial numbers, etc.

[Daniel Stenberg]

On Tue, 19 Aug 2008, Nelson Bolyard wrote:

> Here's a simple (?) shell script to do it.

Great!

> certutil -L -h 'Builtin Object Token' -d DB

What exactly is 'DB' in this context? My firefox 3 directory has three .db
files, and trying them all one by one makes certutil with the command line
above say:

certutil: function failed: security library: bad database.

(Debian Linux 32bit here, nss 3.12.0, Firefox 3.0.1 although named
iceweasel...)

--

/ daniel.haxx.se

[Wan-Teh Chang]

On Wed, Aug 20, 2008 at 1:56 PM, Daniel Stenberg <dan...@haxx.se> wrote:
>
>> certutil -L -h 'Builtin Object Token' -d DB
>

> What exactly is 'DB' in this context? My firefox 3 directory has three .db
> files, and trying them all one by one makes certutil with the command line
> above say:
>
> certutil: function failed: security library: bad database.

'DB' is the directory that contains your NSS databases.

See the certutil man page at
http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html

Wan-Teh

[Daniel Stenberg]

On Wed, 20 Aug 2008, Wan-Teh Chang wrote:

>> certutil: function failed: security library: bad database.
>
> 'DB' is the directory that contains your NSS databases.

Thanks for that and sorry for not doing my home work properly.

This turns out to generate a rather interesting list. Using my currently
installed db set I get 126 names, but the certdata.txt file in the Mozilla CVS
repo ( $Revision: 1.45 $ $Date: 2008/01/17 ) contains 124 (using "make
ca-bundle" in the curl build tree).

Diffing the list of names show my db contains 3 more names and one less than
certdata.txt.

Is this a bug in our source to PEM script, or what does it mean? I would
expect the two lists to be identical, or is that just another bad assumption
on my part? Are we using the wrong certdata.txt file?

The file our script downloads and converts to PEM is this:

The certdata.txt is downloaded from here:

http://lxr.mozilla.org/seamonkey/source/security/nss/lib/ckfw/builtins/certdata.txt?raw=1

The conversion script uses the openssl tool and is found here:

http://curl.haxx.se/lxr/source/lib/mk-ca-bundle.pl

--

/ daniel.haxx.se

[Kyle Hamilton]

The current certdata.txt in the repository is not the one that
generated your version of Firefox. (There have been a couple of
changes in the past couple of months, and no client releases.)

-Kyle H

> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>

[Daniel Stenberg]

On Thu, 21 Aug 2008, Kyle Hamilton wrote:

> The current certdata.txt in the repository is not the one that generated
> your version of Firefox. (There have been a couple of changes in the past
> couple of months, and no client releases.)

But where is the certdata.txt that was used for my Firefox release then? The
one I mentioned was last updated in January 2008.

--

/ daniel.haxx.se

[Wan-Teh Chang]

Did you get your Firefox release from www.mozilla.com or from your
Linux distribution?

If you get your Firefox release from www.mozilla.com, what's the Firefox
version number? I documented most of the NSS versions used in
various Mozilla clients at
http://www.mozilla.org/projects/security/pki/nss/mozilla-nss-versions.html

You may be able to look up the NSS version from that page. Then, you
can download the source tar file from
https://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/

If you can't find the NSS version in that page, I can look it up for you.

If you get your Firefox release from your Linux distribution, you need
to get the source package for that Linux distribution. Check the
patches in the source package and see if any of them applies to
certdata.txt.

Wan-Teh

[Daniel Stenberg]

On Thu, 21 Aug 2008, Wan-Teh Chang wrote:

> Did you get your Firefox release from www.mozilla.com or from your Linux
> distribution?

I did say NSS 3.12, Firefox 3.01 and Debian Linux.

> If you get your Firefox release from your Linux distribution, you need to
> get the source package for that Linux distribution. Check the patches in
> the source package and see if any of them applies to certdata.txt.

But yes, the lxr URL at mozilla.org that I showed you before contains an older
certdata.txt than what Firefox 3.0.1 (NSS 3.12) uses. I found another URL at
mozilla.org that shows a newer one.

--

/ daniel.haxx.se

[Wan-Teh Chang]

On Thu, Aug 21, 2008 at 10:43 AM, Daniel Stenberg <dan...@haxx.se> wrote:
> On Thu, 21 Aug 2008, Wan-Teh Chang wrote:
>
>> Did you get your Firefox release from www.mozilla.com or from your Linux
>> distribution?
>
> I did say NSS 3.12, Firefox 3.01 and Debian Linux.

If you get your NSS 3.12 from Debian Linux, you need to get the
NSS source package from Debian and examine its patches.
Debian adds the SPI Inc. and CAcert.org CA certificates to
certdata.txt. See the 95_add_spi+cacert_ca_certs.dpatch patch in
https://bugzilla.mozilla.org/show_bug.cgi?id=448792

I don't know how to get the exact version of certdata.txt in
Firefox 3.0.1/NSS 3.12 from mxr.mozilla.org. mxr.mozilla.org
shows the *current* versions of certdata.txt in the NSS trunk,
Firefox trunk, and various branches, and some of them are
already newer than the certdata.txt (CVS rev. 1.47.2.1) in
Firefox 3.0.1/NSS 3.12. In any case, you can get the
certdata.txt in the official Firefox 3.0.1 (from www.mozilla.com) in
https://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_12_RTM/src/

Wan-Teh

[Kaspar Brand]

Wan-Teh Chang wrote:
> I don't know how to get the exact version of certdata.txt in
> Firefox 3.0.1/NSS 3.12 from mxr.mozilla.org.

bonsai's cvsblame.cgi is somewhat better (though not perfect) for this -
try e.g.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ckfw/builtins/certdata.txt&rev=FIREFOX_3_0_1_RELEASE

Kaspar

[Nelson B Bolyard]

Wan-Teh Chang wrote, On 2008-08-22 10:02:
> On Thu, Aug 21, 2008 at 10:43 AM, Daniel Stenberg <dan...@haxx.se> wrote:
>> On Thu, 21 Aug 2008, Wan-Teh Chang wrote:
>>
>>> Did you get your Firefox release from www.mozilla.com or from your Linux
>>> distribution?
>> I did say NSS 3.12, Firefox 3.01 and Debian Linux.
>
> If you get your NSS 3.12 from Debian Linux, you need to get the
> NSS source package from Debian and examine its patches.
> Debian adds the SPI Inc. and CAcert.org CA certificates to
> certdata.txt. See the 95_add_spi+cacert_ca_certs.dpatch patch in
> https://bugzilla.mozilla.org/show_bug.cgi?id=448792

Right, and because they've altered the root CA list, they're not allowed
to call their version "Firefox". That's why they call it "Ice Ape" or
"Ice Weasel" or something like that, I believe.

Daniel claimed he was running Firefox. If he's running a browser with
the Debian root list and the brand name Firefox, then somebody is in
trouble (not Daniel :).

[Kyle Hamilton]

My understanding is that they were not allowed to use the Firefox
brand because its terms of use conflicted with their packaging and
freedom rules. Any additional changes after they changed the brand to
IceWeasel might also affect the ability to use the Firefox brand, but
that wasn't the reason they rebranded it.

But hypothetically... if he truly were running firefox, and they
created a script to run firefox that automatically added SPI and
CAcert to the per-profile DB using certutil on the first run, would
that case violate the terms of branded-firefox distribution? If a
sysadmin did that to implement a site security policy (since we've
never figured out if there's any way to add a sitewide db to the
search list), would that violate terms of branded-firefox site
distribution?

-Kyle H

[Nelson B Bolyard]

Kyle Hamilton wrote, On 2008-08-22 14:38:
> My understanding is that they were not allowed to use the Firefox
> brand because its terms of use conflicted with their packaging and
> freedom rules. Any additional changes after they changed the brand to
> IceWeasel might also affect the ability to use the Firefox brand, but
> that wasn't the reason they rebranded it.

OK, I don't know which came first, the rebranding or the additional roots.

> But hypothetically... if he truly were running firefox, and they created
> a script to run firefox that automatically added SPI and CAcert to the
> per-profile DB using certutil on the first run, would that case violate
> the terms of branded-firefox distribution?

That's a good question for the folks who govern the FF trademark rules.

> If a sysadmin did that to implement a site security policy [...], would

> that violate terms of branded-firefox site distribution?

This question has come up in the context of the CCK (Client Customization
Kit), and IIRC, there is a statement somewhere that it's OK as long as you
don't distribute the modified client outside of your (company, enterprise,
school, etc.}.

In my view, there's a big difference between a company's sysadmin doing
it for his users and a Linux distro doing it for (potentially) all of
planet Earth. But I don't write Mozilla's trademark policy, so my answers
are not authoritative for these questions.