Error SSL de nombre incorrecto: causa y arreglo rápido

En pocas palabras: El error NET::ERR_CERT_COMMON_NAME_INVALID significa que el dominio visitado no figura en el Subject Alternative Name (SAN) del certificado SSL. Como desde Chrome 58 (abril de 2017) los navegadores ignoran el Common Name y validan solo el SAN, la solución es reemitir el certificado incluyendo todos los hostnames.

Cuando Chrome te muestra NET::ERR_CERT_COMMON_NAME_INVALID, está señalando el caso más común de error SSL por certificado con nombre incorrecto: el certificado que devuelve el servidor existe, lo firmó una autoridad certificante confiable y no está vencido, pero no cubre el dominio al que te estás conectando. La criptografía es válida; el nombre, no.

El NET::ERR_CERT_COMMON_NAME_INVALID es un mensaje de seguridad del navegador que avisa que el hostname solicitado no figura en el Subject Alternative Name (SAN) del certificado SSL que entregó el servidor. Ni vencido ni con la cadena rota: el certificado salió para otro nombre, y eso basta para que Chrome, Firefox o curl corten la conexión. La salida pasa por emitir un certificado cuyo SAN incluya todos los hosts que el servidor atiende.

Dicho rápido: el Subject Alternative Name (SAN) es la extensión del certificado que enumera los hostnames exactos para los que ese certificado es válido. Todo lo que sigue gira alrededor de esa lista.

¿Por qué el navegador rechaza un certificado SSL que se ve válido?

Porque validez y cobertura son verificaciones distintas. Un certificado puede pasar todos los controles de autenticidad y aun así ser rechazado si el hostname que pediste no está en su lista de SAN.

Ponele que renovaste todo, el panel de control marca el candado como activo y el vencimiento queda a meses vista. De repente un cliente te avisa que su navegador le escupe “Tu conexión no es privada”. Entrás, revisás el certificado y está impecable. El problema es otro: alguien le pidió al servidor un nombre para el cual ese certificado nunca salió, y el navegador hizo lo que tenía que hacer. Esto se conecta con lo que analizamos en cómo montar tu proyecto en cloud hosting.

Cada ecosistema describe el mismo fallo con su propio acento:

Herramienta	Mensaje que ves
Chrome / Edge	NET::ERR_CERT_COMMON_NAME_INVALID
Firefox	SSL_ERROR_BAD_CERT_DOMAIN
curl	curl: (60) SSL: no alternative certificate subject name matches target host name
Node.js	ERR_TLS_CERT_ALTNAME_INVALID
OpenSSL	Hostname/IP does not match certificate’s altnames
Python (ssl)	ssl.CertificateError: hostname ‘app.example.com’ doesn’t match ‘example.com’

Una sola raíz, seis dialectos. Ojo con no confundirlo con sus dos primos: si el certificado estuviera vencido, las fechas no darían; si la cadena estuviera rota, no habría camino hasta una raíz confiable. En este caso las dos cosas están bien, y esa es justo la pista diagnóstica: cuando el certificado imprime fechas sanas, encadena limpio y lo único raro es tu hostname ausente del SAN, el diagnóstico está hecho.

La criptografía está sana. La confianza, también. El nombre, no.

¿Qué es el SAN y por qué dejó de importar el Common Name?

Los navegadores dejaron de usar el Common Name para validar hostnames alrededor de 2017, cuando Chrome 58 eliminó el CN como método de respaldo, según documenta el blog oficial de Chromium. Hoy lo único que cuenta es el Subject Alternative Name.

El propio mensaje de error es un fósil: sigue diciendo “common name”, pero ese campo legible que aparece como CN=example.com quedó reducido a decoración. El contrato real es el SAN, la lista explícita de hostnames autorizados. Un cliente moderno arma esa lista, verifica si tu hostname figura (aceptando el comodín solo como etiqueta izquierda completa) y, si no figura, corta. Sin fallback al CN. Sin negociación. (Sí, en serio: puede haber un certificado con CN=example.com perfectamente legible y aun así ser rechazado, porque el SAN omitió ese host.)

Entonces la pregunta correcta nunca es “este certificado, ¿es válido?”. Eso ya lo sabés. La pregunta es si el SAN cubre el nombre que pusiste en la barra del navegador o en la config de tu cliente.

Las 5 causas más comunes del error de nombre incorrecto en certificados

Siguiendo el orden en que suelen morder, según el análisis que Merlonix publicó en dev.to:

• El corte apex/www. El certificado salió para example.com (o al revés) y una redirección, un link hardcodeado o un registro DNS perdido mandó tráfico al nombre que el certificado no lista. Es el disparador más frecuente de todos.
• La profundidad del wildcard. *.example.com cubre un solo nivel: matchea api.example.com, pero ni api.sub.example.com ni example.com entran. El comodín no es “todo lo que cuelga del dominio”, es “una etiqueta acá, ni una más”.
• Un certificado por defecto. El servidor recibió un pedido para un hostname sin vhost ni match de SNI y respondió con el certificado default: el placeholder del hosting compartido, el nombre del balanceador o el site de otro dominio en la misma caja. Clásico en proxies reversos mal configurados y en CDNs donde el hostname custom se agregó al DNS antes que a la config TLS.
• Certificados solo-CN, sin SAN. Certificados viejos, hechos a mano o emitidos por una CA interna con Common Name y nada más. Como todo cliente moderno ignora el CN, no matchean nada. Y lo engañoso es que el CN está ahí, deletreando tu hostname, y el cliente lo rechaza igual.
• Una IP contra un certificado de nombres. Te conectás por IP cuando el certificado lista solo nombres DNS. Los clientes exigen la IP literal como entrada de tipo IP SAN; un certificado de nombres no la cubre.

