SSL Certificate Checker

Para que serve esta ferramenta?

O SSL Certificate Checker responde a uma pergunta que o navegador deixa sem resposta: este certificado HTTPS é válido, de confiança, corresponde ao domínio e quando expira? Um navegador exibe «ligação segura» ou «a sua ligação não é privada», nunca o porquê.

A ferramenta abre uma verdadeira ligação TLS para o host, inspeciona o certificado do servidor e a cadeia apresentada, e emite um veredicto com estados discretos. Nada de «parece estar tudo bem». Uma resposta.

A diferença face à barra de endereços resume-se a um ponto: o navegador julga a ligação tal como ele a vê, depois de já ter compensado nos bastidores uma cadeia frágil. O checker julga a cadeia tal como o servidor a serve de facto, como a veria o curl, um servidor de API remoto ou um smartphone. É esta visão honesta que desmascara as falhas fantasma.

Três usos que se repetem sem parar:

• Antes de um incidente: um certificado expira dentro de oito dias, nenhum aviso do navegador, falha total no prazo. Vê a coisa a chegar.
• Depois de uma implementação: o site abre em sua casa, mas o webhook do parceiro devolve um erro TLS. Cadeia incompleta, quase sempre.
• Em auditoria: chave RSA de 1024 bits ou assinatura SHA-1 esquecida num velho serviço interno. O veredicto aponta-a diretamente.

Como ler o veredicto

O veredicto resume-se a uma palavra colorida, e essa palavra basta para decidir. Eis como descodificá-la.

Sob o veredicto, o detalhe: data de expiração e dias restantes, cadeia apresentada por ordem, lista dos SAN, versão TLS, cipher, tipo e tamanho da chave, algoritmo de assinatura. O suficiente para diagnosticar, não apenas para constatar.

Um caso merece uma pausa. Inválido nem sempre quer dizer «certificado estragado». Quando a única anomalia é uma cadeia servida incompleta, a mensagem muda para um diagnóstico preciso: sirva o fullchain. O certificado é bom; é a sua entrega que falha.

Os casos concretos que a ferramenta desmascara

Cadeia incompleta: o servidor apresenta apenas o certificado do servidor

É o grande clássico. O servidor envia o seu certificado do servidor, mas esquece o intermediário que o liga à raiz. Resultado: a cadeia não sobe até nenhuma autoridade reconhecida, tal como é servida.

O Chrome e o Edge safam-se: descarregam o intermediário em falta sozinhos (AIA fetching). O site «funciona em sua casa». Mas o curl falha, o cliente de email falha, a app móvel falha, a biblioteca HTTP do parceiro falha. Um inferno para diagnosticar sem ferramenta dedicada, porque o sintoma depende de quem observa.

A correção é única e sem surpresas: servir a fullchain, ou seja, o certificado do servidor seguido do ou dos intermediários, concatenados na ordem certa. A Let's Encrypt fornece-lhe diretamente um ficheiro fullchain.pem pronto a usar.

# Contar os certificados realmente servidos
openssl s_client -connect captaindns.com:443 -servername captaindns.com -showcerts </dev/null 2>/dev/null | grep -c "BEGIN CERTIFICATE"
# 1 único certificado = cadeia incompleta

Um caso particular passa muitas vezes por um bug da ferramenta: o certificado do servidor servido sozinho que mesmo assim se verifica. Isto só acontece se esse certificado tiver sido emitido diretamente por uma raiz, o que o CA/Browser Forum agora proíbe. Na prática, um certificado público servido sozinho sai inválido, e a recomendação é sempre a mesma: fullchain.

Expiração: a falha que nenhum navegador anuncia

Um certificado que expira dentro de dez dias não desencadeia qualquer aviso. No dia D, tudo cai. HTTPS bloqueado, API muda, webhooks em erro, e o suporte a arder.

A ferramenta coloca a data de expiração e os dias restantes no topo do resultado. Abaixo de um mês, passa a aviso. Mas um instantâneo não previne: para isso, é preciso uma monitorização que corre em ciclo (ver mais abaixo).

Nome de host: o domínio ausente dos SAN

O certificado é válido e de confiança, mas não cobre o nome pedido. Os navegadores ignoram o velho campo Common Name: leem apenas os SAN (Subject Alternative Names). Se o domínio não estiver lá, erro NET::ERR_CERT_COMMON_NAME_INVALID, diga o que disser o CN.

A armadilha mais frequente é o wildcard. *.captaindns.com cobre www.captaindns.com, mas não o apex captaindns.com, nem um nível mais abaixo como a.b.captaindns.com. Um wildcard só desce um degrau. A correção: reemitir listando todos os nomes pretendidos nos SAN.

Autoassinado: cifrado, mas sem confiança

Um certificado autoassinado tem o mesmo emissor e o mesmo sujeito. Cifra a ligação, por isso os dados transitam bem protegidos. Mas ninguém garante a quem pertence a chave. O navegador recusa e exibe um aviso.

Perfeito para um serviço interno ou um ambiente de teste. Num site público, é um beco sem saída: emita antes um certificado gratuito via Let's Encrypt e automatize-o com ACME. A ferramenta isola este caso num veredicto à parte, para não o confundir com um certificado partido.

Criptografia fraca: os fósseis que se arrastam

