Como configurar SSL/TLS no Nginx e obter nota A+

O alerta de monitoramento disparou de repente. Abri o celular e vi que o certificado do site havia expirado. Os 90 dias do certificado gratuito tinham passado completamente despercebidos. O aviso vermelho de “Não seguro” do navegador parecia uma bandeira de deboche pendurada na página inicial do blog.

Depois desse incidente, passei uma semana estudando a configuração SSL/TLS do Nginx do início ao fim. Saí de uma nota F para A+ no SSL Labs, troquei a renovação manual pela automática e reduzi o handshake, que antes prejudicava o desempenho, para menos de 100 ms.

HTTPS não serve apenas para colocar um cadeado na barra de endereço do navegador. O Google afirma claramente que HTTPS é um dos fatores de ranqueamento nas buscas e que, depois de configurar HTTPS corretamente, o tráfego orgânico pode crescer entre 15% e 20%. Mais importante: ele impede a interceptação por ataques man-in-the-middle. Manter um site sem HTTPS é como falar os dados do cartão bancário em voz alta em um lugar público.

Aqui você vai configurar HTTPS no Nginx desde o início: emissão de certificado Let’s Encrypt, hardening com TLS 1.3, modelo de configuração para obter nota A+ no SSL Labs e renovação automática indispensável em produção. Todas as configurações podem ser copiadas e usadas diretamente.

Capítulo 1: conceitos básicos de HTTPS e escolha do tipo de certificado

1.1 Por que todo site precisa de HTTPS

O HTTP transmite dados em texto simples. Isso significa que cada página acessada e cada formulário enviado atravessam a rede sem proteção. O Wi-Fi público de uma cafeteria, o gateway da empresa ou o equipamento da operadora no bairro: qualquer nó intermediário pode ver o que você enviou.

O HTTPS adiciona uma camada de criptografia TLS entre HTTP e TCP. Os dados são criptografados antes do envio e descriptografados ao chegar ao destino; um observador no caminho vê apenas conteúdo ilegível.

O TLS faz muito mais do que criptografar. Ele também autentica a identidade do servidor, garantindo que você esteja acessando o verdadeiro example.com, e não um site de phishing após um sequestro de DNS. É por isso que o navegador exibe um alerta vermelho para certificados expirados ou incompatíveis com o domínio: ele está dizendo que “este site talvez não seja quem afirma ser”.

1.2 Os três principais tipos de certificado SSL: DV, OV e EV

Os certificados são divididos em três categorias conforme o rigor da validação:

Para ser sincero, um certificado DV é suficiente para a maioria dos projetos pessoais e equipes pequenas. O certificado DV gratuito da Let’s Encrypt é válido por 90 dias e recebe a mesma confiança dos navegadores que um certificado DV pago. A única “desvantagem” é a renovação a cada 90 dias, mas isso deixa de ser um problema quando a renovação automática está configurada.

A diferença entre os certificados OV e EV aparece principalmente na barra de endereço do navegador. Um certificado EV pode exibir o nome da empresa, mas os navegadores dão cada vez menos destaque visual a esse tipo de certificado; o Chrome nem sequer exibe mais o nome da empresa por padrão. Como os certificados OV e EV podem custar centenas ou milhares, o custo-benefício é baixo.

1.3 Let’s Encrypt: a melhor escolha de certificado gratuito

A Let’s Encrypt é uma autoridade certificadora sem fins lucrativos operada pelo ISRG (Internet Security Research Group). Ela oferece algumas vantagens importantes:

• Totalmente gratuito: certificados DV gratuitos sem prazo promocional
• Automação: emissão e renovação automáticas pelo protocolo ACME
• Ampla confiança: reconhecido por todos os principais navegadores e sistemas operacionais
• Validade de 90 dias: certificados de curta duração são mais seguros e obrigam você a automatizar o processo

Também há limitações: a Let’s Encrypt oferece apenas certificados DV, não OV ou EV, e certificados curinga exigem validação por DNS, que é um pouco mais trabalhosa. Ainda assim, para 99% dos projetos pessoais e sites de pequeno ou médio porte, essas limitações não representam um problema.

A seguir, vamos emitir o certificado com o Certbot, cliente oficial da Let’s Encrypt.

Capítulo 2: emissão de certificado Let’s Encrypt na prática

2.1 Instalar o Certbot

A forma de instalar o Certbot varia conforme o sistema operacional. Para quem usa Ubuntu, o caminho mais simples é:

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

# Ubuntu 20.04+ / Debian 10+
sudo apt update
sudo apt install certbot python3-certbot-nginx

No CentOS/RHEL, primeiro é necessário ativar o repositório EPEL:

# CentOS 8 / RHEL 8
sudo dnf install epel-release
sudo dnf install certbot python3-certbot-nginx

