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

Question

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

Answer 1

Параметр -nodes - это не английское слово «node», а «no 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 с выбранным вами алгоритмом шифрования (или его отсутствием).

Answer 2

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

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

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

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

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

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

Вариант A

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

Вариант B

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

Вариант C

более слабая защита, но НЕ запрашивается для незашифрованного private.key passphrase