PSM:EV Testing

This document explains how to modify PSM (mozilla/security/manager) sources in order to enable a root CA cert for Extended Validation (EV).

Ensure the root CA cert has been added to NSS storage.

Find file mozilla/security/manager/ssl/src/nsIdentityChecking.cpp, which contains a definition for a type named nsMyTrustedEVInfo. Following the structure definition, add a new entry to array myTrustedEVInfos. (There is a patch in bug 421989 which enhances NSS tool "pp" to dump those fields in the expected format.)

To ensure this page won't get out of date, please study the existing entries and field names, they should make it clear what you must provide. One noteworthy detail are the issuer and serial number fields. To produce the strings expected both in source code and the external file, take the binary representation of those fields (as stored in the certificate) and encode them as base64. Note that the binary representation of the serial number is of the DER encoded INTEGER with the Identifier and Length octets removed. Only the Contents octets from the DER representation of the integer serial number are base64 encoded for this file.

PSM will use {issuer name, serial number} as a key to find potential root certs in NSS storage.

Each entry should have a comment that mentions the cert's subject name, to make it easier for human readers to find the referenced cert.

Should you require to test various root certs with EV, and want to build only once, PSM offers a mechanism to load "EV approvals" from an external text file. This code is excluded in release builds for safety reasons, and enabled in debug builds. The source code switch is controlled using #define PSM_ENABLE_TEST_EV_ROOTS

You could produce such a build once and use it for future testing. In addition to using an enabled build, you must switch it on when starting the application (e.g. Firefox). To do so, set environment variable ENABLE_TEST_EV_ROOTS_FILE=1

PSM will load a file called test_ev_roots.txt from the profile directory. Please refer to the source code comments in function loadTestEVInfos() for the expected format of that file.

At the time of writing of this page, an example entry would look like this (4 lines):

1_fingerprint 99:A6:9B:E6:1A:FE:88:6B:4D:2B:82:00:7C:B8:54:FC:31:7E:15:39
2_readable_oid 2.16.840.1.114028.10.1.2
3_issuer MIHDMQswCQYDVQQGEwJVUzEUMBIGA1UEChMLRW50cnVzdC5uZXQxOzA5BgNVBAsTMnd3dy5lbnRydXN0Lm5ldC9DUFMgaW5jb3JwLiBieSByZWYuIChsaW1pdHMgbGlhYi4pMSUwIwYDVQQLExwoYykgMTk5OSBFbnRydXN0Lm5ldCBMaW1pdGVkMTowOAYDVQQDEzFFbnRydXN0Lm5ldCBTZWN1cmUgU2VydmVyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5
4_serial N0rSQw==

Some words on PSM's EV verification strategy:

At runtime, PSM will register alls OIDs found in array entries, cobined with the oid name string.

When verifying end entity (EE) certs for EV, PSM will match policy OIDs contained in the EE cert against all entries in myTrustedEVInfos and derive a list of candidate roots. Next it will ask NSS to validate the EE cert, including policy validation, and find a path to one of the candidate roots.

User interface reporting: As of today, PSM's user interface, in particular the certificate viewer, is not in synch with EV policy validation. The displayed chain may be good for validating the cert, but a different chain might have been used for cert plus policy validation.