Depois da instalação, execute certbot --version para conferir a versão. Se estiver tudo certo, o próximo passo é emitir o certificado.

2.2 Emitir o certificado

O Certbot aceita diferentes métodos de validação. Os mais usados são standalone (validação independente) e webroot (validação pela raiz do site). Se o Nginx já estiver em execução, recomenda-se o modo webroot:

# Modo webroot: use quando o site já estiver em execução
sudo certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com

-w define o diretório raiz do site, enquanto -d define o domínio. É possível solicitar um único certificado para vários domínios.

Se o Nginx ainda não foi iniciado ou se você abriu um servidor apenas para um teste temporário, use o modo standalone:

# Modo standalone: precisa ocupar temporariamente a porta 80
sudo certbot certonly --standalone -d example.com -d www.example.com

Nesse modo, o Certbot inicia temporariamente um servidor HTTP e o encerra assim que a validação termina. A porta 80 precisa estar livre durante a validação; portanto, se o Nginx já estiver em execução, será necessário interrompê-lo primeiro.

Há ainda uma opção mais simples: o plugin do Certbot para Nginx pode alterar a configuração automaticamente:

# Modo de configuração automática: o Certbot altera a configuração do Nginx
sudo certbot --nginx -d example.com -d www.example.com

Esse comando emite o certificado, altera a configuração do Nginx e cria o redirecionamento para HTTPS. É uma forma rápida para iniciantes começarem, mas em produção é melhor fazer a configuração manualmente para controlar os parâmetros SSL com mais precisão.

2.3 Estrutura dos arquivos do certificado

Depois da emissão, os arquivos do certificado ficam, por padrão, no diretório /etc/letsencrypt/live/example.com/:

/etc/letsencrypt/live/example.com/
├── cert.pem        # Certificado do domínio
├── chain.pem       # Cadeia de certificados intermediários
├── fullchain.pem   # Cadeia completa de certificados (cert + chain)
└── privkey.pem     # Arquivo da chave privada

Na configuração do Nginx, você vai usar dois arquivos: fullchain.pem em ssl_certificate e privkey.pem em ssl_certificate_key. O privkey.pem é confidencial, deve ter permissão 600 e jamais pode ser exposto.

Capítulo 3: configuração básica de SSL no Nginx

3.1 A configuração HTTPS mais básica

Com o certificado pronto, o próximo passo é configurar HTTPS no Nginx. A configuração mínima é esta:

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Outras configurações...
    root /var/www/example.com;
    index index.html;
}

Essa configuração faz o HTTPS funcionar, mas rende apenas uma nota D. O problema é que ela não define as versões do TLS e, por padrão, aceita TLS 1.0 e 1.1, versões consideradas inseguras há anos.

3.2 Redirecionar HTTP para HTTPS

Configurar HTTPS não basta, pois o usuário ainda pode acessar diretamente a versão HTTP. É preciso redirecionar todas as requisições HTTP para HTTPS:

server {
    listen 80;
    server_name example.com www.example.com;

    # Redirecionamento permanente para HTTPS
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Outras configurações...
}

return 301 cria um redirecionamento permanente, que o navegador armazena em cache. Na próxima vez que o usuário digitar http://, o navegador irá diretamente para https://, eliminando uma requisição.

3.3 Um erro comum de configuração

É comum encontrar http2 depois de listen 443 ssl;, na forma listen 443 ssl http2;. A partir do Nginx 1.25.1, o suporte a HTTP/2 passou para a diretiva http2:

# Nova sintaxe do Nginx 1.25.1+
server {
    listen 443 ssl;
    http2 on;  # Diretiva http2 independente
    server_name example.com;

    # ...
}

Se a sua versão do Nginx for recente, prefira a nova sintaxe para evitar avisos de configuração. Execute nginx -v para conferir a versão.

Capítulo 4: hardening de segurança com TLS 1.3

4.1 Escolher as versões do TLS

O TLS tem quatro versões: 1.0, 1.1, 1.2 e 1.3. As versões 1.0 e 1.1 foram descontinuadas, e todos os principais navegadores deixaram de aceitá-las em 2020.

A principal vantagem do TLS 1.3 é o desempenho: o handshake passa de 2-RTT (duas idas e voltas) para 1-RTT, o que pode reduzir sua latência pela metade. Em testes reais, o handshake do TLS 1.3 pode ficar abaixo de 100 ms.

Na configuração do Nginx, use a diretiva ssl_protocols para definir as versões do TLS:

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

ssl_protocols TLSv1.2 TLSv1.3;

Não é recomendável ativar apenas TLS 1.3. Embora quase todos os navegadores ofereçam suporte ao TLS 1.3 em 2026, alguns clientes HTTP antigos, como determinadas ferramentas de API e dispositivos embarcados, talvez ainda não sejam compatíveis. Manter TLS 1.2 como opção de compatibilidade é uma escolha mais segura.

