Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add intermediate CA with nameConstraint #69

Open
chiefidiot opened this issue Feb 2, 2021 · 1 comment
Open

Add intermediate CA with nameConstraint #69

chiefidiot opened this issue Feb 2, 2021 · 1 comment

Comments

@chiefidiot
Copy link

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

@lewisl9029
Copy link

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants