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 contextohttp { }
oserver { }
. [ 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