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.