¿Por qué mi certificado SSL no coincide con mi dominio? SAN y SNI explicados
Un error de nombre no siempre significa que el certificado se solicitó mal. El hostname pedido, los SAN, la profundidad del comodín, SNI, DNS, CDN y el balanceador pueden hacer que el cliente reciba otro certificado. Sigue la ruta pública hasta el extremo que realmente lo entrega.
Cuando el navegador dice que el certificado no coincide con el dominio, es fácil concluir que el certificado se solicitó mal. A veces es así, pero a menudo el certificado es correcto: la persona usó otro hostname, el servidor eligió su certificado por defecto porque faltaba SNI o DNS llevó parte del tráfico a un extremo que aún sirve un certificado viejo.
La investigación se simplifica al separar dos preguntas: ¿qué hostname pidió el cliente?, ¿y qué certificado devolvió de verdad el extremo TLS público? Cuando esos hechos se separan, errores como NET::ERR_CERT_COMMON_NAME_INVALID dejan de ser misteriosos.
Empieza con el comprobador de SSL contra el hostname público. Muestra el resultado del nombre, la cadena servida y las direcciones resueltas. Después usa el decodificador de certificados para leer los Subject Alternative Names.
La cobertura del nombre sale de SAN, no del archivo ni del Common Name
Los clientes modernos usan la extensión Subject Alternative Name (SAN) para decidir qué nombres cubre el certificado. El Common Name puede seguir visible, pero no es la fuente fiable de cobertura. Tampoco lo son los nombres de archivo, pedidos ni notas de consola.
Abre el certificado hoja que devuelve el extremo público y compara cada DNS SAN con el hostname completo de la barra de direcciones. No basta con ver el dominio de la empresa «por algún lado»; debe estar cubierto el nombre exacto solicitado.
| Dirección solicitada | Cobertura necesaria | Confusión habitual |
|---|---|---|
example.com | Un DNS SAN para example.com | *.example.com incluye el dominio raíz |
www.example.com | www.example.com o un comodín que lo alcance | Un certificado solo para la raíz cubre www automáticamente |
api.example.com | api.example.com o *.example.com | Cualquier comodín sirve a cualquier profundidad |
v2.api.example.com | Un SAN exacto o *.api.example.com | *.example.com cruza dos etiquetas |
https://203.0.113.10/ | Un IP SAN correspondiente | Un DNS SAN cubre una visita por IP |
Un comodín sustituye una etiqueta, no toda la jerarquía
*.example.com puede cubrir api.example.com, pero no example.com ni v2.api.example.com. El asterisco representa una sola etiqueta entre puntos; no da permiso para todos los niveles bajo un dominio.
Antes de solicitar el certificado, haz inventario desde las entradas reales: raíz, www, API, administración, subdominios regionales y hostnames de monitorización. Incluye los nombres que vayas a mover pronto en el plan de renovación o reemplazo, en lugar de descubrir un SAN ausente durante el cambio.
SNI le dice al servidor qué certificado elegir primero
Una IP puede servir muchos nombres HTTPS. TLS empieza antes de la petición HTTP, así que el servidor no puede usar la ruta completa de la URL para elegir el certificado. El cliente envía SNI para indicar qué hostname espera, y el servidor selecciona el certificado a partir de ese valor.
Si una prueba conecta solo a una IP, un monitor omite SNI o un proxy cambia el nombre SNI, el servidor suele devolver el certificado de su sitio predeterminado. Puede ser un certificado perfectamente válido, pero no para el nombre al que quería llegar la persona.
Prueba con el hostname real y, al probar una IP, indica expresamente el SNI esperado. Compara la misma IP con y sin ese SNI: certificados distintos significan que la selección cambia por petición o nodo. Si aparece el certificado incorrecto incluso con SNI correcto, revisa la regla de virtual host, Ingress o balanceador correspondiente.
DNS, CDN y balanceadores pueden llevar a un extremo antiguo
Tener SAN y SNI correctos no garantiza llegar al servidor previsto. Tras una migración o cambio de certificado, IPv4 puede estar actualizado mientras IPv6 sigue apuntando al servicio antiguo; un CNAME puede atravesar un CDN, plataforma o varias capas de balanceo.
Usa DNS Lookup para revisar A, AAAA, CNAME y TTL, y sigue los CNAME hasta identificar el borde público real. Un TTL bajo no hace que todas las cachés recursivas olviden una respuesta antigua al instante; solo limita cuánto puede retenerla una caché desde que la recibió. Si el fallo es intermitente, prueba cada resolución y nodo.
El certificado en disco puede no ser el que sirve Internet
Muchas investigaciones se detienen en «el certificado de mi servidor tiene los SAN correctos». El terminador TLS público puede ser un CDN, balanceador cloud, Ingress de Kubernetes, proxy inverso o incluso un servidor antiguo que nunca salió de servicio. Que el backend sea correcto solo demuestra que el backend es correcto.
Toma como referencia el número de serie o la huella SHA-256 del handshake público. Sigue la ruta de tráfico hasta el terminador TLS que devuelve ese certificado. Si un borde aún entrega el certificado antiguo, actualiza y recarga ese borde, y verifícalo desde fuera en vez de volver a cambiar el servidor de aplicación.
La forma del hostname también cambia el resultado
Quien visita el sitio no siempre usa la dirección canónica que imaginabas. Puede introducir una IP, un nombre antiguo, un alias interno o un hostname con una errata. Los dominios internacionalizados suelen representarse como Punycode en certificados y DNS, por lo que conviene comparar el hostname usado realmente en el handshake y no solo lo que muestra una interfaz.
La coincidencia de certificado responde solo si el nombre solicitado está cubierto. Si certificado y cadena son correctos, pero una red concreta muestra un certificado extraño, descarta también la inspección HTTPS corporativa, portales cautivos y software de seguridad que sustituya la conexión.
Un orden práctico desde el error hasta la corrección
- Anota el hostname completo y el error del navegador o cliente; no lo reduzcas a «no coincide el certificado».
- Comprueba ese hostname público con el comprobador de SSL, incluyendo puerto y SNI reales cuando haga falta.
- Abre la hoja pública en el decodificador de certificados y compara sus DNS SAN con el hostname solicitado.
- Comprueba raíz, www, profundidad del comodín, subdominios anidados y acceso por IP frente a la cobertura prevista.
- Compara la misma IP con y sin SNI esperado, y revisa el enrutamiento de nombres en CDN, balanceador o Ingress.
- Usa DNS Lookup para A, AAAA, CNAME y cada entrada pública posible; asegúrate de que ningún nodo antiguo siga devolviendo el certificado equivocado.
- Corrige el terminador TLS real y repite el handshake público por IPv4, IPv6 y el cliente que falló primero.
Si la cobertura de nombre pasa pero el cliente sigue sin confiar en el certificado, deja de cambiar SAN. La siguiente capa es la cadena: lee ¿Por qué mi cadena de certificados está incompleta?. Para el mapa general, consulta ¿Por qué mi certificado SSL no es válido?.