4.2 Configurar Cipher Suites

A Cipher Suite, ou conjunto de cifras, define o algoritmo de criptografia, o método de troca de chaves e o código de autenticação de mensagem. Uma escolha errada pode tornar o HTTPS praticamente inútil.

Lista recomendada de Cipher Suites para TLS 1.3 em 2026:

ssl_protocols TLSv1.2 TLSv1.3;

# Cipher Suites do TLS 1.3 (o Nginx usa automaticamente a lista padrão do OpenSSL)
# Esta linha pode ser omitida, mas mantê-la não causa problemas
ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

# Cipher Suites do TLS 1.2 (compatibilidade com versões anteriores)
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;

# Dê preferência às cifras especificadas pelo servidor
ssl_prefer_server_ciphers on;

Os pontos principais dessa configuração são:

• ECDHE: prioriza a troca de chaves por curva elíptica, mais segura e rápida que RSA
• AES-GCM: o modo GCM oferece criptografia autenticada e é mais seguro que o modo CBC
• CHACHA20-POLY1305: oferece melhor desempenho em dispositivos móveis sem aceleração de hardware para AES

Se estiver em dúvida, use o Mozilla SSL Configuration Generator para gerar a configuração: https://ssl-config.mozilla.org/

4.3 HSTS: forçar o acesso por HTTPS

O HSTS (HTTP Strict Transport Security) informa ao navegador que “este site aceita apenas conexões HTTPS”. Mesmo que o usuário digite http:// manualmente, o navegador força o acesso a https:// no próprio dispositivo, evitando uma requisição de rede.

# Cabeçalho HSTS
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Explicação dos parâmetros:

• max-age=31536000: validade de 1 ano, em segundos
• includeSubDomains: inclui todos os subdomínios
• preload: adiciona o domínio à HSTS Preload List, mediante envio para hstspreload.org

Atenção: depois de ativado, o HSTS fica armazenado no navegador por bastante tempo. Se você ainda precisa testar a versão HTTP, não adicione preload por enquanto ou use um max-age menor.

Capítulo 5: como otimizar o desempenho do SSL

5.1 SSL Session Cache

Cada handshake TLS exige troca de chaves e validação do certificado, operações que têm um custo considerável. O Session Cache permite que o cliente reutilize uma sessão anterior por determinado período, evitando todo o fluxo de um handshake completo.

# Configuração do Session Cache
ssl_session_cache shared:SSL:10m;  # Cache de 10 MB, cerca de 40.000 sessões
ssl_session_timeout 1d;            # Sessão válida por 1 dia
ssl_session_tickets off;           # Desativa Session Tickets para aumentar a segurança

shared:SSL:10m indica que todos os processos worker compartilham uma área de cache de 10 MB. Cada 1 MB armazena aproximadamente 4.000 sessões, portanto 10 MB são suficientes para sites pequenos e médios.

ssl_session_tickets off é uma decisão de segurança. O mecanismo de Session Ticket exige que o servidor mantenha uma chave para criptografar o ticket. Se essa chave vazar, um invasor poderá descriptografar todas as sessões anteriores. Desativar o recurso aumenta a segurança, mas também a carga do servidor, sendo indicado para cenários com requisitos de segurança mais rigorosos.

5.2 OCSP Stapling

Ao validar um certificado, o navegador precisa verificar se ele foi revogado. No método tradicional, ele envia uma consulta OCSP à autoridade certificadora, o que acrescenta uma requisição de rede e revela quais sites o usuário acessou.

Com o OCSP Stapling, o servidor consulta o status OCSP no lugar do navegador, guarda o resultado em cache e o envia junto com o certificado. Isso protege a privacidade e reduz a latência.

# Configuração do OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

resolver define os servidores DNS usados para resolver o domínio do servidor OCSP. Os endereços 8.8.8.8 e 8.8.4.4 do Google são escolhas comuns.

Depois de configurar, teste com OpenSSL:

openssl s_client -connect example.com:443 -status < /dev/null 2>&1 | grep -A 17 "OCSP response"

Se aparecer “OCSP Response Status: successful”, o OCSP Stapling está funcionando corretamente.

5.3 Ajustar ssl_buffer_size

ssl_buffer_size controla o tamanho dos registros TLS. O valor padrão é 16 KB, grande demais para respostas pequenas, como as de APIs, e pode aumentar o TTFB (tempo até o primeiro byte).

Para servidores de API ou blogs que enviam principalmente respostas pequenas, reduza o valor:

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

ssl_buffer_size 4k;  # Adequado para respostas pequenas

