in

¿Cómo generar un certificado SSL autofirmado usando OpenSSL?

apple touch icon@2

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

Es fácil crear un certificado autofirmado. Solo usa el openssl req mando. Puede resultar 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 los IETF. Los requisitos utilizados por los navegadores están documentados en el CA / foros de navegadores (véanse 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 vuelva a encadenar a un ancla de confianza, y quieren que los nombres DNS se presenten de formas particulares 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 puede hacerlo con algunos navegadores, como el navegador de Android. Entonces, la solución completa es convertirse en su propia autoridad.

En ausencia de convertirse en su propia autoridad, debe obtener los nombres DNS correctos para darle al certificado la mayor probabilidad de éxito. Pero le animo a que se convierta en su propia autoridad. Es fácil convertirse en su propia autoridad y evitará todos los problemas de confianza (¿en quién mejor para confiar que en usted mismo?).


¡Probablemente este no sea el sitio que está 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 del servidor. Un certificado autofirmado no se vuelve a encadenar a un ancla de confianza.

La mejor forma de evitarlo es:

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

Paso 1 – Crea tu propia autoridad solo significa crear un certificado autofirmado con CA: true y uso adecuado de las claves. Eso significa el Tema y Editor son la misma entidad, CA se establece en verdadero en Restricciones básicas (también debe estar marcado como crítico), el uso de claves es keyCertSign y crlSign (si está utilizando CRL), y el Identificador de clave de 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 se firma una solicitud de firma de certificado con su autoridad de certificación? en Stack Overflow. Luego, importe su CA a Trust Store que utiliza 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 Concierto. Los pasos 1 y 5 le permiten evitar la autoridad de terceros y actuar como su propia autoridad (¿en quién mejor para confiar que en usted mismo?).

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) no confiar en los certificados autofirmados será un gran problema en la Internet de las cosas (IoT). Por ejemplo, ¿qué va a pasar cuando te conectes a tu termostato o frigorífico para programarlo? 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. Ver, por ejemplo, Propuesta: Marcar HTTP como no seguro.


Cómo crear un certificado autofirmado con OpenSSL

Los siguientes comandos y el archivo de configuración crean un certificado autofirmado (también 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). Entonces hay un alternate_names sección en el archivo de configuración (debe ajustar esto 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
# IP.1        = 127.0.0.1
# IP.2        = ::1

Es importante poner el nombre DNS en la SAN y no en el CN, porque ambos IETF y CA / Browser Forums especifican la práctica. También especifican que los nombres DNS en el CN ​​están obsoletos (pero no prohibidos). Si pones un nombre DNS en el CN, luego debe estar incluido en la SAN bajo las políticas CA / B. Por lo tanto, no puede evitar usar el nombre alternativo del sujeto.

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

Relacionado: 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.


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

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

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

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

Imprime 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 -config opción)

[ 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 it's 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        = test@example.com

# 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 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 un CN en este caso.

# IPv4 localhost
# IP.1       = 127.0.0.1

# IPv6 localhost
# IP.2     = ::1

Existen otras reglas relativas al manejo de nombres DNS en certificados X.509 / PKIX. Consulte estos documentos para conocer las reglas:

Se enumeran RFC 6797 y RFC 7469, porque son más restrictivas que las otras RFC y documentos CA / B. RFC 6797 y 7469 no permitir una dirección IP, tampoco.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Función de biblioteca C – pow ()

gfg 200x200 min

Generando números aleatorios en Java