TLS Certificate Checker

Comprueba el certificado TLS/SSL de un sitio: sujeto/emisor, fechas de validez, SANs, integridad de la cadena y configuraciones erróneas comunes de HTTPS. Opcionalmente sigue redirecciones para verificar que el destino final sea HTTPS con un certificado válido. Exporta informes en JSON/PDF.

Loading…

Acerca de Comprobador de Certificados TLS

Cuando HTTPS falla, los usuarios ven advertencias alarmantes y los bots dejan de confiar en tu sitio. Esta herramienta obtiene una URL, opcionalmente sigue redirecciones e inspecciona el certificado TLS que protege el endpoint HTTPS final. Te ayuda a detectar certificados próximos a caducar, cadenas incompletas, discrepancias de nombre de host/SANs y otros problemas que comúnmente causan errores en navegadores y problemas de SEO/disponibilidad.

Características

  • Inspecciona el sujeto y emisor del certificado (para quién es, quién lo emitió).
  • Valida fechas: notBefore / notAfter, y advierte sobre caducidad inminente.
  • Comprueba SANs (Nombres Alternativos del Sujeto) y cobertura del nombre de host (www vs dominio principal, subdominios).
  • Detecta problemas en la cadena de certificados (intermedios faltantes / cadena incompleta).
  • Seguimiento opcional de redirecciones para validar la aplicación HTTPS de la URL final.
  • Identifica errores comunes de HTTPS (host incorrecto, certificado incorrecto, flujos de redirección mixtos).
  • Resultados y hallazgos fáciles de copiar para tickets de incidencias.
  • Descarga informes JSON y PDF para documentación y comprobaciones de regresión.

🧭 Cómo usarlo for tls-certificate-checker

1

Pega la URL a probar

Introduce la URL objetivo. Puedes pegar https://ejemplo.com o incluso http://ejemplo.com si quieres confirmar que finalmente se actualiza a HTTPS.

2

Activa "Seguir Redirecciones" para un comportamiento real

Si quieres validar el destino real al que llegan usuarios y rastreadores (http→https, no-www→www), mantén activado Seguir Redirecciones.

3

Ejecuta la comprobación y revisa el resumen

Revisa los elementos clave: fechas de validez, coincidencia de nombre de host/SANs y si la cadena está completa.

4

Inspecciona los hallazgos y corrige la causa raíz

Si ves advertencias (caducidad próxima, discrepancia, cadena incompleta), corrígelas en la capa de terminación TLS (CDN, proxy inverso, balanceador de carga o servidor web).

5

Exporta JSON/PDF para seguimiento

Descarga un informe para adjuntar a tickets de operaciones/SEO o para guardar una instantánea de antes/después.

Especificaciones técnicas

Entrada y operación

Esta herramienta comprueba una URL e inspecciona el certificado TLS para el endpoint HTTPS resuelto.

CapacidadDetalles
Formatos de URL admitidosURLs HTTP o HTTPS (se puede habilitar el seguimiento de redirecciones).
Manejo de redireccionesOpcional; cuando está habilitado, sigue hasta el máximo configurado de redirecciones.
Enfoque en TLSInspecciona las propiedades del certificado y configuraciones erróneas comunes.

Valores predeterminados y límites

Los valores predeterminados de obtención y seguridad están ajustados para un comportamiento predecible.

