Como verificar quando um certificado SSL vence

O jeito rápido: o cadeado e uma verificação online

Em qualquer navegador, clique no cadeado na barra de endereço, abra os detalhes do certificado e leia "válido a partir de" e "válido até". Isso leva dez segundos e mostra o que o seu próprio navegador vê. A limitação é que cobre só o certificado que foi entregue a você, a partir do nó de borda ou servidor que você alcançou, no momento em que você olhou.

Uma verificação SSL online faz o mesmo handshake a partir de fora da sua rede e informa a data de vencimento, o emissor, os nomes que o certificado cobre, e se a cadeia entregue está completa. Os navegadores escondem esse último ponto, então a verificação externa te conta algo que o cadeado não consegue.

O jeito manual com openssl

Um comando imprime a janela de validade:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null   | openssl x509 -noout -dates -subject -issuer

A flag -servername envia o SNI, o que importa porque a maioria dos servidores hospeda vários certificados em um único endereço e vai te entregar o errado sem ela. A saída traz notBefore e notAfter em UTC, além de para quem o certificado é e quem o emitiu.

Para ver a cadeia inteira que o servidor envia, em vez de só o certificado final:

openssl s_client -connect example.com:443 -servername example.com -showcerts < /dev/null

Leia o bloco "Certificate chain" no topo: você deve ver o certificado final, depois um ou mais intermediários. Uma linha "verify error: unable to get local issuer certificate" significa que o servidor não está enviando o intermediário, o que muitos navegadores disfarçam e muitos clientes de API, aplicativos móveis e sistemas mais antigos não.

Certificado final, cadeia e o que vence

Três certificados estão envolvidos em uma conexão HTTPS normal, e cada um tem sua própria data de vencimento:

• O certificado final é o certificado emitido para o seu domínio. É o de vida curta, tipicamente 90 dias para emissão automatizada e até cerca de um ano para um comprado, e é o que as pessoas querem dizer com "o certificado".
• O intermediário assina o certificado final e precisa ser enviado pelo servidor junto com ele. Ele dura anos, e é justamente por mudar tão raramente que o vencimento dele pega as equipes de surpresa.
• A raiz fica no repositório de confiança do cliente, não no seu servidor. Quando uma raiz vence ou perde a confiança, dispositivos mais antigos que nunca receberam a atualização começam a falhar enquanto os atuais ficam bem, produzindo uma indisponibilidade que parece impossível a partir do seu próprio notebook.

Então valide a cadeia, não só a data no certificado final. Um certificado final com dois meses restantes em uma cadeia quebrada já está falhando para alguns clientes.

Por que o vencimento é a indisponibilidade evitável mais comum

O vencimento de certificado é uma falha excepcionalmente danosa. Ela falha completamente em vez de gradualmente, porque um navegador recusa a conexão de imediato e mostra um aviso de página inteira em vez do site. O momento em que isso acontece foi fixado no dia em que o certificado foi emitido, e ninguém estava de olho nessa data. Também derruba tudo o que usa aquele nome de uma vez, não só o site: APIs, backends de aplicativos móveis, webhooks e integrações. Callbacks de pagamento falhados e integrações quebradas muitas vezes custam mais do que a indisponibilidade visível.

Também é totalmente evitável, e é por isso que é a falha que mais vale a pena automatizar uma verificação.

Como a renovação automática ainda falha

A emissão automatizada eliminou a maioria dos vencimentos e introduziu um conjunto de falhas mais difíceis de enxergar:

• A renovação rodou mas nada recarregou. Um certificado novo fica no disco enquanto o servidor web continua servindo o antigo a partir da memória até ser recarregado.
• O desafio de validação quebrou. Uma regra de redirecionamento, uma mudança de firewall ou uma nova CDN na frente da origem bloqueia o caminho do desafio HTTP, então a renovação continua falhando por semanas sem nenhum sintoma visível.
• A validação por DNS perdeu as credenciais. Um token de API foi rotacionado ou expirou e o desafio de DNS não consegue mais criar o registro dele.
• O temporizador de renovação não está rodando. Um contêiner foi reconstruído sem o cron job ou o timer do systemd, ou a máquina foi migrada e a agenda não foi junto.
• Só um nó renovou. Atrás de um balanceador de carga, um servidor tem o certificado novo e outro ainda serve o antigo, então as falhas parecem intermitentes.
• Os e-mails de renovação foram para alguém que saiu. A versão de certificado comprado do mesmo problema.
• O certificado renovou mas não para todos os nomes. Um subdomínio adicionado depois está faltando no certificado novo, então aquele nome de host específico falha.

Cada um desses é invisível de dentro do sistema de renovação e óbvio de fora. Esse é o argumento para verificar o handshake ao vivo em vez de confiar nos próprios logs da automação.

Automatizando a verificação

Ler uma data te dá a resposta de hoje, e todo o problema do vencimento é que ele chega em um dia que ninguém escolheu para verificar. O monitoramento agendado de certificados executa o handshake real a partir de fora em um intervalo, avisa um número definido de dias antes do notAfter, e pega os problemas de cadeia e de nome de host que um lembrete de calendário jamais pegaria. A HostTracker avisa por e-mail, SMS, chamada de voz, Slack, Telegram e outros canais, então o aviso chega a alguém antes do vencimento. O monitoramento de domínio e TLS roda a verificação continuamente, a ferramenta de verificação SSL faz uma verificação avulsa, e como verificar se uma porta está aberta trata de um handshake que falha antes mesmo de um certificado ser oferecido.