softpedia - ¿Cuál es el propósito del argumento-nodes en openssl?

openssl softpedia (2)

¿Cuál es el propósito del argumento -nodes en openssl?

La opción -nodes no es la palabra en inglés "nodes", sino que es "no DES". Cuando se presenta como argumento, significa que OpenSSL no encriptará la clave privada en un archivo PKCS # 12 .

Para encriptar la clave privada, puede omitir -nodes y su clave se cifrará con 3DES-CBC. Para encriptar la clave, OpenSSL le solicita una contraseña y usa esa contraseña para generar una clave de cifrado usando la función de derivación de clave EVP_BytesToKey .

Dependiendo de su versión de OpenSSL y las opciones compiladas, puede proporcionar estas opciones en 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

Finalmente, en el nivel de la biblioteca, OpenSSL llama a la función PEM_write_bio_PrivateKey con el algoritmo de cifrado (o la falta del mismo) que elija.

editar: nginx v1.7.3 ha agregado una directiva ssl_password_file que lee las frases de contraseña de un archivo específico probando cada frase de contraseña en la clave privada encriptada del contexto

indiv es correcto que el argumento -nodes significa que OpenSSL creará una clave privada no encriptada ; de lo contrario, aparecerá un mensaje de frase de contraseña para crear una clave privada encriptada . ver req , pkcs12 , CA.pl

sin embargo, creo que el propósito (para los programadores) es porque:

Los servidores HTTP (por ejemplo, Apache , Nginx ) no pueden leer la clave privada encriptada sin contraseña →
- Opción A: cada vez que se inicia el servidor HTTP, debe proporcionar una frase de contraseña para clave privada cifrada
- Opción B: especifique ssl_password_file file.keys; en el contexto http { } o server { } . [ ref ]
- Opción C: -nodes uso para crear private.key sin cifrado

útil: bloquear private.key

{agregar servidor HTTP al grupo ssl-cert }
sudo chown root:ssl-cert private.key - ch ange propietario de private.key para usuario root , grupo ssl-cert
sudo chmod 640 private.key - cambie los permisos de acceso de private.key al propietario R / W, grupo R
ahora, el servidor HTTP debería poder iniciar y leer la clave privada no cifrada.

Opción A

mayor seguridad, sin embargo, cuando el servidor se reinicia, tiene que escribir manualmente la frase de contraseña para clave privada encriptada

Opción B

seguridad media, y probablemente un buen equilibrio entre A / C

Opción C

seguridad más débil, pero NO se le solicitó una contraseña secreta privada no encriptada