Monitorar a expiração de certificados TLS em todos os endpoints, não só no site principal

Objetivo

Nunca descobrir um certificado expirado por meio de um usuário. Todo certificado servido pela organização tem uma data de expiração conhecida e um alerta que dispara cedo o bastante para corrigir a renovação manualmente.

Pré-requisitos

Um inventário de hostnames e portas que terminam TLS (443, mas também SMTP, IMAP, LDAP, portas de banco de dados, painéis de administração, listeners de balanceadores de carga, endpoints de VPN); um sistema de monitoramento que execute sondas de forma agendada; conhecimento de como cada certificado é emitido (cliente ACME, gerenciado pelo provedor, manual).

Passos

1. Monte o inventário a partir do que é realmente servido, não do que está documentado: varra os endereços e nomes DNS que a organização possui em busca de listeners TLS e registre host, porta, subject e emissor.
2. Para cada endpoint, faça a sondagem de fora do host e leia a cadeia como um cliente a vê. A RFC 5280 define o período de validade por notBefore e notAfter; o certificado final (leaf) e cada intermediário têm os seus próprios valores.
3. Calcule os dias até notAfter para o leaf e para os intermediários e exporte o resultado como métrica. Em um script, o manual do OpenSSL documenta openssl x509 -checkend <seconds>, que termina com código diferente de zero quando o certificado expira dentro desse número de segundos; o manual da versão 3.6 acrescenta -multi, com o qual -checkend falha se qualquer certificado da entrada (por exemplo, uma cadeia salva) expirar dentro do período. O manual da versão 3.5 não lista -multi; por isso, em versões mais antigas, verifique o leaf e cada intermediário separadamente.
4. Defina o limite de acordo com o mecanismo de emissão. A Let's Encrypt informa que seus certificados padrão têm validade de 90 dias e recomenda renová-los a cada 60 dias, e que seus certificados de curta duração são válidos por seis dias, com renovação a cada três. No caso de 90 dias, a renovação no dia 60 deixa 30 dias de folga; um alerta com 20 dias restantes significa, portanto, que a renovação automática já perdeu um ciclo, mas ainda há tempo para uma pessoa agir. Certificados de seis dias exigem um limite medido em horas.
5. Alerte também em caso de falha da sonda (porta fechada, erro de handshake) e quando o subject ou o emissor do certificado forem diferentes do esperado.
6. Teste o alerta sondando um certificado propositalmente de curta duração ou elevando o limite acima dos dias restantes atuais em um endpoint.
7. Registre, para cada endpoint, quem o renova e como; o runbook do alerta é "executar a renovação e depois sondar de novo".

Resultado esperado

Uma visão única do tempo de vida restante de todos os certificados, um alerta que dispara enquanto a renovação manual ainda é tranquila e nenhum endpoint cujo certificado seja uma surpresa.

Limites e base de verificação

Sondar de dentro do host não detecta certificados apresentados por um balanceador de carga ou CDN colocado à frente. Certificados de cliente e de assinatura de código exigem o mesmo inventário, mas sondas diferentes. Os tempos de vida seguem as declarações dos emissores citados; não se afirma nenhuma estatística de falhas.