Does Chrome support X509v3 Permitted Name Constraints?

Question

I'm trying to set permitted name constraints on a private CA certificate. For example, I have the following constraints on my root certificate

X509v3 Name Constraints: critical
     Permitted:
       DNS:.mytestdomain.local
       DNS:mytestdomain.local

I've issued a certificate for another domain anothertestdomain.local. Both the Common Name and Subject Alternative Names are set to that domain. When testing validation for that certificate, OpenSSL and Firefox both fail with a Permitted Subtree Violation as expected. Chrome, however, accepts that certificate. Is this expected under Chrome?

I'm testing with Chromium on Linux.

Answer 1

It should now work correctly.

Enable anchor constraints enforcement on user added roots.

https://bugs.chromium.org/p/chromium/issues/detail?id=1072083#c28

Answer 2

You can use BetterTLS to check the Name Constraints support of various clients. It's open source and made by the Netflix team.

BetterTLS is a test suite for HTTPS clients implementing verification of the Name Constraints certificate extension.

It works for the browser and for non-browser clients (like Java and Python).

Answer 3

According to this Chromium bug, what you're experiencing is intended functionality. https://bugs.chromium.org/p/chromium/issues/detail?id=1072083

It sounds like you're placing nameConstraints on the root, which is not supported, not only in Chrome, but many major PKI implementations. That's because RFC 5280 does not require such support; imported root certificates are treated as trust anchors (that is, only the Subject and SPKI are used, not other extensions).

If you place the constraints on the intermediate, this should work as intended. The net-internals log and full chain will help confirm, in which case, this may be WontFix/WorkingAsIntended.

I have not verified either way, but apparently the functionality you're after works (or worked) on Chromium on MacOS, but it seems like that's short-lived.

I guess what threw me off is that macOS's SSL stack, the latest OpenSSL, and the latest stable Firefox were all were honoring nameConstraints on the root cert

Yeah, the inconsistency between platforms is something we're aware of, and we're in the process of aligning Chrome platforms to the Chrome on Linux behaviour (that is, treating the root cert as a trust anchor). The Firefox change was a recent change, and partially motivated by a publicly-trusted CA request (a consortium of Greek universities)