Protegendo o Nginx com HTTPS: Um Guia Passo a Passo
Aprenda como proteger seu servidor web Nginx com HTTPS neste guia abrangente passo a passo. Abordamos a obtenção de certificados SSL/TLS gratuitos do Let's Encrypt usando Certbot, a configuração do Nginx para conexões criptografadas e a implementação de medidas de segurança essenciais como HSTS. Proteja seus dados, construa a confiança do usuário e melhore o SEO com uma configuração HTTPS adequada.
Protegendo o Nginx com HTTPS: Um Guia Passo a Passo
Proteger o Nginx com HTTPS geralmente é um trabalho pequeno, mas é um daqueles trabalhos onde pequenos erros são barulhentos. Um arquivo de certificado ausente impede o Nginx de recarregar. Uma regra de firewall esquecida faz o site parecer fora do ar. Um cabeçalho HSTS apressado pode prender os usuários em uma configuração HTTPS quebrada por mais tempo do que você pretendia.
A boa notícia é que o caminho normal é simples. Você aponta o DNS para o servidor, certifica-se de que o Nginx responda na porta 80, usa o Certbot para solicitar um certificado Let's Encrypt, testa a configuração gerada do Nginx, recarrega e verifica a renovação. Esse é o caminho que este guia segue.
Usarei example.com e www.example.com abaixo. Substitua-os pelos seus nomes reais e não pule as verificações antes de recarregar o Nginx.
Antes de Solicitar um Certificado
Antes de tocar no Certbot, confirme as peças chatas. A maioria dos problemas de certificado vem de DNS, firewalls ou um bloco de servidor que não responde pelo domínio solicitado.
Verifique o DNS de algum lugar fora do servidor:
dig +short example.com
dig +short www.example.com
Ambos os nomes devem resolver para o endereço público que alcança seu host Nginx ou balanceador de carga.
Certifique-se de que as portas 80 e 443 estejam abertas em todas as camadas: grupo de segurança da nuvem, firewall do host, firewall de rede e qualquer balanceador de carga na frente do host.
sudo ss -tulnp | grep nginx
sudo ufw status
Em uma VM na nuvem, verifique também o console do provedor. Já vi muitas configurações limpas do Nginx falharem porque o firewall da instância permitia 443, mas o grupo de segurança da nuvem ainda bloqueava.
Finalmente, confirme que o Nginx já atende o domínio via HTTP simples:
curl -I http://example.com
curl -I http://www.example.com
A resposta não precisa ser bonita. Pode ser uma página de espaço reservado. Só precisa provar que as requisições para aquele hostname chegam a este servidor Nginx.
Instalar o Certbot
Para Debian/Ubuntu:
sudo apt update
sudo apt install certbot python3-certbot-nginx
Para sistemas compatíveis com RHEL:
sudo dnf install certbot python3-certbot-nginx
Sistemas CentOS mais antigos podem usar yum e podem precisar habilitar o EPEL primeiro. Os nomes dos pacotes também variam conforme a versão da distribuição, então use a documentação de pacotes da sua distribuição se esses comandos não encontrarem o plugin.
Solicitar o Certificado
O plugin do Nginx pode solicitar o certificado e editar o bloco de servidor correspondente:
sudo certbot --nginx -d example.com -d www.example.com
O Certbot pedirá um endereço de e-mail, concordância com os termos e, às vezes, se deve redirecionar HTTP para HTTPS. Para um site público normal, escolha o redirecionamento. Para uma API ou serviço interno, verifique primeiro os clientes. Alguns clientes mais antigos ou verificações de integridade ainda podem chamar http:// e esperar uma resposta específica.
Se o Certbot disser que não consegue encontrar um bloco de servidor correspondente, verifique server_name. Um bloco como este dá ao Certbot algo claro para trabalhar:
server {
listen 80;
server_name example.com www.example.com;
root /var/www/example.com/public;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
Execute uma verificação de sintaxe antes de pedir ao Certbot para editar qualquer coisa:
sudo nginx -t
Se a configuração atual já estiver quebrada, corrija isso primeiro.
Como a Configuração do Nginx Deve Ficar
Após uma execução bem-sucedida, você geralmente verá um bloco HTTP que redireciona e um bloco HTTPS que atende o site:
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$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;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
root /var/www/example.com/public;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
Não copie isso cegamente sobre uma configuração de produção. Preserve suas regras location existentes, configurações de proxy, logs e limites de upload. As partes importantes são o listen 443 ssl, os caminhos dos certificados e o comportamento de redirecionamento na porta 80.
Testar, Recarregar e Verificar
Sempre teste antes de recarregar:
sudo nginx -t
Depois recarregue:
sudo systemctl reload nginx
Verifique pela linha de comando:
curl -I http://example.com
curl -I https://example.com
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates
A requisição HTTP deve redirecionar se você escolheu essa opção. A requisição HTTPS deve retornar o status esperado. O comando openssl deve mostrar um certificado cujo assunto ou nomes alternativos de assunto cubram o domínio e cujas datas estejam atuais.
Testar no navegador ainda é importante. Abra o site em uma janela privada e clique no ícone de cadeado para inspecionar o certificado. Se seu site carregar ativos de URLs http:// antigas, a página pode mostrar avisos de conteúdo misto mesmo que o certificado principal esteja bom. Corrija essas URLs de ativos no aplicativo, CMS ou camada de template.
Renovação
Os certificados Let's Encrypt têm vida curta, então a renovação deve funcionar sem que você se lembre dela. O Certbot normalmente instala um timer systemd ou um cron job. Verifique:
systemctl list-timers | grep certbot
sudo certbot renew --dry-run
O dry run é a parte útil. Ele realiza uma simulação de renovação e captura problemas comuns, como validação HTTP quebrada, alterações de DNS, plugins ausentes ou uma configuração que não pode recarregar.
Se você terminar o TLS em um balanceador de carga ou CDN em vez de diretamente no host Nginx, a renovação pode precisar de um desafio DNS ou de um caminho de implantação diferente. Não presuma que o desafio HTTP padrão funcionará se o tráfego público nunca chegar a este servidor.
Configurações TLS que Vale a Pena Verificar
Para a maioria dos sites públicos modernos, TLS 1.2 e TLS 1.3 são a linha de base prática:
ssl_protocols TLSv1.2 TLSv1.3;
Evite ajustar manualmente listas de cifras a menos que você saiba o porquê. O options-ssl-nginx.conf incluído pelo Certbot e o Gerador de Configuração SSL da Mozilla são melhores pontos de partida do que uma string de cifra copiada de um post de blog antigo. As orientações sobre cifras mudam com o tempo, e os requisitos de compatibilidade diferem entre um site público de marketing e uma API legada interna.
HSTS é útil, mas merece cautela:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
Comece com um valor curto durante os testes:
add_header Strict-Transport-Security "max-age=300" always;
Use includeSubDomains apenas quando cada subdomínio puder servir HTTPS válido. Se old.example.com, mail.example.com ou um subdomínio específico de cliente não estiver pronto, essa opção pode quebrar usuários reais.
Falhas Comuns
Se o Certbot não conseguir verificar o domínio, verifique primeiro o DNS, depois a porta 80 e depois o bloco de servidor do Nginx. O desafio HTTP-01 precisa que o Let's Encrypt alcance um token em /.well-known/acme-challenge/. Redirecionamentos são aceitáveis quando configurados corretamente, mas um proxy, CDN ou bloco catch-all pode acidentalmente enviar o desafio para outro lugar.
Se o Nginx falhar ao recarregar após as alterações do Certbot, execute:
sudo nginx -t
sudo journalctl -u nginx -n 80 --no-pager
O teste de sintaxe geralmente informa o arquivo e a linha exatos. Causas comuns são blocos listen 443 ssl duplicados, um caminho de certificado removido ou um snippet incluído de um caminho que não existe neste servidor.
Se HTTPS funcionar localmente, mas não para os usuários, verifique o caminho público. Um balanceador de carga pode ainda apontar para um grupo de destino antigo. Um CDN pode ter armazenado em cache um redirecionamento. O DNS IPv6 pode apontar para um host diferente do IPv4. Teste ambos:
curl -4 -I https://example.com
curl -6 -I https://example.com
A configuração HTTPS mais limpa é chata: DNS aponta para o lugar certo, Nginx tem um bloco de servidor óbvio para o domínio, a renovação do Certbot passa em um dry run e os cabeçalhos são adicionados somente depois que o básico funciona.