A while back I wrote an entry about TLS CA root certificate name constraints for internal Certificate Authorities. One of the traditional problems with your own TLS CA is that this CA can be used to sign any name, even names you don't want to sign. A name constraint would limit that, but traditionally these weren't widely supported, especially on TLS CA root certificates. Then I read Michal Jirků's Running one's own root Certificate Authority in 2023 and had a realization about a general way out so that everything would accept your TLS name constraints.

Some software will accept name constraints on root CA certificates, so you create your root certificate with them. Some software will only accept name constraints on intermediate CA certificates, so then you create an intermediate certificate with the same constraints as your root certificate; it should also have the same validity period as your root certificate (or as long a validity period as you expect to need your CA for). At this point, you throw away the CA root certificate's private key, so no one can make any more intermediate certificates. This insures an attacker can't create a new intermediate certificate without name constraints and then issue certificates from it that will be accepted by older Chrome versions and other things that ignore root CA name constraints.

(Modern Chrome versions support root CA name constraints, but I expect that older Chrome versions will linger on for quite some time in the form of old Android devices that aren't getting updates.)

I suspect that there are some uncertainties and potential problems with this approach. Most obviously, you're in trouble if TLS clients decide to start limiting the lifetime of intermediate CA certificates, since you can't make any more once you destroy the root CA key. As far as I can tell, the CA/Browser Forum Baseline Requirements don't currently limit intermediate certificate lifetimes, but this may change someday.

(One option would be to pre-mint a series of intermediates with relatively short (and overlapping) lifetimes as a precaution. But then you have to protect all of these intermediate certificates for possibly several decades.)

Since using intermediate CAs is what's done in public (web) TLS, probably pretty much everything supports it so maybe there aren't really any uncertainties beyond the long validity period of the intermediate certificate. I don't know how many levels of intermediates are commonly supported, so maybe there could be problems if you wanted two levels of intermediate (the one that's effective your 'root' CA and then a second, shorter term one below it that you used to directly issue TLS certificates).