When using openssl 0.9.8 to create a new self-signed cert+key, there is a -nodes parameter that can be used to tell openssl to not encrypt the private key it creates. For example:
openssl req -x509 -nodes -days 365 \ -subj '/C=US/ST=Florida/L=Jupiter/CN=test.com' \ -newkey rsa:1024 -keyout mykey.pem -out mycert.pem But with the new openssl v1.0.1, it seems as if the -nodes parameter is ignored. From what I can tell, the private key is always encrypted. Am I using openssl wrong? Is there a different parameter I should be using instead?
The -nodes parameter is documented to mean:
if this option is specified then if a private key is created it will not be encrypted Source: http://www.openssl.org/docs/apps/req.html#item__nodes
More details as asked:
With openssl 0.9.8, the key + cert can be directly imported into other 3rd-party devices we have which expect un-encrypted keys and certs. This works without any problem.
But when using openssl 1.0.1, these 3rd-party devices complain the key is invalid. The exact error message is:
ERROR: Private key for 'My Cert' does not appear to be a valid RSA private key in PEM format. This is a closed source system, and it doesn't provide additional details. What I've discovered through playing around with it today is if I run the v1.0.1 private key through this command:
openssl rsa -in mykey.pem -out decryptedkey.pem ...then at that point this 3rd party system has no problem importing the cert and the decrypted key. And when I run this command on the v1.0.1 key:
openssl rsa -text -in mykey.pem ...the text of the private key is not the same as what is in the v1.0.1 mykey.pem file. This is why I thought the key was somehow encrypted.
openssl rsa -in mykey.pem. But I'd rather find the right way to getopenssl reqto work as documented.)openssl rsabeing different doesn't mean that there's something wrong. Please specify what problem you're actually having when using the generated key.