Check de certificado TLS

Qué verifica

Cada región abre un handshake TLS directo a host y puerto, envía el nombre de host como SNI y lee el certificado hoja. El check pasa si el handshake se valida contra el almacén de raíces públicas, el certificado no ha caducado, y el emisor y el nombre común del sujeto coinciden con los patrones que hayas definido. Dentro de la ventana de aviso, el resultado lleva un aviso, y propietarios y administradores reciben cada hora un correo y un aviso en la app. Solo un check fallido cambia el estado: un certificado caducado, un handshake rechazado, un patrón que no coincide o un host que no resuelve.

Úsalo cuando

• Un host sirve TLS sin un endpoint HTTP sobre el que merezca la pena hacer aserciones, o el certificado necesita su propio monitor, historial e incidente.
• El certificado debe venir de un emisor concreto o llevar un sujeto concreto, por ejemplo tras un cambio de CA o una migración a un nombre nuevo.
• Quienes renuevan el certificado deben enterarse de la caducidad con antelación. Por defecto, desde 14 días antes del final, el resultado lleva un aviso y sale un correo cada hora.

El check solo lee el certificado hoja, sin OCSP, sin CRL y sin calificación de cifrados. Para puertos STARTTLS, como SMTP en 587 o IMAP en 143, usa el check SMTP o IMAP con su subcheck de certificado, porque este check hace el handshake directamente. Una URL https que ya monitorizas puede llevar la misma política como subcheck del check HTTP(S).

Desliza lateralmente para ver la vista del producto.

app.perstat.io

Configuración

Objetivo. Un nombre de host o una dirección IP sin esquema, ruta ni espacios (etiquetas de hasta 63 caracteres, 253 en total), más un puerto opcional de 1 a 65535. Sin puerto, el handshake va al 443. La sonda resuelve el host con su propio resolver y lo envía como SNI en cada handshake. Las direcciones de loopback, privadas, link-local y de metadatos de nube se rechazan como otros rangos reservados, así que el monitor no puede llegar a una red interna.

Familias IP

El handshake va por IPv4 por defecto. Con las dos familias, cada dirección resuelta de cada familia recibe su propio handshake. El resultado conserva un subresultado por familia y por dirección, así que un fallo solo de IPv6 se ve como tal. El formulario solo ofrece IPv6 cuando el host tiene un registro AAAA o es un literal IPv6, y entonces solo quedan seleccionables las regiones que sondean IPv6.

Cómo se ejecuta un check

1. Cada región a la que le toca el intervalo inicia el check, que expira a los 10 s. Primero compila los patrones de emisor y sujeto, y un patrón inválido termina el check como error antes de cualquier acceso a la red.
2. El resolver propio del nodo resuelve el host. Cada dirección resuelta de la familia elegida se valida contra los rangos bloqueados.
3. Cada dirección recibe su propio handshake TLS con el nombre de host como SNI. La validación usa el almacén de raíces públicas, o un verificador permisivo cuando allow_self_signed está activado. El certificado hoja se lee del handshake.
4. Se analizan el nombre común, los nombres alternativos, el emisor y la validez. Cada patrón que definas debe coincidir, y la caducidad se evalúa al segundo frente a la fecha de fin del certificado.
5. El certificado se conserva con el resultado para mostrarlo. En cuanto la vida restante baja de warn_days, se adjunta el aviso. El control plane lo convierte en un correo cada hora y un aviso en la app para propietarios y administradores, y el estado no cambia.
6. La región envía su resultado al control plane. La política de alertas decide cuándo las regiones que fallan abren un incidente, por defecto cuando 2 regiones coinciden en 2 checks consecutivos.

Desliza lateralmente para ver la vista del producto.

app.perstat.io

Qué contiene un resultado

Certificado

El resultado conserva el nombre común, los nombres alternativos y el emisor, además de la validez desde y hasta con los días restantes. Registra si el certificado es autofirmado y de confianza pública (public_trusted, mostrado como publicly trusted en la vista del monitor). Al alcanzar la ventana de aviso, lleva también el aviso.

Línea de detalle

Una línea con el nombre común, el emisor y los días restantes, o una nota de que el certificado ha caducado. Con allow_self_signed activado, la línea empieza diciendo si se aceptó un certificado autofirmado o no confiable.