ConfiguraciónValor
Seguir RedireccionesHabilitado
Redirecciones Máximas10
Tiempo de espera15000 ms
Agente de usuarioEncode64Bot/1.0 (+https://encode64.com)
Redes privadasNo permitido

Qué se verifica

Las verificaciones están diseñadas en torno a las fallas más frecuentes observadas en producción: caducidad, falta de coincidencia del nombre de host (cobertura SAN) e integridad de la cadena. El seguimiento de redirecciones ayuda a detectar casos donde HTTPS solo es válido en el host canónico final.

Un certificado válido es necesario pero no suficiente para una seguridad sólida. Combínalo con auditorías de HSTS y cabeceras de seguridad para implementaciones reforzadas.

Línea de comandos

Usa OpenSSL y curl para confirmar los detalles del certificado desde tu propia terminal y comparar con lo que reporta la herramienta.

macOS / Linux

Mostrar cadena de certificados (SNI) para un host

echo | openssl s_client -servername example.com -connect example.com:443 -showcerts 2>/dev/null

Útil para inspeccionar el certificado hoja presentado y la cadena intermedia.

Extraer fecha de caducidad rápidamente

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

Imprime notBefore / notAfter.

Listar SANs

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Muestra qué nombres de host cubre el certificado.

Verificar redirecciones HTTP a HTTPS

curl -I http://example.com

Verificar cabecera Location y esquema final.

Seguir redirecciones y mostrar URL final

curl -IL http://example.com | sed -n '1,120p'

Ayuda a detectar cadenas de redirección y endpoints no canónicos.

Siempre usa -servername con openssl s_client en servidores/CDN con alojamiento virtual. Sin SNI, puedes obtener el certificado incorrecto.

Casos de uso

Prevenir interrupciones por expiración de certificados

Identifica certificados próximos a expirar para que puedas renovarlos antes de que usuarios y bots encuentren errores en el navegador.

  • Revisiones semanales de salud de certificados
  • Auditar dominios después de cambios en DNS o CDN

Solucionar problemas de cadena de certificados incompleta

Detecta intermediarios faltantes (común en configuraciones de servidor personalizadas) que rompen clientes antiguos y algunos rastreadores.

  • Paquete de cadena de Nginx/Apache mal configurado
  • Balanceador de carga sin certificados intermedios

Depurar discordancia de nombre de host/SAN (www vs dominio principal)

Confirma que el certificado cubre el host exacto al que acceden los usuarios, incluyendo www/no-www y subdominios.

  • El dominio principal funciona pero www falla
  • Subdominio API faltante en la lista SAN

Verificar aplicación de HTTPS mediante redirecciones

Asegura que las URLs http redirijan al endpoint https canónico con un certificado válido.

  • http→https con 301
  • canonicalización de no-www→www

❓ Frequently Asked Questions

¿Por qué un navegador puede decir "certificado no confiable" incluso si HTTPS está habilitado?

Las causas comunes son un certificado expirado, una cadena incompleta (intermediario faltante), una discordancia de nombre de host (SAN no incluye el host), o servir el certificado incorrecto debido a una mala configuración de SNI/alojamiento virtual.

¿Qué son los SAN y por qué son importantes?

Los SAN (Nombres Alternativos del Sujeto) son los nombres de host para los que un certificado es válido. Si tu sitio se accede tanto por example.com como por www.example.com, el certificado debe cubrir ambos (o debes redirigir consistentemente a un host cubierto).

¿Está bien que http redirija a https?

Sí, es lo recomendado. Solo asegúrate de que el destino HTTPS final presente un certificado válido y que la cadena de redirección sea corta y consistente (prefiere 301 para redirecciones canónicas).

¿Esta herramienta verifica versiones/cifrados TLS?

Esta herramienta se enfoca en la inspección de certificados y configuraciones erróneas comunes. Para el fortalecimiento de protocolos/cifrados (TLS 1.2/1.3, cifrados débiles), usa un escáner de configuración TLS dedicado.

¿Cuál es la diferencia entre certificados hoja, intermedios y raíz?

El certificado hoja es el certificado de tu sitio. Los intermedios lo vinculan a una CA raíz confiable. Los navegadores confían en las raíces, por lo que la falta de intermedios puede impedir construir una cadena de confianza válida.

Pro Tips

Best Practice

Renueva los certificados temprano y automatiza las renovaciones (ACME) siempre que sea posible.

Best Practice

Asegúrate de que los SANs cubran cada nombre de host público que sirvas (www, dominio principal, subdominios de API) o impón un único host canónico mediante redirecciones.

Best Practice

Sirve siempre la cadena completa (certificado hoja + intermedios). Muchas interrupciones provienen de paquetes de cadena incompletos después de migraciones.

Best Practice

Si habilitas redirecciones, mantenlas al mínimo: un solo salto a la URL https canónica es lo ideal.

Best Practice

Combina TLS válido con HSTS y cabeceras de seguridad para una protección más sólida en el mundo real.

Additional Resources

Other Tools