[benburkert]

We did do some research a few months ago, and I don't remember flagging this Chrome issue. It could either be because we add the name constraints to the intermediate CA certs (we always setup a two-tier PKI), or because our tooling adds the certs to the system trust store (same as mkcert, which IIRC also adds name constraints), not importing them directly into the browser. Other than some issues with Rust's webpki crate (which they have since fixed), I don't recall any client compatibility issues with name constraints. Support was added to OpenSSL around the same time that SNI names were added, so we think of them as roughly the same level of support, which is pretty good in 2023.

I don't have a solid answer, but my hunch for why BetterTLS doesn't place much emphasis on Name Constraints is because they have very limited use in public CAs. The latest cacert.pem bundle from curl only shows 141 certs with name constraints: `curl -s https://curl.se/ca/cacert.pem | certigo dump --json --format PEM | jq '.certificates[] | .name_constraints' | wc -l`

[nickf]

"...because they have very limited use in public CAs" Not really. It was/is mostly because NCs aren't 'widely' supported, even now. Name Constraints (referred to as 'Technical Constraints') allows - currently - a public CA to issue a CA certificate with NCs to a third party who then wouldn't require the full panel of WebTrust audits. It's very rarely used, and the one I dealt with eventually got wound down for myriad reasons including how tricky it really is to run a public CA, even a constrained one.

Some solutions (ADCS) obeyed name constraints when signing, but that doesn't help much.

Also - checking the cacert bundle isn't really a good test - that's for roots and you'll not find name constraints there. You'd better look at the thousands of issuing CAs (but the number is still tiny).