O teu site tem o cadeado no navegador, por isso "já é seguro". É a frase que mais ouvimos e a mais enganadora. O cadeado só diz que existe um certificado válido para esse domínio: não diz nada sobre que versões do protocolo aceitas, que cifras negoceias, se a cadeia está completa ou quando expira. Por isso as ferramentas de análise dão uma nota, de A+ a F, e por isso dois sites com cadeado podem estar em extremos opostos. Este guia explica o que mede cada parte dessa nota, que configuração é razoável em 2026 e como verificar a tua com dois comandos.
O que avalia uma nota de TLS
As ferramentas sérias combinam sete verificações. As duas primeiras são eliminatórias: se falharem, a nota desce para F sem olhar para o resto.
- Certificado válido: emitido por uma autoridade reconhecida, para o domínio certo, dentro do seu período de validade.
- Cadeia completa: o certificado intermédio que liga o teu à autoridade raiz é enviado com ele.
- Versões do protocolo: que TLS aceitas e quais rejeitas.
- Cifras: que algoritmos ofereces e em que ordem.
- Redirecionamento: se o HTTP leva ao HTTPS em todo o site.
- HSTS: se dizes ao navegador para não voltar a usar HTTP.
- Vulnerabilidades conhecidas: renegociação insegura, compressão, os ataques com nome próprio da década passada.
Versões: só 1.2 e 1.3
O TLS 1.0 e 1.1 estão obsoletos desde 2020 e os navegadores rejeitam-nos. Se o teu servidor continua a aceitá-los, a nota desce porque um atacante pode forçar um cliente antigo a usá-los. O TLS 1.2 é o mínimo aceitável; o TLS 1.3 é o padrão atual: menos idas e voltas ao ligar, cifras modernas obrigatórias e sem as opções inseguras das versões anteriores. A configuração certa hoje é aceitar 1.2 e 1.3 e mais nada. Se usas Vercel, Netlify, Cloudflare ou um alojamento gerido, isto já vem assim; se administras o teu próprio nginx ou um balanceador, revê-o.
Cifras: o que importa mesmo
A cifra define como se troca a chave e como se protege o tráfego. Duas coisas fazem a diferença. A primeira é o sigilo perfeito para a frente (as cifras que começam por ECDHE): se alguém roubar a tua chave privada no futuro, não consegue decifrar o tráfego que gravou antes. A segunda é evitar algoritmos quebrados ou fracos: RC4, 3DES, os modos CBC antigos e a troca de chave RSA pura. Uma lista razoável para TLS 1.2 reduz-se a ECDHE com AES-GCM ou ChaCha20; em TLS 1.3 o protocolo já só permite cifras modernas, outra razão para o ativares.
A cadeia de certificados: a falha invisível
O teu certificado é assinado por um intermédio, e o intermédio é assinado por uma raiz que os dispositivos já conhecem. O servidor tem de enviar o teu certificado e o intermédio. Se te esqueceres do intermédio, o Chrome no desktop descarrega-o por conta própria e não verás nenhum erro; mas muitos telemóveis, o curl, os bots de IA e as integrações de pagamento falham com um "certificado não confiável". É a falha mais comum em servidores configurados à mão e a mais difícil de notar porque "a mim funciona". Verifica assim:
openssl s_client -connect oteudominio.com:443 -servername oteudominio.com </dev/null 2>/dev/null | grep -E "s:|i:|Verify return"Devem aparecer pelo menos dois certificados na cadeia e a verificação deve terminar em Verify return code: 0 (ok).
Domínio e nomes alternativos
O certificado tem de cobrir exatamente os nomes que usas: oteudominio.com e www.oteudominio.com são dois nomes diferentes. Um certificado só para a raiz faz com que o www dê erro, e vice-versa. Os certificados atuais listam vários nomes no campo SAN, e os wildcards (*.oteudominio.com) cobrem subdomínios de um nível. Revê também os subdomínios esquecidos: api, app, staging com certificados expirados são um clássico.
Expiração: cada vez mais curta
Os certificados da Let's Encrypt duram 90 dias, o máximo permitido pelos navegadores hoje é de 398 e a indústria acordou baixá-lo progressivamente até 47 dias em 2029. A mensagem é clara: a renovação tem de ser automática. As plataformas geridas fazem-no sozinhas; se tens o teu próprio servidor, usa um cliente ACME com renovação agendada e, sobretudo, um alerta externo que te avise se faltarem menos de 14 dias. A queda por certificado expirado é a mais tola e a mais frequente.
Redirecionamento e HSTS
Todo o tráfego HTTP tem de redirecionar para HTTPS com um 301, em todas as rotas, não só na home. E quando tudo funciona em HTTPS, o cabeçalho Strict-Transport-Security diz ao navegador para não voltar a tentar HTTP durante o tempo que indicares, o que elimina a pequena brecha do primeiro pedido. Com includeSubDomains e preload podes incluir o teu domínio na lista que os navegadores trazem de fábrica. É a diferença habitual entre um A e um A+. Como se configura, em cabeçalhos de segurança HTTP.
Conteúdo misto
Um detalhe que não afeta a nota do certificado mas afeta o cadeado: se a tua página HTTPS carrega uma imagem, um script ou uma fonte por HTTP, o navegador bloqueia-o ou marca a página como não segura. Costuma vir de URLs copiados de um template antigo. Procura no código-fonte por http:// e muda para caminhos relativos ou HTTPS.
Se estás numa plataforma gerida
Vercel, Netlify, Cloudflare Pages, Railway ou Render emitem e renovam o certificado, forçam versões modernas e escolhem cifras seguras. Não tens de tocar em nada disso. O que continua a ser teu: acrescentar HSTS, eliminar conteúdo misto, redirecionar os domínios alternativos e vigiar os subdomínios que apontam para outros sítios.
Porque importa para lá da nota
Um TLS fraco permite intercetar sessões em redes públicas, e um certificado mal configurado faz com que o teu site falhe em dispositivos que não vês. Os processadores de pagamento exigem TLS 1.2 no mínimo para cumprir o PCI DSS. O Google usa o HTTPS como sinal de posicionamento e os navegadores marcam como "não seguro" tudo o que não o tenha. E, de forma mais terrena, um certificado expirado num sábado de manhã é um site em baixo até alguém reparar.
Verificar em trinta segundos
curl -sIL http://oteudominio.com | grep -iE "^(HTTP|location|strict-transport)"
openssl s_client -connect oteudominio.com:443 -servername oteudominio.com -tls1_1 </dev/null 2>&1 | grep -iE "alert|error" | head -1O primeiro deve mostrar um 301 para https:// e depois o cabeçalho HSTS. O segundo tenta ligar com TLS 1.1 e deve falhar: se ligar, aceitas uma versão obsoleta.
O Scanaris revê o teu TLS em cada análise
O Scanaris verifica versões do protocolo, cifras, cadeia completa, nomes do certificado, dias até à expiração, redirecionamento e HSTS, e avisa-te por email antes de o certificado expirar. Cada achado traz um fix prompt com a configuração exata para o teu servidor ou a tua plataforma. São verificações só de leitura: liga-se ao teu site tal como um navegador o faria. Para veres tudo o que revê em trinta segundos, lê como saber se o teu site é seguro em 5 minutos.
Perguntas frequentes
Qual é a diferença entre SSL e TLS?
SSL é o nome antigo do protocolo, retirado há anos por ser inseguro. O que se usa hoje é TLS, mas as pessoas continuam a dizer "certificado SSL". Para efeitos práticos, quando leres SSL pensa em TLS.
Preciso de um certificado pago?
Não. Os certificados gratuitos da Let's Encrypt ou os que a tua plataforma emite cifram exatamente da mesma forma. Os pagos acrescentam validação da organização ou garantias, não mais segurança na ligação.
Porque tiro um B se o meu certificado é válido?
Normalmente por aceitar TLS 1.0 ou 1.1, oferecer cifras fracas ou não enviar o cabeçalho HSTS. O certificado é só uma das sete coisas que se avaliam.