¿Cómo crear un certificado autofirmado con openssl?

Estoy agregando soporte https a un dispositivo Linux incorporado. Intenté 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 obtengo 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 crear un certificado autofirmado?

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 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) puede reemplazarse con cualquier número para afectar la fecha de vencimiento. Luego, le solicitará cosas como “Nombre del país”, pero puede presionar Entrar y aceptar valores predeterminados.

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

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

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

Es fácil crear un certificado autofirmado. Simplemente 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 (ver referencias a continuación). Las restricciones surgen en dos áreas clave: (1) anclajes de confianza y (2) nombres de DNS.

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

Algunos navegadores no hacen exactamente fácil importar un certificado de servidor autofirmado. De hecho, no puedes con algunos navegadores, como el navegador de Android. Entonces, la solución completa es convertirse en su propia autoridad.

En la ausencia de convertirse en su propia autoridad, debe obtener los nombres DNS correctos para dar al certificado la mayor posibilidad de éxito. Pero te animo a convertirte en tu propia autoridad. Es fácil convertirse en su propia autoridad y dará un paso al costado de todos los problemas de confianza (¿quién mejor para 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 usan una lista predefinida de anclajes de confianza para validar los certificados del servidor. Un certificado autofirmado no encadena a un ancla de confianza.

La mejor manera de evitar esto es:

  1. Crea tu propia autoridad (es decir, conviértete en CA)
  2. Crear una solicitud de firma de certificado (CSR) para el servidor
  3. Firme la CSR del servidor con su clave CA
  4. Instala el certificado del servidor en el servidor
  5. Instale el certificado de CA en el cliente

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

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

Los pasos 2 – 4 son más o menos 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 (¿quién mejor para confiar que usted?).

La siguiente mejor forma 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. Por lo tanto, nunca funcionará en la plataforma.

El problema de los navegadores (y otros agentes de usuario 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é va a pasar cuando te conectes a tu termostato o refrigerador para progtwigrlo? La respuesta es, nada bueno en lo que respecta a la experiencia del usuario.

El Grupo de Trabajo WebAppSec del W3C está empezando a analizar el problema. Consulte, 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 se encuentran en el Nombre alternativo del sujeto (SAN) y no en 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 alternate_names en el archivo de configuración (debe ajustar esto para que se ajuste a su gusto):

 [ 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 DNS en la SAN y no en el CN ​​porque tanto el IETF como el CA / Browser Forums especifican la práctica. También especifican que los nombres DNS en el CN ​​están en desuso (pero no están prohibidos). Si coloca un nombre DNS en el CN, debe incluirse en la SAN según las políticas de CA / B. Por lo tanto, no puede evitar el uso del nombre alternativo del sujeto.

Si no lo hace, ponga nombres DNS en la SAN, entonces el certificado no podrá validar bajo un navegador y otros agentes de usuario que cumplan con los lineamientos del CA / Browser Forum.

Relacionado: los navegadores siguen las políticas de CA / Browser Forum; y no las políticas IETF. Esa es una de las razones por las que un certificado creado con OpenSSL (que generalmente sigue el IETF) a veces no valida bajo 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 (observe 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 

Imprima 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 (eg server FQDN or YOUR name) commonName_default = Example Company emailAddress = Email Address emailAddress_default = test@example.com # Section x509_ext is used when generating a self-signed certificate. Ie, openssl req -x509 ... [ x509_ext ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer # You only need digitalSignature below. *If* you don't allow # RSA Key transport (ie, 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. Ie, 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 sobre el manejo de nombres DNS en certificados X.509 / PKIX. Consulte estos documentos para conocer las reglas:

  • RFC 5280, Internet X.509 Certificado de infraestructura de claves públicas y lista de revocación de certificados (CRL)
  • 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 utilizando los certificados X.509 (PKIX) en el contexto de la seguridad de la capa de transporte (TLS)
  • RFC 6797, Apéndice A, HTTP Strict Transport Security (HSTS)
  • RFC 7469, extensión de vinculación de clave pública para HTTP
  • Requisitos de Baseline del CA / Browser Forum
  • Directrices de validación ampliada de CA / Browser Forum

RFC 6797 y RFC 7469 se enumeran porque son más restrictivos que los otros documentos RFC y CA / B. RFC’s 6797 y 7469 tampoco permiten una dirección IP.

Estas son las opciones descritas en la respuesta de @diegows , descrita con más detalle, de la documentación :

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

PKCS # 10 solicitud de certificado y utilidad de generación de certificado.

 -x509 

esta opción genera un certificado autofirmado en lugar de una solicitud de certificado. Esto normalmente se usa para generar un certificado de prueba o una CA raíz auto-firmada.

 -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 nbits en tamaño.

 -keyout filename 

esto le da el nombre de archivo para escribir la clave privada recién creada.

 -out filename 

Esto especifica el nombre de archivo de salida para escribir en o salida estándar por defecto.

 -days n 

cuando se usa 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, la resumí aquí.

El siguiente comando satisface 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 entrada interactiva molesta. Además, todos los pasos necesarios se ejecutan mediante esta única invocación de OpenSSL: desde la generación de claves privadas hasta el certificado autofirmado.

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

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

Observación: Teóricamente 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 una instalación de servidor, ya que tendría que almacenar la contraseña en el servidor también, o tendría que ingresarla manualmente en cada reinicio.

No puedo hacer ningún comentario, así que pondré esto como una respuesta separada. Encontré algunos problemas con la respuesta aceptada de una línea:

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

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

 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 

Reemplaza ‘localhost’ con cualquier dominio que necesites. Tendrá que ejecutar los dos primeros comandos uno por uno, ya que openssl solicitará una frase de contraseña.

Para combinar los dos en un archivo .pem:

 cat server.crt server.key > cert.pem 

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

La misma línea de comando de la respuesta aceptada – @diegows con -sha256 añadido

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

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

Actualice mayo de 2018. Como muchos observaron en los comentarios, el uso de SHA-2 no agrega seguridad al certificado autofirmado. Pero todavía recomiendo usarlo como un buen hábito de no usar funciones hash criptográficas desactualizadas / 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

Los navegadores modernos ahora arrojan un error de seguridad para los certificados autofirmados bien formados si faltan 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 desactualizados de repente.

La forma más rápida de volver a ejecutar es un archivo conf breve y autónomo:

  1. Crear 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 
  2. Crea 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 

Configuración de ejemplo desde https://support.citrix.com/article/CTX135602

Esta es la secuencia de comandos que uso en los cuadros locales para configurar la SAN (subjectAltName) en certificados autofirmados.

Este script toma el nombre de dominio (example.com) y genera la SAN para * .example.com y example.com en el mismo certificado. Las siguientes secciones están comentadas. Nombra la secuencia de comandos (por ejemplo, generate-ssl.sh ) y dale permisos ejecutables. Los archivos se escribirán en el mismo directorio que el script.

Chrome 58 en adelante requiere que la 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" 

Este script 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:

  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  

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

2017 un trazador de líneas:

 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 aquí . Esto crea un único archivo .pem que contiene tanto la clave privada como el certificado. Puede moverlos a archivos .pem separados si es necesario.

Usted tiene el procedimiento general correcto. La syntax para el comando está debajo.

 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 se trata de 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, entonces el procedimiento está a continuación.

  1. Generar una clave privada
  2. Usa esa clave privada para crear un archivo CSR
  3. Enviar CSR a CA (Verisign u otros, etc.)
  4. Instalar certificado recibido de CA en el servidor web
  5. Agregue otros certs a la cadena de autenticación dependiendo del tipo cert

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 mantenerlo simple. ¿Por qué no utilizar un comando que contiene TODOS los argumentos necesarios? Así es como me gusta: esto crea un certificado x509 y es 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/emailAddress=someEmail@gmail.com" 

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

>> más aquí < <

Generar claves

Estoy usando /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 configuración

/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 se conectó a: /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 cert si no está en la configuración de apparmors . Como se mencionó en los pasos anteriores ^, guarde todos nuestros .pem como archivos .pem en el directorio /etc/mysql/ aprobado por defecto por apparmor (o modifique su apparmor / SELinux para permitir el acceso a donde los haya almacenado).

  • SSL error: Unable to get private key

    Es posible que su versión del servidor mysql no sea compatible con el formato rsa:2048 predeterminado.

    Covert 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 admite 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 | +---------------+----------------------------+ 
  • La verificación de una conexión a la base de datos está encriptada en ssl :

    Verificar la 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 específica del usuario (‘require ssl’):

    • SSL

    Le dice al servidor que permita solo conexiones cifradas con 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 puede especificar adicionalmente 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

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"))