Vigilar la caducidad de los certificados TLS en todos los endpoints, no solo en el sitio web principal

Objetivo

No enterarse nunca de un certificado caducado por boca de un usuario. Todo certificado que sirve la organización tiene una fecha de caducidad conocida y una alerta que se dispara con antelación suficiente para reparar la renovación a mano.

Requisitos previos

Un inventario de los nombres de host y puertos que terminan TLS (443, pero también SMTP, IMAP, LDAP, puertos de bases de datos, paneles de administración, listeners de balanceadores de carga, endpoints de VPN); un sistema de monitorización que ejecute sondeos según una programación; y el conocimiento de cómo se emite cada certificado (cliente ACME, gestionado por el proveedor, manual).

Pasos

1. Construye el inventario a partir de lo que realmente se sirve, no de lo que está documentado: escanea las direcciones y los nombres DNS propios en busca de listeners TLS, y registra host, puerto, subject y emisor.
2. Para cada endpoint, sondea desde fuera del host y lee la cadena tal como la ve un cliente. La RFC 5280 define el período de validez mediante notBefore y notAfter; tanto el certificado hoja como cada intermedio tienen los suyos propios.
3. Calcula los días que faltan hasta notAfter para el certificado hoja y para los intermedios, y expórtalo como una métrica. Para un script, el manual de OpenSSL documenta openssl x509 -checkend <seconds>, que termina con un código distinto de cero cuando el certificado caduca dentro de ese número de segundos; el manual de la versión 3.6 añade -multi, con el que -checkend falla si algún certificado de la entrada (por ejemplo, una cadena guardada) caduca dentro del período. El manual de la 3.5 no incluye -multi, así que en versiones más antiguas hay que comprobar el certificado hoja y cada intermedio por separado.
4. Fija el umbral en función del mecanismo de emisión. Let's Encrypt indica que sus certificados por defecto son válidos durante 90 días y recomienda renovarlos cada 60, y que sus certificados de corta duración son válidos seis días y se renuevan cada tres. En el caso de 90 días, renovar en el día 60 deja 30 días de margen; una alerta con 20 días restantes significa, por tanto, que la renovación automática ya ha fallado un ciclo, aunque todavía queda tiempo para que una persona actúe. Los certificados de seis días necesitan un umbral medido en horas.
5. Genera también una alerta ante el fallo del sondeo (puerto cerrado, error de handshake) y ante un certificado cuyo subject o emisor difiera del esperado.
6. Comprueba la alerta sondeando un certificado deliberadamente de corta duración, o subiendo el umbral por encima de los días restantes actuales de un endpoint.
7. Registra para cada endpoint quién lo renueva y cómo; el runbook de la alerta se resume en «ejecutar la renovación y volver a sondear».

Resultado esperado

Una vista única de la vida restante de cada certificado, una alerta que se dispara mientras renovar a mano todavía resulta cómodo, y ningún endpoint cuyo certificado sea una sorpresa.

Límites y base de verificación

Sondear desde dentro del host pasa por alto los certificados que presenta un balanceador de carga o una CDN situados delante. Los certificados de cliente y los de firma de código necesitan el mismo inventario pero sondeos distintos. Las duraciones siguen lo declarado por los emisores citados; no se afirma ninguna estadística de fallos.