NET::ERR_CERT_COMMON_NAME_INVALID

Qué significa este error y cómo reconocerlo

• Chrome o Edge muestra “Tu conexión no es privada” con NET::ERR_CERT_COMMON_NAME_INVALID.
• Los detalles del certificado muestran un Common Name o Subject Alternative Name correspondiente a otro hostname.
• El dominio raíz funciona, pero falla un subdominio concreto.
• El error comienza después de añadir un subdominio, cambiar el DNS, migrar el hosting o activar un CDN o balanceador de carga.
• Un servidor compartido o CDN presenta un certificado predeterminado, provisional o no relacionado.
• Algunos usuarios o redes ven el error y otros no, lo que suele indicar rutas diferentes de IPv4, IPv6, DNS o enrutamiento del edge.

Causas principales, ordenadas por probabilidad

1. El certificado no incluye el hostname solicitado. El hostname que falla puede no estar en la lista de SAN del certificado. Un wildcard puede cubrir algunos subdominios, pero su alcance debe coincidir con el nombre solicitado.
2. El servidor está sirviendo su certificado predeterminado. Es posible que el hosting compartido no tenga el certificado asignado al dominio o que la selección de SNI y del virtual host HTTPS sea incorrecta.
3. Un CDN o balanceador de carga tiene el certificado edge equivocado. Es posible que el hostname no esté configurado en el servicio o que la solicitud llegue a un listener o una configuración edge predeterminados.
4. El DNS apunta al endpoint equivocado. Un registro A, AAAA o CNAME incorrecto puede enviar la solicitud a un servidor que presenta el certificado de otro sitio. Un registro AAAA incorrecto puede afectar a los usuarios de IPv6 aunque IPv4 funcione.
5. Una migración o cambio de dominio dejó los servicios desincronizados. El DNS, el CDN, el servidor de origen y el certificado pueden estar configurados para hostnames o endpoints diferentes.

Cómo solucionarlo

1. Identifica el hostname exacto y la discrepancia del certificado

Comprueba el hostname completo en la barra de direcciones, incluidos todos los subdominios. Abre los detalles del certificado del navegador e inspecciona el Common Name y los Subject Alternative Names (SAN). El hostname solicitado debe aparecer en la lista de SAN o coincidir con un patrón wildcard aplicable.

Para comprobarlo desde la línea de comandos, establece la variable con el hostname que estás probando:

HOSTNAME='[your hostname]'
openssl s_client -connect "$HOSTNAME:443" -servername "$HOSTNAME" </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

La opción -servername envía el hostname mediante SNI, algo importante en infraestructuras HTTPS compartidas. Ejecuta los comandos de diagnóstico antes de cambiar la configuración.

2. Añade el hostname al certificado

Si el certificado cubre el dominio raíz, pero no el subdominio que falla, vuelve a emitirlo o reemplázalo por uno que incluya el hostname necesario como SAN. Un certificado wildcard puede cubrir varios subdominios de un nivel, pero confirma por separado la cobertura del dominio raíz y de cualquier subdominio más profundo.

Si utilizas Certbot, confirma primero que tienes autorización para solicitar y desplegar un certificado para el dominio, que el webroot es correcto y que el método de validación es adecuado para el servidor. Incluye todos los nombres necesarios en la solicitud de emisión:

DOMAIN='[your bare domain]'
SUBDOMAIN='[your subdomain]'
certbot certonly --webroot -w '[your webroot]' -d "$DOMAIN" -d "$SUBDOMAIN"

Esto obtiene un certificado, pero por sí solo no lo instala ni lo activa. Utiliza el método de emisión y el webroot adecuados para el servidor; después, instala el certificado en el endpoint que termina HTTPS y asígnalo al hostname correcto.

3. Comprueba la configuración del hosting compartido y del servidor de origen

En el panel de control del hosting, confirma que hay un certificado instalado y asignado al dominio o subdominio exacto. En un servidor compartido, pide al proveedor que verifique la selección de certificados basada en SNI y la configuración del virtual host HTTPS.

Recarga o reinicia el servidor web solo después de confirmar que los archivos del certificado, los permisos y la configuración son correctos. Una recarga o un reinicio puede interrumpir el servicio, así que sigue el procedimiento de cambios del proveedor y obtén la autorización necesaria antes de aplicarlo.

4. Comprueba la cobertura del certificado en el CDN y el balanceador de carga

Verifica que el hostname exacto esté configurado en el CDN o balanceador de carga y que esté incluido en su certificado edge. Confirma también que el hostname se enruta al origen previsto.

Si el CDN termina HTTPS, el certificado del origen por sí solo no resuelve una discrepancia en el navegador. El certificado servido por el endpoint edge público debe cubrir el hostname. Si el CDN transmite HTTPS directamente, inspecciona el certificado del origen.

5. Verifica el DNS para IPv4 e IPv6

Compara los registros A, AAAA y CNAME del hostname con el endpoint o destino proporcionado por el proveedor de hosting o CDN. Comprueba si la red afectada utiliza IPv4 o IPv6 y si ambas rutas llegan al servicio previsto.

Corrige los registros obsoletos o no deseados solo después de confirmar el endpoint previsto y el procedimiento adecuado para el cambio de DNS. Comprueba el resultado desde la red afectada, ya que las respuestas DNS almacenadas en caché pueden persistir hasta que expire su TTL.

6. Vuelve a probar el mismo hostname HTTPS

Después de cambiar la asignación del certificado, el enrutamiento o el DNS, prueba la URL exacta que fallaba. Inspecciona de nuevo el certificado devuelto y confirma su lista de SAN, emisor y fechas de validez. Prueba también desde la red afectada y desde el entorno de hosting, CDN o servidor para distinguir las diferencias de propagación o resolución de una configuración incorrecta activa.

Prevención y cómo verificar la solución

• Incluye la cobertura del certificado cada vez que añadas un subdominio, cambies el DNS, migres el hosting o añadas un CDN.
• Usa cobertura SAN o un wildcard con el alcance adecuado solo después de comprobar el dominio raíz, los subdominios de un nivel y los nombres más profundos que realmente utilice el servicio.
• Mantén alineados los registros DNS, los hostnames del CDN, los listeners del balanceador de carga, los virtual hosts del origen y las asignaciones de certificados.
• Prueba las rutas A y AAAA después de cambiar el DNS.
• Inspecciona el certificado servido por el endpoint público en lugar de basarte únicamente en la ausencia de una advertencia del navegador.
• Registra qué servicio termina HTTPS para realizar los cambios de certificado en la capa correcta.
• Mantén procedimientos de renovación y despliegue de certificados que incluyan todos los hostnames necesarios.

Preguntas frecuentes