Como Instalar um Certificado SSL no NGINX

Este guia mostra como instalar um certificado SSL/TLS no NGINX. Ele aborda a parte que confunde a maioria das pessoas: construir a cadeia de certificados correta (“fullchain”) que o NGINX exige, apontar as diretivas corretas para os arquivos corretos, testar a configuração antes de recarregar e adicionar um redirecionamento limpo de HTTP para HTTPS para que todo visitante chegue à versão segura do seu site.

Gerar um código CSR para NGINX

Se você já gerou seu CSR e tem em mãos os arquivos do certificado emitido, avance para Instalar um certificado SSL no NGINX.

Antes que uma Autoridade Certificadora possa emitir seu certificado, você precisa enviar um CSR (Certificate Signing Request): um pequeno bloco de texto que contém os detalhes do seu domínio e uma chave pública, associado a uma chave privada mantida no servidor. Você tem duas opções:

• Gerar o CSR automaticamente com nosso Gerador de CSR. A ferramenta retorna tanto o CSR quanto a chave privada correspondente, que você depois envia ao servidor.
• Gerar o CSR no próprio servidor com o OpenSSL, seguindo nosso tutorial sobre como gerar um CSR no NGINX. A chave privada permanece no servidor.

Abra o arquivo .csr resultante em qualquer editor de texto; o bloco de texto interno (incluindo as linhas —–BEGIN CERTIFICATE REQUEST—– e —–END CERTIFICATE REQUEST—–) é o que você cola no formulário de solicitação de SSL durante o checkout. Se quiser confirmar o conteúdo do CSR antes de enviá-lo, cole-o em nosso decodificador de CSR.

Instalar um certificado SSL no NGINX

Depois que a CA emitir o certificado, você normalmente receberá:

• Seu certificado primário (do servidor), geralmente um arquivo .crt com o nome do seu domínio.
• Os certificados intermediários (e às vezes o raiz), como arquivos .crt separados ou agrupados em um único arquivo .ca-bundle.
• A chave privada (um arquivo .key) que foi gerada junto com seu CSR.

O NGINX precisa que o certificado do servidor e a cadeia intermediária estejam combinados em um único arquivo (o “fullchain”) e apontados por ssl_certificate; a chave privada é apontada separadamente por ssl_certificate_key. Pular a cadeia é o erro de instalação mais comum: o certificado parece correto em um navegador desktop, mas falha no Android, em clientes de API e em ferramentas como nosso SSL Checker.

Etapa 1: Combine os certificados em um único arquivo

A ordem dos certificados no arquivo combinado é importante. Seu certificado de servidor vem primeiro, depois cada intermediário da CA emissora final para cima, com o raiz por último (ou omitido, já que os navegadores já confiam nos certificados raiz de sua própria loja integrada):

• Seu certificado primário para o nome de domínio.
• Certificado(s) intermediário(s).
• Certificado raiz (opcional).

Você pode montar o arquivo fullchain manualmente em um editor de texto (colando cada bloco PEM em ordem) ou com um único comando cat. Se você recebeu arquivos separados de intermediário e raiz, execute:

cat your_domain.crt intermediate.crt root.crt > ssl-bundle.crt

Se os intermediários e o raiz já estiverem em um único arquivo .ca-bundle, execute:

cat example_com.crt example_com.ca-bundle > ssl-bundle.crt

Substitua os nomes de arquivo pelos seus. Mova o arquivo combinado (e a chave privada, se ainda não estiver lá) para o diretório SSL do seu servidor, por exemplo /etc/ssl/ ou /etc/nginx/ssl/. Mantenha o arquivo de chave legível apenas pelo root:

sudo chmod 600 /etc/ssl/your_domain.key
sudo chown root:root /etc/ssl/your_domain.key

Etapa 2: Edite o arquivo de configuração do NGINX

Abra o arquivo de configuração do NGINX para o seu site. No Debian e no Ubuntu, ele fica em /etc/nginx/sites-available/ (com um link simbólico em sites-enabled/); no RHEL, CentOS, AlmaLinux e Rocky Linux, ele fica em /etc/nginx/conf.d/. Adicione ou edite o bloco de servidor que escuta na porta 443 para que ele aponte para o arquivo fullchain e a chave privada:

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

    ssl_certificate     /etc/ssl/ssl-bundle.crt;
    ssl_certificate_key /etc/ssl/your_domain.key;

    # Modern TLS only
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    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_session_timeout 1d;
    ssl_session_cache shared:NginxSSL:10m;
    ssl_session_tickets off;

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;

    root /var/www/example.com;
    index index.html;

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

Algumas observações sobre as diretivas acima:

• listen 443 ssl; ativa o TLS na porta 443. A antiga diretiva ssl on; foi removida no NGINX 1.25 e não deve aparecer em configurações modernas.
• http2 on; ativa o HTTP/2 como diretiva própria (NGINX 1.25.1 e posteriores). Configurações mais antigas usavam listen 443 ssl http2;, que ainda funciona, mas está obsoleta.
• ssl_protocols TLSv1.2 TLSv1.3; desativa os obsoletos TLS 1.0 e 1.1. A partir do NGINX 1.27.3, este também é o padrão caso você omita a diretiva, mas defini-la explicitamente é a escolha mais clara e adequada para auditoria.
• A lista de cifras corresponde ao perfil “intermediate” da Mozilla e funciona em todos os clientes recentes. Se você precisar apenas de clientes TLS 1.3, pode remover completamente ssl_ciphers.

Etapa 3: Redirecionar HTTP para HTTPS

Adicione um bloco de servidor separado na porta 80 que redirecione permanentemente todas as solicitações para HTTPS, para que os visitantes que chegam via HTTP simples cheguem à URL segura:

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

Usar return 301 é mais rápido e mais seguro do que uma regra rewrite baseada em regex e é o padrão que o próprio NGINX recomenda.

Etapa 4: Teste a configuração e recarregue o NGINX

Sempre valide a configuração antes de recarregar, para que um erro de digitação não deixe o serviço indisponível:

sudo nginx -t

Você deve ver syntax is ok e test is successful. Se houver um erro relatado, a mensagem inclui o arquivo e o número da linha; corrija-o e execute o teste novamente. Quando o teste for aprovado, recarregue o NGINX para que ele adote a nova configuração sem encerrar as conexões existentes:

sudo systemctl reload nginx

Em sistemas sem systemd, use o próprio sinal de recarregamento do NGINX:

sudo nginx -s reload

Prefira reload em vez de restart: um reload relê a configuração sem encerrar as conexões ativas, enquanto um restart as encerra.

Etapa 5 (opcional): Ative o OCSP stapling

O OCSP stapling permite que o NGINX entregue um status de revogação atualizado e assinado junto com o certificado, para que os clientes não precisem contatar a CA em cada handshake. Adicione o seguinte dentro do seu bloco de servidor HTTPS:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/ssl-bundle.crt;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;

Recarregue o NGINX novamente com sudo systemctl reload nginx. O stapling é uma etapa de reforço pequena, mas útil, e a maioria dos certificados modernos o suporta imediatamente.

Verifique a instalação

Abra o seu site via https:// em um navegador e verifique se o cadeado está fechado e se o certificado corresponde ao seu domínio. Em seguida, execute uma verificação mais aprofundada com nosso SSL Checker para obter um relatório instantâneo sobre o certificado, a cadeia e os protocolos e cifras que o seu servidor está oferecendo. Um resultado verde ali significa que os clientes em todas as principais plataformas confiarão no certificado, incluindo clientes móveis e de API.

Perguntas Frequentes