Certificados TLS e redirecionamento HTTPS: certificado válido e usuários sempre em HTTPS
Certificados expirados e falta de redirecionamento HTTPS expõem usuários e os ensinam a ignorar avisos. Como verificar e corrigir.
Severidade típica: Alta · Verificado pelo módulo da NovaPentest: SSL/TLS
O que é
Um certificado TLS permite ao navegador confirmar que está falando com o seu servidor e não com um impostor, e é a base da criptografia que protege tudo o que trafega em HTTPS. O certificado é emitido por uma autoridade certificadora em que os navegadores confiam, lista os domínios que cobre e vale por um período limitado, que o setor vem encurtando ano após ano.
Com um certificado válido, a conexão não mostra aviso algum e o usuário nem pensa no assunto. Quando ele expira, é autoassinado ou cita outro domínio, o navegador interrompe o acesso e exibe um aviso de segurança em tela cheia antes de carregar o site.
A segunda metade do tema é o redirecionamento de HTTP para HTTPS. Ter um certificado não coloca, por si só, os usuários em HTTPS. As pessoas digitam o domínio sem protocolo e seguem links e favoritos antigos, e muitos deles começam com http://. O servidor precisa responder a essas requisições com um redirecionamento permanente para o endereço HTTPS, e o HSTS mantém o navegador em HTTPS nas visitas seguintes.
Juntos, um certificado confiável e dentro da validade e um redirecionamento obrigatório garantem que todo visitante termine em uma conexão criptografada com o site verdadeiro, sem precisar fazer nada. Os dois são controles operacionais, não de código: falham porque um job de renovação parou, um subdomínio novo entrou no ar sem certificado ou um servidor foi reconstruído sem a regra de redirecionamento.
Como é explorada
Um certificado expirado derruba o site para todo mundo ao mesmo tempo. Os navegadores mostram um aviso em tela cheia, clientes de API e apps mobile recusam a conexão, e webhooks de provedores de pagamento ou de e-mail começam a falhar. O custo menos óbvio é de comportamento: usuários que veem avisos de certificado em um site em que confiam aprendem a clicar para seguir em frente, e quem pega esse hábito também vai ignorar o aviso no dia em que alguém na rede estiver de fato se passando pelo site.
Um certificado autoassinado gera o mesmo aviso em toda visita, com o mesmo efeito sobre os hábitos do usuário, e não dá ao navegador nenhum meio de distinguir o seu servidor de qualquer outro.
Um site que não redireciona HTTP para HTTPS deixa sem criptografia a primeira requisição de muitas visitas. Em um Wi-Fi público, ou em qualquer rede controlada por outra pessoa, essa requisição pode ser respondida pelo operador da rede no lugar do seu servidor, mantendo o usuário em uma versão HTTP do site em que logins, dados de formulário e cookies sem a flag Secure trafegam em texto claro. O usuário vê o conteúdo do seu site e não tem motivo para procurar o cadeado.
Nada disso exige uma falha na aplicação. Os problemas estão na configuração e na manutenção, e é por isso que costumam aparecer de repente em um site que funcionou bem por meses.
Como detectar
O módulo SSL/TLS da NovaPentest se comporta de forma diferente conforme a URL alvo. Para um alvo https://, ele completa uma conexão TLS, lê o certificado apresentado pelo servidor e reporta certificado já vencido como Crítica, vencimento em menos de 7 dias como Crítica, vencimento em menos de 30 dias como Alta e certificado cujo emissor é igual ao titular (autoassinado) como Alta. Para um alvo http://, ele faz a requisição sem seguir redirecionamentos e reporta Alta se a resposta não trouxer um header Location apontando para um endereço https://. O módulo roda no scanner passivo gratuito em novapentest.com/scan.
Vale conhecer os limites. O módulo aceita qualquer certificado para conseguir lê-lo, então não reporta divergência de hostname, cadeia incompleta ou não confiável, nem certificado emitido por autoridade desconhecida, a menos que seja autoassinado. Ele não testa versões de protocolo nem cipher suites. E, como a checagem de redirecionamento só roda para alvos http:// e o scanner gratuito escolhe HTTPS sempre que o site responde nele, a falta de redirecionamento normalmente não é reportada ali. A checagem também aceita, no primeiro salto, um redirecionamento para qualquer URL HTTPS, sem conferir o host.
Para conferir manualmente, inspecione o certificado com openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -subject -issuer -dates e leia a data notAfter. Verifique o redirecionamento com curl -sI http://example.com: a resposta deve ser 301 ou 308 com Location: https://example.com/. Repita para a variante www e para todos os outros hostnames que você publica.
Como corrigir
1. Automatize a renovação. Use um cliente ACME como certbot ou acme.sh, ou a automação nativa do Caddy, do load balancer do seu provedor de nuvem ou do ingress do Kubernetes (cert-manager). Confirme que a renovação agendada funciona com um teste, por exemplo certbot renew --dry-run.
2. Garanta que o certificado renovado seja de fato servido. Muitas quedas acontecem porque o arquivo foi renovado, mas o servidor web nunca foi recarregado. Adicione um hook como certbot renew --deploy-hook "systemctl reload nginx".
3. Monitore o vencimento de forma independente do job de renovação, com alertas aos 30 e aos 14 dias. Se a renovação quebrar, o monitoramento é a única coisa que vai avisar você.
4. Troque certificados autoassinados em qualquer serviço público por um emitido por autoridade confiável. Os certificados do Let's Encrypt são gratuitos.
5. Sirva a cadeia completa. No nginx, ssl_certificate deve apontar para o arquivo fullchain, não só para o certificado final, ou alguns clientes não vão conseguir validá-lo.
6. Cubra todos os hostnames que você publica, incluindo www e subdomínios de API, com um certificado que liste todos ou com certificados separados.
7. Redirecione todo o tráfego HTTP com um redirecionamento permanente. No nginx: server { listen 80; server_name example.com www.example.com; return 301 https://$host$request_uri; } No Apache: RewriteEngine On, RewriteCond %{HTTPS} off, RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]. No IIS, use o módulo URL Rewrite com uma regra que casa {HTTPS} off. No ASP.NET Core, chame app.UseHttpsRedirection(). Atrás de um load balancer que termina o TLS, faça o redirecionamento no próprio load balancer ou verifique o header X-Forwarded-Proto.
8. Ative o HSTS quando o redirecionamento estiver funcionando em todo lugar, para que navegadores que já visitaram o site pulem a requisição sem criptografia.
9. Restrinja os protocolos a TLS 1.2 e 1.3, por exemplo com ssl_protocols TLSv1.2 TLSv1.3; no nginx.
Verifique o seu próprio site
Comece pelo scan passivo gratuito: não precisa de conta e você recebe uma nota de A a F cobrindo cabeçalhos, TLS, cookies, DNS e outras configurações que qualquer visitante consegue observar. Ele não envia payloads de ataque, então não confirma todas as classes de falha. O scan completo, disponível com uma conta gratuita, executa as verificações ativas, incluindo a descrita nesta página.