Por qué mi certificado SSL no es válido y cómo localizar la causa
Un aviso del navegador no prueba que el archivo del certificado sea el problema. Revisa caducidad, SAN, cadena de confianza, intermedios, SNI, TLS y DNS en orden para encontrar la capa que falla.
El navegador dice que la conexión no es privada, o una alerta de despliegue informa de un certificado no válido. Lo primero que apetece hacer es renovar el certificado. Muchas veces no cambia nada.
Una conexión HTTPS exige más que un archivo PEM correcto: el servicio tiene que presentar el certificado adecuado para el nombre solicitado, estar dentro de su periodo de validez, enviar los intermedios necesarios para formar una cadena de confianza y negociar TLS de forma compatible. Puedes tener el certificado nuevo en el disco y seguir sirviendo uno antiguo, o incluso el de otro sitio, al público.
Empieza por el comprobador de SSL. Hace un handshake real y separa caducidad, coincidencia del nombre, confianza, cadena enviada por el servidor y versiones de TLS. «El certificado no es válido» es un síntoma; separar esas comprobaciones evita cambiar cosas a ciegas.
Comprueba primero el extremo al que llega el cliente
Introduce el nombre público, no la ruta del certificado en tu servidor. Si el servicio usa otro puerto, indícalo. Si conectas directamente a una IP situada detrás de un host virtual o balanceador, configura como SNI el nombre que esperas probar.
Anota estos cuatro resultados antes de tocar la configuración:
| Comprobación | Qué responde | Un fallo suele indicar |
|---|---|---|
| Validez | ¿Se puede usar hoy? | Caducidad, fecha de inicio futura o reloj del cliente erróneo |
| Nombre de host | ¿El certificado cubre el nombre solicitado? | SAN incorrectas o respuesta del host virtual equivocado |
| Confianza | ¿Un cliente público llega a una raíz confiable? | Intermedio ausente, CA privada, inspección o emisor no confiable |
| Cadena servida | ¿El servidor entregó los intermedios? | Puede faltar un intermedio, o un problema de confianza o validez puede impedir construir la cadena |
No son el mismo problema. Un certificado caducado puede tener una cadena impecable; uno vigente puede ser de otro nombre; un navegador puede aceptar una cadena incompleta porque ya tenía el intermedio en caché.
Usa el mensaje del navegador para elegir la primera pista
Los nombres cambian entre navegadores, pero este mapa resulta útil:
| Mensaje habitual | Capa más probable | Comprueba primero |
|---|---|---|
NET::ERR_CERT_DATE_INVALID | Fechas o reloj del cliente | notBefore, notAfter y hora del equipo |
NET::ERR_CERT_COMMON_NAME_INVALID | Cobertura del nombre o SNI | SAN y nombre solicitado |
NET::ERR_CERT_AUTHORITY_INVALID | Cadena de confianza o intervención local | Emisor, intermedios y si falla solo en una red |
NET::ERR_CERT_REVOKED | Estado de revocación | Estado del número de serie en la CA y despliegue del certificado nuevo |
ERR_SSL_VERSION_OR_CIPHER_MISMATCH | Negociación TLS | Versiones TLS, proxy y configuración del servidor |
Es un punto de partida, no una prueba. ERR_CERT_AUTHORITY_INVALID puede significar un intermedio que falta, pero también un proxy corporativo que inspecciona HTTPS, un antivirus o un portal cautivo de Wi‑Fi que responde con su propio certificado. Prueba desde otra red antes de declararlo una incidencia de servidor.
Las advertencias de contenido mixto son otra cosa: una página HTTPS cargó un recurso HTTP. Cambiar el certificado no las arregla.
Que haya caducado no significa que la renovación falló
Si el host público sirve un certificado caducado, lee su notAfter exacto y compara su número de serie o huella SHA-256 con el certificado que pensabas desplegar. La renovación puede haber terminado bien en la autoridad certificadora y, aun así, el extremo público seguir presentando el archivo viejo.
Los motivos más comunes son poco exóticos:
- el TLS termina en un CDN, balanceador, Ingress o proxy inverso, no en el servidor de la aplicación;
- un nodo de un grupo no se recargó y el fallo aparece solo a ratos;
- el proceso de renovación escribió el archivo nuevo, pero el servidor web no se recargó;
- el nombre aún resuelve a una IP antigua, preproducción, o IPv4 se actualizó pero IPv6 no.
Toma la IP resuelta por el comprobador y consulta A, AAAA y TTL con DNS Lookup. Revisa ambas familias de direcciones. Que funcione en tu ordenador puede significar únicamente que este prefirió el IPv4 actualizado y otro cliente llegó al IPv6 antiguo.
La revocación es distinta de la caducidad
Un certificado dentro de su periodo de validez también puede estar revocado. NET::ERR_CERT_REVOKED indica que el cliente, según la información de revocación que obtuvo, ya no debe confiar en él; no implica que notAfter sea incorrecto. El comprobador de SSL muestra si se presentó OCSP stapling, pero no verifica la revocación. La fuente de esos datos y el uso de caché varían entre clientes.
Primero confirma con la CA el estado del número de serie. Si la CA confirma la revocación, reemite y despliega de inmediato un certificado nuevo en el terminador TLS real, e investiga causas como una clave privada comprometida, emisión indebida o cambios en el control del dominio. Solo si la CA no confirma la revocación y el error queda limitado a un cliente, revisa ese entorno y la configuración de OCSP stapling.
La cobertura la definen las SAN, no el nombre del archivo
Los clientes modernos verifican la extensión Subject Alternative Name (SAN). El Common Name puede seguir visible, pero no es la base fiable para saber qué nombres cubre el certificado.
Abre el certificado hoja que entrega el extremo público en el decodificador de certificados y compara cada DNS SAN con el nombre que visita la persona:
example.comywww.example.comson nombres distintos;*.example.comcubreapi.example.com, pero noexample.comniv2.api.example.com;- si se accede por IP, hace falta una SAN de tipo IP; una DNS SAN no sirve;
- un certificado para un nombre interno no pasa a ser apto para el nombre público por existir en el mismo servidor.
Si las SAN son correctas pero sigue habiendo discrepancia, sospecha del enrutamiento. Al conectar a una IP sin el SNI esperado, el servidor puede devolver el certificado predeterminado. Un proxy que enruta por nombre puede hacer lo mismo si recibe un SNI distinto al previsto.
No confundas un intermedio ausente con una raíz no confiable
Un servidor normalmente envía el certificado hoja y uno o más intermedios. No debería enviar la raíz. El cliente usa esos intermedios para construir el camino hasta una raíz que ya tiene en su almacén de confianza.
Configurar solo cert.pem en vez del fullchain.pem entregado por la CA es un error de despliegue clásico. Algunos navegadores descargan un intermedio desde Authority Information Access o reutilizan una copia cacheada; clientes de línea de comandos, aplicaciones móviles, dispositivos antiguos y entornos corporativos cerrados quizá no. Por eso una persona puede abrir el sitio y un cliente real no.
El comprobador muestra por separado si la cadena es confiable y si el servidor la entregó completa. Este último fallo suele deberse a un intermedio ausente, pero también puede aparecer si otro certificado de la cadena está caducado o no es confiable. Inspecciona cada certificado entregado antes de instalar nada. Si el certificado hoja es válido y falta un intermedio, instala la cadena completa proporcionada por el emisor en el terminador TLS real. No arregles el problema añadiendo una raíz cualquiera a la configuración del servidor.
Revisa SNI antes de culpar al certificado
Una sola IP puede servir muchos nombres HTTPS. SNI indica durante el handshake qué nombre espera el cliente. Sin el SNI adecuado, el servidor puede devolver correctamente su certificado predeterminado; simplemente no será el certificado del nombre al que querías llegar.
Esto es frecuente tras migrar a un CDN, proxy inverso, Kubernetes Ingress o balanceador compartido. También afecta a la monitorización: una sonda que se conecta a una IP sin SNI no está haciendo la misma petición que un navegador.
Para aislarlo, revisa la misma IP dos veces: una sin SNI y otra con el nombre de producción como SNI. Si el certificado cambia, su selección varía con la petición o con el nodo alcanzado; los hosts virtuales son habituales, pero el balanceo también puede explicarlo. Si solo con SNI aparece uno incorrecto, revisa la regla de proxy o de enrutamiento de ese nombre.
DNS puede llevar a la gente al extremo TLS equivocado
DNS no valida certificados, pero decide a qué extremo se le pide uno. Tras una migración, revisa A, AAAA y CNAME, y sigue los CNAME para descubrir si hay un CDN o plataforma delante. Un TTL bajo no borra de inmediato las respuestas antiguas de todas las cachés; solo limita cuánto pueden conservar una respuesta desde que la recibieron.
CAA afecta a la emisión y renovación, no a la validación por el navegador de un certificado ya emitido. Si no puedes renovar, inspecciona CAA. Si ves un nombre que no coincide, empieza por A, AAAA, CNAME, el mapeo del CDN y SNI.
Si solo falla en un equipo, mira el lado del cliente
Cuando la comprobación desde una red independiente es correcta y solo una persona ve el aviso, busca qué diferencia a ese cliente:
- revisa hora y zona horaria; un reloj muy desviado vuelve inválido un certificado válido;
- prueba otra red; portales cautivos, inspección HTTPS corporativa y software de seguridad pueden presentar su propio certificado;
- comprueba si el almacén de raíces de un sistema o dispositivo muy antiguo confía en la cadena; quizá haga falta una actualización o un cambio de confianza admitido por el proveedor;
- comprueba que no se introdujo una IP, un nombre antiguo o un alias interno en lugar del host público.
No aconsejes «continuar de todos modos» ante un aviso de certificado en un inicio de sesión, pago o panel de administración. Primero hay que saber por qué ese cliente está viendo un certificado distinto o no confiable.
Un orden seguro para resolverlo
- Comprueba el host público con el comprobador de SSL, usando el puerto y SNI reales si hacen falta.
- Separa el fallo: fecha, nombre, confianza, cadena enviada o negociación TLS. La revocación se determina con el aviso del navegador y el estado de la CA, no con el comprobador de SSL.
- Decodifica la cadena pública con el decodificador de certificados y compara SAN, emisores, fechas, números de serie y huellas con los certificados que pretendías servir.
- Si hay migración o renovación, consulta A, AAAA, CNAME y CAA con DNS Lookup.
- Corrige el terminador TLS que sirve el certificado incorrecto y recárgalo o vuelve a desplegarlo.
- Comprueba de nuevo el extremo público; en un servicio con varios nodos, verifica que cada dirección devuelve el certificado esperado.
Este orden mantiene pequeño un incidente de certificados. En vez de emitir certificados una y otra vez hasta que desaparezca el aviso, averiguas si el fallo está en el certificado, la cadena, el nombre, la ruta o el cliente que lo observa.
Si la comprobación pública apunta a la cadena, sigue con ¿Por qué mi cadena de certificados está incompleta?. Si el certificado es confiable pero no cubre el hostname solicitado, consulta ¿Por qué mi certificado SSL no coincide con mi dominio?.