1525985 - Entrust intermediate CA validation fails with: Certificate contains unknown critical extension.

Status: RESOLVED WONTFIX

(NSS :: Libraries, defect)

Description

[Rob Crittenden]

Attachment: OU=Entrust Managed Services Root CA,OU=Certification Authorities,O=Entrust,C=US

Validation of an intermediate CA certificate using certutil fails:

$ certutil -N -d sql:/tmp/nsdb
$ certutil -A -d sql:/tmp/nsdb/ -a -i /tmp/ca.crt -n ca -t C,,
$ certutil -V -u L -d sql:/tmp/nsdb/ -n ca
certutil: certificate is invalid: Certificate contains unknown critical extension.

nss-3.41.0-3.fc28.x86_64 on Fedora 28

Comment 1

[Ryan Sleevi]

Failing for unhandled critical extensions is Working As Intended. So that argues for a WontFix, or, alternatively, we can pivot this into a feature request to support the given critical extension

The critical extensions from this certificate:

• basicConstraints
• inhibitAnyPolicy
• policyConstraints
• keyUsage

For mozpkix, Bug 989051 is related to support for inhibitAnyPolicy, and there was intentional desire not to support it (as it is not used in the WebPKI), as captured at https://dxr.mozilla.org/mozilla-central/rev/c2593a3058afdfeaac5c990e18794ee8257afe99/security/nss/lib/mozpkix/lib/pkixcheck.cpp#565

For libpkix, nss/lib/libpkix/pkix_pl_nss/pki/pkix_pl_cert.c and nss/lib/libpkix/pkix/checker/pkix_policychecker support the inhibitAnyPolicy extension; you can test by adding the environment variable NSS_ENABLE_PKIX_VERIFY=1 before your final command.

For 'classic' (which is effectively what you get with certutil), inhibitAnyPolicy is supported in generation, but not in verification processing. This logic is captured in https://dxr.mozilla.org/nss/rev/db68b6975216d1f21f2963356e31ae87968aa53c/nss/lib/certdb/certxutl.c#468 , which ultimately dispatches to the policy table in https://dxr.mozilla.org/nss/rev/db68b6975216d1f21f2963356e31ae87968aa53c/nss/lib/util/secoid.c#632 regarding supported extensions. inhibitAnyPolicy is marked as a 'fake supported cert extension' ( https://dxr.mozilla.org/nss/rev/db68b6975216d1f21f2963356e31ae87968aa53c/nss/lib/util/secoid.c#1578 ).

The processing model for those 'fake' supported extensions is gated based on the NSS compile-time definition of NSS_ALLOW_UNSUPPORTED_CRITICAL; by default, it's not set, because it's a critical security failure to allow unsupported critical extensions.

So to recap:

• Classic & mozpkix (aka: what Firefox has always used) do not support inhibitAnyPolicy, nor are the likely to
• libpkix (deprecated) does

I'll punt this over to jcj to triage if feature request or WontFix.

Comment 2

[Fraser Tweedale]

According to https://tools.ietf.org/html/rfc5280#section-4.2:

At a minimum, applications conforming to this profile MUST recognize
the following extensions: key usage (Section 4.2.1.3), certificate
policies (Section 4.2.1.4), subject alternative name (Section
4.2.1.6), basic constraints (Section 4.2.1.9), name constraints
(Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended
key usage (Section 4.2.1.12), and inhibit anyPolicy (Section
4.2.1.14).

Yes, failing on unknown critical extension is correct behaviour.
But not handling inhibit anyPolicy seems like a bug to me.

Comment 3

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

One fox's bug is another fox's feature. As Sleevi pointed out, we already have backlogged bugs on file here for inhibitAnyPolicy in Bug 989051, but I don't see a reason to up the priority at this time.

(5280 specifies a bunch of behaviors that mozilla::pkix doesn't do, because of safety and the baseline requirements.)

Thanks for the report though. It's just such a niche thing.