Яка мета аргументу -nodes у openssl?

Яка мета -nodesаргументу у openssl?

Параметр -nodes- не англійське слово "nodes", а скоріше "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 з алгоритмом шифрування (або його відсутністю).

редагувати: nginx v1.7.3 додав директиву ssl_password_file, яка читає парольні фрази із зазначеного файлу, намагаючись кожну парольну фразу на зашифрованому приватному ключі контексту.

indiv правильний, що -nodesаргумент означає, що OpenSSL створить незашифрований private.key ; інакше з'явиться запит із парольною фразою для створення шифрованого-private.key . див. req , pkcs12 , CA.pl

однак я вважаю, що мета (для програмістів) полягає в тому, що:

• HTTP-сервери (наприклад, Apache , Nginx ) не можуть читати зашифровані-private.key без парольної фрази →
  • Варіант A - кожен раз, коли HTTP-сервер запускається, повинен надати парольну фразу для encrypted-private.key
  • Варіант В - вкажіть ssl_password_file file.keys;у контексті http { }чи в server { }контексті. [ ref ]
  • Варіант С - використовувати -nodesдля створення private.key без шифрування

корисно: заблокуйте private.key

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

Варіант А

Більш сильна безпека, але при перезапуску сервера доводиться вручну вводити пароль для encrypted-private.key

Варіант В

середня безпека та, ймовірно, хороший баланс між кондиціонерами

Варіант С

слабша безпека, але НЕ запропоновано незашифрований пароль. private.key