Qual é o propósito do argumento -nodes no openssl?

Qual é o propósito do -nodesargumento em openssl?

A opção -nodesnão é a palavra em inglês "nodes", mas sim "no DES". Quando fornecido como um argumento, significa que o OpenSSL não criptografará a chave privada em um arquivo PKCS # 12 .

Para criptografar a chave privada, você pode omitir -nodese sua chave será criptografada com 3DES-CBC. Para criptografar a chave, o OpenSSL solicita uma senha e usa essa senha para gerar uma chave de criptografia usando a função de derivação de chave EVP_BytesToKey .

Dependendo da sua versão do OpenSSL e das opções compiladas, você pode fornecer essas opções no lugar 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

Em última análise, no nível da biblioteca, o OpenSSL chama a função PEM_write_bio_PrivateKey com o algoritmo de criptografia (ou a falta dele) que você escolher.

edit: nginx v1.7.3 adicionou uma diretiva ssl_password_file que lê as frases-senha de um arquivo especificado tentando cada frase-senha na chave privada criptografada do contexto

indiv é correto que os -nodesmeios de argumentos que OpenSSL criarão UNENCRYPTED private.key ; caso contrário, haverá um prompt de senha para criar criptografado-privado.key . consulte req , pkcs12 , CA.pl

no entanto, sinto que o objetivo (para programadores) é porque:

• Os servidores HTTP (por exemplo , Apache , Nginx ) não podem ler chave privada criptografada sem senha →
  • Opção A - cada vez que o servidor HTTP for iniciado, deve fornecer senha para criptografado-privado.key
  • Opção B - especifique ssl_password_file file.keys;em http { }ou server { }contexto. [ ref ]
  • Opção C - use -nodespara criar private.key sem criptografia

útil: bloquear private.key

• {adicionar servidor HTTP ao grupo SSL-cert }
• sudo chown root:ssl-cert private.key- ch ange própria er de private.key a raiz do usuário, ssl-cert grupo
• sudo chmod 640 private.key- alterar as permissões de acesso da chave privada para o proprietário R / W, grupo R
• agora, servidor HTTP deve ser capaz de iniciar e ler sem criptografia private.key

Opção A

segurança mais forte, mas quando o servidor for reiniciado, terá que digitar manualmente a senha para criptografada-privada.key

Opção B

segurança média e provavelmente bom equilíbrio entre A / C

Opção C

segurança mais fraco, ainda não solicitado para não criptografadas private.key senha