Given a CA certificate with a Name Constraints extension with: Permitted: DNS:.de DNS:.com email:.de email:.com Given a server certificate, issued by above CA, using a hostname in the .org domain: Using a Firefox profile that trusts above CA certificate, and connects to a server using a certificate issued by above CA, which isn't whitelisted as permitted. Expected: NSS rejects the certificate and Firefox aborts the connection Actual behaviour: NSS acceptes it and Firefox connects successfully. Test case: - create a new Firefox test profile - visit https://n-2.org:8654/ (expected: cert error because CA unknown) - import the test CA that issued the server cert from http://kuix.de/ca/constrained-test-ca.php and mark it as trusted - again visit (reload) https://n-2.org:8654/ - expected: cert should still get rejected - incorrect behaviour: Firefox loads page without error Dump of CA cert: Certificate: Data: Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: sha1WithRSAEncryption Issuer: C=DE, ST=Test State, L=Test Loc, O=Test Org, CN=Kai's Constrained .de .com Test CA Validity Not Before: Dec 29 14:45:31 2012 GMT Not After : Mar 29 14:45:31 2021 GMT Subject: C=DE, ST=Test State, L=Test Loc, O=Test Org, CN=Kai's Constrained .de .com Test CA Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:cd:11:fe:24:95:eb:c2:a0:a5:23:ed:db:5c:03: 46:ef:00:48:8f:d3:12:c0:8a:82:f4:b1:82:80:4c: 89:84:59:72:75:0b:a4:77:69:8b:6c:c8:43:4f:7a: 08:b2:26:b4:25:46:69:90:40:25:5e:13:18:86:64: 28:9e:46:9d:54:cd:19:ae:d5:15:25:bf:b7:5c:66: d1:bb:02:10:db:ae:70:f0:d7:d1:09:a0:77:a0:96: 2c:a3:20:82:6a:c0:61:4d:60:96:07:81:aa:48:13: 92:d9:53:e2:45:56:57:69:14:f9:de:9f:cd:57:e2: 89:8f:8a:92:21:0f:2b:95:55 Exponent: 65537 (0x10001) X509v3 extensions: Netscape Cert Type: SSL CA, S/MIME CA, Object Signing CA X509v3 Name Constraints: Permitted: DNS:.de DNS:.com email:.de email:.com X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: Certificate Sign, CRL Sign Signature Algorithm: sha1WithRSAEncryption 6c:38:d4:6e:98:20:c6:96:86:0f:41:47:30:b5:ef:6a:3a:7c: 06:40:88:bc:3d:db:a9:ff:d9:15:a0:af:67:43:9a:3a:c6:7f: b6:bc:95:f8:4e:c0:6d:25:9a:0e:d8:e9:09:c8:fc:86:ad:2b: a5:ef:d1:65:c7:b6:69:35:e4:79:a4:e0:c8:47:ee:52:b1:45: d4:c6:9a:76:e5:9c:88:d4:6e:a7:e2:49:7d:c6:11:63:b4:d4: ac:22:1d:ea:9f:33:b1:e9:17:4b:11:9a:5d:e5:46:48:fb:4c: 7f:ed:d2:76:51:5d:4e:f6:80:55:5b:ca:c5:57:ee:a8:55:85: 45:f6 Dump of server cert: Certificate: Data: Version: 3 (0x2) Serial Number: 5 (0x5) Signature Algorithm: sha1WithRSAEncryption Issuer: C=DE, ST=Test State, L=Test Loc, O=Test Org, CN=Kai's Constrained .de .com Test CA Validity Not Before: Mar 29 15:03:31 2013 GMT Not After : Mar 29 15:03:31 2018 GMT Subject: C=DE, ST=Test State, L=Test Loc, O=Test Org, CN=n-2.org Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:bd:2f:35:7a:26:ef:82:15:55:93:27:38:c9:58: c3:b5:3b:0c:c8:41:13:25:69:3f:56:90:ec:1b:fd: 54:20:e3:ca:34:b0:6a:96:9c:0a:f0:89:a7:4e:42: 1f:60:0e:33:f0:3b:35:85:e3:66:1c:f8:4a:5c:c3: 24:54:80:db:b8:9b:e9:ff:5a:2c:f8:88:9b:d2:7b: a7:53:21:9b:21:9b:52:e7:ce:3a:03:9a:d1:66:09: 59:ef:09:9b:80:66:4d:83:df:3f:57:fb:c9:b5:14: 91:2d:4a:5b:ca:90:40:6d:00:2d:a0:64:25:8c:4a: 13:6f:9c:06:fe:a5:e9:05:23 Exponent: 65537 (0x10001) X509v3 extensions: Netscape Cert Type: SSL Client, SSL Server X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: Key Encipherment, Data Encipherment, Key Agreement Signature Algorithm: sha1WithRSAEncryption 4b:81:63:a2:cb:31:21:24:01:cd:31:bc:40:77:73:41:fc:d4: 42:55:08:00:ca:ca:44:f3:95:8e:bb:7e:2f:5c:b2:85:1d:0e: 0e:47:b5:d0:67:24:78:c2:0d:c1:a6:26:8a:78:c1:3a:96:3f: f8:e9:d7:d4:63:45:a8:69:2c:e2:1d:fe:6f:86:b2:e5:e6:e0: 69:54:0f:17:54:e2:0a:dd:9d:6d:3a:6e:46:c3:34:25:e5:35: 32:5c:99:4d:32:c9:84:94:8c:66:41:e0:5e:ae:23:96:19:2f: e3:75:54:dd:84:91:42:3f:03:de:a9:ea:77:71:f4:b6:70:e2: 59:b1