Fijate que las últimas dos dependen de cómo emitieron el certificado, mientras las primeras tres son de enrutamiento: un pedido llegando a un host que el certificado, correcto, no iba a atender. Desde el navegador ambas situaciones se sienten iguales, y por eso leer el SAN real es la única manera de distinguirlas.

Causa	Señal típica	Arreglo
Apex/www dividido	Funciona en un nombre y falla en el otro	Reemitir cubriendo ambos o redirigir en la capa que termina TLS
Wildcard corto	Fallan subdominios de dos niveles o el apex	Sumar entradas SAN por cada host
Certificado por defecto	Falla solo desde afuera o en nombres nuevos	Configurar vhost/SNI por hostname
Solo-CN sin SAN	El CN muestra tu host y aun así rechaza	Reemitir con SAN moderno
IP contra nombre	Te conectás por IP y no hay entrada IP	Emitir certificado con la IP como SAN

¿Cómo leo el SAN de mi certificado con comandos, sin instalar nada?

Con OpenSSL, que ya viene en cualquier Linux o macOS, alcanza. Este comando pide el certificado que el servidor entrega para un hostname SNI específico e imprime sus nombres. Para más detalles técnicos, mirá arreglar errores comunes de hosting y dominio.

openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -text

Buscá dos cosas en la salida. Primero, el bloque X509v3 Subject Alternative Name: esa es la lista autoritativa, y si el hostname al que te conectás no figura ahí (ni lo tapa un wildcard como única etiqueta izquierda), tenés el mismatch confirmado. Segundo, el parámetro -servername, que en servers con varios vhosts cambia todo: el certificado que te devuelven depende del nombre que enviaste, así que ejecutalo una vez con -servername www.example.com y otra con -servername example.com.

¿Y qué pasa si te devuelve certificados distintos, o el mismo certificado que solo cubre uno de los dos nombres? Encontraste el problema en vivo, sin abrir un solo panel de control.

Subís el comando, leés la salida, ves DNS:example.com, DNS:www.example.com, mirás la URL que estás sirviendo en producción, te das cuenta de que ahí vive app.example.com, y ahí cae la ficha de por qué media oficina te reclama que el sitio “está caído” cuando en realidad nunca estuvo caído: estaba mal vestido.

La pista que separa este error de cualquier otro TLS: el certificado sale vigente, encadena limpio, y lo único torcido es que tu hostname no está en el SAN. En ese escenario, reemitir por validez o retocar la cadena no cambia nada; el certificado tiene que cubrir el nombre donde lo estás sirviendo, punto.

¿Cómo arreglo el error SSL según el tipo de problema?

No hay un fix único: hay tres familias de arreglo, y elegir mal te hace girar en círculos. Complementá con cómo los DNS autoritativos evitan caídas.

Si falta el apex o el www

Reemití el certificado incluyendo ambos nombres en el SAN (con Let’s Encrypt es gratis: certbot -d example.com -d www.example.com) o redirigí el tráfico en la capa que termina TLS con el certificado correcto, antes de que el pedido toque el certificado incompleto. Como remarca el análisis original: “solo usamos www” es cierto solo si nada apunta jamás al apex, y algo siempre apunta.

Si tenés subdominios profundos

Acordate del alcance real de tu wildcard: una etiqueta. Para metrics.internal.example.com o para servir el apex necesitás entradas SAN propias, o certificados separados. Let’s Encrypt permite listar varios SAN en una sola emisión sin costo, y los wildcard comerciales se venden por suscripción anual con precios que varían mucho según proveedor, así que compará antes de comprar.

Si el problema es un certificado por defecto

Tocá la config de vhosts o de SNI para que cada hostname tenga su bloque TLS propio. En hosting compartido, el chequeo es directo: cada dominio debe tener su propio vhost con su certificado asignado. Y si el sitio pasó por una migración o por un CDN, probá cada nombre desde afuera después de cualquier cambio, porque el error de certificado default es invisible hasta que pedís el hostname exacto.

¿Cómo evito que un certificado deje de cubrir mis dominios sin avisarme?

Monitoreando el SAN, no solo la fecha de vencimiento. Un certificado puede renovarse en tiempo y forma, pasar todas las alarmas de expiración y aun así dejar de cubrir un hostname el día que alguien lo reemite desde una plantilla que perdió un SAN.

El monitoreo que solo lee la fecha va a declarar ese certificado saludable mientras una parte real de tu tráfico recibe NET::ERR_CERT_COMMON_NAME_INVALID. (Que no es poco.)

