You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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):
Options set an array of allowed domains (default might be ['localhost', '.localhost']) for signing (. prefix allows for any subdomain of a passed domain)
Generate root CA & key
Generate intermediate CA & key signed using root key & cert, allowed domains are set on nameConstraints
Discard root key (makes any further cert singing by the root CA impossible)
Install root CA in trust store
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
The text was updated successfully, but these errors were encountered:
I've been looking for exactly this feature to limit the potential impact of a compromised local CA. Specifically on Windows systems where the password requirement is decidedly not ideal UX. Would be much better if we could limit the CA to be only valid for a limited subset of lower risk domains intended for local dev and not have to be as worried with restricting access to the cert.
Curious if you've made any progress on a fork/PR? I don't have a whole lot of experience working with certs & CAs so would prefer to leave it to the experts, but I'd be happy to give it a shot if nobody else has the time/interest to implement this. Just let me know either way!
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):
['localhost', '.localhost']
) for signing (. prefix allows for any subdomain of a passed domain)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
The text was updated successfully, but these errors were encountered: