[greengreengrass]

Possibly a separate concern, but I have some degree of confidence that the requirements and oversight of the CA/B forum (or whomever else determines which root certs go into bundles) are sufficiently strict, and issuers kept under sufficient scrutiny, that I tend to trust those more than I trust myself to secure my own root CA keys adequately. The ideal would be for people setting up their own PKI to ensure their root uses the Name Constraints extension, but the default “can sign anything for any host” I fear makes it easy for people to install their own self-pwn device, and probably left the private key lying around on a box exposed to the Internet.

* with some notable root certs that I have… questionable… trust and confidence are not simply controlled by certain state actors.

[WhyNotHugo]

Personally, I use a custom local CA with name constraints so that it can only sign domains for The .internal TLD. This is the most important bit: because if the cert is ever leaked, it cannot be used to MITM connections to other domains.

I have to secure the CA's key, but I also have to secure all the keys for the certificate it signs, both being a similar level of challenge.

For personal use, or for very small organisations, using a passphrase-protected Yubikey as a "cheap HSM" should suffice.

[throw0101a]

Yubi makes an 'actual' HSM product:

* https://www.yubico.com/products/hardware-security-module/

See also perhaps less expensive option:

* https://shop.nitrokey.com/shop/nkhs2-nitrokey-hsm-2-7

[cduzz]

I am planning on fiddling with using the TPM of an old dell 5820 I've got floating around my house as a budget HSM.

It looks possible, on paper, if you don't poke at it too often.

[thayne]

I wish that in addition to the CA setting Name Constraints (and client software validating that), that end users could add additional constraints when adding a new trusted CA, so that even if the CA cert doesn't have Name Constraints, you can restrict it to a specific domain.