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 ligação TLS de verdade para o host, inspeciona o certificado do servidor e a cadeia apresentada, e emite um veredicto com estados distintos. Nada de "parece estar tudo bem". Uma resposta.

A diferença em relação à 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. É essa visão honesta que desmascara as falhas fantasma.

Três usos que se repetem sem parar:

• Antes de um incidente: um certificado expira em oito dias, nenhum aviso do navegador, falha total no prazo. Vê o problema chegando.
• Depois de uma implantação: o site abre na sua máquina, 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. Veja 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 entrega dele 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 certificadora reconhecida, tal como é servida.

O Chrome e o Edge safam-se: descarregam sozinhos o intermediário que falta (AIA fetching). O site "funciona na sua máquina". Mas o curl falha, o cliente de email falha, o 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 entrega diretamente um ficheiro fullchain.pem pronto para 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. Isso 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 em dez dias não dispara nenhum 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 em falta nos 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, não importa o que diga 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: encriptado, mas sem confiança

Um certificado autoassinado tem o mesmo emissor e o mesmo sujeito. Ele encripta a ligação, pelo que os dados trafegam 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 com ACME. A ferramenta isola esse caso num veredicto à parte, para não confundir com um certificado quebrado.

Encriptação 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 manualmente serve para um incidente pontual. Não aguenta ao longo do tempo, e o calendário torna isso insustentável.

O CA/Browser Forum reduz o tempo de vida dos certificados por etapas: 200 dias desde março de 2026, 100 dias em 2027, 47 dias em 2029. Aos 47 dias, renovar manualmente torna-se absurdo. Dois reflexos impõem-se.

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 continuamente. A automatização por vezes falha em silêncio: cota de emissão atingida, DNS quebrado para a validação, hook de recarregamento mudo. Uma monitorização que verifica a expiração em intervalos regulares e alerta com antecedência recupera esses buracos. O HTTP Uptime Monitor da CaptainDNS cumpre esse 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 predefinição. O email está fora do escopo. Um servidor SMTP geralmente negocia o TLS depois, via STARTTLS, nas portas 25, 587 ou 465: uma ligação direta não veria nada.

Para o certificado de um servidor de email, duas ferramentas assumem o bastão: o SMTP/MX Tester inspeciona o certificado apresentado em STARTTLS, e o verificador DANE/TLSA confirma que ele 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 predefiniçã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 repositório de certificados fiáveis do sistema. O servidor deve apresentar o certificado do servidor seguido dos intermediários; a raiz não precisa de ser enviada. Essa sequência é a fullchain.

P: Porque é que o meu site funciona no Chrome mas falha noutros lugares?

R: É o sintoma de um intermediário em falta. O Chrome e o Edge recuperam sozinhos o intermediário que falta (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 todos os lugares.

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

R: Até 200 dias desde 15 de março de 2026, primeira fase do ballot SC-081v3 do CA/Browser Forum. O teto cai para 100 dias em 15 de março de 2027, e depois para 47 dias em 15 de março de 2029. A Let's Encrypt já emite certificados de 90 dias. A esse ritmo, renovar manualmente 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: ele verifica a expiração em intervalos regulares e alerta quando o prazo se aproxima.

P: O que significa um certificado autoassinado?

R: O seu emissor e o seu sujeito são idênticos: ele assinou a si mesmo. Encripta a ligação mas não oferece nenhuma 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 certificadora 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.

P: A ferramenta cobre os servidores de email (SMTP, STARTTLS)?

R: Não. Esta versão cobre apenas a web HTTPS (ligação TLS implícita em host:port). Para o certificado de um servidor de email via STARTTLS, use o SMTP/MX Tester; para fixar esse certificado por impressão digital, o verificador DANE/TLSA.

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)