Verificação de certificado SSL: online, no navegador e com OpenSSL
Uma verificação de certificado SSL mostra se os navegadores confiam no seu HTTPS: se o certificado expirou, se o nome corresponde ao domínio, se a cadeia está completa e quem o emitiu. A forma mais rápida de verificar o SSL online é informar o domínio no verificador de certificado SSL: o resultado leva alguns segundos. Sem um certificado funcionando, os navegadores marcam o site como não seguro e alguns visitantes saem antes de a página carregar.
Como verificar um certificado SSL online, passo a passo
- Abra o verificador de certificado SSL e informe um domínio:
example.com. Uma URL completa também funciona: a ferramenta extrai o hostname. Uma porta fora do padrão vai depois de dois-pontos:example.com:8443. - A ferramenta se conecta de forma tão rigorosa quanto um navegador, verificando a cadeia de confiança e o hostname. Se a verificação rigorosa falhar, ela se conecta uma segunda vez sem esse rigor, para ainda poder mostrar o certificado e explicar o que está errado.
- Veja o banner no topo: quantos dias restam. Com menos de 30 dias, você recebe um aviso amarelo; um banner vermelho significa que os navegadores não confiam no certificado, com os motivos listados logo abaixo: expirado, emitido para outro nome, autoassinado ou com uma cadeia que não é verificada. A mensagem do OpenSSL da tentativa rigorosa aparece abaixo da lista.
- Percorra os cards de detalhes: Common Name, emissor, datas de "válido a partir de" e "válido até", tipo e tamanho da chave (RSA abaixo de 2048 bits é marcado como fraco), algoritmo de assinatura e os Subject Alternative Names (SAN): todos os hostnames que você atende, incluindo www, devem estar nessa lista.
- Repita a verificação para
www.example.come para seus subdomínios. Cada nome pode ter seu próprio certificado, e o que está com problema costuma ser o host que ninguém visita.
Para deixar claros os limites: esta é uma verificação pontual de um único hostname. Ela não lista as versões de TLS e as cifras que seu servidor aceita, não procura conteúdo misto nas páginas e não monitora a data de expiração para você. As versões de protocolo podem ser testadas com os comandos openssl abaixo ou com o scanner do Shield.
Como ver um certificado no navegador
- Chrome, Edge e outros navegadores baseados em Chromium: clique no ícone à esquerda do endereço, depois em "A conexão é segura" → "O certificado é válido". O visualizador mostra para quem o certificado foi emitido, quem o emitiu, o período de validade e a cadeia.
- Firefox: cadeado → "Conexão segura" → "Mais informações" → "Ver certificado".
- Safari: cadeado na barra de endereços → "Mostrar certificado".
O navegador é prático para uma olhada rápida na data de expiração e no emissor, mas não é um veredito final: os navegadores armazenam certificados intermediários em cache e podem "completar" uma cadeia quebrada que um crawler ou um aplicativo móvel rejeitaria.
Como verificar o SSL pela linha de comando (openssl)
O openssl já vem com macOS e Linux; no Windows, você o obtém com o Git for Windows, por exemplo. O comando básico se conecta ao servidor e exibe a cadeia e o resultado da verificação:
openssl s_client -connect example.com:443 -servername example.com </dev/null-servername envia o hostname (SNI). Sem ele, um servidor que hospeda vários sites pode devolver o certificado de outro domínio, e você acaba perseguindo um erro que não existe. Na saída, encontre Verify return code: 0 (ok) significa que a cadeia está correta; 21 (unable to verify the first certificate) geralmente significa que o servidor não envia o intermediário; 10 (certificate has expired): expirado; 18 (self-signed certificate): autoassinado.
Para extrair as datas, o subject e o emissor em uma linha:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -checkend 1209600notBefore e notAfter são o início e o fim da validade, -ext subjectAltName lista os nomes (OpenSSL 1.1.1 e posteriores), e -checkend 1209600 informa se o certificado expira nos próximos 14 dias (1.209.600 segundos): uma linha prática para um cron job de monitoramento.
Para ver se o servidor ainda aceita um protocolo antigo, tente conectar usando somente essa versão: openssl s_client -connect example.com:443 -servername example.com -tls1_1 </dev/null. Se o handshake for bem-sucedido, o TLS 1.1 está ativado no servidor. Uma ressalva: versões recentes do OpenSSL podem recusar versões antigas no lado do cliente e, nesse caso, uma falha não diz nada sobre o servidor. Use -tls1_2 e -tls1_3 para as versões atuais.
O que observar no relatório
| Parâmetro | O que deve ser |
|---|---|
| Validade | Mais de duas semanas de antecedência; certificados gratuitos duram cerca de três meses e são renovados automaticamente |
| Nome no certificado | Corresponde ao domínio, incluindo a variante com www |
| Cadeia de confiança | Completa: sem o certificado intermediário, alguns clientes exibirão um erro |
| Protocolos | TLS 1.2 e 1.3; é melhor desativar as versões obsoletas |
| Emissor | Autoridade certificadora conhecida, não um certificado autoassinado |
O que fazer em caso de erros
- Expirado. Renove o certificado e verifique se a renovação automática realmente está funcionando.
- Nome não corresponde. Adicione os domínios necessários ao certificado ou configure um separado.
- Cadeia incompleta. Envie o certificado intermediário para o servidor.
- Conteúdo misto. Troque os links de imagens, estilos e scripts de http para https, caso contrário o navegador vai reclamar mesmo com um certificado válido.
Erros de SSL: como aparecem e como corrigir
| Problema | O que você vê | Correção |
|---|---|---|
| Certificado expirado | Chrome: NET::ERR_CERT_DATE_INVALID; openssl: certificate has expired | Emita-o novamente e verifique se a renovação automática funciona. Um caso comum: o novo arquivo já está no disco, mas o servidor web nunca foi recarregado e continua servindo o antigo. |
| Nome não corresponde | NET::ERR_CERT_COMMON_NAME_INVALID | Emita um certificado com todos os hostnames no SAN, por exemplo, example.com e www.example.com. Um wildcard *.example.com cobre um nível de subdomínios, mas não o próprio example.com nem a.b.example.com. |
| Cadeia incompleta | Funciona em alguns navegadores, NET::ERR_CERT_AUTHORITY_INVALID em outros; openssl: unable to verify the first certificate | Instale a cadeia completa: o certificado do site mais os intermediários. Com Let's Encrypt no nginx, aponte para fullchain.pem, não para cert.pem. |
| Certificado autoassinado | NET::ERR_CERT_AUTHORITY_INVALID; openssl: self-signed certificate | Substitua por um certificado de uma CA confiável. Opções gratuitas: Let's Encrypt ou o certificado emitido pela sua hospedagem ou CDN. |
| Somente TLS obsoleto | Geralmente ERR_SSL_VERSION_OR_CIPHER_MISMATCH | Ative o TLS 1.2 e 1.3, desative o SSL 3.0, o TLS 1.0 e 1.1, e atualize o servidor web e o OpenSSL. |
| Relógio incorreto | Um erro de data em um certificado que na verdade é válido | Verifique o relógio do dispositivo do visitante ou do servidor: a validade é comparada com a data atual. |
Por quanto tempo os certificados SSL são válidos
O prazo máximo de validade dos certificados TLS publicamente confiáveis é definido pelo CA/Browser Forum, o órgão formado por autoridades certificadoras e fabricantes de navegadores. Durante anos, o limite foi de 398 dias. Em abril de 2025, o fórum adotou a votação SC-081, que o reduz em etapas, e a primeira etapa já está em vigor:
| Certificado emitido | Validade máxima |
|---|---|
| em ou após 15 de março de 2026 | 200 dias |
| em ou após 15 de março de 2027 | 100 dias |
| em ou após 15 de março de 2029 | 47 dias |
O limite vale pela data de emissão: um certificado emitido antes vai até a data de término original. Os detalhes estão na votação SC-081 no site do CA/Browser Forum. Os certificados gratuitos do Let's Encrypt já são curtos: segundo o FAQ do Let's Encrypt, eles duram 90 dias (os certificados de 6 dias são opcionais), e os de 90 dias devem ser renovados a cada 60 dias. A conclusão: renovar manualmente uma vez por ano ficou no passado, a renovação precisa ser automatizada.
Renovação automática do Let's Encrypt: como confirmar que funciona
sudo certbot certificates
sudo certbot renew --dry-run
systemctl list-timers | grep certbotcertbot certificateslista todos os certificados do servidor com a data de expiração.certbot renew --dry-runsimula a renovação no servidor de staging do Let's Encrypt sem alterar os certificados em produção. Se a simulação falhar, a renovação real também vai falhar.- A renovação é disparada por um timer do systemd ou por uma tarefa do cron; com o pacote snap, o timer é
snap.certbot.renew.timer. Se não houver nenhum dos dois, não há renovação automática. - Para que o servidor web passe a usar o novo certificado, recarregue-o após a renovação:
--deploy-hook "systemctl reload nginx". - Motivos típicos de falha na renovação:
/.well-known/acme-challenge/bloqueado por um redirecionamento, uma senha ou uma regra de firewall; ou o domínio foi movido para outro servidor ou CDN enquanto o certbot continua rodando no antigo.
Se a sua hospedagem ou CDN emite o certificado, a renovação normalmente fica por conta deles, mas só enquanto o domínio apontar para eles. Depois de qualquer alteração de DNS, verifique o certificado novamente.
Monitoramento de certificados
- Alertas com antecedência. Use um monitoramento externo ou um script no cron com
openssl x509 -checkend: receba o alerta pelo menos duas semanas antes do vencimento. - Nova verificação após a renovação. Passe o domínio pelo verificador de SSL: novas datas, cadeia completa, todos os nomes no SAN.
- Logs de Certificate Transparency. Todo certificado público é registrado em logs abertos; ao buscar seu domínio (por exemplo no crt.sh), você vê quais certificados foram emitidos para ele, incluindo subdomínios esquecidos e emissões inesperadas.
- Auditorias regulares. O Shield é uma verificação de segurança paga (avulsa, com saldo da sua conta, ou por assinatura de monitoramento); o grupo "TLS e certificado" cobre validade e expiração do certificado, TLS 1.0/1.1 obsoletos, o redirecionamento de HTTP para HTTPS e o HSTS.
Certificado gratuito ou pago
Para fins de verificação de validade, não há diferença: tanto o navegador quanto o bot verificam a validade, não o preço. Os certificados gratuitos são emitidos automaticamente e se renovam sozinhos, o que é suficiente para a grande maioria dos sites. Os certificados pagos fazem sentido quando é preciso validação estendida da organização, seguro ou suporte para cenários raros. O principal é que a renovação automática realmente funcione: um certificado caro vencido é pior do que um gratuito renovado a tempo.
Como isso se relaciona com a promoção
HTTPS é um requisito básico: um site sem ele perde confiança e visitantes. Além disso, um erro de certificado atrapalha nossas verificações: a página pode ficar inacessível para rastreamento. Um panorama completo de segurança é oferecido pelo Shield, e os cabeçalhos de segurança são abordados no artigo sobre cabeçalhos de segurança.
