Monitorización de certificados SSL: alertas de expiración para certificados y dominios

Un certificado SSL vencido no es el único plazo que puede dejar un sitio fuera de línea - el verificador de expiración de dominio de HostTracker vigila el estado de tu registro junto con tus certificados, sin costo adicional.

Un monitor de expiración de certificados SSL suele venderse como un simple recordatorio de calendario, y la expiración es realmente la forma más común en que fallan los certificados. Pero no es la única. Cada ejecución de HostTracker abre una conexión TLS real y evalúa el certificado que el servidor realmente entregó - lo cual detecta los fallos que llegan sin que ninguna fecha cambie en absoluto.

Por debajo, un monitor de certificados es una conexión TLS a un host y un puerto. El puerto asume 443 por defecto, y puedes nombrar uno distinto - example.com:8443 - así que una puerta de enlace de API, un puerto HTTPS alternativo o un servicio en un puerto de TLS implícito se vigilan exactamente de la misma forma. El nombre de host se envía mediante SNI, así que un servidor que aloja varios certificados en una sola dirección IP devuelve el correcto.

Cuando un servidor cae, un visitante ve un error del navegador y normalmente lo intenta de nuevo más tarde. Cuando un certificado expira, el servidor sigue perfectamente saludable - responde a cada solicitud - y el navegador se niega a mostrar lo que envió. La diferencia importa de cuatro maneras que es fácil subestimar hasta que ocurre.

• La advertencia está diseñada para asustar. Una pantalla completa sobre una conexión insegura es la misma pantalla que muestra un navegador ante un ataque de interceptación. Los visitantes no la leen como "su certificado caducó"; la leen como "este sitio no es seguro".
• En un sitio con HSTS activado no hay forma de continuar. Si alguna vez enviaste una cabecera Strict-Transport-Security - y deberías haberlo hecho -, los navegadores eliminan por completo la opción de "continuar de todos modos". Cada visitante queda bloqueado hasta que se reemplace el certificado.
• Las máquinas fallan más duro que las personas. Tu app móvil, tus webhooks de pago, las integraciones de tus socios y cada cliente de API también validan el certificado, y ninguno de ellos tiene un botón para pasar por alto la advertencia. Una expiración es una caída total de integración, no solo de sitio web.
• Tu propio monitoreo puede verse en verde. Una verificación configurada para ignorar problemas de certificado sigue reportando HTTP 200 desde un servidor cuyo certificado expiró hace una hora. La aplicación nunca lo notó. Ese es precisamente el vacío que existe para cerrar un monitor de certificados.

La misma asimetría se aplica a un dominio caducado, solo que más lenta y menos reversible: un certificado puede reemitirse en minutos, mientras que un dominio que sale del período de redención puede ser registrado por cualquiera.

La vigilancia de certificados viene en dos formas, y la mayoría de las cuentas quiere la primera.

Un certificado no cambia de un minuto al siguiente, así que ninguna de las dos formas verifica más a menudo de lo que resulta útil. Seis horas significa que el peor caso entre que un certificado se rompa y que HostTracker lo note es de unas pocas horas, sobre algo que normalmente te da 30 días de aviso.

HostTracker envía avisos recordatorios 30 días, 7 días y 1 día antes de una fecha de expiración - tanto para certificados SSL/TLS como para registros de dominio. Tres escalones en lugar de uno, porque cada uno atrapa un tipo distinto de descuido: 30 días es suficiente antelación para tramitar una orden de compra o reparar un trabajo de renovación roto, 7 días atrapa el ticket que nadie tomó, y 1 día es el último aviso antes de que los navegadores empiecen a advertir a tus visitantes.

Un recordatorio no es una alerta de caída, y HostTracker mantiene ambas cosas separadas. Si el certificado ya es inválido en este momento - vencido, revocado, encadenado a una raíz no confiable, o emitido para un nombre de host distinto -, eso es una verificación fallida, y escala a través de tus contactos normales de caída con el retraso que cada uno eligió: inmediatamente, o después de 3, 5, 15, 30 o 60 minutos, o de 3, 6, 12 o 24 horas.

Las alertas salen por los nueve canales que soporta HostTracker - correo electrónico, SMS, llamada de voz, webhook, Slack, notificaciones push y las apps de mensajería Telegram, Discord y Viber. Las renovaciones de certificados y las de dominio suelen estar a cargo de personas distintas, así que pon a ambas en la lista de contactos: el recordatorio que solo llega a la bandeja de entrada de quien configuró el monitor es el que se pasa por alto.

La escalera de arriba es exactamente lo que en la práctica es un rastreador de caducidad de certificados SSL. Cada seis horas HostTracker vuelve a leer el certificado que tu servidor sirvió realmente y recalcula los días que le quedan; tres de esos números llevan un aviso enganchado.

