search

davewasmer / devcert

Local HTTPS development made easy
1.28k stars 75 forks source link

Add intermediate CA with nameConstraint #69

Open chiefidiot opened 3 years ago

chiefidiot commented 3 years ago

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 commented 3 years ago

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!