Какова цель аргумента -nodes в openssl?

Ответ 1

Опция -nodes не является английским словом "узлы", а скорее "нет DES". Если данный аргумент указан, это означает, что OpenSSL не будет шифровать закрытый ключ в файле PKCS # 12.

Чтобы зашифровать закрытый ключ, вы можете опустить -nodes, и ваш ключ будет зашифрован с помощью 3DES-CBC. Чтобы зашифровать ключ, OpenSSL запрашивает пароль и использует этот пароль для генерации ключа шифрования с помощью функции вывода ключа EVP_BytesToKey.

В зависимости от вашей версии OpenSSL и скомпилированных опций вы можете предоставить эти параметры вместо -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

В конечном счете на уровне библиотеки OpenSSL вызывает функцию PEM_write_bio_PrivateKey с выбранным алгоритмом шифрования (или отсутствием).

Ответ 2

edit: nginx v1.7.3 добавила директиву ssl_password_file, которая считывает кодовые фразы из заданного файла, пробовавшего каждую кодовую фразу в контексте encrypted-private.key

indiv правильно, что аргумент -nodes означает, что OpenSSL будет создавать UNencrypted private.key; в противном случае будет предложено ввести парольную фразу для создания encrypted-private.key. см. req, pkcs12, CA.pl

однако, я считаю, что цель (для программистов) заключается в следующем:

• HTTP-серверы (например, Apache, Nginx) не может читать encrypted-private.key без passphrase →
  • Параметр A - каждый раз, когда запускается HTTP-сервер, необходимо предоставить парольную фразу для encrypted-private.key
  • Вариант B - укажите ssl_password_file file.keys; в контексте http { } или server { }. [ref]
  • Вариант C - используйте -nodes для создания private.key без шифрования.

полезно: заблокировать private.key

• {добавить HTTP-сервер в группу ssl-cert}
• sudo chown root:ssl-cert private.key - ch ange собственный пользователь private.key для пользователя root, ssl-cert group
• sudo chmod 640 private.key - изменить права доступа private.key к владельцу R/W, группа R
• теперь HTTP-сервер должен иметь возможность запускать и читать UNencrypted private.key

Вариант A

более высокая безопасность, но при перезапуске сервера необходимо вручную ввести парольную фразу для encrypted-private.key

Вариант B

средняя безопасность и, вероятно, хороший баланс между A/C

Вариант C

более слабая безопасность, но НЕ запрашивается для ключевой фразы UNencrypted private.key