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.

  • (For now, as a workaround, I have to run this additional command to decrypt the key after it is created: openssl rsa -in mykey.pem. But I'd rather find the right way to get openssl req to work as documented.) – Stéphane May 26 '12 at 5:59
  • Works for me with 1.0.1 on Ubuntu Precise. – mgorven May 26 '12 at 6:01
  • The command works fine. The problem is the key is encrypted. The way you can tell is run it through "openssl rsa -in mykey.pem". If the input and output are not the same, then it means it was encrypted. – Stéphane May 26 '12 at 6:04
  • I mean that it runs and does not encrypt the private key. – mgorven May 26 '12 at 6:04
  • 1
    If it doesn't prompt for a passphrase then the key is not encrypted (there's nothing to encrypt it with). The output of openssl rsa being different doesn't mean that there's something wrong. Please specify what problem you're actually having when using the generated key. – mgorven May 26 '12 at 6:16

It looks like the default format has changed in later versions. Earlier versions appear to produce a PKCS#1 RSAPrivateKey format as denoted by


and the later versions generate a PKCS#8 PrivateKeyInfo format as denoted by


when you openssl rsa -in mykey.pem -out decryptedkey.pem you convert from #8 to #1

  • Perfect. Now I understand what has happened to require us to run the extra openssl rsa command. Thanks. – Stéphane May 26 '12 at 7:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.