Comprobador SSL
Escribe un dominio y verás el certificado TLS que el servidor está sirviendo ahora mismo: cuántos días quedan hasta que caduque, si la cadena se valida contra los certificados raíz públicos, si el nombre coincide, qué hosts cubren los SAN y qué versiones de TLS sigue aceptando el servidor. Cada certificado de la cadena se puede exportar como PEM o abrir en el decodificador de certificados. Es gratis y no requiere registro.
- Handshake real contra el host: no hace falta pegar un PEM, basta con el dominio
- Cuenta atrás en días hasta la caducidad, con las fechas exactas de inicio y fin
- Veredictos separados para confianza de la cadena, coincidencia del nombre, vigencia y cadena completa
- Matriz de TLS 1.0 a 1.3 con el cifrado negociado en cada versión
- Cadena completa con SAN, tamaño de clave y huellas, exportable como PEM o JSON
El nombre de host que se envía en el handshake. Déjalo vacío para usar el destino de arriba; indícalo cuando conectes a una IP concreta pero quieras el certificado de un nombre determinado.
Resumen
Una sola comprobación responde a lo que siempre se pregunta cuando un certificado falla: cuándo caduca, si es de confianza, qué nombres cubre y qué negocia el servidor.
- 01
Cuenta atrás hasta la caducidad
Los días restantes se muestran como una cifra clara, con color según se acerque el plazo, junto al periodo de validez exacto en UTC.
- 02
Cada veredicto por separado
Confianza, coincidencia del nombre, vigencia, cadena completa y versiones obsoletas de TLS se informan uno a uno, de modo que un nombre que no coincide nunca tape una cadena que no es de confianza.
- 03
Todos los nombres que cubre
La lista completa de nombres alternativos del sujeto, comodines incluidos, para confirmar que un subdominio está cubierto antes de apuntarlo al servidor.
- 04
Compatibilidad por versión de TLS
TLS 1.0, 1.1, 1.2 y 1.3 se prueban por separado, con el conjunto de cifrado negociado en las versiones que el servidor acepta.
- 05
La cadena tal y como la envía el servidor
Certificado del servidor, intermedios y la raíz que el servidor incluya, cada uno con su emisor, clave, usos, huellas y puntos OCSP y CRL.
- 06
Exportar y continuar en otra herramienta
Descarga la cadena como fullchain.pem o el resultado completo en JSON, o abre cualquier certificado en el decodificador para leerlo campo a campo.
Cómo usarla
Comprueba un certificado como lo ve un navegador: escribe el destino, lee los veredictos y luego entra en la cadena.
- 01
Escribe un dominio —o pega una URL completa, el esquema y la ruta se ignoran— y pulsa Comprobar.
- 02
Indica un puerto si el servicio no escucha en el 443, y un SNI si conectas directamente a una IP.
- 03
Lee la cuenta atrás y las comprobaciones: confianza, nombre de host, vigencia, cadena completa y protocolos obsoletos aún aceptados.
- 04
Revisa la matriz de versiones por si TLS 1.0 o 1.1 siguen aceptándose, y fíjate en el cifrado negociado.
- 05
Abre cualquier certificado de la cadena para ver sus SAN y huellas, y exporta la cadena en PEM o el resultado en JSON.
Detalles
Los certificados fallan de unas pocas maneras conocidas, y cada una tiene su propia línea en el resultado en lugar de un único aprobado o suspenso.
- La comprobación hace un handshake real desde el servicio de DevKitLab, así que refleja el extremo al que llega ese servicio y no lo que tu navegador tenga en caché
- La confianza y la verificación del nombre se informan por separado, porque un certificado puede ser válido y aun así no ser el del nombre solicitado
- Una cadena incompleta se señala aunque tu navegador la resuelva por el enlace AIA, porque los clientes estrictos y los dispositivos antiguos no lo harán
- La cuenta atrás pasa a negativo cuando el certificado ya ha caducado, de modo que el tamaño del problema queda a la vista
- Admite servicios que empiezan TLS al conectarse al puerto: correo con TLS implícito, LDAPS y servicios compatibles en puertos no estándar
- Indicar el SNI aparte del destino permite probar un servidor concreto detrás de un balanceador o de una dirección anycast
Casos de uso
La vida de los certificados es cada vez más corta —90 días es lo habitual— y casi todo el mundo llega a esta página justo después de que algo se rompa.
-
Confirmar que la renovación surtió efecto
Tras renovar, comprueba el host: la cuenta atrás demuestra que el certificado nuevo se está sirviendo y no solo está guardado en disco.
-
Localizar el origen de un aviso del navegador
Separa las tres causas habituales —caducado, cadena no confiable, nombre incorrecto— en vez de adivinar desde la página de error.
-
Encontrar un intermedio que falta
Un sitio que funciona en el navegador pero falla en curl, Java o una app móvil suele ser una cadena que el servidor no envía completa.
-
Verificar que un subdominio está cubierto
Consulta la lista de SAN para ver si el comodín o el nombre exacto que vas a desplegar está realmente en el certificado.
-
Revisar un servicio en un puerto no estándar
Correo en 465, IMAPS en 993, LDAPS en 636 u otro servicio que empiece TLS al conectarse a su propio puerto: indícalo y revisa el certificado que presenta.
-
Auditar los protocolos antes de una revisión
Comprueba si el servidor sigue aceptando TLS 1.0 o 1.1 y qué cifrado negocia cada versión, y lleva el resultado al ticket.
Ver también
Si ya tienes el certificado en un archivo PEM y quieres leer cada extensión campo a campo, usa el Decodificador de certificados. Si el host ni siquiera resuelve, o necesitas confirmar el registro CAA que controla quién puede emitir certificados para el dominio, empieza por la Consulta de DNS. Y para comparar la huella de un certificado con el valor que te han dado, calcula los resúmenes en local con el Generador de hash.
Buenas prácticas
Una comprobación es una foto de un extremo en un momento concreto. Estas costumbres hacen que el resultado siga siendo útil.
- Comprueba el nombre que escriben tus usuarios, con y sin www: a menudo los sirven configuraciones distintas.
- Renueva mucho antes de que la cuenta atrás baje de diez días; una renovación automática que falló en silencio es la causa más común de caída.
- Trata una cadena incompleta como un error real aunque los navegadores lo disimulen, porque los clientes de API, los Android antiguos y varios runtimes no lo hacen.
- Detrás de un balanceador, comprueba cada origen por IP indicando el SNI, porque un nodo puede haberse quedado con el certificado antiguo.
- Desactiva TLS 1.0 y 1.1 en cuanto confirmes que nada depende de ellos: ambos están obsoletos y suelen aparecer en las auditorías.
- Guarda el JSON junto al ticket cuando traspases una incidencia, para dejar registrado el estado exacto de ese momento.
Limitaciones
La herramienta hace un handshake TLS saliente e informa de lo que el servidor presenta. Su alcance es deliberadamente más limitado que el de una calificación de seguridad completa.
- No comprueba la revocación. Los puntos OCSP y CRL del certificado se listan, pero no se consultan, así que un certificado revocado puede seguir pareciendo válido aquí.
- Solo se pueden comprobar hosts accesibles desde internet. Las direcciones privadas, de bucle local, de enlace local y reservadas se rechazan, así que un servidor interno necesita una herramienta local como openssl s_client.
- El resultado refleja el extremo al que llegó nuestro servidor. Los despliegues anycast o con enrutado geográfico pueden servir otro certificado en otras regiones.
- No hay una nota global. El orden de los cifrados, la fuerza del intercambio de claves y las vulnerabilidades conocidas del protocolo quedan fuera de esta comprobación.
- Los registros de transparencia de certificados, la política HSTS y el contenido mixto son asuntos aparte y no se analizan aquí.
- Las comprobaciones pasan por el servicio de DevKitLab, que conecta en tu nombre; el host de destino ve nuestra dirección, no la tuya.
Preguntas frecuentes
Preguntas frecuentes sobre caducidad, errores de confianza, nombres que no coinciden, puertos y lo que esta comprobación no cubre.
¿Cómo compruebo el certificado SSL de un sitio web?
Escribe el dominio —example.com, o una URL completa: el esquema y la ruta se ignoran— y pulsa Comprobar. La herramienta abre una conexión TLS con el host e informa del certificado que sirve: días hasta la caducidad, si la cadena es de confianza, si el nombre coincide, los SAN y qué versiones de TLS acepta el servidor.
¿Cuándo caduca mi certificado SSL?
La cuenta atrás de la parte superior del resultado es el número de días que le quedan al certificado que se está sirviendo, con las fechas exactas de inicio y fin en UTC al lado. Un número negativo significa que caducó hace esos días.
¿Qué significa que «la cadena no es de confianza»?
Significa que la cadena presentada por el servidor no se ha podido validar hasta un certificado del almacén de raíces públicas. Las causas habituales son un certificado autofirmado, una CA interna que los clientes públicos no conocen, un intermedio que falta o un certificado caducado. El motivo devuelto por el validador aparece junto a la comprobación fallida.
¿Por qué el certificado no coincide con el nombre de host?
Un certificado solo es válido para los nombres de sus SAN, y un comodín como *.example.com cubre una única etiqueta: sirve para api.example.com, pero no para example.com ni para a.b.example.com. La herramienta informa de la confianza y del nombre por separado, así que puedes ver una cadena perfectamente válida emitida para otro nombre.
Mi sitio funciona en Chrome pero falla en curl o en mi app. ¿Por qué?
Ese patrón casi siempre significa que el servidor no envía los certificados intermedios. Los navegadores pueden descargar el emisor que falta mediante el enlace AIA del certificado y salir del paso sin avisar; curl, Java, Go y los dispositivos móviles antiguos normalmente no. La comprobación «la cadena se envía completa» detecta justo esto.
¿Puedo comprobar un certificado en un puerto distinto del 443?
Sí. Rellena el campo de puerto o pega el host con el puerto incluido, como example.com:8443. Sirve para servicios que empiezan TLS al conectarse a ese puerto, como el envío de correo en 465 o LDAPS en 636. No admite protocolos que se actualizan tras un saludo en texto plano, como STARTTLS en el 587, ni servicios que necesitan una negociación propia antes de TLS.
¿Qué es el SNI y cuándo tengo que indicarlo?
El SNI es el nombre de host que se envía en el handshake para que un servidor con muchos sitios sepa qué certificado presentar. Por defecto se usa el destino que has escrito. Indícalo cuando conectes directamente a una IP pero quieras el certificado de un nombre concreto: es útil para probar un nodo detrás de un balanceador.
¿Comprueba si un certificado ha sido revocado?
No. Se listan el respondedor OCSP y los puntos CRL publicados en el certificado, y el resultado indica si el servidor grapó una respuesta OCSP durante el handshake, pero esos puntos no se consultan. Un certificado revocado que siga dentro de su periodo de validez parecerá válido aquí.
¿Debo seguir admitiendo TLS 1.0 y 1.1?
En general no. Los principales navegadores retiraron ambos en 2020 y las auditorías los señalan con frecuencia. La matriz prueba las cuatro versiones por separado, así que ves lo que el servidor acepta de verdad y no lo que sugiere el archivo de configuración; cualquier versión obsoleta que siga aceptándose se marca como advertencia.
¿Puedo comprobar localhost o un servidor de mi red interna?
No. La comprobación se ejecuta desde nuestro servidor, así que solo alcanza hosts de internet, y las direcciones privadas, de bucle local, de enlace local y reservadas se rechazan directamente. Para un host interno, ejecuta openssl s_client -connect host:puerto -servername host en local y pega el PEM en el decodificador de certificados.
Herramientas relacionadas
Lee un certificado que ya tengas, o sigue bajando por la pila hasta los registros DNS y la dirección que hay detrás del nombre.