Creación de certificado autofirmado para dominio y subdominios - NET :: ERR_CERT_COMMON_NAME_INVALID

82

Seguí este tutorial para crear certificados SSL firmados en Windows con fines de desarrollo, y funcionó muy bien para uno de mis dominios (estoy usando el archivo hosts para simular dns). Luego pensé que tengo muchos subdominios, y sería un fastidio crear un certificado para cada uno de ellos. Así que intenté crear un certificado usando comodines en el Commoncampo como se sugiere en algunas de las respuestas en serverfault. Me gusta esto:

Common Name: *.myserver.net/CN=myserver.net

Sin embargo, después de importar este certificado a Trusted Root Certification Authority, NET::ERR_CERT_COMMON_NAME_INVALIDaparece un error en Chrome, para el dominio principal y todos sus submains, por ejemplo: https://sub1.myserver.nety https://myserver.net.

Este servidor no pudo probar que es myserver.net; su certificado de seguridad es de * .myserver.net / CN = myserver.net.

Esto puede deberse a una configuración incorrecta o un atacante que intercepta su conexión.

¿Hay algún problema en el campo Nombre común que esté causando este error?

ssl  dns  openssl  windows-7-x64 
— Zed
fuente
Pasé mucho tiempo tratando de arreglar esto también. Vea mi respuesta aquí stackoverflow.com/questions/42816218/…
— Alex Vasilev

Respuestas:

20

Como dijo Rahul, es un error común de Chrome y OSX. Tuve problemas similares en el pasado. De hecho, finalmente me cansé de hacer 2 [sí, sé que no son muchos] clics adicionales al probar un sitio local para el trabajo.

En cuanto a una posible solución a este problema [usando Windows], usaría una de las muchas utilidades de certificado autofirmado disponibles .

Pasos recomendados:

  1. Cree un certificado autofirmado
  2. Importar certificado al Administrador de certificados de Windows
  3. Importar certificado en el Administrador de certificados de Chrome
    NOTA: El paso 3 resolverá el problema experimentado una vez que Google solucione el error ... considerando que el tiempo ha sido obsoleto, no hay ETA en el futuro previsible. **

    Por mucho que prefiera usar Chrome para desarrollo, me he encontrado en Firefox Developer Edition últimamente. que no tiene este problema.

    Espero que esto ayude :)
— Thomas.Donnelly
fuente
El error al que vinculó es A) solo válido para OS X, y B) se refiere a dominios con un "." Final, ninguno de los cuales es válido para @Zed.
— Philip
Hmm, ¿qué enlace sería ese?
— Thomas.Donnelly
El enlace al error del cromo (98627)
— Philip
Independientemente de la solución que propuse, también funciona en Windows, ya que la he usado muchas veces.
— Thomas.Donnelly
"Por mucho que prefiera usar Chrome para el desarrollo, últimamente me he encontrado en Firefox Developer Edition, que no tiene este problema". No podría estar más de acuerdo aquí ..
— Ash
26

Una solución alternativa es agregar los nombres de dominio que usa como "subjectAltName" (X509v3 Subject Alternative Name). Esto se puede hacer cambiando la configuración de OpenSSL ( /etc/ssl/openssl.cnfen Linux) y modificando la v3_reqsección para que se vea así:

