openssl req -x509 -days 365 -newkey rsa: 2048 -keyout /etc/ssl/apache.key -out /etc/ssl/apache.crt
No puede usar este comando para generar un certificado X.509 bien formado. Su formato será incorrecto porque el nombre de host se coloca en el Nombre común (CN) . La colocación de un nombre de host o una dirección IP en el CN está en desuso por parte de IETF (la mayoría de las herramientas, me gusta wgety curl) y de los foros de CA / B (CA y navegadores).
De acuerdo con los foros IETF y CA / B, los nombres de los servidores y las direcciones IP siempre van en el Nombre alternativo del sujeto (SAN) . Para conocer las reglas, consulte el RFC 5280, el Certificado de Infraestructura de Clave Pública de Internet X.509 y el Perfil de la Lista de Revocación de Certificados (CRL) y los Requisitos de Referencia del Foro de CA / Navegador .
En su mayoría, necesita usar un archivo de configuración de OpenSSL y adaptarlo a sus necesidades. A continuación se muestra un ejemplo de uno que uso. Se llama example-com.confy se pasa al comando OpenSSL a través de -config example-com.conf.
También tenga en cuenta así : todas las máquinas dicen ser localhost, localhost.localdomainetc. Tenga cuidado con la emisión de certificados para localhost. No digo que no lo hagas; solo entiendo que hay algunos riesgos involucrados.
Las alternativas localhostson: (1) ejecutar DNS y emitir certificados para el nombre DNS de la máquina. O, (2) use IP estática e incluya la dirección IP estática.
Los navegadores aún le darán advertencias sobre un certificado autofirmado que no se encadena a una raíz confiable. Las herramientas tienen gusto curly wgetno se quejarán, pero aún así debe confiar en su propia firma con una opción como cURL's --cafile. Para superar el problema de confianza del navegador, debe convertirse en su propia CA.
"Convertirse en su propia CA" se conoce como ejecutar una PKI privada. No hay mucho de eso. Puede hacer todo lo que una CA pública puede hacer. Lo único diferente es que necesitará instalar su certificado de CA raíz en las distintas tiendas. No es diferente a, digamos, usar cURL's cacerts.pm. cacerts.pmes solo una colección de Root CA's, y ahora te has unido al club.
Si se convierte en su propia CA, asegúrese de grabar su clave privada de CA raíz en un disco y mantenerla fuera de línea. Luego, colóquelo en su unidad de CD / DVD cuando necesite firmar una solicitud de firma. Ahora está emitiendo certificados como una CA pública.
Nada de esto es terriblemente difícil una vez que firma una o dos solicitudes de firma. He estado ejecutando un PKI privado durante años en la casa. Todos mis dispositivos y gadgets confían en mi CA.
Para obtener más información sobre cómo convertirse en su propia CA, consulte ¿Cómo firmar la Solicitud de firma de certificado con su Autoridad de certificación y Cómo crear un certificado autofirmado con openssl? .
De los comentarios en el archivo de configuración a continuación ...
Autofirmado (tenga en cuenta la adición de -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
Solicitud de firma (tenga en cuenta la falta de -x509)
openssl req -config example-com.conf -new -newkey rsa:2048 -nodes -keyout example-com.key.pem -days 365 -out example-com.req.pem
Imprima un 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
# Self Signed (note the addition of -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
# Signing Request (note the lack of -x509):
# openssl req -config example-com.conf -new -newkey rsa:2048 -nodes -keyout example-com.key.pem -days 365 -out example-com.req.pem
# Print it:
# openssl x509 -in example-com.cert.pem -text -noout
# openssl req -in example-com.req.pem -text -noout
[ 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).
# It's 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
# If RSA Key Transport bothers you, then remove keyEncipherment. TLS 1.3 is removing RSA
# Key Transport in favor of exchanges with Forward Secrecy, like DHE and ECDHE.
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
# 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
# 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
# DNS.9 = fe80::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 un CN en este caso.
# IPv4 localhost
# IP.1 = 127.0.0.1
# IPv6 localhost
# IP.2 = ::1
Centos 7 / Vagrant / Chrome Browser.