¿Para qué sirve esta herramienta?
El SSL Certificate Checker responde a una pregunta que el navegador deja sin respuesta: ¿este certificado HTTPS es válido, de confianza, coincide con el dominio y cuándo expira? Un navegador muestra «conexión segura» o «tu conexión no es privada», nunca el porqué.
La herramienta abre una conexión TLS real hacia el host, inspecciona el certificado del servidor y la cadena presentada, y luego emite un veredicto de estados discretos. Nada de «parece que va bien». Una respuesta.
La diferencia con la barra de direcciones se reduce a un punto: el navegador juzga la conexión tal como él la ve, después de haber rescatado ya entre bastidores una cadena defectuosa. El checker juzga la cadena tal como el servidor la sirve realmente, como la vería curl, un servidor de API remoto o un smartphone. Es esta visión honesta la que destapa las averías fantasma.
Tres usos que aparecen una y otra vez:
- Antes de un incidente: un certificado expira dentro de ocho días, sin ninguna alerta del navegador, avería total en el vencimiento. Lo ves venir.
- Después de un despliegue: el sitio se abre en tu equipo, pero el webhook del socio devuelve un error TLS. Cadena incompleta, casi siempre.
- En una auditoría: clave RSA de 1024 bits o firma SHA-1 que arrastra un viejo servicio interno. El veredicto la señala.
Cómo leer el veredicto
El veredicto cabe en una palabra con color, y esa palabra basta para decidir. Así se descifra.
| Veredicto | Color | Qué significa |
|---|---|---|
| Válido | verde | De confianza, coincide con el dominio, cadena completa, clave y firma al día. Nada que hacer. |
| Expira pronto | naranja | Correcto hoy, pero el vencimiento se acerca o la criptografía es débil. A corregir sin prisa. |
| Inválido | rojo | Expirado, aún no válido, nombre de host incorrecto, o cadena no verificable. El navegador mostrará un error. |
| Autofirmado | rojo distinto | El certificado se firmó a sí mismo. Ninguna confianza pública. |
| Inaccesible | técnico | El servidor no respondió: timeout, rechazo, o IP bloqueada. |
Bajo el veredicto, el detalle: fecha de expiración y días restantes, cadena presentada en orden, lista de SAN, versión TLS, cipher, tipo y tamaño de clave, algoritmo de firma. Suficiente para diagnosticar, no solo constatar.
Un caso merece detenerse en él. Inválido no siempre quiere decir «certificado malo». Cuando la única anomalía es una cadena servida incompleta, el mensaje pasa a un diagnóstico preciso: sirve el fullchain. El certificado es bueno; lo que falla es su entrega.
Los casos concretos que la herramienta destapa
Cadena incompleta: el servidor solo presenta el certificado del servidor
Es el gran clásico. El servidor envía su certificado del servidor, pero olvida el intermedio que lo enlaza con la raíz. Resultado: la cadena no remonta a ninguna autoridad reconocida, tal como se sirve.
Chrome y Edge se las arreglan: descargan el intermedio ausente por su cuenta (AIA fetching). El sitio «funciona en tu equipo». Pero curl falla, el cliente de correo falla, la app móvil falla, la biblioteca HTTP del socio falla. Un infierno para diagnosticar sin herramienta dedicada, porque el síntoma depende de quién mire.
La corrección es única y sin sorpresas: servir el fullchain, es decir, el certificado del servidor seguido del intermedio o los intermedios, concatenados en el orden correcto. Let's Encrypt te entrega directamente un archivo fullchain.pem listo para usar.
# Contar los certificados realmente servidos
openssl s_client -connect captaindns.com:443 -servername captaindns.com -showcerts </dev/null 2>/dev/null | grep -c "BEGIN CERTIFICATE"
# 1 solo certificado = cadena incompleta
Un caso particular a menudo se toma por un fallo de la herramienta: el certificado del servidor servido solo que se verifica de todos modos. Eso solo ocurre si ese certificado fue emitido directamente por una raíz, algo que el CA/Browser Forum ahora prohíbe. En la práctica, un certificado público servido solo sale inválido, y la recomendación es siempre la misma: fullchain.
Expiración: la avería que ningún navegador anuncia
Un certificado que expira dentro de diez días no dispara ningún aviso. El día señalado, todo cae. HTTPS bloqueado, API muda, webhooks en error, y el soporte ardiendo.
La herramienta coloca la fecha de expiración y los días restantes al frente del resultado. Por debajo de un mes, pasa a aviso. Pero una instantánea no previene: para eso hace falta una supervisión que gire en bucle (ver más abajo).
Nombre de host: el dominio ausente de los SAN
El certificado es válido y de confianza, pero no cubre el nombre solicitado. Los navegadores ignoran el viejo campo Common Name: leen únicamente los SAN (Subject Alternative Names). Si el dominio no está ahí, error NET::ERR_CERT_COMMON_NAME_INVALID, diga lo que diga el CN.
La trampa más frecuente es el wildcard. *.captaindns.com cubre www.captaindns.com, pero no el apex captaindns.com, ni un nivel más abajo como a.b.captaindns.com. Un wildcard solo baja un peldaño. La corrección: reemitir listando todos los nombres deseados en los SAN.
Autofirmado: cifrado, pero sin confianza
Un certificado autofirmado tiene el mismo emisor y el mismo sujeto. Cifra la conexión, así que los datos circulan bien protegidos. Pero nadie garantiza a quién pertenece la clave. El navegador la rechaza y muestra un aviso.
Perfecto para un servicio interno o un entorno de pruebas. En un sitio público, es un callejón sin salida: emite mejor un certificado gratuito mediante Let's Encrypt y automatízalo con ACME. La herramienta aísla este caso en un veredicto aparte, para no confundirlo con un certificado roto.
Criptografía débil: los fósiles que arrastramos
Una clave RSA por debajo de 2048 bits, una clave ECDSA por debajo de 256 bits, una firma SHA-1 o MD5: otras tantas reliquias que rondan por viejos servicios jamás migrados. El navegador puede tolerarlas un tiempo, pero están en la cuerda floja. La herramienta las señala en el certificado del servidor, antes de que un endurecimiento del cliente las haga rechazar de un día para otro.
Automatización y supervisión: la única estrategia sostenible
Verificar a mano sirve para un incidente puntual. No aguanta con el tiempo, y el calendario lo vuelve insostenible.
El CA/Browser Forum reduce la vida útil de los certificados por etapas: 200 días en marzo de 2026, 100 días en 2027, 47 días en 2029. Con 47 días, renovar a mano se vuelve absurdo. Se imponen dos reflejos.
Automatizar la emisión con ACME. El protocolo ACME (el de Let's Encrypt, mediante certbot, Caddy, Traefik, lego) renueva y reinstala el certificado sin intervención humana. Configurado una vez, olvidado después. Es la única forma de seguir el ritmo.
Supervisar la expiración de forma continua. La automatización falla a veces en silencio: cuota de emisión alcanzada, DNS roto para la validación, hook de recarga mudo. Una supervisión que comprueba la expiración a intervalos regulares y alerta con antelación cubre esos huecos. El HTTP Uptime Monitor de CaptainDNS cumple este papel para tus endpoints HTTPS.
Este checker y el monitor se complementan: uno diagnostica en el instante, el otro monta guardia. Para profundizar en el calendario y sus consecuencias, lee nuestra guía sobre la reducción de la duración de los certificados a 47 días. Y para pasar de la verificación puntual a un enfoque completo (inventario, automatización ACME, supervisión de expiración), nuestra guía sobre la gestión del ciclo de vida de los certificados desarrolla el método.
Solo web HTTPS
Esta versión cubre el web HTTPS: conexión TLS implícita sobre host:puerto, puerto 443 por defecto. El correo queda fuera del alcance. Un servidor SMTP suele negociar el TLS después, mediante STARTTLS, en los puertos 25, 587 o 465: una conexión directa no vería nada ahí.
Para el certificado de un servidor de correo, dos herramientas toman el relevo: el SMTP/MX Tester inspecciona el certificado presentado en STARTTLS, y el verificador DANE/TLSA confirma que coincide con la huella publicada en el DNS. No mezcles los dos mundos: un certificado web y un certificado MX no se verifican de la misma forma.
FAQ - Preguntas frecuentes
P: ¿Cómo verificar un certificado SSL en línea?
R: Introduce el nombre de dominio en el campo host y ejecuta la verificación. La herramienta abre una conexión TLS hacia el host y el puerto (443 por defecto), inspecciona el certificado del servidor y la cadena presentada, y devuelve un veredicto: validez, coincidencia del nombre de host, confianza del sistema, expiración, robustez de la clave y de la firma.
P: ¿Qué diferencia hay entre certificado del servidor, intermedio y raíz?
R: El certificado del servidor lleva tu nombre de dominio. El intermedio enlaza entre él y la raíz. La raíz (root CA) vive en el almacén de confianza del sistema. El servidor debe presentar el certificado del servidor seguido de los intermedios; la raíz no tiene que enviarse. Esa secuencia es el fullchain.
P: ¿Por qué mi sitio funciona en Chrome pero falla en otros lugares?
R: Es el síntoma de un intermediario ausente. Chrome y Edge recuperan el intermediario que falta por su cuenta (AIA fetching), pero curl, los clientes de correo y muchos móviles rechazan la conexión. Sirve la cadena completa (fullchain) para corregir en todas partes.
P: ¿Cuánto tiempo es válido un certificado SSL?
R: Hasta 398 días hoy, pero la duración se derrite. El CA/Browser Forum impone 200 días en marzo de 2026, 100 días en 2027, 47 días en 2029. Let's Encrypt ya emite a 90 días. A este ritmo, renovar a mano deja de ser viable: hay que automatizar mediante ACME.
P: ¿Cómo supervisar la expiración de un certificado SSL?
R: Este checker ofrece una instantánea. Para recibir un aviso antes del corte, conecta una supervisión continua con el HTTP Uptime Monitor: comprueba la expiración a intervalos regulares y alerta al acercarse el vencimiento.
P: ¿Qué significa un certificado autofirmado?
R: Su emisor y su sujeto son idénticos: se firmó a sí mismo. Cifra la conexión pero no ofrece ninguna confianza pública, de ahí el aviso del navegador. Bueno para uso interno; para un sitio público, elige un certificado emitido por una autoridad reconocida como Let's Encrypt.
P: ¿Qué hacer si el nombre de host no coincide?
R: El dominio solicitado no está en los SAN del certificado. Caso corriente: un wildcard *.captaindns.com no cubre ni el apex ni un sub-subdominio. Reemite el certificado con todos los nombres deseados en los SAN. El Common Name ya no cuenta: solo se leen los SAN.
Herramientas complementarias
| Herramienta | Utilidad |
|---|---|
| Analizador de CSR | Decodificar un CSR antes de enviarlo a tu autoridad de certificación |
| Verificador DANE/TLSA | Confirmar la huella del certificado de correo publicada en el DNS |
| Verificador TLS-RPT | Recibir informes sobre los fallos TLS de tus servidores de correo |
| HTTP Uptime Monitor | Supervisar la disponibilidad y la expiración de tus endpoints HTTPS |
Recursos útiles
- RFC 5280 - Perfil de los certificados X.509 (estructura y validación de los certificados)
- RFC 6125 - Verificación del nombre de host (coincidencia SAN y wildcards)
- CA/Browser Forum - Baseline Requirements (reglas de emisión y vida útil)
- Documentación Let's Encrypt - Certificados de cadena (fullchain e intermedios)