Los tres peldaños son fijos: 30, 7 y 1 día, y la misma escalera cubre las registraciones de dominio además de los certificados. Un aviso es informativo y por sí solo nunca marca el monitor como caído; un certificado realmente inválido - caducado, revocado, emitido para otro nombre de host o encadenado a una raíz no confiable - es una verificación fallida y escala como cualquier otra caída.

¿Todavía sin monitoreo? La verificación SSL instantánea gratuita lee el mismo certificado e informa de la misma fecha de caducidad, emisor, cadena y versión de TLS negociada: una vez, ahora mismo, sin cuenta. El rastreador de caducidad es esa misma verificación en un ciclo de seis horas, con los tres avisos enganchados.

El monitor de certificados de arriba responde "¿este certificado es válido?". Un conjunto separado de interruptores en un monitor de disponibilidad HTTPS responde una pregunta más difícil - "¿esta conexión está a la altura de nuestro estándar?" - y cada uno es opcional, porque activarlos todos para cada cliente haría fallar a muchísimos sitios que funcionan exactamente como sus propietarios pretenden.

• Requerir una cadena de certificado válida. Desactivado por defecto, para que un certificado autofirmado en un host interno no haga fallar su verificación de disponibilidad. Actívalo para cualquier cosa pública.
• Requerir un protocolo TLS fuerte. Hace fallar la verificación cuando el servidor negocia algo por debajo de TLS 1.2 - el interruptor útil después de un proyecto de endurecimiento, para que una configuración revertida no pueda reintroducir en silencio un protocolo obsoleto.
• Bloquear cifrados débiles. Hace fallar la verificación cuando el cifrado negociado es más débil que 128 bits.
• Verificar la revocación del certificado. Añade una consulta OCSP/CRL a la propia verificación de disponibilidad.

Un monitor de expiración de certificados independiente ya aplica la validación de cadena y la verificación de revocación por sí solo, sin ninguno de estos interruptores - existen para que tu verificación de disponibilidad pueda hacerse tan estricta como lo exija tu postura de seguridad, con independencia de lo que reporte el monitor de certificados.

Se suponía que la renovación automática acabaría con los incidentes de expiración, y en su mayoría lo ha hecho. Lo que cambió es la forma de los que quedan: en lugar de que una persona olvide una fecha, una pieza de automatización deja de funcionar y nadie lo nota, porque una automatización que funciona es silenciosa y una automatización rota lo es exactamente de la misma manera. La vida útil de los certificados sigue acortándose en toda la industria - las autoridades gratuitas más usadas emiten certificados de 90 días, y la vida máxima que aceptan los navegadores se está reduciendo por etapas -, lo que significa que la renovación ahora ocurre muchas veces al año, y cualquiera de esas renovaciones puede ser la que falle.

Los fallos que vemos reportados se ven así:

• El trabajo cron de renovación murió hace meses. El último certificado que renovó era válido por 90 días, así que el fallo solo se hizo visible el día 91.
• La renovación tuvo éxito, pero nada se recargó. El nuevo certificado queda en disco mientras el servidor web, el balanceador de carga o el contenedor sigue sirviendo el antiguo desde memoria. Cada registro de renovación dice éxito.
• Se pasó por alto uno de varios nodos. Detrás de un balanceador de carga, la mayoría de las solicitudes reciben el certificado nuevo y una fracción recibe el vencido - por eso un error de certificado intermitente, del tipo "a mí me funciona", casi siempre es un problema de consistencia entre servidores.
• El borde está bien, el origen no. Tu CDN presenta su propio certificado válido mientras el del origen expiró por debajo. Cualquier cosa que hable directamente con el origen se rompe.
• El método de validación dejó de funcionar. Se ordenó un registro DNS, una ruta /.well-known/ empezó a redirigir, cambió una regla de firewall - y la renovación que depende de eso dejó de pasar en silencio.
• El comodín no cubría el nuevo subdominio. Un certificado comodín cubre un nivel, así que un host añadido bajo una etiqueta más profunda no queda cubierto en absoluto.

Cada uno de esos casos es invisible desde dentro de tu propio pipeline de despliegue y evidente desde fuera, que es todo el argumento a favor de un vigilante externo. Un monitor que se conecta de la misma forma que lo haría el navegador de un desconocido ve el certificado que realmente estás sirviendo, no el que tu automatización cree haber instalado.

