Verificar um certificado SSL/TLS

Hoje toda a gente tem automação de certificados, e é exatamente por isso que as falhas por certificado continuam a ser comuns. A renovação é invisível até ao dia em que deixa silenciosamente de funcionar — a conta ACME esbarrou num limite de pedidos, o caminho do desafio HTTP-01 passou a estar atrás de autenticação, o cron job que renova é precisamente o cron job cuja paragem ninguém notou. Em todos os casos o certificado continua a funcionar até à hora exata em que deixa de o fazer, e então todos os navegadores e todos os clientes de API recusam ao mesmo tempo.

A falha é total e não gradual. Não existe modo degradado para um certificado expirado: um site que estava bem às 9h59 está inacessível às 10h00, e os primeiros a dar por isso são os seus clientes. Os fluxos de pagamento e as apps móveis com certificate pinning falham com mais força, porque não têm nenhum botão «continuar mesmo assim» para clicar.

Um certificado pode ser perfeitamente válido e ainda assim falhar para a maior parte da internet. A causa habitual é um intermédio em falta: o seu servidor envia apenas o certificado folha, o seu navegador guardou o intermédio em cache há meses e preenche a lacuna em silêncio, e todos aqueles cujo navegador não o fez — mais cada curl, cada cliente de API, cada app móvel — recebem um erro de verificação.

É por isso que esta ferramenta reporta a cadeia separadamente da data de expiração. Uma expiração a verde com uma cadeia inválida é uma falha em curso para parte dos seus visitantes neste preciso momento, e não vai aparecer ao carregar o site no navegador que tem usado toda a semana.

A porta 443 por omissão. Pode indicar outra com example.com:8443, e é suportada uma mão-cheia de portas de TLS implícito — 465 (SMTPS), 636 (LDAPS), 853 (DNS over TLS), 990 (FTPS), 993 (IMAPS), 995 (POP3S), 8443 e 9443.

As portas STARTTLS como 25, 143 e 587 não são verificadas. Um handshake TLS em bruto contra elas falha por razões de protocolo, e reportar isso como «o seu certificado está avariado» seria errado.

É mesmo gratuito, e preciso de uma conta?

Sim, e não. Não há registo, nem campo de email, nem período de teste. O endpoint tem um limite de pedidos por IP para se manter disponível, e esse é o seu único limite.

Guardam os domínios que verifico?

Não. A verificação é sem estado: o seu pedido produz uma ligação TLS e uma resposta JSON, e nada disso fica anotado. Como nada é guardado, não há histórico para consultar nem histórico que alguém nos possa pedir.

Porque recusa nomes de host internos?

Porque liga ao que quer que indique a partir da nossa infraestrutura, só resolve e liga a endereços publicamente encaminháveis. Um nome que aponte para 127.0.0.1, para o espaço RFC 1918 ou para um endereço de metadados de nuvem é recusado antes de qualquer ligação. Se precisa de vigiar um certificado interno, a resposta é uma verificação a correr dentro da sua rede, não uma ferramenta pública.

Posso verificar um endereço IP em vez de um domínio?

Não — introduza um nome de domínio. O SNI precisa de um nome, os certificados são emitidos para nomes, e um certificado verificado sem nome fala-lhe do host virtual que por acaso responde primeiro e não do seu site.

Em que é que isto difere de olhar para o cadeado?

O seu navegador tem uma cache e um repositório de confiança moldados por todos os sites que visitou este ano. Esta ferramenta liga de fresco, a partir de uma máquina que nunca viu o seu site — muito mais próximo do que experimenta um visitante novo ou um cliente de API.

Um certificado válido hoje significa que estou seguro?

Significa que está seguro hoje. Os certificados são agora emitidos para semanas em vez de anos, e a indústria continua a encurtá-los — por isso o intervalo em que uma verificação manual é tranquilizadora em vez de desatualizada não para de encolher. É um argumento a favor de algo que verifica continuamente, não de verificar mais vezes à mão.