Tiempo de respuesta

Ninguno para este tipo. El check evalúa el certificado, no la velocidad del handshake, así que no se registra ni se muestra ningún tiempo de respuesta.

Capa de causa

Si el fallo está en el DNS del objetivo (NXDOMAIN o NODATA) o en el propio objetivo, una vez resuelto el nombre. Cualquier otra causa se registra como unknown.

Región, familia, dirección

Cada resultado lleva la región que lo midió, y un subresultado por familia IP y por dirección.

Estados y gravedad

• okEl handshake se acepta, el certificado sigue siendo válido y los patrones de emisor y sujeto coinciden. Un certificado dentro de su ventana de aviso mantiene este estado.
• degradadoEste estado solo surge al combinar varios resultados con el family_fail_severity por defecto. Una familia IP falla mientras la otra responde, o fallan algunas de varias direcciones resueltas. La comprobación del certificado en sí no tiene resultado degradado.
• caídoEl handshake se rechaza por una cadena no confiable, un nombre de host no coincidente o la caducidad en el modo estricto. El check también está caído pasada la fecha de fin, si un patrón no coincide, si no se sirve ningún certificado o si el host no resuelve o resuelve a una dirección bloqueada. Con family_fail_severity: failed, una familia que falla también cuenta como caído.
• errorEl check no se puede evaluar porque un patrón de emisor o de sujeto es inválido o el certificado servido no se puede analizar. Cuenta como caída con gravedad critical.

Confirmado por quórum: por defecto, 2 regiones deben informar del fallo antes de que se abra un incidente. El valor por defecto de la organización pide 2 regiones y 2 checks consecutivos. Un monitor puede llevar su propia regla con número o porcentaje, checks consecutivos y una duración mínima.

Planes y límites

Intervalo mínimo

300 s en Free, 60 s en Pulse, 30 s en Sentinel, 15 s en Command y 10 s en Enterprise. El formulario web ofrece 30 s, 1 min, 5 min, 15 min y 1 h. Los mínimos de 15 s y 10 s solo se alcanzan por MCP.

Regiones

2 de 6 en Free, 3 de 6 en Pulse y las 6 desde Sentinel.

Monitores

10 en Free, 50 en Pulse, 150 en Sentinel, 500 en Command y un cupo a medida en Enterprise. Los once tipos de check de sonda comparten este cupo. Los agentes de host y los heartbeats tienen cupos propios.

Comparar todos los límites

Desde la pipeline o un agente

La misma config sirve en el paso de despliegue, en un cliente MCP como Claude Code y en el formulario de arriba. create_monitor necesita una clave de API válida para toda la organización. Si omites regions, el plan aplica su valor por defecto.

{
  "name": "Storefront certificate",
  "type": "ssl_cert",
  "interval_seconds": 900,
  "config": {
    "host": "example.com",
    "port": 443,
    "warn_days": 21,
    "issuer_regex": "Let's Encrypt",
    "subject_regex": "example\\.com"
  }
}

Cada interfaz, con su límite

Límites

• Solo se evalúa el certificado hoja. De la cadena solo se informa si es de confianza pública o no.
• Sin OCSP, sin CRL y sin calificación de cifrados.
• Solo handshake directo, sin STARTTLS. Para SMTP en 587 o IMAP en 143, usa el check SMTP o IMAP con su subcheck de certificado.
• Este tipo no registra tiempo de respuesta. El uptime y el certificado llevan el resultado.
• La ventana de aviso nunca cambia el estado del monitor. La caducidad sí.
• Se rechazan los objetivos en direcciones privadas, de loopback, link-local y de metadatos de nube.
• No todas las regiones sondean IPv6, así que seleccionar ipv6 restringe las regiones utilizables.

Tipos de check relacionados

• Check HTTP(S)Disponibilidad y respuesta de una URL, con aserciones sobre estado, cuerpo y TLS.
• Check SMTPBanner y EHLO de un servidor de correo, con una comprobación opcional del certificado por STARTTLS o TLS implícito.
• Check IMAPAlcanzabilidad de un servidor IMAP por su saludo, en el 993 tras un handshake TLS, con una política de certificado opcional.
• Check de dominioDelegación en cada servidor de nombres autoritativo, caducidad del dominio y DNSSEC de un dominio registrable.

Todos los tipos de check