web-dev-qa-db-fra.com

Quel est le but de l'argument -nodes dans openssl?

Quel est le but du -nodes argument dans openssl?

openssl
83
user624409

L'option -nodes n'est pas le mot anglais "nodes", mais plutôt "no DES". Lorsqu'il est donné en argument, cela signifie qu'OpenSSL ne chiffrera pas la clé privée dans un fichier PKCS # 12 .

Pour crypter la clé privée, vous pouvez omettre -nodes et votre clé sera cryptée avec 3DES-CBC. Pour chiffrer la clé, OpenSSL vous demande un mot de passe et il utilise ce mot de passe pour générer une clé de chiffrement à l'aide de la fonction de dérivation de clé EVP_BytesToKey .

Selon votre version d'OpenSSL et les options compilées, vous pouvez fournir ces options à la place de -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

Au final, au niveau de la bibliothèque, OpenSSL appelle la fonction PEM_write_bio_PrivateKey avec l'algorithme de chiffrement (ou son absence) que vous choisissez.

107
indiv

edit: nginx v1.7.3 a ajouté un ssl_password_file directive qui lit les mots de passe d'un fichier spécifié en essayant chaque phrase de passe sur le encrypted-private.key du contexte

indiv a raison que le -nodes l'argument signifie que OpenSSL créera UNencrypted private.key; sinon, il y aura une invite de phrase secrète pour créer encrypted-private.key. voir req , pkcs12 , CA.pl

cependant, je pense que le but (pour les programmeurs) est parce que:

  • Les serveurs HTTP (par exemple Apache , Nginx ) ne peuvent pas lire encrypted-private.key sans mot de passe →
    • Option A - à chaque démarrage du serveur HTTP, doit fournir une phrase secrète pour encrypted-private.key
    • Option B - spécifiez ssl_password_file file.keys; dans http { } ou server { } le contexte. [ ref ]
    • Option C - utilisez -nodes pour créer private.key sans chiffrement

utile: verrouiller private.key

  • {ajouter un serveur HTTP au ssl-cert groupe}
  • Sudo chown root:ssl-cert private.key - change posséderer de private.key to root user, ssl-cert group
  • Sudo chmod 640 private.key - modifiez les autorisations d'accès de private.key au propriétaire R/W, groupe R
  • maintenant, le serveur HTTP devrait pouvoir démarrer et lire UNencrypted private.key

Option A

une sécurité renforcée, mais au redémarrage du serveur, vous devez saisir manuellement la phrase secrète pour encrypted-private.key

Option B

sécurité moyenne, et probablement un bon équilibre entre la climatisation

Option C

sécurité plus faible, mais PAS invité à chiffrer UN private.key phrase secrète

12
Jake Berger