Herramientas concretas hay varias. Merlonix lee el certificado que tu servidor presenta, SAN incluido, desde afuera de tu stack, te lo traduce a lenguaje plano y nombra los hostnames cubiertos para que veas el hueco, con chequeo en vivo sin registro previo. La alternativa artesanal es un cron con el comando openssl de arriba, corriendo contra cada nombre que atendés. No hay magia: es disciplina de inventario. Listá todos los nombres que responden por HTTPS y verificá cada uno.

Errores comunes al “arreglar” el error SSL de nombre incorrecto

Este error invita a atajos, y los atajos acá salen caros. Estos son los cuatro que más veo. En decidir entre self-hosting y servicio gestionado profundizamos sobre esto.

• Poner rejectUnauthorized: false y seguir. La “solución” favorita de los foros apaga el chequeo que te avisó que la identidad del endpoint no coincide con su nombre, que es justo la señal que querés encendida cuando un pedido puede estar llegando de callado al host equivocado. Es la puerta de entrada clásica a un ataque de hombre en el medio.
• Reemitir el mismo certificado esperando otro resultado. Si el SAN no cubre el host, reemitir desde la misma plantilla reproduce el mismo error. El arreglo es hacer que el SAN y los hostnames servidos coincidan.
• Ponerse a “arreglar la cadena” cuando el problema es el nombre. Cadena rota y nombre equivocado se parecen en el cartel, pero acá el camino hacia la raíz confiable está intacto. Retocar certificados intermedios no va a cambiar nada.
• Ocultar el aviso con “continuar de todos modos”. Estás aceptando navegar un sitio cuya identidad tu equipo no pudo confirmar. En un banco o en un login, cerrá la pestaña. Y si es un servicio de terceros, escribile el bug con precisión: “tu endpoint sirve un certificado con SAN X, yo me conecto a Y”. Es un reporte accionable, mucho mejor que trabajar con la verificación apagada.

Preguntas Frecuentes

¿Qué significa el error NET::ERR_CERT_COMMON_NAME_INVALID?

Significa que el certificado SSL presentado por el servidor no es válido para el nombre del host al que te conectaste. El certificado puede ser legítimo y estar vigente: lo que falla es que su lista de Subject Alternative Names no incluye tu hostname. Se distingue de un certificado vencido (fechas mal) y de una cadena rota (camino a raíz confiable cortado).

¿Por qué mi certificado SSL no funciona en algunos subdominios?

Porque el wildcard *.dominio.com cubre un solo nivel: valida api.dominio.com, pero ni api.sub.dominio.com ni el dominio pelado. Cada nivel adicional necesita su propia entrada SAN o un certificado aparte. Otra posibilidad es que un certificado por defecto esté respondiendo por un hostname sin vhost propio en el servidor.

¿Cómo verifico qué dominios cubre mi certificado SSL?

Ejecutá openssl s_client -connect tudominio.com:443 -servername tudominio.com </dev/null 2>/dev/null | openssl x509 -noout -text y buscá la sección X509v3 Subject Alternative Name. Ahí están todos los hostnames para los que el certificado es válido, y conviene repetir la consulta cambiando el -servername si el servidor aloja varios sitios.

¿Un wildcard *.example.com cubre api.sub.example.com?

No. Cubre una sola etiqueta: matchea api.example.com, pero api.sub.example.com lleva dos niveles y queda afuera, igual que example.com. Para cubrir más profundidad necesitás otro certificado o entradas SAN específicas por cada host.

¿Cómo arreglo un error de SSL por nombre incorrecto?

Primero identificá la causa con el comando openssl: apex/www, wildcard corto, certificado default, solo-CN o IP. Después reemití el certificado incluyendo todos los nombres que servís en el SAN, o redirigí el tráfico hacia el host cubierto en la capa que termina TLS. Verificá cada hostname con SNI antes de dar por cerrado el tema.

Conclusión

El cambio de fondo ya ocurrió y no vuelve atrás: desde 2017 la identidad de un certificado se lee en el SAN, y el Common Name es adorno. Por eso este error sigue apareciendo en 2026 cada vez que alguien agrega un subdominio, migra un sitio o reemite un certificado desde una plantilla vieja que perdió un nombre.

Lo accionable cabe en cuatro pasos: hacé un inventario de todos los nombres que responden por HTTPS en tu infraestructura, verificá el SAN de cada uno con -servername desde afuera de la caja, montá alertas que lean la cobertura y no solo el vencimiento, y dejá la verificación SSL siempre encendida en tus clientes. El navegador no está siendo difícil cuando rechaza un certificado “perfecto”: te está diciendo que el certificado y el hostname dejaron de coincidir, y el único lugar donde se arregla eso es en la lista de SAN que tu servidor entrega.

Fuentes

• Merlonix en dev.to – Análisis técnico del error SSL de nombre incorrecto
• Chromium Blog – Deprecaciones de Chrome 58: fin del fallback al Common Name (2017)
• IETF – RFC 6125: Representación y verificación de identidad de endpoints en TLS
• Let’s Encrypt – Documentación oficial de certificados gratuitos con múltiples SAN