Estoy intentando configurar un certificado comodín autofirmado para que lo use Apache, normalmente esto es bastante sencillo. Simplemente establezco un nombre alternativo de sujeto con el dominio raíz y especifico *.dcrdev.com en el campo de nombre común. Sin embargo, parece que esto no funciona: cuando intento acceder al sitio en Chrome o lo pruebo en sslabs, informan discrepancias de URL al acceder a cualquier subdominio como www.dcrdev.com o subdominio1.dcrdev.com. No estoy seguro de por qué, cuando veo la información del certificado en Chrome, muestra el nombre común como *.dcrdev.com.
Mi rsc:
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=GB, ST=South Yorkshire, L=Sheffield, O=DCR Holdings, OU=DCR Development, CN=*.dcrdev.com/[email protected]
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
lah blah
Mi certificado:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1048577 (0x100001)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=GB, ST=South Yorkshire, L=Sheffield, O=DCR Holdings, OU=DCR Root Authority, CN=*.dcrdev.com/[email protected]
Validity
Not Before: Oct 13 23:41:03 2015 GMT
Not After : Oct 10 23:41:03 2025 GMT
Subject: C=GB, ST=South Yorkshire, L=Sheffield, O=DCR Holdings, OU=DCR Development, CN=*.dcrdev.com/[email protected]
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
Blah blah
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
83:2D:84:F1:E2:B0:72:30:E6:3B:6A:F6:8E:6A:68:8E:3F:D4:69:44
X509v3 Authority Key Identifier:
keyid:F5:A6:82:E2:DD:52:10:CE:FD:C5:C7:E1:E9:CF:C6:8C:30:26:D7:DC
X509v3 Subject Alternative Name:
DNS:dcrdev.com
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
Signature Algorithm: sha256WithRSAEncryption
Blah blah
Respuesta1
Duplicación cruzada dehttps://stackoverflow.com/questions/3093112/certificateexception-no-name-matching-ssl-someurl-de-found.
El nombre común del sujeto ya no controla los certificados HTTPS.
AFAICT, en realidad no existe un estándar que lo diga, peroLa práctica desde hace algunos años es que los navegadores, etc. utilicen la extensión SubjectAlternativeName (SAN) si está presente, y CommonName (CN) en Asunto sólo si SAN está ausente. Su certificado tiene SAN presente dcrdev.com, por lo que solo eso coincide.
actualizar:encontrado enRFC2818 3.1:
Si está presente una extensión sujetoAltName de tipo dNSName, DEBE usarse como identidad. De lo contrario, DEBE utilizarse el campo Nombre común (más específico) en el campo Asunto del certificado. Aunque el uso del nombre común es una práctica existente, está en desuso y se recomienda a las autoridades de certificación que utilicen el nombre dNS en su lugar.
Ese RFC fue de mayo de 2000, pero, según recuerdo, los certificados que encontré no comenzaron a usar SAN hasta más cerca de 2010. El más reciente de marzo de 2011RFC6125identificado por @JennyD (¿funciona en el cuerpo de la respuesta?) es un tratamiento más general, pero dice explícitamente
Este documento tampoco reemplaza las reglas para verificar la identidad del servicio proporcionadas en las especificaciones para los protocolos de aplicación existentes publicados antes de este documento, como los extraídos en el Apéndice B.
y el apéndice B incluye RFC2818.
Los requisitos básicos deForo de navegador CAdecir que las CA debenasuntocertificados con SAN mientras Subject.CN está en desuso, aunque eso no es directamente un requisito para los navegadores/clientes.
Si desea utilizar tanto el dominio como los subdominios (solo un nivel), coloque dos entradas dnsName en SAN, una para dcrdev.comy otra para *.dcrdev.com.