El lado de dominio le pregunta al registro, no al servidor. HostTracker consulta el dominio mediante RDAP - el sucesor moderno y estructurado de WHOIS -, resolviendo qué registro responde por tu TLD a partir del directorio publicado por la propia IANA, y recurre a una consulta WHOIS clásica por el puerto 43 para los TLD que aún no publican un servicio RDAP. La consulta se ejecuta con una cadencia fija de seis horas, y la verificación reporta:

• la fecha de expiración que tiene el registro - la autoritativa, no la de tu sistema de facturación;
• los códigos de estado del registro sobre el dominio, cuando RDAP los proporciona - incluyendo si hay un bloqueo de transferencia activo;
• un aviso separado de "la fecha de expiración cambió" cada vez que la fecha del registro difiere de la verificación anterior - que es cómo confirmas que una renovación realmente se aplicó, y cómo te enteras de una que no autorizaste.

Ese último punto es, discretamente, la señal más útil de la página. Una renovación que pagaste y que nunca llegó al registro se ve idéntica a un dominio saludable hasta justo el momento en que se dispara el recordatorio de 30 días. Vigilar que la fecha misma cambie convierte la renovación de algo que esperas que haya ocurrido en algo que puedes ver.

¿Quieres el registro completo ahora mismo - registrador, servidores de nombres, fecha de creación - en lugar de como monitor? Ejecuta la consulta gratuita de WHOIS y expiración de dominio; no necesitas iniciar sesión. El monitor recurrente reporta deliberadamente menos, porque lo que cambia es la expiración y el estado.

1. Consulta primero el dominio con la verificación instantánea gratuita para saber cuáles son las fechas de expiración de hoy antes de automatizar nada.
2. Si ya monitoreas la disponibilidad del sitio, abre ese monitor y activa la vigilancia de certificados y de expiración de dominio. Sin monitor nuevo, sin solicitud adicional.
3. Para todo lo que no monitorees para disponibilidad - un servidor de correo, una puerta de enlace interna, un puerto alternativo -, añade un monitor independiente de Expiración de certificado y dale host:puerto. El puerto 443 se asume cuando lo omites.
4. Añade un monitor de Expiración de dominio para cada dominio registrable que poseas, incluidos los registros defensivos y los dominios de redirección. Esos son exactamente los que caducan, porque nadie vigila un dominio que no tiene sitio.
5. Pon a más de una persona en la lista de contactos. Los certificados y los dominios suelen estar a cargo de equipos distintos, y el recordatorio que solo llega a quien configuró el monitor es el que queda sin leer cuando esa persona cambia de trabajo.
6. Ten en cuenta la escalera de recordatorios - 30, 7 y 1 día - y asegúrate de que tu proceso de renovación quepa dentro de esos 30 días. Si una orden de compra tarda seis semanas, la escalera no es tu restricción; el proceso lo es.

Las herramientas gratuitas de verificación SSL - incluida la propia de HostTracker - son realmente útiles y responden una pregunta distinta. Un verificador te dice el estado de un certificado en el momento en que preguntas. El monitoreo te dice cuándo cambia ese estado mientras no estás mirando, que es la única vez que realmente importa.

Los certificados están junto a las otras cosas de un dominio que pueden salir mal sin que nadie toque tu servidor. Una vez vigilado el lado de expiración, los dos siguientes habituales son las alertas de malware y phishing y las listas negras de DNS - ambas fallos silenciosos de reputación que dejan el sitio activo y el tráfico desaparecido.

• Sin STARTTLS. La verificación se conecta e inicia el handshake TLS de inmediato, así que funciona en cualquier puerto que hable TLS directamente. Los protocolos que empiezan en texto plano y actualizan a mitad de sesión - SMTP en el 587, IMAP en el 143, FTP con TLS explícito - necesitan una negociación que la verificación no realiza. Apúntala al puerto de TLS implícito en su lugar.
• Los días de recordatorio están fijos en 30, 7 y 1. Actualmente no son una configuración por monitor.
• Un respondedor de revocación inaccesible se reporta, no falla. Eso es deliberado - una caída del OCSP de una autoridad certificadora no es la caída de tu sitio -, pero sí significa que la cobertura de revocación depende de que un tercero esté activo.
• Los registros de Certificate Transparency no se monitorean. HostTracker te informa sobre el certificado que se está sirviendo; no vigila los registros CT públicos en busca de certificados emitidos para tu dominio por otra parte.
• Los certificados de cliente no se ejercitan. La verificación valida el certificado que presenta el servidor, no un handshake TLS mutuo.
• La cobertura de dominios sigue a los registros. Se usa RDAP donde el TLD lo publica y WHOIS clásico donde no; un pequeño número de TLD poco comunes no publican bien ninguno de los dos, y la verificación reporta un fallo de consulta en lugar de fingir que conoce una fecha.