[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = myserver.net
DNS.2 = sub1.myserver.net

Con esto en su lugar, no olvide usar el -extensions v3_reqinterruptor cuando genere su nuevo certificado. (consulte también ¿Cómo puedo generar un certificado autofirmado con SubjectAltName usando OpenSSL? )

— Fabián S
fuente
1
El uso de subjectAltName = @alt_namestotalmente resuelto mi problema. Sin embargo, había vinculado previamente la identidad DNS a mi dominio proporcionándola CN=*.example.com. Configuración DNS.1 = example.come DNS.2 = *.example.comhizo el truco. Lo extraño (para mí) fue que todo funcionó hasta ~ 2017-03-17 y se detuvo un día después (había ejecutado un gran lote de udates de Windows). Sin embargo, nada se rompió para mí en Linux, esto fue solo Chrome , Firefox en Windows .
— bossi
@bossi: Desafortunadamente, tengo este problema en Chrome / Ubuntu. Y cert no es nada elegante, host único, DN único (repositorio interno de GitLab).
— Pawel Kraszewski
Funcionó hace aproximadamente una semana, nada cambió en el servidor. Otros 2 servidores comenzaron a despotricar debido a una discrepancia entre mayúsculas y minúsculas (el certificado está en mayúsculas, Chrome deja la dirección en minúsculas)
— Pawel Kraszewski
2
@bossi Apuesto a que tu versión de Windows está en fase beta, ¿verdad? Chrome tiene certificados obsoletos sin una versión subjectAltName de Chrome 58, que actualmente se encuentra en versión beta. Esto me fastidió porque no solo no había visto nada al respecto, sino que el nombre del error es muy engañoso (¡no es el nombre común el que no es válido!). Yo era lo opuesto a usted; solo sucedió en Linux para mí, así que pasé horas tratando de arreglar mi tienda de certificados local allí.
— Tobias J
2
@TobyJ 58.0.3029.19 beta (64-bit)lo es. He regenerado el árbol de certificados con correctas subjectAltName-s y todo funciona ahora. Y estoy de acuerdo, el mensaje de error es muy engañoso, ya que no CommonNamees válido. Si el mensaje decía "Falta un certificado adecuado subjectAltName" , todo el mundo estaría mucho más feliz.
— Pawel Kraszewski
17

Crear openssl.confarchivo:

[req]
default_bits = 2048
default_keyfile = oats.key
encrypt_key = no
utf8 = yes
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no

[req_distinguished_name]
C = US
ST = Cary
L = Cary
O  = BigCompany
CN = *.myserver.net

[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = myserver.net
DNS.2 = *.myserver.net

Ejecute este comando:

openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:2048 -keyout app.key -out app.crt  -config openssl.conf

Salida de archivos app.crty app.keytrabajo para mí.

— Alykoff Gali
fuente
2
Hay un error tipográfico en DNS.1 = *.myserver.net. Debería ser DNS.2 = *.myserver.net. Funciona bien para mí.
— Artem Stepin
2
si está en Windows, esto se puede hacer usando openssl instalado con git usando un cmd que se ejecuta como administrador y la siguiente ubicación: "C: \ Archivos de programa \ Git \ usr \ bin \ openssl.exe" req -x509 -sha256 -nodes -days 3650 -newkey rsa: 2048 -keyout app.key -out app.crt -config openssl.conf
— George
Escribí CN = localhost, DNS.1 = localhost, DNS.2 = * .localhost: 8080 y no me funciona. ¿Qué más debería cambiar?
— Esqarrouth
14

Su comodín *.example.comno no cubre el dominio raíz example.com, pero cubrirá cualquier variante en un sub -domain como www.example.comotest.example.com

El método preferido es establecer nombres alternativos del sujeto como en la respuesta de Fabián, pero tenga en cuenta que Chrome actualmente requiere que el nombre común se incluya además como uno de los nombres alternativos del sujeto (como se demuestra correctamente en su respuesta). Recientemente descubrí este problema porque tenía el nombre común example.comcon SAN www.example.comy test.example.com, pero recibí la NET::ERR_CERT_COMMON_NAME_INVALIDadvertencia de Chrome. Tuve que generar una nueva solicitud de firma de certificado con example.comel nombre común y una de las SAN. Entonces Chrome confió plenamente en el certificado. Y no olvide importar el certificado raíz a Chrome como autoridad confiable para identificar sitios web.

— Jeff Puckett
fuente
Si alguien que lee esto usa Pantheon para hospedaje, parece que reconstituye el nombre común asociado con su certificado cuando lo carga en su plataforma, creando este problema. Debe probar con la IP estática personalizada que le brindan para ver si el nombre común del certificado permaneció intacto durante la configuración.
— serraosays
1
¡Brillante! "Su comodín * .example.com no cubre el dominio raíz example.com, pero cubrirá cualquier variante en un subdominio como www.example.com o test.example.com". Este fue precisamente el problema en mi caso. La solución fue simplemente incluir ambos DNS.1 = example.comy DNS.2 = *.example.commenos [alt_names]en openssl.cnf.
— Ben Johnson
5

Creo que puede ser un error en Chrome. Hubo un problema similar hace mucho tiempo: vea esto.

Pruebe en un navegador diferente. Creo que debería funcionar bien.

— Rahul Sreeram
fuente
1

Para todos los que se encuentren con esto y quieran aceptar el riesgo de probarlo, hay una solución: vaya al modo incógnito en Chrome y podrá abrir "Avanzado" y hacer clic en "Proceder a some.url".

Esto puede ser útil si necesita consultar algún sitio web que está manteniendo usted mismo y simplemente probando como desarrollador (y cuando aún no tiene configurado el certificado de desarrollo adecuado).

Por supuesto, esto NO ES PARA PERSONAS que utilizan un sitio web en producción donde este error indica que hay un problema con la seguridad del sitio web.

— bashmish
fuente
0

Si estás cansado de este error. Puede hacer que Chrome no actúe así. No digo que sea la mejor manera, solo digo que es una manera.

Como solución alternativa, se puede crear una clave de registro de Windows para permitir que Google Chrome use el commonName de un certificado de servidor para que coincida con un nombre de host si al certificado le falta una extensión subjectAlternativeName, siempre y cuando se valide correctamente y se encadene a una CA instalada localmente Certificados.

Tipo de datos: booleano [Windows: REG_DWORD] Ubicación del registro de Windows: HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Google \ Chrome Nombre de preferencia de Windows / Mac / Linux / Android: EnableCommonNameFallbackForLocalAnchors Valor: 0x00000001 (Windows), true (Linux), true (Android), (Mac) Para crear una clave de registro de Windows, simplemente siga estos pasos:

Abra el Bloc de notas Copie y pegue el siguiente contenido en el Bloc de notas Editor del registro de Windows Versión 5.00

[HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Google \ Chrome] "EnableCommonNameFallbackForLocalAnchors" = dword: 00000001 Vaya a Archivo> Guardar como nombre de archivo: any_filename.reg Guardar como tipo: Todos los archivos

Seleccione una ubicación preferida para el archivo

Haga clic en Guardar

Haga doble clic en el archivo guardado para ejecutar

Haga clic en Sí en la advertencia del Editor del registro

Encontré esta información en la página de soporte de Symantec: https://support.symantec.com/en_US/article.TECH240507.html

— ambidiestro
fuente
0

Las respuestas proporcionadas no funcionaron para mí (Chrome o Firefox) mientras creaba PWA para desarrollo y pruebas locales. ¡NO UTILIZAR PARA LA PRODUCCIÓN! Pude usar lo siguiente:

  1. Herramientas de certificación en líneaSitio de con las siguientes opciones:
    • Nombres comunes: agregue tanto el "localhost" como la IP de su sistema, por ejemplo, 192.168.1.12
    • Nombres alternativos del sujeto: agregue "DNS" = "localhost" e "IP" = <your ip here, e.g. 192.168.1.12>
    • Opciones desplegables de "CRS" configuradas como "Autofirma"
    • todas las demás opciones eran predeterminadas
  2. Descarga todos los enlaces
  3. Importe el certificado .p7b a Windows haciendo doble clic y seleccione "instalar" / OSX? / Linux?
  4. Certificados agregados a la aplicación de nodo ... usando el ejemplo de PWA de Google
    • agregar const https = require('https'); const fs = require('fs');a la parte superior del archivo server.js
    • comentar return app.listen(PORT, () => { ... });en la parte inferior del archivo server.js
    • Agrega abajo https.createServer({ key: fs.readFileSync('./cert.key','utf8'), cert: fs.readFileSync('./cert.crt','utf8'), requestCert: false, rejectUnauthorized: false }, app).listen(PORT)

No tengo más errores en Chrome o Firefox

— James Nelson
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.