What is the purpose of the -nodes argument in openssl?

Solution 1:

The option -nodes is not the English word "nodes", but rather is "no DES". When given as an argument, it means OpenSSL will not encrypt the private key in a PKCS#12 file.

To encrypt the private key, you can omit -nodes and your key will be encrypted with 3DES-CBC. To encrypt the key, OpenSSL prompts you for a password and it uses that password to generate an encryption key using the key-derivation function EVP_BytesToKey.

Depending on your version of OpenSSL and compiled options, you may be able to provide these options in place of -nodes:

-des          encrypt private keys with DES
-des3         encrypt private keys with triple DES (default)
-idea         encrypt private keys with idea
-seed         encrypt private keys with seed
-aes128, -aes192, -aes256
              encrypt PEM output with cbc aes
-camellia128, -camellia192, -camellia256
              encrypt PEM output with cbc camellia

Ultimately at the library level OpenSSL calls the function PEM_write_bio_PrivateKey with the encryption algorithm (or lack thereof) you choose.

Solution 2:

edit: nginx v1.7.3 has added an ssl_password_file directive which reads passphrases from a specified file trying each passphrase on the context's encrypted-private.key

indiv is correct that the -nodes argument means that OpenSSL will create UNencrypted private.key; otherwise, there will be a passphrase prompt to create encrypted-private.key. see req, pkcs12, CA.pl

however, I feel the purpose (for programmers) is because:

• HTTP servers (e.g. Apache, Nginx) cannot read encrypted-private.key without passphrase →
  • Option A - each time HTTP server starts, must provide passphrase for encrypted-private.key
  • Option B - specify ssl_password_file file.keys; in http { } or server { } context. [ref]
  • Option C - use -nodes to create private.key without encryption

useful: lock down private.key

• { add HTTP server to ssl-cert group }
• sudo chown root:ssl-cert private.key - change owner of private.key to root user, ssl-cert group
• sudo chmod 640 private.key - change access permissions of private.key to owner R/W, group R
• now, HTTP server should be able to start and read UNencrypted private.key

Option A

stronger security, yet when server restarts, have to manually type in passphrase for encrypted-private.key

Option B

medium security, and probably good balance between A/C

Option C

weaker security, yet NOT prompted for UNencrypted private.key passphrase