Monitorizar o vencimento de certificados TLS em todos os endpoints, não só no site principal

Objetivo

Nunca saber de um certificado expirado através de um utilizador. Todos os certificados que a organização serve têm uma data de vencimento conhecida e um alerta que dispara com antecedência suficiente para corrigir a renovação manualmente.

Pré-requisitos

Um inventário dos nomes de anfitrião e portas que terminam TLS (443, mas também SMTP, IMAP, LDAP, portas de bases de dados, painéis de administração, listeners de balanceadores de carga, endpoints de VPN); um sistema de monitorização que execute verificações periodicamente; conhecimento de como cada certificado é emitido (cliente ACME, gerido pelo fornecedor, manual).

Passos

1. Construa o inventário a partir do que está efetivamente a ser servido, não do que está documentado: procure listeners TLS nos endereços e nomes DNS que a organização possui, e registe o anfitrião, a porta, o subject e o emissor (issuer).
2. Para cada endpoint, faça a verificação a partir de fora do anfitrião e leia a cadeia tal como um cliente a vê. A RFC 5280 define o período de validade através de notBefore e notAfter; tanto o certificado folha como cada intermediário têm os seus próprios valores.
3. Calcule os dias até notAfter para o certificado folha e para os intermediários, e exporte isso como métrica. Para um script, o manual do OpenSSL documenta openssl x509 -checkend <seconds>, que termina com um 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 algum certificado da entrada (por exemplo, uma cadeia guardada) 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 certificado folha e cada intermediário separadamente.
4. Defina o limiar em função do mecanismo de emissão. A Let's Encrypt afirma que os seus certificados padrão são válidos por 90 dias e recomenda renová-los a cada 60 dias, e que os seus certificados de curta duração são válidos por seis dias, com renovação a cada três. No caso dos 90 dias, uma renovação ao dia 60 deixa 30 dias de margem; um alerta com 20 dias restantes significa, portanto, que a renovação automática já falhou um ciclo, ainda havendo tempo para uma pessoa intervir. Os certificados de seis dias precisam de um limiar medido em horas.
5. Configure também alertas para falhas na verificação (porta fechada, erro de handshake) e para um certificado cujo subject ou emissor seja diferente do esperado.
6. Teste o alerta verificando um certificado deliberadamente de curta duração, ou aumentando o limiar acima dos dias restantes atuais para um endpoint.
7. Registe, para cada endpoint, quem o renova e como; o runbook do alerta resume-se a "executar a renovação e depois verificar de novo".

Resultado esperado

Uma única vista sobre o 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

Verificar a partir de dentro do anfitrião não deteta certificados apresentados por um balanceador de carga ou CDN à frente dele. Os certificados de cliente e os certificados de assinatura de código precisam do mesmo inventário, mas de verificações diferentes. Os prazos de validade seguem as declarações citadas dos emissores; não se afirma nenhuma estatística de falhas.