Love this library, but as noted in the README.md, obvious vulnerability is someone getting the CA key & cert for that machine. While the risk is probably low given it is tied to a single machine, there does seem to be a way of mitigating using X.509 v3 Name Constraints (https://tools.ietf.org/html/rfc5280#section-4.2.1.10):

1. Options set an array of allowed domains (default might be ['localhost', '.localhost']) for signing (. prefix allows for any subdomain of a passed domain)
2. Generate root CA & key
3. Generate intermediate CA & key signed using root key & cert, allowed domains are set on nameConstraints
4. Discard root key (makes any further cert singing by the root CA impossible)
5. Install root CA in trust store
6. Use intermediate CA for signing certs

This should mostly prevent the ability to sign for any arbitrary domain and reduces the scope to only the TLDs explicitly specified. The intermediate is required because by spec name constraints aren't supported on roots (i.e. self-signed) and only a couple implementations support the extension there, but should work on the intermediate in the chain. Discarding the root key prevents future signing by the root or creating another intermediate CA. Removing the root from the trust store will invalidate the whole chain, so still one click invalidation.

For the end user, the only complexity would be configuring the allowed domains and the feature could be opt-in. The resulting cert can contain the chain with the intermediate cert included or changing options.

I can work on an implementation if needed