I don't think Firefox or Chrome can do that can it?
To the best of my knowledge, no browser can do this today, and I don't know of any other software that can do that either. (I'd want to have it in the system certificate store with the same constraint, as well.)
Name Constraints, as mentioned elsewhere in this thread, wouldn't solve the problem, for two reasons: most software doesn't support them (and silently ignores them rather than correctly failing closed), and they require the CA certificate to contain the constraints rather than system configuration adding the constraints.
We need a mechanism to place certificates in a certificate store (browser or system) with specific domain constraints configured by the administrator. To avoid the failure mode of Name Constraints, those certificates shouldn't be accessible to software that doesn't know to enforce domain constraints.
That would also require updates to various SSL libraries (and to browsers) to handle this new certificate store and enforce the constraints.
It seems like the principle of least privilege could easily be applied to the CA system rather than trusting all CAs for all domains, as there seem to be obvious/natural constraints in certain cases (like CAs that only operate under a particular country TLD).
Could you elaborate on this? Specific examples? CVEs? My experience has been that most software will either honor them, or honor the "critical" flag, which is correct (if disappointing) behavior. If you want it to fail closed, use the critical flag. If you want it to fail open, clear the critical flag.
Doing some additional research, it looks like the situation has improved significantly now, and name constraints might actually work as designed if you don't care about older systems.
That still doesn't address the ability for a browser/administrator to apply such name constraints to a CA that didn't ship as part of its certificate, though.
Firefox does, though I don't know how much they check beyond just the dNSName constraints. Here's the unit test making sure it stays working: https://github.com/mozilla/gecko-dev/blob/b8157dfaafc42deb3b...
1. The actual browser software has its own rules for what's trusted on top of the root trust store often copy-pasted into other software (e.g. in the Python package Certifi). These rules include name constraints of the sort you're interested in, functionally they're used to constrain roots that might be fine but whose government operators promise they're only for some TLDs under authority of that government, so in a sense for those names the government decides who "really" owns them anyway.
Rather than link a horde of HN readers into Mozilla's poor mercurial server I'll point you more indirectly at a summary from their wiki:
https://wiki.mozilla.org/CA/Additional_Trust_Changes
You can fork Firefox and add your own rules to NSS, or if you're feeling really fancy, your own extension mechanism to add rules at runtime.
2. You can spin up a root, and trust it, and use that to sign a suitable constrained intermediate. Then, destroy the private key for the root and continue using the intermediate.
In this scenario Firefox gives total trust to your root, but it can't possibly proxy mybank.com because you destroyed the private keys, it can't do anything further at all. The intermediate, which can still issue, is constrained.
Google (I think? Some big tech firm with know-how) has used this trick for products that do loop-back HTTPS. It mints a root cert during instal, issues one certificate and then destroys the private key, then it can trust the root cert but without any danger you later get MITM'd by the root, because that root's private key no longer exists anywhere.
https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-c...
CAA is a mechanism for trustworthy CAs to agree not to issue certificates to people who don't want them.
So if you set CAA to insist you only want Comodo certificates in darkhorn.example, Let's Encrypt will refuse to issue certificates for names under darkhorn.example
But no matter how you set CAA for darkhorn.example, my private CA can issue certificates for it no problem. Let's Encrypt aren't _prevented_ from issuing, they are _declining_ to issue by policy, and that policy is part of why the world trusts them. But the world doesn't trust my private CA, so I don't have to follow that policy.
You only need a root if you're issuing other keys.
Modern browsers do respect name constraints of intermediate issuing certificates.
But the other systems did at least appear to honor the constraints.
I've asked Apple security folks about this a few times, but they just look uncomfortable and change the topic.
Any way to avoid or bypass name or path constraints would be considered a huge and monumental vulnerability today.
You would be unduly optimistic — for example, Apple did not support them at least as recently as 2015 (see e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=407093...) and 10 years ago OpenSSL hadn't even shipped support upstream, plus however long it took your distribution to ship a major version upgrade to 1.0.
I was hoping someone might have a pointer to current information on that topic since I believe Apple did finally fix Secure Transport but not when.
I have not gotten as far as testing it in production but based on testing Safari and Chrome in https://nameconstraints.bettertls.com/ and creating our own name constrained cert and testing it with both OS X Curl and Linux Curl (OpenSSL) I am still of the impression it works.
Most other people seem to be sure that it does not though (for example in this discussion and here https://security.stackexchange.com/questions/95600/are-x-509...) so I am not sure if I missed something or if people are just not up to date.