Para servidores de download de arquivos grandes, mantenha o padrão de 16 KB ou aumente para 32 KB.

Capítulo 6: renovação automática do certificado

6.1 Comando de renovação automática do Certbot

Os certificados da Let’s Encrypt são válidos por apenas 90 dias e precisam ser renovados periodicamente. O Certbot oferece o comando renew:

# Testar a renovação sem executá-la
sudo certbot renew --dry-run

# Executar a renovação
sudo certbot renew

O comando renew verifica a data de validade de todos os certificados e renova apenas aqueles com menos de 30 dias restantes. Por isso, você pode executá-lo diariamente sem preocupação: ele não desperdiça a cota do limite de solicitações da Let’s Encrypt.

6.2 Configurar uma tarefa no crontab

A forma mais confiável é agendar a renovação automática no crontab:

# Editar o crontab do usuário root
sudo crontab -e

Adicione estas duas linhas:

# Verificar todos os dias às 3:00 e às 15:00
0 3 * * * /usr/bin/certbot renew --quiet --post-hook "systemctl reload nginx"
0 15 * * * /usr/bin/certbot renew --quiet --post-hook "systemctl reload nginx"

--quiet ativa o modo silencioso, sem saída de log. --post-hook "systemctl reload nginx" recarrega a configuração do Nginx depois de uma renovação bem-sucedida, fazendo o novo certificado entrar em vigor.

Por que verificar duas vezes por dia? Porque uma renovação pode falhar ocasionalmente, por exemplo, durante uma falha temporária de DNS. Várias verificações aumentam a chance de sucesso.

6.3 Testar a renovação e resolver falhas

Quando a renovação falha, o Certbot registra os detalhes em /var/log/letsencrypt/letsencrypt.log. Os problemas mais comuns são:

1. Porta ocupada: o modo standalone precisa da porta 80; verifique se o Nginx não a está ocupando
2. Falha na resolução DNS: confirme que os registros DNS do domínio apontam corretamente para o servidor
3. Limite de solicitações: a Let’s Encrypt permite no máximo 5 emissões semanais do mesmo certificado; durante testes, use --dry-run
4. Permissão no diretório do certificado: confirme que o Certbot pode ler e gravar em /etc/letsencrypt/

Fluxo completo para testar a renovação:

# 1. Primeiro faça o teste com dry-run
sudo certbot renew --dry-run

# 2. Se o dry-run funcionar, faça a renovação real
sudo certbot renew

# 3. Confira a validade do certificado
sudo certbot certificates

# 4. Recarregue o Nginx
sudo systemctl reload nginx

Modelo de configuração completo

Abaixo está um modelo de configuração SSL do Nginx pronto para produção e capaz de obter nota A+ no SSL Labs:

# Redirecionamento HTTP
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$server_name$request_uri;
}

# Serviço HTTPS
server {
    listen 443 ssl;
    http2 on;
    server_name example.com www.example.com;

    # Configuração do certificado
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Versões do TLS
    ssl_protocols TLSv1.2 TLSv1.3;

    # Cipher Suites
    ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256: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 on;

    # Cabeçalhos de segurança
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    add_header X-Frame-Options SAMEORIGIN always;
    add_header X-Content-Type-Options nosniff always;
    add_header X-XSS-Protection "1; mode=block" always;

    # Session Cache
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    # Ajuste de desempenho
    ssl_buffer_size 4k;

    # Configuração do site
    root /var/www/example.com;
    index index.html index.htm;

    location / {
        try_files $uri $uri/ =404;
    }
}

Depois de concluir a configuração, teste a nota no SSL Labs: https://www.ssllabs.com/ssltest/

Conclusão

Começar a usar HTTPS não é difícil: algumas linhas de configuração já colocam o serviço no ar. Para alcançar nota A+ no SSL Labs sem abrir mão de desempenho e compatibilidade, porém, é preciso entender detalhes como versões do TLS, Cipher Suites, Session Cache e OCSP Stapling.

Resumo dos pontos essenciais:

1. Emissão do certificado: a Let’s Encrypt é gratuita e o Certbot simplifica a automação
2. Versões do TLS: use TLS 1.2 e 1.3; desative 1.0 e 1.1
3. Cipher Suites: priorize ECDHE e AES-GCM, mantendo CHACHA20 para compatibilidade de desempenho
4. HSTS: force HTTPS e reduza o custo do redirecionamento
5. Otimização de desempenho: Session Cache e OCSP Stapling são indispensáveis
6. Renovação automática: use duas verificações no crontab e recarregue o Nginx após a renovação

Copie o modelo acima para a configuração do seu Nginx e altere o domínio e os caminhos dos certificados. Depois, teste a nota no SSL Labs e conte nos comentários qual foi o resultado. Meu palpite é que será A+.