6

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.

Stéphane
  • 456
  • 1
  • 7
  • 16
  • (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 05:59
  • Works for me with 1.0.1 on Ubuntu Precise. – mgorven May 26 '12 at 06: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 06:04
  • I mean that it runs and does not encrypt the private key. – mgorven May 26 '12 at 06:04
  • Hmm. Strange. We have several rigs at work running Ubuntu 12.04, in addition to my home desktop, and on all of them this fails. – Stéphane May 26 '12 at 06:08
  • So it always prompts you to enter a passphrase? – mgorven May 26 '12 at 06:09
  • It never prompts me for a passphrase. But the the input and output key is different, which tells me it decrypts <something>. And until the key is decrypted, it cannot be used as input into another system which is expecting a decrypted key+cert. – Stéphane May 26 '12 at 06:11
  • 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 06:16

1 Answers1

8

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

-----BEGIN RSA PRIVATE KEY-----

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

-----BEGIN PRIVATE KEY-----

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

user9517
  • 115,471
  • 20
  • 215
  • 297
  • Perfect. Now I understand what has happened to require us to run the extra `openssl rsa` command. Thanks. – Stéphane May 26 '12 at 07:50