ERR_CERT_COMMON_NAME_INVALID: qué significa y cómo solucionarlo

ERR_CERT_COMMON_NAME_INVALID significa que el sitio web presentó un certificado auténtico y vigente, pero emitido para un nombre distinto al que aparece en tu barra de direcciones. Chrome compara el dominio que solicitaste con los nombres de host del campo Subject Alternative Name (SAN) del certificado. Si ninguno coincide, Chrome bloquea la página con este error. La solución depende de quién seas: como visitante normalmente puedes resolverlo o evaluarlo en minutos, mientras que como propietario del sitio tendrás que reemitir o reconfigurar un certificado. Esta guía cubre ambos casos, con datos sobre la frecuencia real de cada causa.

Qué significa realmente el error

Cada certificado HTTPS público contiene una lista de nombres de host para los que es válido, almacenada en la extensión SAN. Históricamente los navegadores también aceptaban el campo Common Name (CN) del certificado, y de ahí viene el nombre del error. Ese mecanismo de respaldo desapareció hace tiempo:

• RFC 2818 desaconsejó la comparación con el CN para HTTPS ya en el año 2000.
• Chrome 58 eliminó por completo la comparación con el CN en abril de 2017 y desde entonces exige entradas SAN (fuente: Chrome for Developers, "Deprecations and Removals in Chrome 58"). En ese momento, solo alrededor del 0,1 % de todas las validaciones de certificados dependían todavía del CN (Chromium security-dev, 2017).
• RFC 9525 (noviembre de 2023), que sustituyó a RFC 6125, lo formalizó en toda la industria: los clientes deben comprobar únicamente la extensión SAN y no deben comparar nombres de dominio con el CN.

Así que, pese a su nombre, este error significa en realidad "discrepancia de SAN": nada en la lista de nombres del certificado cubre el host que pediste.

Además es un error notablemente frecuente. En el estudio de Google sobre más de 300 millones de avisos reales de certificado en Chrome (Acer et al., "Where the Wild Warnings Are", ACM CCS 2017), la discrepancia de nombre fue la mayor causa individual del lado del servidor en escritorio: el 11,7 % de todos los avisos en Windows y el 11,6 % en Mac, por delante de las autoridades no confiables y de los certificados caducados.

Causas de servidor de los avisos de certificado de Chrome como porcentaje de todos los informes en Windows. Datos: Acer et al., "Where the Wild Warnings Are", ACM CCS 2017.

Las 7 causas habituales y quién puede corregirlas

Dentro de las discrepancias de nombre destacan los errores de subdominio. En el mismo conjunto de datos de Google, el 13,2 % de las discrepancias de nombre del servidor eran peticiones de subdominios fuera del alcance de un comodín, y el 3,7 % eran simples discrepancias www (Acer et al., CCS 2017). Otro 3,8 % de los errores de nombre coincidía con patrones conocidos de portales cautivos, es decir, los causó la red y no el sitio web.

Si eres visitante: 5 comprobaciones rápidas

1. Prueba la otra forma de la dirección. Si example.com falla, prueba www.example.com, o al revés. Si una funciona, el sitio tiene una discrepancia www y puedes decírselo al propietario con exactitud.
2. Mira a nombre de quién se emitió el certificado. Haz clic en el candado o en "No es seguro", abre los detalles del certificado y lee la lista SAN. Un certificado del dominio de relleno de un hosting o de un sitio sin relación explica el bloqueo al instante.
3. En Wi-Fi públicas, provoca primero la página de acceso. Los portales cautivos interceptan tu primera petición HTTPS y responden con su propio certificado. Abre cualquier página HTTP simple (por ejemplo la página de estado del router o neverssl.com), completa el acceso al portal y reintenta.
4. Prueba con la inspección HTTPS desactivada. Algunos antivirus y proxies corporativos vuelven a firmar el tráfico TLS. Desactiva temporalmente el análisis HTTPS o prueba otra red; si el error desaparece, la causa es el software de inspección.
5. No continúes en sitios importantes. En banca, correo o cualquier servicio con inicio de sesión, trata una discrepancia de nombre como un alto total. La versión genérica de este aviso la cubrimos en la guía del error "La conexión no es privada".