As a first step, I'd be interested in confirmation of this bug. Is my assumption correct, that n-2.org should be a forbidden hostname, and should be rejected by NSS, given above name constraints extension?

Kai, Thank you for looking into this. I believe that this is the currently expected behavior regarding root certs. https://groups.google.com/d/msg/mozilla.dev.security.policy/5v-yMBII6Mw/h0vMICe1IL0J Have you confirmed that name constraints are being enforced at the intermediate and end-entity cert levels? (If yes, then maybe this bug should be closed as a dup of Bug #743700.) Thanks, Kathleen

(In reply to Kathleen Wilson from comment #2) > Have you confirmed that name constraints are being enforced at the > intermediate and end-entity cert levels? If I understand your statement correctly, your *assumption* is: (a) today, NSS does NOT yet respect name constraints in topmost root CA certificates (b) today, NSS does already respect name constraints on intermediate CA certificates The initial test case in this bug is scenario (a). I just added another test case for scenario (b). Using the same above setup, you can find it at https://n-2.org:8653/ It uses an intermediate CA which contains the same name constraints that I have described earlier in this bug. Test result: NSS connects fine to the test case (b), too! Expected result: NSS should reject the cert at https://n-2.org:8653/

In Firefox Nightly (23.0a1) and a copy of Firefox Beta 20, when connecting to that site, I get: Secure Connection Failed An error occurred during a connection to n-2.org:8653. The Certifying Authority for this certificate is not permitted to issue a certificate with this name. (Error code: sec_error_cert_not_in_name_space) That seems correct to me... Gerv

Gerv, thanks for testing, my Firefox was configured to use the libpkix verification engine. So, it seems it's working as hoped only in one scenario. Summary: (a) toplevel root constrained, using NSS classic verify: constraint ignored, cert accepted (b) toplevel root constrained, using NSS libpkix verify: constraint ignored, cert accepted (c) intermediate root constrained, using NSS classic verify: constraint respected, cert rejected (d) intermediate root constrained, using NSS libpkix verify: constraint ignored, cert accepted I talked to Gerv on IRC. We agree that (d) is a bug. This means we found another blocker for using libpkix by default. I propose that we handle scenario (d) in this bug, and I'm adjusting the subject accordingly. Given that libpkix has its own verification logic, it's probably reasonable to handle both (d) and (b) in this bug. Regarding (a), I'm disappointed that it's not yet working, let's get that fixed with a high priority. I agree to use bug 743700 to track (a). Given that bug 743700 is already a public bug, I will copy the information about the test case to bug 743700. Regarding this bug, given that Chroms uses the libpkix engine by default, I'd like to hear Wan-Teh's opinion if this bug should remain hidden until the bug gets fixed in libpkix.

I get a "root not trusted" error on the n-2.org site in Chrome, which suggests that we've got past the check-name-constraints stage (as otherwise we'd get the same error in Firefox)... Gerv

I used the chromium 23 browser on Fedora, I imported the test CA from comment 0, and chromium connects to both test sites (8654 and 8653), no errors.

This needs to "block" the tracking bug for Firefox's switch to libPKIX

