Netscape Certificate Database Information.

The following document gives some information about the format of the Netscape certificate database. It is not intended to be a complete description. Its primary purpose is to allow the contents of the certificate database to be read: in order to be exportable to another (fully documented) format. It does not supply enough information to modify the database. This information was determined largely by experiment and without any assistance from Netscape Corps employees (i.e. none of them broke EAR or any other export laws).

General Information.

The database is in a file called cert7.db. It is in Berkeley 1.85 DB hash format. This is the same format used for the history database. The actual DB code is in the Mozilla source release in a directory called dbm. For more information about Berkeley DB see  http://www.sleepycat.com/

Record Structure.

Other than a couple of version information records, each record contains either a pointer to other record(s) or a certificate and a pointer. Each key has the following form:

[type byte]   [Data]

Where type byte is type of record being looked up. Data is an unambiguous representation of the data to look up.

Here is a list of  type bytes and their records. This may well be not 100% accurate.
 
 
Type Meaning Record Structure Points to
0x01 Certificate record Serial number (big endian) and Issuer (DER format). Certificate, name, trust information.
0x02 Name Null terminated name Subject information.
0x03 Subject DER encoded subject name Name and one or more Serial number and Issuer records
0x04 Subject DER encoded subject name CRL and URL.
0x06 Email address Null terminated email address Subject Information, 
Supported encryption, time.
 For example to lookup the email record for shenson@bigfoot.com the following record would be looked up:

0000 06 73 68 65 6e 73 6f 6e 40 62 69 67 66 6f 6f 74  |.shenson@bigfoot|
0010 2e 63 6f 6d 00                                   |.com.|

The value of this record would then allow the subject to be looked up. Followed by serial number and issuer and finally the certificate itself.

Certificate Record Information.

To export the contents of a database it is (mercifully) not necessary to know the meaning of all records types. It should be sufficient to simply enumerate all records and export the certificate records (first byte of key 0x01). Here is a typical certificate record.

0000 07 01 00 00 40 00 41 00 40 02 cd 00 10 30 82 02  |....@.A.@....0..|
0010 c9 30 82 02 73 a0 03 02 01 02 02 01 0c 30 0d 06  |.0..s........0..|
0020 09 2a 86 48 86 f7 0d 01 01 04 05 00 30 81 90 31  |.*.H........0..1|
........
02c0 27 9b da 93 0b 6f cf 38 51 a8 49 6c fc bd 25 87  |'....o.8Q.Il..%.|
02d0 7d 59 39 f9 4c 9c e2 04 a4 90 53 74 65 76 65 20  |}Y9.L.....Steve |
02e0 4d 41 49 4c 20 43 45 52 54 00                    |MAIL CERT.|

This particular record is for my email certificate. Which has the name Steve MAIL CERT. It should be apparent that this record not only contains my certificate but also its name as well.

More information can be obtained by analysing the first few bytes.

0000 07 01 00 00 40 00 41 00 40 02 cd 00 10 30 82 02  |....@.A.@....0..|

The first 13 bytes contain the required information. The four bytes outlined in bold contain the length of the following information. Namely the certificate length and name length: both in big endian format. Using this the certificate and name can be extracted unambiguously.

Type and Trust Information.

Being able to read a certificate is only part of the data required. We also need to know the type of certificate and what trust is placed upon it. The following summarize what I think are the criteria for certificate types. In this table t is an unsigned character pointer which points to the start of the record. This table is probably incomplete and possibly inaccurate.
 
 
Type Criteria Notes
User Certificate t[6] & 0x40 Incorrectly specified as t[4] & 0x40 in earlier version of this text.
Email Certificate t[6] & 0x01 Only if not User certificate. The name is 
also an empty string.
CA Certificate (t[4] | t[6] | t[8]) & 0x08 This seems to be the only criteria 
that always works.
Server Certificate t[4] & 0x01
The trust information varies according to the type of certificate. The details are summarized in the next table.
 
 
Certificate Type Trust Type Criteria
CA Certificate Warn t[4] & 0x04
CA Certificate Network  t[4] & 0x10
CA Certificate Email t[6] & 0x10
CA Certificate Software t[8] & 0x10
Server Certificate Connect t[4] & 0x02
Server Certificate Warn t[4] & 0x04
Email Certificate Explicitly Trust t[6] & 0x02

There are some other bits here the use of which (if any) is unknown. For example the initial CAs can have t[4,6,8] & 0x20 set, whereas those loaded manually do not. Also the "CA certificate" rule seems a bit odd.

Private Key Database.

For details of the private key database key3.db see here.

Unknown Information.

Currently many details are not known or incomplete. Not all are relevant. The more relevant ones are listed below.