Si el sitio es tuyo: diagnostica y corrige

Empieza por leer exactamente qué nombres cubre tu certificado. Desde cualquier terminal con OpenSSL instalado:

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

Ejecútalo dos veces, una con tu dominio raíz y otra con www, y compara la salida SAN con cada nombre de host que tus usuarios visitan realmente. Después corrige la causa que encuentres:

• Cubre el dominio raíz y www juntos. Emite un certificado que liste ambos nombres. Let's Encrypt incluye hasta 100 nombres de host por certificado sin coste (documentación de límites de Let's Encrypt), y todas las CA comerciales venden certificados multidominio (SAN).
• Vigila el alcance del comodín. Un comodín cubre exactamente un nivel, según RFC 9525:

• Corrige SNI y el host virtual por defecto. Si tu servidor aloja varios sitios, asegura que cada nombre de host esté ligado a su propio certificado y que el host virtual por defecto no responda con el equivocado a clientes o bots que omiten SNI.
• Revisa los dos extremos de tu CDN. Con un CDN o proxy inverso delante, el certificado del borde debe cubrir tu nombre público y el certificado de origen debe cubrir el nombre al que el CDN se conecta. Una discrepancia en cualquiera de los dos tramos dispara errores.
• No confíes en las redirecciones. TLS se negocia antes de enviar cualquier redirección HTTP. Aunque example.com redirija de inmediato a www.example.com, el certificado servido en example.com debe seguir cubriendo ese nombre.

Una razón más para automatizar: con la votación SC-081v3 del CA/Browser Forum (aprobada en abril de 2025), la vida máxima de los certificados públicos bajó de 398 a 200 días el 15 de marzo de 2026, bajará a 100 días en marzo de 2027 y quedará en 47 días en marzo de 2029. Las renovaciones serán mucho más frecuentes, y cada renovación es una nueva oportunidad de que una lista SAN pierda un nombre sin que nadie lo note. Usa automatización ACME y monitoriza la cobertura en lugar de confiar en la memoria.

Preguntas frecuentes

¿Es seguro hacer clic en "Continuar de todos modos"? Solo cuando sabes con certeza por qué existe la discrepancia, por ejemplo tu propio servidor de pruebas accedido por dirección IP. En cualquier sitio donde escribirías una contraseña o datos de pago, no continúes.

¿Este error significa que el sitio fue hackeado? Casi nunca. Suele indicar un error de configuración: un dominio renombrado, una entrada www olvidada o un comodín que no llega tan lejos como creía el propietario. Los ataques existen, y precisamente por eso los navegadores se niegan a adivinar.

¿Por qué se llama "common name" si los navegadores ignoran el campo CN? El nombre es histórico. Los navegadores comparaban el campo CN hasta que RFC 2818 (2000) lo desaconsejó y Chrome 58 (abril de 2017) lo eliminó. Hoy solo cuenta la lista SAN, según RFC 9525 (noviembre de 2023), pero el identificador del error nunca se renombró.

¿Necesito un certificado distinto para cada subdominio? No. Un certificado puede listar muchas entradas SAN, y un comodín cubre todos los subdominios directos de un nivel. Solo necesitas planificar más para niveles profundos como a.b.example.com, que un comodín de un nivel no cubre.

Comprueba la cobertura de tu certificado en 60 segundos

Una discrepancia de nombre es invisible hasta que alguien visita justo el nombre de host que olvidaste. El escáner gratuito de FortifyNet lee tu certificado activo e informa de qué nombres cubre, junto con tu configuración TLS, cabeceras de seguridad, DNS, autenticación de correo y exposición en la dark web. Ejecuta el escáner gratuito en tu dominio y revisa raíz, www y subdominios de una vez.

Guías relacionadas

• "La conexión no es privada": qué significa el error y cómo solucionarlo
• ERR_CERT_AUTHORITY_INVALID: por qué aparece y cómo solucionarlo
• ERR_SSL_PROTOCOL_ERROR: qué significa y cómo solucionarlo