1603034 - NSS accepts a version-1 certificate with extension fields

Status: NEW

(NSS :: Tools, defect, P5)

Description

[13132239506]

Attachment: file.tar( including rootca.cert.pem powerca.cert.pem leaf.pem)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36

Steps to reproduce:

1.Create folder by “mkdir nssdb”
2.Creating NSS database through "certutil - N - d dbm:nssdb"
3.Add certificates (powerca.cert.pem and rootca.cert.pem) to nssdb database by the command "certutil - A - n powerca.cert.pem - t "c, c, c" - i powerca.cert.pem - d nssdb" and the command "certutil - A - n rootca.cert.pem - t "c, c, c" - i rootca.cert.pem - d nssdb"
4. verify the version-1 certificate with extension fields ("leaf.pem") by "vfychain -a -d nssdb leaf.pem"

Actual results:

Chain is good!

Expected results:

Chain is bad!
Clearly, leaf certificate violate Section 4.1.2.1, RFC5280: “When extensions are used, as expected in this profile, version MUST be 3 (value is 2). ”.

Comment 1

[J.C. Jones [:jcj] (he/they)]

Confirmed.

vfychain uses the compatibility-focused classic verification and doesn't necessarily conform tightly to RFC5280. If compliance is necessary, we'd recommend implementing a verifier built on mozilla::pkix.

We should rewrite vfychain someday in C++ and implement mozilla::pkix there. I've opened Bug 1603183 to cover that, but it's not going to be a priority over the next quarter, I'm afraid.

As-is, making the classic verification conformant is not something I'm likely to spend time on. I think moz::pkix and leveraging all the effort used for Firefox is the right approach.

[0] https://wiki.mozilla.org/SecurityEngineering/Certificate_Verification