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
To generate self-signed x.509 certificates and private keys from within an application, modules like pem have to rely on spawning the system's OpenSSL, which is problematic as it can be out of date or worse, not available at all (Windows).
I think it would make sense to expose the following APIs from the bundled OpenSSL through crypto:
generate a private key
generate a self-signed certificate
generate dh parameters
Accompaning the above, I could also see the following:
I think we can strike dh parameters (prime) generation off that list, as these seem to be obtainable through crypto.createDiffieHellman(keysize).getPrime() which I assume can be fed directly into TLS's dhparam option.
I take that back. Pretty sure the docs on dhparam are actually lacking and it only accepts PEM formatted dh parameters, not raw primes in buffer format. Is this correct?
openssl related stuff might be a good candidate for things that should be in core due to how easy it is to get openssl wrong with consequences that can popup in unexpected ways
I don't think there's consensus that it doesn't belong, but neither is there consensus that it would make it in. I think it's safe to say that it's unlikely this would make it in.
I wouldn't necessarily object such additions but it's a bit of a slippery slope. For example:
generate a self-signed certificate
Self-signed certificates are useless except for testing, so the logical next step is to support certificate signing using a CA key.
But once you allow that, you can make a case that creating CA keys with node should also be possible. And once that is in, it should probably also be taught how to do CRL management, etc., etc.
It would be a lot easier to simply link the openssl apps into the node binary so you could node genrsa -out key.pem 2048. :-)
This issue has been inactive for sufficiently long that it seems like perhaps it should be closed. Feel free to re-open (or leave a comment requesting that it be re-opened) if you disagree. I'm just tidying up and not acting on a super-strong opinion or anything like that.
Sorry to revive an old issue, but I'm wondering what the state of things is in 2020? Is it possible using the Node's crypto module only to create a certificate, a key pair and then sign the certificate using the private key and serialize both to PEM without shelling out to OpenSSL? Essentially I'm wondering if this https://flaviocopes.com/express-https-self-signed-certificate/ can be done purely in NodeJS.
generate a self-signed certificate
I want to do this programmatically and in a cross-platform way for testing, hence my interest. The closest I found was:
This uses Forge which I'd like to avoid (I'd rather use a built-in module for this, it doesn't feel right for crypto to be done by a non built-in module to me).
This generates the key-pair and signs a general payload with it, but it doesn't contain code showing how to generate a payload that would encode a certificate. I'm neither capable enough to write that code myself nor knowledgeable enough to know whether that is possible given the above described constraints, and while I don't expect anyone more capable or knowledgeable than me to whip up this code, I'd be grateful for an answer to whether this is possible and what would it take.
I would also like to see this implemented as I wanted to programatically generate a certificate as well, without relying on a pure javascript implementation of openssl that hasn't been updated in over 4 years...
Activity
silverwind commentedon Aug 26, 2015
I wonder if something like this should live in
tlsorcrypto. @indutny any feedback?indutny commentedon Aug 27, 2015
It should be
cryptofor sure. Can't it be done in binary addons?It feels like we are trying to workaround problems with C++ addons by moving everything into the core. I don't like this tendency.
cc @bnoordhuis
silverwind commentedon Sep 12, 2015
I think we can strike dh parameters (prime) generation off that list, as these seem to be obtainable through
crypto.createDiffieHellman(keysize).getPrime()which I assume can be fed directly into TLS'sdhparamoption.silverwind commentedon Sep 12, 2015
I take that back. Pretty sure the docs on
dhparamare actually lacking and it only accepts PEM formatted dh parameters, not raw primes in buffer format. Is this correct?cc: @shigeki
indutny commentedon Sep 13, 2015
@silverwind this is correct.
silverwind commentedon Sep 13, 2015
@indutny yeah, I figured out generating dhparam in node yesterday, thanks to your nice asn.1 module :)
shigeki commentedon Sep 14, 2015
@silverwind Yes, the supported format of
dhparamis PEM of PKCS#3 in buffer.F.Y.I. In the future, DH prime/base will not be explicitly written as a parameter and be changed to be written and negotiable in a built-in named group as https://tools.ietf.org/html/draft-ietf-tls-tls13-07 and https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.3.1.4.2 . So we will be able to write it as
ffdhe2048such likeprime256v1in ecparam.calvinmetcalf commentedon Dec 18, 2015
openssl related stuff might be a good candidate for things that should be in core due to how easy it is to get openssl wrong with consequences that can popup in unexpected ways
Trott commentedon Jun 8, 2016
Is there consensus that this does or doesn't belong in core? Or is that still up for debate?
jasnell commentedon Jun 9, 2016
I don't think there's consensus that it doesn't belong, but neither is there consensus that it would make it in. I think it's safe to say that it's unlikely this would make it in.
bnoordhuis commentedon Jun 9, 2016
I wouldn't necessarily object such additions but it's a bit of a slippery slope. For example:
Self-signed certificates are useless except for testing, so the logical next step is to support certificate signing using a CA key.
But once you allow that, you can make a case that creating CA keys with node should also be possible. And once that is in, it should probably also be taught how to do CRL management, etc., etc.
It would be a lot easier to simply link the openssl apps into the node binary so you could
node genrsa -out key.pem 2048. :-)Trott commentedon Jul 7, 2017
This issue has been inactive for sufficiently long that it seems like perhaps it should be closed. Feel free to re-open (or leave a comment requesting that it be re-opened) if you disagree. I'm just tidying up and not acting on a super-strong opinion or anything like that.
TomasHubelbauer commentedon Nov 8, 2020
Sorry to revive an old issue, but I'm wondering what the state of things is in 2020? Is it possible using the Node's
cryptomodule only to create a certificate, a key pair and then sign the certificate using the private key and serialize both to PEM without shelling out to OpenSSL? Essentially I'm wondering if this https://flaviocopes.com/express-https-self-signed-certificate/ can be done purely in NodeJS.I want to do this programmatically and in a cross-platform way for testing, hence my interest. The closest I found was:
https://stackoverflow.com/a/31624843/2715716
This uses Forge which I'd like to avoid (I'd rather use a built-in module for this, it doesn't feel right for crypto to be done by a non built-in module to me).
https://stackoverflow.com/q/51942824/2715716
This generates the key-pair and signs a general payload with it, but it doesn't contain code showing how to generate a payload that would encode a certificate. I'm neither capable enough to write that code myself nor knowledgeable enough to know whether that is possible given the above described constraints, and while I don't expect anyone more capable or knowledgeable than me to whip up this code, I'd be grateful for an answer to whether this is possible and what would it take.
theoparis commentedon Oct 25, 2025
I would also like to see this implemented as I wanted to programatically generate a certificate as well, without relying on a pure javascript implementation of openssl that hasn't been updated in over 4 years...