Verificar a cadeia de certificados TLS servida e a sua validade na linha de comando com openssl

Objetivo

Responder, para um único hostname, a três perguntas que o navegador resolve em silêncio: quais certificados o servidor envia, se eles formam uma cadeia que um cliente consegue verificar e quando cada um expira. Este é o diagnóstico pontual; o alerta agendado é tema de outro artigo.

Pré-requisitos

Um binário openssl, acesso de rede ao host e os hostnames exatos que os clientes usam (apex, www, hosts de API), pois o servidor pode escolher um certificado diferente para cada nome.

Passos

1. Obtenha o que o servidor envia, definindo o SNI de forma explícita: openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null > sent.txt. O manual informa que -showcerts exibe a lista de certificados do servidor tal como foi enviada, na ordem de envio, e que essa lista não é uma cadeia verificada. O manual também informa que, sem -servername, o SNI é preenchido a partir do nome em -connect somente se este parecer um nome DNS; por isso, informe-o ao conectar a um endereço IP.
2. Leia o resultado da verificação que o s_client imprime após o handshake. Uma cadeia que passa na verificação local ainda exige o passo 4, porque o trust store local pode conter um certificado intermediário que os clientes não têm.
3. Divida o sent.txt em um arquivo PEM por certificado e inspecione cada um: openssl x509 -in cert1.pem -noout -subject -issuer -enddate -ext subjectAltName. Segundo o manual, -enddate imprime a data notAfter e -ext imprime extensões nomeadas, como subjectAltName. O primeiro certificado deve ser o leaf cujos SANs contêm o hostname; cada certificado seguinte deve ser o emissor do anterior.
4. Reconstrua a cadeia de forma independente do que o servidor afirma: openssl verify -show_chain -untrusted intermediates.pem leaf.pem. O manual descreve -untrusted como um arquivo de certificados não confiáveis usados para montar a cadeia e -show_chain como a exibição da cadeia construída, com os membros não confiáveis sinalizados. Execute o comando contra o trust store do sistema e, se necessário, contra um -CAfile específico.
5. Repita o passo 1 com -4 e depois com -6; o manual documenta essas opções como conexões somente IPv4 e somente IPv6. Um balanceador de carga pode servir um certificado diferente para cada família de endereços.
6. Repita para cada hostname e cada porta que termina TLS.
7. Registre em uma tabela o hostname, a família de endereços, o notAfter do leaf, o notAfter do intermediário que expira primeiro e o resultado da verificação.

Resultado esperado

Uma tabela curta por hostname que mostre que a cadeia enviada está completa e ordenada, que a verificação é bem-sucedida sem que o trust store local esconda um intermediário ausente, e qual é a data de expiração mais próxima na cadeia.

Limites e base de verificação

Um intermediário ausente pode passar na verificação em uma máquina que o tenha em cache e falhar em um cliente novo; o passo 4 com um trust store mínimo é o teste honesto. Os comandos seguem os manuais citados; a disponibilidade das opções varia conforme a versão do OpenSSL. Não se afirma nenhum resultado de campo.