Solución:
Puedes hacerlo con un comando:
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365
También puede agregar -nodes (corto 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”.
los days parámetro (365) que puede reemplazar con cualquier número para afectar la fecha de vencimiento. Luego le pedirá cosas como “Nombre del país”, pero puede presionar Ingresar y acepta los valores predeterminados.
Agregar -subj '/CN=localhost' para suprimir preguntas sobre el contenido del certificado (reemplazar localhost con su dominio deseado).
Los certificados autofirmados no se validan con ningún tercero a menos que los importe a los navegadores previamente. Si necesita más seguridad, debe utilizar un certificado firmado por una autoridad de certificación (CA).
¿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 el IETF. Los requisitos utilizados por los navegadores están documentados en CA / Browser Forums (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 usamos 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:
- Cree su propia autoridad (es decir, conviértase en CA)
- Cree una solicitud de firma de certificado (CSR) para el servidor
- Firme la CSR del servidor con su clave CA
- Instale el certificado del servidor en el servidor
- 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 marcarse 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 CAcert. 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. Consulte, 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 (nota 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 = [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 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:
- RFC 5280, certificado de infraestructura de clave pública de Internet X.509 y perfil de 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 mediante certificados X.509 (PKIX) en el contexto de la seguridad de la capa de transporte (TLS)
- RFC 6797, Apéndice A, Seguridad de transporte estricta HTTP (HSTS)
- RFC 7469, extensión de fijación de clave pública para HTTP
- Requisitos básicos de CA / Browser Forum
- Directrices de validación ampliada de CA / Browser Forum
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.
Aquí están las opciones descritas en la respuesta de @ diegows, descritas con más detalle, de la documentación:
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days XXX
reqSolicitud de certificado PKCS # 10 y utilidad de generación de certificado.
-x509esta opción genera un certificado autofirmado en lugar de una solicitud de certificado. Suele utilizarse para generar un certificado de prueba o una CA raíz autofirmada.
-newkey argesta opción crea una nueva solicitud de certificado y una nueva clave privada. El argumento adopta una de varias formas. rsa: nbits, dónde nbits es el número de bits, genera una clave RSA nbits en tamaño.
-keyout filenameesto le da el nombre de archivo para escribir la clave privada recién creada.
-out filenameEsto especifica el nombre del archivo de salida para escribir o la salida estándar de forma predeterminada.
-days ncuando el -x509 se está utilizando la opción, esto especifica el número de días para certificar el certificado. El valor predeterminado es 30 días.
-nodessi se especifica esta opción, si se crea una clave privada, no se cifrará.
En realidad, la documentación es más detallada que la anterior; Lo resumí aquí.