instalar - habilitar ssl apache2

¿Cómo crear un certificado autofirmado con openssl? (13)

Estoy agregando soporte https a un dispositivo linux incrustado. He intentado generar un certificado autofirmado con estos pasos:

openssl req -new > cert.csr openssl rsa -in privkey.pem -out key.pem openssl x509 -in cert.csr -out cert.pem -req -signkey key.pem -days 1001 cat key.pem>>cert.pem

Esto funciona, pero recibo algunos errores con, por ejemplo, google chrome:

¡Probablemente este no sea el sitio que estás buscando!
Certificado de seguridad del sitio no es de confianza!

¿Me estoy perdiendo de algo? ¿Es esta la forma correcta de construir un certificado autofirmado?

Generar claves
Estoy utilizando /etc/mysql para el almacenamiento de /etc/apparmor.d/usr.sbin.mysqld porque /etc/apparmor.d/usr.sbin.mysqld contiene /etc/mysql/*.pem r .
sudo su - cd /etc/mysql openssl genrsa -out ca-key.pem 2048; openssl req -new -x509 -nodes -days 1000 -key ca-key.pem -out ca-cert.pem; openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem -out server-req.pem; openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem; openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem -out client-req.pem; openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem;
Agregar configuracion
/etc/mysql/my.cnf

[client] ssl-ca=/etc/mysql/ca-cert.pem ssl-cert=/etc/mysql/client-cert.pem ssl-key=/etc/mysql/client-key.pem [mysqld] ssl-ca=/etc/mysql/ca-cert.pem ssl-cert=/etc/mysql/server-cert.pem ssl-key=/etc/mysql/server-key.pem

En mi configuración, el servidor ubuntu inició sesión en: /var/log/mysql/error.log

Notas de seguimiento:

SSL error: Unable to get certificate from ''...''

Es posible que a Mysql se le niegue el acceso de lectura a su archivo de certificado si no está en la configuración de los armadores . Como se mencionó en los pasos anteriores ^, Guarde todos nuestros .pem como archivos .pem en el directorio /etc/mysql/ que está aprobado de forma predeterminada por el armador (o modifique su apparmor / SELinux para permitir el acceso a donde sea que los haya guardado).
SSL error: Unable to get private key

Es posible que la versión de su servidor mysql no admita el formato rsa:2048 predeterminado.
Encubierto generado rsa:2048 a rsa simple con:
openssl rsa -in server-key.pem -out server-key.pem openssl rsa -in client-key.pem -out client-key.pem
Compruebe si el servidor local soporta ssl :
mysql -u root -p mysql> show variables like "%ssl%"; +---------------+----------------------------+ | Variable_name | Value | +---------------+----------------------------+ | have_openssl | YES | | have_ssl | YES | | ssl_ca | /etc/mysql/ca-cert.pem | | ssl_capath | | | ssl_cert | /etc/mysql/server-cert.pem | | ssl_cipher | | | ssl_key | /etc/mysql/server-key.pem | +---------------+----------------------------+
Verificando que una conexión a la base de datos es ssl encriptado :
Verificación de conexión
Cuando inicie sesión en la instancia de MySQL, puede emitir la consulta:
show status like ''Ssl_cipher'';
Si su conexión no está encriptada, el resultado estará en blanco:
mysql> show status like ''Ssl_cipher''; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Ssl_cipher | | +---------------+-------+ 1 row in set (0.00 sec)
De lo contrario, mostraría una cadena de longitud distinta de cero para el cifrado en uso:
mysql> show status like ''Ssl_cipher''; +---------------+--------------------+ | Variable_name | Value | +---------------+--------------------+ | Ssl_cipher | DHE-RSA-AES256-SHA | +---------------+--------------------+ 1 row in set (0.00 sec)
Requiere ssl para la conexión del usuario específico (''require ssl''):
- SSL
Le dice al servidor que permita solo conexiones cifradas SSL para la cuenta.
GRANT ALL PRIVILEGES ON test.* TO ''root''@''localhost'' REQUIRE SSL;
Para conectarse, el cliente debe especificar la opción --ssl-ca para autenticar el certificado del servidor y, además, puede especificar las opciones --ssl-key y --ssl-cert. Si no se especifica la opción --ssl-ca ni la opción --ssl-capath, el cliente no autentica el certificado del servidor.

Enlace alternativo: tutorial extenso aquí http://www.madirish.net/214

¿Me estoy perdiendo de algo? ¿Es esta la forma correcta de construir un certificado autofirmado?

Es fácil crear un certificado autofirmado. Solo usa el comando openssl req . Puede ser complicado crear uno que pueda ser consumido por la mayor selección de clientes, como navegadores y herramientas de línea de comandos.

Es difícil porque los navegadores tienen su propio conjunto de requisitos y son más restrictivos que el IETF. Los requisitos utilizados por los navegadores están documentados en los foros de CA / Browser (consulte las referencias a continuación). Las restricciones surgen en dos áreas clave: (1) anclajes de confianza y (2) nombres DNS.

Los navegadores modernos (como el warez que estamos usando en 2014/2015) quieren un certificado que se encadena de nuevo a un ancla de confianza, y quieren que los nombres de DNS se presenten de manera particular en el certificado. Y los navegadores se están moviendo activamente contra los certificados de servidor autofirmados

Algunos navegadores no facilitan exactamente la importación de un certificado de servidor autofirmado. De hecho, no puedes con algunos navegadores, como el navegador de Android. Así que la solución completa es convertirse en tu propia autoridad.

En ausencia de convertirse en su propia autoridad, debe obtener los nombres de DNS correctos para otorgar al certificado la mayor posibilidad de éxito. Pero te animo a que te conviertas en tu propia autoridad. Es fácil convertirse en su propia autoridad y evitará todos los problemas de confianza (¿en quién es mejor confiar que usted?).

¡Probablemente este no sea el sitio que estás buscando!
Certificado de seguridad del sitio no es de confianza!

Esto se debe a que los navegadores utilizan una lista predefinida de anclajes de confianza para validar los certificados de servidor. Un certificado autofirmado no se encadena a un ancla de confianza.

La mejor manera de evitar esto es:

Crea tu propia autoridad (es decir, conviértete en un CA)
Crear una solicitud de firma de certificado (CSR) para el servidor
Firma la CSR del servidor con tu clave de CA
Instale el certificado del servidor en el servidor
Instalar el certificado de CA en el cliente.

Paso 1: crear su propia autoridad solo significa crear un certificado autofirmado con CA: true uso de clave CA: true y correcto. Eso significa que el Asunto y el Emisor son la misma entidad, CA se establece en verdadero en Restricciones Básicas (también debe marcarse como crítica), el uso de la clave es keyCertSign y crlSign (si está usando CRL), y el Identificador de Clave del Asunto (SKI) ) es el mismo que el identificador de clave de autoridad (AKI).

Para convertirse en su propia autoridad de certificación, consulte ¿Cómo firma la Solicitud de firma de certificado con su Autoridad de certificación? en desbordamiento de pila. Luego, importe su CA en el Trust Store que usa el navegador.

Los pasos 2 a 4 son aproximadamente lo que hace ahora para un servidor público cuando contrata los servicios de una CA como Startcom o CAcert . Los pasos 1 y 5 le permiten evitar la autoridad de terceros y actuar como su propia autoridad (¿en quién es mejor confiar que usted?).

La siguiente mejor manera de evitar la advertencia del navegador es confiar en el certificado del servidor. Pero algunos navegadores, como el navegador predeterminado de Android, no te permiten hacerlo. Así que nunca funcionará en la plataforma.

El problema de los navegadores (y otros agentes de usuarios similares) que no confían en los certificados autofirmados va a ser un gran problema en el Internet de las cosas (IoT). Por ejemplo, ¿qué sucederá cuando lo conecte a su termostato o refrigerador para programarlo? La respuesta es, nada bueno en lo que se refiere a la experiencia del usuario.

El Grupo de Trabajo WebAppSec del W3C está comenzando a analizar el problema. Ver, por ejemplo, Propuesta: Marcar HTTP como no seguro .

¿Cómo crear un certificado autofirmado con openssl?

Los comandos a continuación y el archivo de configuración crean un certificado autofirmado (también le muestra cómo crear una solicitud de firma). Se diferencian de otras respuestas en un aspecto: los nombres DNS utilizados para el certificado autofirmado están en el nombre alternativo del sujeto (SAN) , y no el nombre común (CN) .

Los nombres DNS se colocan en la SAN a través del archivo de configuración con la línea subjectAltName = @alternate_names (no hay forma de hacerlo a través de la línea de comandos). Luego hay una sección de nombres alternate_names en el archivo de configuración (debe ajustar esto para que se ajuste a sus gustos):

[ alternate_names ] DNS.1 = example.com DNS.2 = www.example.com DNS.3 = mail.example.com DNS.4 = ftp.example.com # Add these if you need them. But usually you don''t want them or # need them in production. You may need them for development. # DNS.5 = localhost # DNS.6 = localhost.localdomain # DNS.7 = 127.0.0.1 # IPv6 localhost # DNS.8 = ::1

Es importante poner el nombre de DNS en la SAN y no en la CN, ya que tanto el IETF como los foros de CA / Browser especifican la práctica. También especifican que los nombres de DNS en el CN están en desuso (pero no están prohibidos). Si coloca un nombre de DNS en el CN, debe incluirse en la SAN en las políticas de CA / B. Así que no puedes evitar usar el nombre alternativo del sujeto.

Si no coloca los nombres de DNS en la SAN, entonces el certificado no podrá validarse en un navegador y otros agentes de usuario que sigan las pautas de CA / Foro de navegador.

Relacionados: los navegadores siguen las políticas de CA / Browser Forum; y no las políticas del IETF. Esa es una de las razones por las que un certificado creado con OpenSSL (que generalmente sigue el IETF) a veces no se valida en un navegador (los navegadores siguen la CA / B). Son estándares diferentes, tienen diferentes políticas de emisión y diferentes requisitos de validación.

Cree un certificado autofirmado (observe la adición de la opción -x509 ):

openssl req -config example-com.conf -new -x509 -sha256 -newkey rsa:2048 -nodes / -keyout example-com.key.pem -days 365 -out example-com.cert.pem

Cree una solicitud de firma (note la falta de la opción -x509 ):

openssl req -config example-com.conf -new -sha256 -newkey rsa:2048 -nodes / -keyout example-com.key.pem -days 365 -out example-com.req.pem

Imprima un certificado autofirmado :

openssl x509 -in example-com.cert.pem -text -noout

Imprimir una solicitud de firma :

openssl req -in example-com.req.pem -text -noout

Archivo de configuración (pasado a través de la opción -config )

[ req ] default_bits = 2048 default_keyfile = server-key.pem distinguished_name = subject req_extensions = req_ext x509_extensions = x509_ext string_mask = utf8only # The Subject DN can be formed using X501 or RFC 4514 (see RFC 4519 for a description). # Its sort of a mashup. For example, RFC 4514 does not provide emailAddress. [ subject ] countryName = Country Name (2 letter code) countryName_default = US stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = NY localityName = Locality Name (eg, city) localityName_default = New York organizationName = Organization Name (eg, company) organizationName_default = Example, LLC # Use a friendly name here because its presented to the user. The server''s DNS # names are placed in Subject Alternate Names. Plus, DNS names here is deprecated # by both IETF and CA/Browser Forums. If you place a DNS name here, then you # must include the DNS name in the SAN too (otherwise, Chrome and others that # strictly follow the CA/Browser Baseline Requirements will fail). commonName = Common Name (e.g. server FQDN or YOUR name) commonName_default = Example Company emailAddress = Email Address emailAddress_default = [email protected] # Section x509_ext is used when generating a self-signed certificate. I.e., openssl req -x509 ... [ x509_ext ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer # You only need digitalSignature below. *If* you don''t allow # RSA Key transport (i.e., you use ephemeral cipher suites), then # omit keyEncipherment because that''s key transport. basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment subjectAltName = @alternate_names nsComment = "OpenSSL Generated Certificate" # RFC 5280, Section 4.2.1.12 makes EKU optional # CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused # In either case, you probably only need serverAuth. # extendedKeyUsage = serverAuth, clientAuth # Section req_ext is used when generating a certificate signing request. I.e., openssl req ... [ req_ext ] subjectKeyIdentifier = hash basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment subjectAltName = @alternate_names nsComment = "OpenSSL Generated Certificate" # RFC 5280, Section 4.2.1.12 makes EKU optional # CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused # In either case, you probably only need serverAuth. # extendedKeyUsage = serverAuth, clientAuth [ alternate_names ] DNS.1 = example.com DNS.2 = www.example.com DNS.3 = mail.example.com DNS.4 = ftp.example.com # Add these if you need them. But usually you don''t want them or # need them in production. You may need them for development. # DNS.5 = localhost # DNS.6 = localhost.localdomain # DNS.7 = 127.0.0.1 # IPv6 localhost # DNS.8 = ::1

Es posible que deba hacer lo siguiente para Chrome. De lo contrario, Chrome puede quejarse de que un nombre común no es válido ( ERR_CERT_COMMON_NAME_INVALID ) . No estoy seguro de cuál es la relación entre una dirección IP en la SAN y una CN en esta instancia.

# IPv4 localhost # IP.1 = 127.0.0.1 # IPv6 localhost # IP.2 = ::1

Existen otras reglas relacionadas con el manejo de nombres DNS en los certificados X.509 / PKIX. Consulte estos documentos para las reglas:

RFC 5280, perfil de la lista de revocación de certificados (CRL) de la infraestructura de claves públicas de Internet X.509
RFC 6125, Representación y verificación de la identidad del servicio de aplicación basada en dominio dentro de la infraestructura de clave pública de Internet usando certificados X.509 (PKIX) en el contexto de seguridad de la capa de transporte (TLS)
RFC 6797, Apéndice A, Seguridad de transporte estricta de HTTP (HSTS)
RFC 7469, Extensión de fijación de clave pública para HTTP
Requisitos básicos de CA / Browser Forum
Pautas de validación extendida de CA / Browser Forum

RFC 6797 y RFC 7469 están listados porque son más restrictivos que los otros RFC y los documentos CA / B. Los números 6797 y 7469 de RFC tampoco permiten una dirección IP.

2017 One liner:

openssl req / -newkey rsa:2048 / -x509 / -nodes / -keyout server.pem / -new / -out server.pem / -subj /CN=localhost / -reqexts SAN / -extensions SAN / -config <(cat /System/Library/OpenSSL/openssl.cnf / <(printf ''[SAN]/nsubjectAltName=DNS:localhost'')) / -sha256 / -days 3650

Esto también funciona en Chrome 57, ya que proporciona la SAN, sin tener otro archivo de configuración. Tomado de una respuesta here . Esto crea un solo archivo .pem que contiene tanto la clave privada como el certificado. Puede moverlos a archivos .pem separados si es necesario.

Aquí están las opciones descritas en la respuesta de @ diegows , descritas con más detalle, en la documentación :

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days XXX

req
Solicitud de certificado PKCS # 10 y utilidad de generación de certificado.
-x509
esta opción genera un certificado autofirmado en lugar de una solicitud de certificado. Esto se suele utilizar para generar un certificado de prueba o una CA raíz autofirmada.
-newkey arg
esta opción crea una nueva solicitud de certificado y una nueva clave privada. El argumento toma una de varias formas. rsa: nbits , donde nbits es el número de bits, genera una clave RSA de nbits de tamaño.
-keyout filename
esto le da al nombre de archivo para escribir la clave privada recién creada.
-out filename
Esto especifica el nombre de archivo de salida para escribir o salida estándar de forma predeterminada.
-days n
cuando se utiliza la opción -x509, esto especifica el número de días para certificar el certificado. El valor predeterminado es 30 días.
-nodes
Si se especifica esta opción, si se crea una clave privada, no se cifrará.

La documentación es en realidad más detallada que la anterior, acabo de resumirla aquí.

El siguiente comando sirve a todas sus necesidades:

openssl req -x509 -newkey rsa:4096 -sha256 -nodes -keyout example.key -out example.crt -subj "/CN=example.com" -days 3650

Crea un certificado para el dominio example.com que es

relativamente fuerte (a partir de 2018) y
válido por 3650 días (~ 10 años).

Crea los siguientes archivos:

Clave privada: example.key
Certificado: example.crt

Como toda la información se proporciona en la línea de comandos, no hay una entrada interactiva molesta. Además, todos los pasos necesarios se ejecutan con esta única invocación de OpenSSL: desde la generación de clave privada hasta el certificado autofirmado.

Dado que el certificado es autofirmado y debe ser aceptado por los usuarios manualmente, no tiene sentido usar una caducidad corta o una criptografía débil.

En el futuro, es posible que desee usar más de 4096 bits para la clave RSA y un algoritmo hash más sha256 que sha256 , pero a partir de 2018 estos son valores sha256 . Son lo suficientemente fuertes al tiempo que son compatibles con todos los navegadores modernos.

Nota: en teoría, podría omitir el parámetro -nodes (que significa "sin cifrado DES"), en cuyo caso example.key se cifraría con una contraseña. Sin embargo, esto casi nunca es útil para la instalación de un servidor, ya que tendría que almacenar la contraseña en el servidor también, o tendría que ingresarla manualmente en cada reinicio.

Este es el script que utilizo en los cuadros locales para configurar el SAN (subjectAltName) en certificados autofirmados.

Esta secuencia de comandos toma el nombre de dominio (example.com) y genera la SAN para * .example.com y example.com en el mismo certificado. Las secciones a continuación están comentadas. Asigne un nombre a la secuencia de comandos (por ejemplo, generate-ssl.sh ) y déle permisos ejecutables. Los archivos se escribirán en el mismo directorio que el script.

Chrome 58 y versiones posteriores requieren que SAN se configure en certificados autofirmados.

#!/usr/bin/env bash # Set the TLD domain we want to use BASE_DOMAIN="example.com" # Days for the cert to live DAYS=1095 # A blank passphrase PASSPHRASE="" # Generated configuration file CONFIG_FILE="config.txt" cat > $CONFIG_FILE <<-EOF [req] default_bits = 2048 prompt = no default_md = sha256 x509_extensions = v3_req distinguished_name = dn [dn] C = CA ST = BC L = Vancouver O = Example Corp OU = Testing Domain emailAddress = webmaster@$BASE_DOMAIN CN = $BASE_DOMAIN [v3_req] subjectAltName = @alt_names [alt_names] DNS.1 = *.$BASE_DOMAIN DNS.2 = $BASE_DOMAIN EOF # The file name can be anything FILE_NAME="$BASE_DOMAIN" # Remove previous keys echo "Removing existing certs like $FILE_NAME.*" chmod 770 $FILE_NAME.* rm $FILE_NAME.* echo "Generating certs for $BASE_DOMAIN" # Generate our Private Key, CSR and Certificate # Use SHA-2 as SHA-1 is unsupported from Jan 1, 2017 openssl req -new -x509 -newkey rsa:2048 -sha256 -nodes -keyout "$FILE_NAME.key" -days $DAYS -out "$FILE_NAME.crt" -passin pass:$PASSPHRASE -config "$CONFIG_FILE" # OPTIONAL - write an info to see the details of the generated crt openssl x509 -noout -fingerprint -text < "$FILE_NAME.crt" > "$FILE_NAME.info" # Protect the key chmod 400 "$FILE_NAME.key"

Esta secuencia de comandos también escribe un archivo de información para que pueda inspeccionar el nuevo certificado y verificar que la SAN esté configurada correctamente.

... 28:dd:b8:1e:34:b5:b1:44:1a:60:6d:e3:3c:5a:c4: da:3d Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Alternative Name: DNS:*.example.com, DNS:example.com Signature Algorithm: sha256WithRSAEncryption 3b:35:5a:d6:9e:92:4f:fc:f4:f4:87:78:cd:c7:8d:cd:8c:cc: ...

Si está utilizando Apache, puede hacer referencia al certificado anterior en su archivo de configuración de la siguiente manera:

<VirtualHost _default_:443> ServerName example.com ServerAlias www.example.com DocumentRoot /var/www/htdocs SSLEngine on SSLCertificateFile path/to/your/example.com.crt SSLCertificateKeyFile path/to/your/example.com.key </VirtualHost>

Recuerde reiniciar su servidor Apache (o Nginx o IIS) para que el nuevo certificado tenga efecto.

Los navegadores modernos ahora lanzan un error de seguridad para certificados autofirmados que, de otra manera, están bien formados si les falta una SAN (Nombre alternativo del sujeto). OpenSSL no proporciona una forma de línea de comandos para especificar esto , por lo que los tutoriales y marcadores de muchos desarrolladores están obsoletos de repente.

La forma más rápida de volver a ejecutar es un archivo conf corto e independiente:

Cree un archivo de configuración de OpenSSL (ejemplo: req.cnf )
[req] distinguished_name = req_distinguished_name x509_extensions = v3_req prompt = no [req_distinguished_name] C = US ST = VA L = SomeCity O = MyCompany OU = MyDivision CN = www.company.com [v3_req] keyUsage = critical, digitalSignature, keyAgreement extendedKeyUsage = serverAuth subjectAltName = @alt_names [alt_names] DNS.1 = www.company.com DNS.2 = company.com DNS.3 = company.net
Crear el certificado que hace referencia a este archivo de configuración.
openssl req -x509 -nodes -days 730 -newkey rsa:2048 / -keyout cert.key -out cert.pem -config req.cnf -sha256

Ejemplo de configuración de https://support.citrix.com/article/CTX135602

No puedo comentar, así que pondré esto como una respuesta separada. Encontré algunos problemas con la respuesta de una sola línea aceptada:

El one-liner incluye una frase de contraseña en la clave.
El one-liner usa SHA1 que en muchos navegadores lanza advertencias en la consola.

Aquí hay una versión simplificada que elimina la contraseña, aumenta la seguridad para suprimir las advertencias e incluye una sugerencia en los comentarios para pasar en -subj para eliminar la lista completa de preguntas:

openssl genrsa -out server.key 2048 openssl rsa -in server.key -out server.key openssl req -sha256 -new -key server.key -out server.csr -subj ''/CN=localhost'' openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt

Reemplace ''localhost'' con cualquier dominio que requiera. Deberá ejecutar los dos primeros comandos uno por uno, ya que openssl le pedirá una frase de contraseña.

Para combinar los dos en un archivo .pem:

cat server.crt server.key > cert.pem

Puedes hacer eso en un comando:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365

También puede agregar -nodes (abreviados para no DES ) si no desea proteger su clave privada con una frase de contraseña, de lo contrario le pedirá una contraseña de "al menos 4 caracteres". El parámetro días (365) que puede reemplazar con cualquier número para afectar la fecha de vencimiento. A continuación, le pedirá que ingrese cosas como "Nombre del país", pero simplemente puede pulsar Intro y aceptar valores predeterminados.

Agregue -subj ''/CN=localhost'' para suprimir las preguntas sobre el contenido del certificado (reemplace localhost con su dominio deseado)

Los certificados autofirmados no se validan con terceros a menos que los importe a los navegadores previamente. Si necesita más seguridad, debe usar un certificado firmado por una CA.

Recomendaría agregar el parámetro -sha256 , para usar el algoritmo hash SHA-2, ya que los principales navegadores están considerando mostrar "certificados SHA-1" como no seguros.

La misma línea de comando de la respuesta aceptada - @diegows con agregado -sha256

openssl req -x509 -sha256 -newkey rsa: 2048 -keyout key.pem -out cert.pem -days XXX

Más información en el blog de seguridad de Google .

Actualización de mayo de 2018. Como muchos indicaron en los comentarios, el uso de SHA-2 no agrega ninguna seguridad al certificado autofirmado. Pero todavía recomiendo usarlo como un buen hábito de no usar funciones hash criptográficas obsoletas / inseguras. La explicación completa está disponible en: https://security.stackexchange.com/questions/91913/why-is-it-fine-for-certificates-above-the-end-entity-certificate-to-be-sha1-base

Tienes el procedimiento general correcto. La sintaxis para el comando está abajo.

openssl req -new -key {private key file} -out {output file}

Sin embargo, las advertencias se muestran porque el navegador no pudo verificar la identidad al validar el certificado con una Autoridad de Certificación (CA) conocida.

Como este es un certificado autofirmado, no hay CA y puede ignorar la advertencia y continuar. Si desea obtener un certificado real que sea reconocible por cualquier persona en la Internet pública, a continuación se describe el procedimiento.

Generar una clave privada
Utilice esa clave privada para crear un archivo CSR
Enviar CSR a CA (Verisign u otros, etc.)
Instalar el certificado recibido de CA en el servidor web
Agregue otros certificados a la cadena de autenticación según el tipo de certificado

Tengo más detalles sobre esto en una publicación en https://bigthinkingapplied.com/secure-the-connection-installing-certificates-on-3-common-web-servers/

Un trazador de líneas FTW. Me gusta que sea sencillo. ¿Por qué no usar un comando que contenga TODOS los argumentos necesarios? Así es como me gusta: crea un certificado x509 y su clave PEM:

openssl req -x509 / -nodes -days 365 -newkey rsa:4096 / -keyout self.key.pem / -out self-x509.crt / -subj "/C=US/ST=WA/L=Seattle/CN=example.com/[email protected]"

Ese único comando contiene todas las respuestas que normalmente proporcionaría para los detalles del certificado. De esta manera, puede configurar los parámetros y ejecutar el comando, obtener su salida y luego ir a tomar un café.

>> más aquí <<

oneliner v2017:

centos

openssl req -x509 -nodes -sha256 -newkey rsa:2048 / -keyout localhost.key -out localhost.crt / -days 3650 / -subj "CN=localhost" / -reqexts SAN -extensions SAN / -config <(cat /etc/pki/tls/openssl.cnf <(printf "/n[SAN]/nsubjectAltName=IP:127.0.0.1,DNS:localhost"))

ubuntu:

openssl req -x509 -nodes -sha256 -newkey rsa:2048 / -keyout localhost.key -out localhost.crt / -days 3650 / -subj "CN=localhost" / -reqexts SAN -extensions SAN / -config <(cat /etc/ssl/openssl.cnf <(printf "/n[SAN]/nsubjectAltName=IP:127.0.0.1,DNS:localhost"))

instalar - habilitar ssl apache2

¿Cómo crear un certificado autofirmado con openssl? (13)

Generar claves

Agregar configuracion

Notas de seguimiento:

Verificación de conexión