Uma chave RSA abaixo de 2048 bits, uma chave ECDSA abaixo de 256 bits, uma assinatura SHA-1 ou MD5: outras tantas relíquias que rondam velhos serviços nunca migrados. O navegador pode tolerá-las por algum tempo, mas estão em risco. A ferramenta assinala-as no certificado do servidor, antes que um reforço do lado do cliente as faça rejeitar de um dia para o outro.

Automatização e monitorização: a única estratégia sustentável

Verificar à mão serve para um incidente pontual. Não aguenta ao longo do tempo, e o calendário torna-o insustentável.

O CA/Browser Forum reduz o tempo de vida dos certificados por etapas: 200 dias em março de 2026, 100 dias em 2027, 47 dias em 2029. Aos 47 dias, renovar à mão torna-se absurdo. Impõem-se dois reflexos.

Automatizar a emissão com ACME. O protocolo ACME (o da Let's Encrypt, via certbot, Caddy, Traefik, lego) renova e reinstala o certificado sem intervenção humana. Configurado uma vez, esquecido depois. É a única forma de acompanhar o ritmo.

Monitorizar a expiração em contínuo. A automatização por vezes falha em silêncio: quota de emissão atingida, DNS partido para a validação, hook de recarregamento mudo. Uma monitorização que verifica a expiração a intervalos regulares e alerta com antecedência recupera esses buracos. O HTTP Uptime Monitor da CaptainDNS cumpre este papel para os seus endpoints HTTPS.

Este checker e o monitor complementam-se: um diagnostica no instante T, o outro monta guarda. Para aprofundar o calendário e as suas consequências, leia o nosso guia sobre a redução da duração dos certificados para 47 dias. E para passar da verificação pontual a uma abordagem completa (inventário, automatização ACME, monitorização de expiração), o nosso guia sobre a gestão do ciclo de vida dos certificados detalha o método.

Apenas web HTTPS

Esta versão cobre a web HTTPS: ligação TLS implícita em host:port, porta 443 por omissão. O email está fora do âmbito. Um servidor SMTP negoceia geralmente o TLS depois, via STARTTLS, nas portas 25, 587 ou 465: um dial direto não veria nada.

Para o certificado de um servidor de email, duas ferramentas assumem o testemunho: o SMTP/MX Tester inspeciona o certificado apresentado em STARTTLS, e o verificador DANE/TLSA confirma que corresponde à impressão digital publicada no DNS. Não misture os dois mundos: um certificado web e um certificado MX não se verificam da mesma maneira.

FAQ - Perguntas frequentes

P: Como verificar um certificado SSL online?

R: Introduza o nome de domínio no campo host e execute a verificação. A ferramenta abre uma ligação TLS para o host e a porta (443 por omissão), inspeciona o certificado do servidor e a cadeia apresentada, e devolve um veredicto: validade, correspondência do nome de host, confiança do sistema, expiração, robustez da chave e da assinatura.

P: Qual a diferença entre certificado do servidor, intermediário e raiz?

R: O certificado do servidor contém o seu nome de domínio. O intermediário faz a ligação entre ele e a raiz. A raiz (root CA) vive no arquivo de confiança do sistema. O servidor deve apresentar o certificado do servidor seguido dos intermediários; a raiz não precisa de ser enviada. Esta sequência é a fullchain.

P: Porque é que o meu site funciona no Chrome mas quebra noutros lados?

R: É o sintoma de um intermediário em falta. O Chrome e o Edge recuperam o intermediário ausente sozinhos (AIA fetching), mas o curl, os clientes de email e muitos telemóveis rejeitam a ligação. Sirva a cadeia completa (fullchain) para corrigir em todo o lado.

P: Durante quanto tempo é válido um certificado SSL?

R: Até 398 dias hoje, mas a duração está a encolher. O CA/Browser Forum impõe 200 dias em março de 2026, 100 dias em 2027, 47 dias em 2029. A Let's Encrypt já emite certificados de 90 dias. A este ritmo, renovar à mão deixa de ser viável: é preciso automatizar via ACME.

P: Como monitorizar a expiração de um certificado SSL?

R: Este checker dá um instantâneo. Para ser avisado antes da falha, ligue uma monitorização contínua com o HTTP Uptime Monitor: verifica a expiração a intervalos regulares e alerta à aproximação do prazo.

P: O que significa um certificado autoassinado?

R: O seu emissor e o seu sujeito são idênticos: assinou-se a si próprio. Cifra a ligação mas não oferece qualquer confiança pública, daí o aviso do navegador. Bom para uso interno; para um site público, use um certificado emitido por uma autoridade reconhecida como a Let's Encrypt.

P: O que fazer se o nome de host não corresponder?

R: O domínio pedido não está nos SAN do certificado. Caso comum: um wildcard *.captaindns.com não cobre nem o apex nem um subdomínio de nível inferior. Reemita o certificado com todos os nomes pretendidos nos SAN. O Common Name já não conta: só os SAN são lidos.

Ferramentas complementares

Recursos úteis

• RFC 5280 - Perfil dos certificados X.509 (estrutura e validação dos certificados)
• RFC 6125 - Verificação do nome de host (correspondência SAN e wildcards)
• CA/Browser Forum - Baseline Requirements (regras de emissão e tempo de vida)
• Documentação Let's Encrypt - Certificados de cadeia (fullchain e intermediários)