refactor(ssl): replace openssl dependency with node-forge

[zetlen]

Fewer dependencies means better DX and UX! With this change, devcert no longer requires a local installation of openssl.

The node-forge library:

• implements the TLS standard
• uses native crypto where available, with only a tiny perf hit
• Configures keys and certificates using code, rather than external config file processing
• generates PEM files, but also can connect keys, cAs, CSRs, and certs without bouncing off the filesystem

Notes:

• I had to try many times to get browsers and OSes to verify the chain. Ultimately I succeeded by:

  • Removing the authorityKeyIdentifier extension (considered redundant)
  • Generating serial numbers based on the ASN.1 standard
  • Removing all subject attributes but commonName

  I hope this remains an acceptable certificate configuration for all needs.

• TODO: This can be additionally refactored to remove some of the filesystem-dependent steps. For instance, you could change the way that child certificate generation accesses the root CA, by reading the PEM from the filesystem only once and then threading the CA cert object through the necessary arguments. This would speed up and simplify the code. I chose not to do it for this round, because it would be too large a change for you to safely integrate.

[zetlen]

While I wouldn't trust node-forge with generating certs or CSRs for production, it's already in wide use by devs who use webpack-dev-server over https, through this usage of the selfsigned library.

I know, you gotta step lightly around crypto, but since devcert is for dev environments only, I think this isn't an unprecedented usage of the library.

The idea of a flag is appealing, but I think it would be a pretty big maintenance burden; as browser TLS requirements continue to change, we would have to maintain cert generation configuration in two formats: one as an OpenSSL conf file, and another as a module that configures node-forge.

[zetlen]

Is it likely that you'll merge this? If not, that's okay, we'll just fork it into our own namespace (with no intent to compete with yours, we'll make that clear).

[Dashue]

Would love to see this merged as I'm struggling on windows with devcert not accepting the password provided to openssl

[lewisl9029]

I know it's been a while since this PR got any attention, but I'd love to see this picked back up if there's still interest from the author and maintainer (happy to try to pick this back up myself if the original author is too busy or no longer interested).

Having to ask the end user to install OpenSSL separately might not seem like a big deal, but for building tools/libraries on top of devcert (which seems to be an intended use case), that small point of friction makes it impossible to offer a truly seamless onboarding experience, which is one of those things separates a decent DX from a great one.

If we're not comfortable with node-forge being a replacement/default, I'd happily settle for it being an opt-in instead, so only tooling authors who value DX over a more-battle-tested cert generation process need to use it.

[NewFuture]

👀