Configure TLS 1.2 e 1.3 com cifras seguras e HSTS no Nginx, Apache e Windows Server, desabilite TLS 1.0/1.1 e teste no SSL Labs e com testssl.sh.

Para que serve

Ter certificado válido não garante uma conexão segura: o servidor também precisa recusar protocolos antigos e cifras fracas. TLS 1.0 e 1.1 foram oficialmente descontinuados (RFC 8996), e navegadores, PCI DSS e auditorias apontam servidores que ainda os aceitam. Este artigo mostra como desabilitar TLS 1.0 e 1.1, deixar apenas TLS 1.2 e 1.3 com cifras modernas no Nginx, no Apache e no Windows Server, e conferir o resultado no SSL Labs. Para emitir e renovar o certificado, veja o artigo sobre Let's Encrypt e Certbot.

Pré-requisitos

  • Site já com certificado válido (Let's Encrypt ou comercial).
  • Acesso root à VM do servidor web, ou administrador no Windows Server.
  • Saber se algum cliente antigo precisa acessar o serviço (equipamentos legados, Windows 7, integrações antigas), porque ele pode parar de conectar.

Passo 1: TLS seguro no Nginx

  1. No bloco server com listen 443 ssl (ou em um arquivo comum incluído por todos os sites), use a configuração "intermediária" recomendada pelo gerador da Mozilla: 
    ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;
ssl_session_timeout 1d;
ssl_session_cache shared:TLS:10m;
ssl_session_tickets off;
  2. Teste e recarregue: 
    sudo nginx -t && sudo systemctl reload nginx

Passo 2: TLS seguro no Apache

  1. Em /etc/apache2/mods-available/ssl.conf (vale para todos os sites): 
    SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder off
SSLSessionTickets off
  2. Teste e recarregue: 
    sudo apache2ctl configtest && sudo systemctl reload apache2

Prefira gerar a configuração em ssl-config.mozilla.org informando a versão exata do seu servidor web e do OpenSSL, porque as recomendações são revisadas periodicamente.

Passo 3: HSTS (forçar HTTPS no navegador)

O cabeçalho HSTS faz o navegador usar sempre HTTPS no seu domínio, evitando ataques de rebaixamento. Comece com prazo curto e aumente depois de confirmar que tudo funciona em HTTPS:

# Nginx
add_header Strict-Transport-Security "max-age=86400" always;
# Apache (requer: sudo a2enmod headers)
Header always set Strict-Transport-Security "max-age=86400"

Com tudo estável, suba para max-age=63072000 (dois anos). Só acrescente includeSubDomains se todos os subdomínios tiverem HTTPS.

Cuidado com o HSTS: depois que o navegador recebe o cabeçalho, ele recusa HTTP no domínio até o prazo expirar. Se um subdomínio ainda não tem certificado, ele fica inacessível para quem já visitou o site.

Passo 4: desabilitar TLS 1.0 e 1.1 no Windows Server

No Windows Server 2025, TLS 1.0 e 1.1 já vêm desabilitados por padrão. No Windows Server 2022, desabilite no registro do SCHANNEL (afeta IIS, RDP, SQL Server e outros serviços que usam a pilha do Windows). Em PowerShell como administrador:

foreach ($v in 'TLS 1.0','TLS 1.1') {
  foreach ($lado in 'Server','Client') {
    $p = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\$v\$lado"
    New-Item -Path $p -Force | Out-Null
    New-ItemProperty -Path $p -Name Enabled -Value 0 -PropertyType DWord -Force | Out-Null
    New-ItemProperty -Path $p -Name DisabledByDefault -Value 1 -PropertyType DWord -Force | Out-Null
  }
}

Reinicie o servidor para aplicar. Antes, confirme que o SQL Server, o .NET das suas aplicações e os clientes RDP estão atualizados e suportam TLS 1.2.

Risco de perder o RDP: clientes RDP muito antigos ou componentes desatualizados podem deixar de conectar. Faça a mudança com acesso garantido pelo console noVNC do Proxmox ou pelo IPMI/iLO, e guarde um arquivo .reg de reversão.

Passo 5: testar no SSL Labs e com testssl.sh

  1. SSL Labs: acesse https://www.ssllabs.com/ssltest/, informe o domínio e marque "Do not show the results on the boards" se não quiser o resultado público. A meta é nota A ou A+ (A+ exige HSTS).
  2. testssl.sh (útil para portas que não são 443, como 8006 do Proxmox, 993 do IMAP ou serviços internos): 
    git clone --depth 1 https://github.com/testssl/testssl.sh.git
cd testssl.sh
./testssl.sh --protocols --ciphers www.exemplo.com.br
./testssl.sh 203.0.113.10:8006
  3. Teste rápido com OpenSSL: 
    openssl s_client -connect www.exemplo.com.br:443 -tls1_1 </dev/null
openssl s_client -connect www.exemplo.com.br:443 -tls1_2 </dev/null
    O primeiro deve falhar no handshake; o segundo deve mostrar o certificado. Em OpenSSL 3, o teste com -tls1_1 pode falhar no próprio cliente; nesse caso, confie no SSL Labs ou no testssl.sh.

Como saber se funcionou

  • SSL Labs mostra apenas TLS 1.2 e TLS 1.3 em Protocols e nota A ou superior.
  • testssl.sh lista TLS 1.0 e 1.1 como "not offered".
  • O site e os sistemas que dependem dele (aplicativos, integrações, RDP) continuam funcionando.

Problemas comuns

  • Nota limitada por "certificate chain incomplete": use o arquivo fullchain.pem no servidor, não o cert.pem.
  • Avisos de OCSP stapling: a Let's Encrypt encerrou o serviço OCSP em 2025 e passou a usar CRLs. Remova ssl_stapling/SSLUseStapling da configuração se o seu certificado for da Let's Encrypt.
  • Integração antiga parou: algum sistema só fala TLS 1.0. Atualize o sistema; se for impossível, isole-o em um endereço separado em vez de reabrir TLS 1.0 para todos.
  • Configuração não muda nada no Nginx: outro bloco server (geralmente o primeiro carregado, ou o arquivo do Certbot options-ssl-nginx.conf) define parâmetros diferentes. Procure com sudo nginx -T | grep -n ssl_protocols.

Perguntas frequentes

Preciso desabilitar o TLS 1.2?

Não. TLS 1.2 com cifras ECDHE e AES-GCM ou ChaCha20 continua seguro e é necessário para muitos clientes. A configuração "moderna", só com TLS 1.3, é indicada apenas quando todos os clientes são atuais.

Certificado pago é mais seguro que Let's Encrypt?

A criptografia é a mesma. Certificados pagos podem trazer validação da empresa e suporte, mas não melhoram a nota no SSL Labs.

O SSL Labs testa portas diferentes de 443?

Não. Para outras portas, use o testssl.sh.

Com que frequência devo testar?

Após cada mudança no servidor web e uma vez por mês, junto com o checklist de segurança.

Leitura complementar

Precisa de ajuda?

Se perdeu o acesso RDP após alterar o SCHANNEL e precisa do console IPMI/iLO, abra um ticket ou chame o suporte 24/7.

Esta resposta lhe foi útil? 0 Usuários acharam útil (0 Votos)

Leia também