Tests to follow. I haven't yet started to figure out why the NSS tests didn't catch this particular case, since the PKITS tests cover NCs. I'm also trying to trace down all usages of buildCheckedCritExtOIDs, since it's incorrectly saying nameConstraints were checked during the build phase, when in fact they're *not* being checked (this checks them during the verify chain phase).

To add state to better understand this change: Compare the differences between http://mxr.mozilla.org/nss/source/lib/libpkix/pkix/top/pkix_build.c#976 , which is part of the chain building algorithm for CERT_PKIXVerifyCert (via PKIX_BuildCHain), and http://mxr.mozilla.org/nss/source/lib/libpkix/pkix/top/pkix_validate.c#239 , which is the API for PKIX_ValidateChain [private] The core functional diff between these two functions are: pkix_NameConstraintsChecker_Initialize pkix_NameChainingChecker_Initialize pkix_BasicConstraintsChecker_Initialize I added the call to the NConstraintsChecker here, and I'm still working through tracing whether there's equivalent functionality for the NameChaining and BasicConstraints checker through other aspects of the forward path builder checkers. Ideally the nameConstraints would be handled by the forward builder state, but the way the merge algorithms are setup, it's "simpler" (eg: won't require 3 weeks in the bowels of libpkix) to simply use it as a reverse checker, the same way Validate does.

Comment on attachment 760676 [details] [diff] [review] Correct name constraints r+ rrelyea

To wrap up the investigation on the code (but not the tests): The patch adds pkix_NameConstraintsChecker_Initialize, to explicitly check that NCs are valid when examining the constructed chain. The bug is the difference between libpkix's Build (which is what NSS uses) and Validate (which is never used by NSS). Build uses PKIX_ComCertSelParams_GetNameConstraints ( http://mxr.mozilla.org/nss/source/lib/libpkix/include/pkix_certsel.h#1616 ). If non-NULL, then during the build phase it will only evaluate certs that match that NC - but if NULL, it does no enforcement whatsoever of NC in the built chain. pkix_BasicConstraintsChecker_Initialize enforces the isCA & pathLength fields for Validate, but this is handled differently during the build phase, by having pkix_Build_BuildSelectorAndParams use PKIX_ComCertSelParams_SetBasicConstraints to set the traversal length, which is then checked at http://mxr.mozilla.org/nss/source/lib/libpkix/pkix/certsel/pkix_certselector.c#1274 pkix_NameChainingChecker_Initialize is handled in a similar way - http://mxr.mozilla.org/nss/source/lib/libpkix/pkix/top/pkix_build.c#1480 sets the path to names in the cloned params, and http://mxr.mozilla.org/nss/source/lib/libpkix/pkix/certsel/pkix_certselector.c#1290 then matches.

This only seems to trigger for cases where the subjectAltName is not present. The nameChaining test above handles all the SAN constraints, but the only handling of the CN is done by http://mxr.mozilla.org/nss/source/lib/libpkix/pkix_pl_nss/pki/pkix_pl_cert.c#3130 , which is ultimately what the NameConstraints checker calls. So this is a much less serious issue - as per the BRs, the CN may only contain a value that's ALSO present in the SAN, and the SAN is already constrained, so it will reject. Kai's test does not make use of the subjectAltName, which is why it fails.

Bob, this is a minor tweak - just the addition of tests. I went the route of using a certutil script (consistent with TestCA/TestUser50/TestUser51), compared to defining a whole new syntax and parser for the chains test to be able to express SANs and nameConstraints. I'd rather avoid extending that syntax, given that it's all processed in bash helper functions.

Comment on attachment 761232 [details] [diff] [review] Added unittests, fixed mem leak r+ I'm OK with using certutil here. We really aren't preserving the ;ibrary independence' of the pkix code anyway. bob

Note: I don't think this actually represents a security-bug. The behaviour described is something not found in any RFC, and instead is back from Bug #394919 The 'normal' test (where SANs were present) were and are already checked.

rsleevi and I agreed that this should be considered sec-low *at most*. It could also be considered an enhancement. Also, because Firefox validates the certificate chain using both the classic verification library AND libpkix for EV certs, then Firefox and other Gecko-based products seem to be unaffected in a practical sense by this bug.

Comment 18 is slightly incorrect. For EV certs Firefox only validates unsing libpkix.

Can we open this bug?

I don't see any reason not to. This is something that no (public) CA should be issuing, as per the Baseline Requirements.