O que é o Verificador de SSL
O Verificador de SSL abre uma conexão TLS real com o domínio informado, na porta 443, e lê o certificado apresentado pelo servidor durante o handshake. Em poucos segundos você vê quem emitiu o certificado (autoridade certificadora), o período de validade (Not Before e Not After), quantos dias faltam para expirar, o algoritmo de assinatura e a lista completa de domínios cobertos no campo SAN (Subject Alternative Name). É a checagem que responde à pergunta mais comum de quem administra um site: "meu HTTPS vai quebrar em quantos dias?". Certificado expirado derruba o cadeado do navegador, exibe a tela NET::ERR_CERT_DATE_INVALID em vermelho e faz o tráfego orgânico cair imediatamente — porque o visitante desiste antes de clicar em "avançar". Com o Let's Encrypt emitindo certificados de apenas 90 dias e o CA/Browser Forum já aprovando a redução progressiva do prazo máximo para 47 dias até 2029, monitorar validade deixou de ser tarefa anual e passou a ser rotina mensal.
Como usar o Verificador de SSL
Digite apenas o domínio (exemplo: centraltools.com.br) e clique em verificar. O prefixo https:// e barras finais são removidos automaticamente, então colar a URL inteira também funciona. A ferramenta resolve o domínio, faz o handshake TLS na porta 443 e devolve os campos do certificado. Se quiser checar um subdomínio específico — como api.seusite.com ou loja.seusite.com — informe o subdomínio inteiro, porque cada host pode ter certificado diferente.
Verificador de SSL — Passo a Passo
-
1
Informe o domínio
Cole o domínio ou a URL completa. Use o host exato que os visitantes acessam: www.seusite.com e seusite.com podem ter certificados distintos.
-
2
Execute a verificação
A ferramenta conecta na porta 443 e captura o certificado apresentado no handshake TLS, diretamente no navegador no seu computador.
-
3
Confira os dias restantes
O contador de dias até a expiração é o dado mais importante. Abaixo de 15 dias, verifique imediatamente se a renovação automática está funcionando.
-
4
Valide o emissor
Confirme se a autoridade certificadora é a esperada (Let's Encrypt, DigiCert, Sectigo, Google Trust Services). Emissor inesperado pode indicar proxy, WAF ou configuração trocada.
-
5
Revise a lista SAN
Verifique se todos os hosts que você usa aparecem no campo SAN. Um domínio ausente da lista gera erro de nome incorreto no navegador, mesmo com o certificado válido.
Quando usar o Verificador de SSL
- Antes de um lançamento ou migração: ao trocar de hospedagem, apontar DNS novo ou subir um domínio adicional, verifique o SSL do host final antes de divulgar o link. É o erro mais comum em migração: o site responde, mas o certificado ainda cobre só o domínio antigo.
-
Monitoramento de renovação automática: quem usa Let's Encrypt com certbot, acme.sh ou Caddy depende de um cron silencioso. Quando ele falha (porta 80 fechada, regra de firewall nova, plugin de cache interceptando
/.well-known/acme-challenge), ninguém percebe até o dia da expiração. A checagem manual mensal detecta a falha com semanas de antecedência. - Diagnóstico de erro no navegador do cliente: quando um usuário relata "seu site está inseguro", a verificação separa três causas diferentes: certificado expirado, domínio fora da lista SAN, ou cadeia incompleta servida pelo servidor. Cada uma tem correção distinta.
- Auditoria de subdomínios esquecidos: ambientes de staging, painéis administrativos, APIs e webmail costumam ficar fora do processo de renovação principal. Verifique cada host separadamente para achar o que ficou para trás.
- Checagem de fornecedores e integrações: antes de consumir uma API de terceiro em produção, confirme que o certificado dela está válido e que a cadeia está correta — certificado do parceiro expirando derruba a sua integração também.
Benefícios do Verificador de SSL
Como funciona: explicação técnica
Quando o navegador acessa https://exemplo.com, ele inicia um handshake TLS. O servidor responde enviando sua cadeia de certificados. O navegador então faz três verificações independentes, e é a falha em qualquer uma delas que gera o aviso de site não seguro:
1. Validade temporal. Todo certificado X.509 carrega os campos notBefore e notAfter. Se o relógio atual estiver fora dessa janela, o navegador rejeita a conexão com ERR_CERT_DATE_INVALID. Desde setembro de 2020 os navegadores rejeitam certificados públicos emitidos com validade superior a 398 dias, e o CA/Browser Forum aprovou em 2025 a redução gradual desse limite — 200 dias em 2026, 100 dias em 2027 e 47 dias em 2029 — o que torna a automação de renovação obrigatória na prática.
2. Correspondência de nome. O navegador compara o host digitado com o campo SAN (Subject Alternative Name). O antigo Common Name foi depreciado e é ignorado pelo Chrome desde a versão 58. Um certificado emitido apenas para exemplo.com não serve para www.exemplo.com: são nomes diferentes e é preciso listar os dois. Certificados wildcard no formato *.exemplo.com cobrem qualquer subdomínio de um nível — loja.exemplo.com funciona, mas api.v2.exemplo.com não.
3. Cadeia de confiança. O certificado do site é assinado por um certificado intermediário, que por sua vez é assinado por uma raiz presente no repositório de confiança do sistema operacional ou do navegador. O servidor precisa enviar o certificado da folha e os intermediários. Se o intermediário faltar, o Chrome no desktop frequentemente ainda funciona (porque completa a cadeia via cache ou AIA fetching), mas apps Android, clientes cURL e bibliotecas HTTP falham com unable to get local issuer certificate. É a causa clássica do bug "funciona no meu navegador, quebra no aplicativo".
Sobre SSL e TLS: o SSL 3.0 foi formalmente descontinuado pela RFC 7568 em 2015 e o TLS 1.0 e 1.1 foram depreciados pela RFC 8996 em 2021. O que se usa hoje é TLS 1.2 e TLS 1.3. O termo "certificado SSL" permanece por hábito comercial, mas o protocolo em operação é sempre TLS.
Erros de certificado no navegador e causa provável
| Erro exibido | O que aconteceu | Como corrigir |
|---|---|---|
| ERR_CERT_DATE_INVALID | Certificado expirado ou relógio do servidor errado | Renovar o certificado e conferir o NTP do servidor |
| ERR_CERT_COMMON_NAME_INVALID | O host acessado não está no campo SAN | Reemitir incluindo todos os domínios usados |
| ERR_CERT_AUTHORITY_INVALID | Certificado autoassinado ou cadeia incompleta | Servir o arquivo fullchain com os intermediários |
| ERR_SSL_PROTOCOL_ERROR | Servidor só aceita TLS 1.0/1.1 ou cifras obsoletas | Habilitar TLS 1.2 e 1.3 na configuração do servidor |
| ERR_CERT_REVOKED | Certificado revogado pela autoridade certificadora | Emitir um novo certificado e investigar a causa da revogação |
Exemplos práticos de uso
- Renovação travada sem ninguém perceber: um site em Nginx com certbot mostra 8 dias restantes na verificação. A investigação revela que um bloco
location /novo passou a interceptar/.well-known/acme-challengee o renew silencioso falhava havia dois meses. Correção em 5 minutos, catástrofe evitada. - Domínio sem www quebrado: a loja funciona em
www.loja.com, mas dá erro emloja.com. A lista SAN mostra apenas o host com www. Solução: reemitir o certificado com os dois nomes e configurar redirecionamento 301 do apex para o www. - App mobile falhando e navegador funcionando: a verificação mostra o certificado válido, mas a cadeia servida vem sem o intermediário. O Nginx apontava para
cert.pemem vez defullchain.pem. Uma linha de configuração resolveu as falhas de login no aplicativo Android. - Wildcard que não cobre o subnível esperado: certificado
*.empresa.comaplicado emhomolog.api.empresa.comretorna erro de nome. Wildcard cobre só um nível — foi necessário emitir*.api.empresa.comseparadamente. - Auditoria trimestral de subdomínios: verificando 12 hosts de uma empresa, três (webmail, staging e painel do ERP) apareceram com menos de 20 dias de validade porque nunca entraram no script de renovação central.
Quantos dias de antecedência são seguros para renovar
A regra prática usada por equipes de infraestrutura é renovar quando restar um terço da validade. Para certificados Let's Encrypt de 90 dias, isso significa renovar aos 30 dias restantes — que é exatamente o comportamento padrão do certbot renew. Essa margem existe porque a renovação pode falhar por motivos temporários: rate limit da autoridade certificadora, indisponibilidade do endpoint ACME, DNS ainda propagando ou porta 80 bloqueada por uma regra de firewall recém-aplicada.
Como interpretar o contador de dias restantes:
- Acima de 30 dias: situação normal, a automação está funcionando.
- Entre 15 e 30 dias: se a renovação é automática, ela já deveria ter ocorrido. Rode
certbot renew --dry-rune leia o log. - Entre 5 e 15 dias: alerta. Renove manualmente hoje e depois investigue por que a automação falhou.
- Menos de 5 dias: risco de indisponibilidade. Trate como incidente.
- Valor negativo: o certificado já expirou e os visitantes estão vendo a tela de aviso vermelha.
Se o certificado é pago com validade de um ano, coloque um lembrete de calendário 45 dias antes, porque certificados OV e EV exigem revalidação documental da empresa e o processo pode levar dias úteis.
DV, OV e EV: qual tipo de certificado você realmente precisa
Os três tipos oferecem exatamente a mesma criptografia. A diferença está apenas no que a autoridade certificadora verifica antes de emitir.
DV (Domain Validation). Comprova só que o solicitante controla o domínio, via arquivo HTTP, registro DNS ou e-mail de administrador. Emissão em segundos e online no Let's Encrypt, ZeroSSL e Google Trust Services. Atende blogs, sites institucionais, landing pages, APIs e a maioria dos e-commerces.
OV (Organization Validation). A autoridade verifica a existência legal da empresa consultando registros oficiais. Os dados da organização ficam gravados no certificado. Custa entre US$ 50 e US$ 200 por ano. Usado quando um contrato, edital ou política interna de compliance exige nome da empresa no certificado.
EV (Extended Validation). Validação documental rigorosa, com prazo de dias a semanas. Antigamente exibia a barra verde com o nome da empresa — recurso que Chrome e Firefox removeram da interface em 2019, por estudos mostrando que usuários não notavam a diferença. Hoje o EV entrega pouco valor prático para o visitante comum e permanece por exigência regulatória em setores como bancos.
Conclusão prática: se ninguém está te obrigando por contrato ou regulação a usar OV ou EV, o DV online com renovação automática é a escolha tecnicamente correta e a que menos quebra, porque o processo é totalmente automatizado.
Certificado válido mas o site continua marcado como não seguro
Ter certificado válido não garante o cadeado fechado. Três problemas independentes causam aviso mesmo com o SSL em ordem:
Conteúdo misto (mixed content). A página carrega em HTTPS, mas puxa imagens, scripts ou CSS em http://. O navegador bloqueia scripts e folhas de estilo inseguros e remove o cadeado. Em WordPress, isso costuma vir de URLs absolutas gravadas no banco após uma migração — a correção é atualizar as URLs em wp_options e nos campos de conteúdo.
Falta de redirecionamento HTTP para HTTPS. Sem o redirect 301 na porta 80, o visitante que digita o domínio sem protocolo continua trafegando em texto claro. Além do risco, isso divide o SEO entre duas versões da mesma URL. Configure o redirecionamento no servidor web, não apenas no aplicativo.
Ausência de HSTS. O cabeçalho Strict-Transport-Security instrui o navegador a nunca mais tentar HTTP naquele domínio, eliminando a janela de ataque do primeiro acesso. Comece com max-age curto para validar, e só aumente depois de confirmar que todos os subdomínios têm certificado válido — HSTS com includeSubDomains em um subdomínio sem SSL torna esse subdomínio inacessível.
É útil para administradores de sites, desenvolvedores e profissionais de segurança que precisam confirmar se um domínio está protegido corretamente por HTTPS e identificar problemas antes que afetem os usuários.