Passo a passo: Nginx Reverse Proxy com autenticação mútua TLS

Nginx Reverse Proxy com autenticação mútua TLS (mTLS) é uma arquitetura de proteção criptográfica onde tanto o servidor quanto o cliente validam mutuamente seus certificados digitais X.509 antes de autorizar qualquer transmissão de pacotes HTTP. Para implementar essa camada de segurança Zero Trust na sua infraestrutura, execute os passos abaixo:

1. Crie a infraestrutura de chave pública local (PKI) gerando o certificado da Autoridade Certificadora raiz (CA).
2. Gere a chave privada e assine o certificado digital do cliente através da sua CA privada.
3. Transfira o certificado da CA para o servidor e aponte os caminhos nas configurações do Nginx.
4. Configure as diretivas ssl_client_certificate e ssl_verify_client no bloco do servidor proxy.
5. Repasse os cabeçalhos de identidade TLS para a aplicação interna e valide o acesso restrito via terminal.

Pré-requisitos

• Servidor Linux executando Debian 13 ou AlmaLinux 10 com privilégios de superusuário (acesso root ou sudo).
• Nginx 1.28 ou superior instalado com o módulo ngx_http_ssl_module compilado.
• OpenSSL 3.4 ou superior configurado no ambiente de terminal para geração dos pares de chaves.
• Aplicação backend em execução local (ex.: escutando em 127.0.0.1:8080 ou via socket Unix).
• Domínio ou subdomínio devidamente apontado via DNS com portas 80 e 443 liberadas no firewall. Se você estiver iniciando a configuração do servidor, veja nosso guia sobre como Acessando servidores VPS Linux da AviraHost para preparar o ambiente com segurança.

Como estruturar a CA para o Nginx Reverse Proxy com autenticação mútua TLS

A infraestrutura de chave pública é o alicerce fundamental para estabelecer um canal confiável no proxy reverso. Diferente do protocolo SSL/TLS convencional, no qual confiamos em entidades comerciais públicas para validar apenas o servidor, o modelo mTLS exige que o Nginx conheça e confie na autoridade que assinou o certificado do cliente requisitante.

Para isolar os certificados, crie um diretório de trabalho protegido no sistema operacional e estabeleça permissões restritivas:

sudo mkdir -p /etc/nginx/certs/ca && cd /etc/nginx/certs/ca
sudo chmod 700 /etc/nginx/certs/ca

Gere a chave privada da sua Autoridade Certificadora interna com criptografia RSA de 4096 bits e, em seguida, crie o certificado raiz autoassinado:

sudo openssl genrsa -out ca.key 4096
sudo openssl req -x509 -new -nodes -key ca.key -sha256 -days 1825 -out ca.crt -subj "/CN=Minha-CA-Interna/O=AviraHost Corp"

Ao concluir o comando, verifique se os arquivos foram gravados com os privilégios apropriados executando:

ls -la /etc/nginx/certs/ca

-rw-r--r-- 1 root root 2048 Mar 28 10:00 ca.crt
-rw------- 1 root root 3272 Mar 28 10:00 ca.key

Com a CA pronta, gere o par de chaves e o Certificate Signing Request (CSR) específico para o cliente (aplicação consumidora, microserviço ou usuário administrativo):

sudo openssl genrsa -out cliente1.key 2048
sudo openssl req -new -key cliente1.key -out cliente1.csr -subj "/CN=cliente-api-01/O=Integracao Parceiro"
sudo openssl x509 -req -in cliente1.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out cliente1.crt -days 730 -sha256

Se o cliente for acessar o proxy via navegador web ou aplicativo legatário, converta o certificado e a chave para o formato PKCS#12 (PFX), definindo uma senha de transporte:

sudo openssl pkcs12 -export -out cliente1.p12 -inkey cliente1.key -in cliente1.crt -certfile ca.crt

Configuração do Nginx Reverse Proxy com validação mTLS

O encadeamento de autenticação mTLS é declarado dentro do bloco server de escuta segura (porta 443) do Nginx. É crucial garantir que as requisições não criptografadas sejam tratadas adequadamente. Para entender melhor essa camada de roteamento, consulte Como redirecionar um site http para https? antes de prosseguir com a blindagem das portas.

Crie um arquivo de configuração virtual em /etc/nginx/conf.d/api-mtls.conf:

upstream backend_servico {
    server 127.0.0.1:8080;
    keepalive 32;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name seudominio.com.br;

    # Certificados padrão do servidor web (ex.: Let's Encrypt)
    ssl_certificate /etc/letsencrypt/live/seudominio.com.br/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/seudominio.com.br/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    # Autenticação Mútua TLS (mTLS)
    ssl_client_certificate /etc/nginx/certs/ca/ca.crt;
    ssl_verify_client on;
    ssl_verify_depth 2;

    location / {
        proxy_pass http://backend_servico;
        proxy_http_version 1.1;
        proxy_set_header Connection "";

        # Cabeçalhos padrão de proxy
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Repasse de dados do certificado do cliente para o backend
        proxy_set_header X-SSL-Client-Verify $ssl_client_verify;
        proxy_set_header X-SSL-Client-DN $ssl_client_s_dn;
        proxy_set_header X-SSL-Client-Serial $ssl_client_serial;
        proxy_set_header X-SSL-Client-Fingerprint $ssl_client_fingerprint;
    }
}

Validação sintática e recarregamento dos serviços

Antes de aplicar as diretivas em produção, teste a integridade das instruções carregadas pelo interpretador de arquivos do Nginx:

sudo nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Com a sintaxe confirmada sem falhas de carregamento de biblioteca, recarregue a instância do serviço através do systemctl:

sudo systemctl reload nginx

Testando o handshake e verificando requisições

A validação operacional de um proxy reverso com mTLS deve ser realizada tanto simulando um cliente ilegítimo quanto comprovando a identificação do portador da chave assinada. Essa verificação garante que requisições desprovidas do certificado correto sejam descartadas antes de atingir o backend.

Primeiro, realize um teste de conexão via curl sem fornecer certificados de cliente:

curl -I https://seudominio.com.br/

HTTP/2 400 
server: nginx
date: Fri, 28 Mar 2026 10:15:30 GMT
content-type: text/html
content-length: 220

<html>
<head><title>400 No required SSL certificate was sent</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>No required SSL certificate was sent</center>
<hr><center>nginx</center>
</body>
</html>

Agora, execute a requisição fornecendo explicitamente a chave privada e o certificado assinado pela Autoridade Certificadora interna:

curl -s -o /dev/null -w "%{http_code}\n" --cert cliente1.crt --key cliente1.key https://seudominio.com.br/

200

O código 200 confirma que o handshake bidirecional foi validado com sucesso e a requisição foi repassada para a aplicação interna, acompanhada dos cabeçalhos personalizados de identidade X.509.

Problemas comuns e como resolver

Sintoma: Erro 400 "No required SSL certificate was sent"

Causa: O cliente web (aplicação externa, curl ou navegador) tentou estabelecer uma conexão TLS sem apresentar um certificado de cliente, ou a biblioteca SSL do cliente não enviou a extensão durante o handshake.
Solução: Garanta que o cliente inclua seu certificado e chave privada na chamada HTTP. Caso esteja testando em navegadores, o arquivo PKCS#12 (.p12 ou .pfx) precisa ser importado diretamente no repositório de certificados pessoais do sistema operacional ou do próprio navegador.

Sintoma: Erro 400 "The SSL certificate error" com verificação falhando no log

Causa: O Nginx rejeitou o certificado do cliente porque a assinatura não pertence à CA definida na diretiva ssl_client_certificate, ou a cadeia intermediária não foi incluída.
Solução: Abra o log de erros do Nginx com tail -f /var/log/nginx/error.log. Se o log acusar certificate verify failed, confira se o arquivo indicado em ssl_client_certificate contém todos os certificados intermediários e a raiz da CA concatenados. Ajuste a diretiva ssl_verify_depth para um valor maior (ex.: 2 ou 3) caso utilize certificados intermediários.

Sintoma: Erro de timeout ou falha de resolução ao conectar no backend

Causa: O upstream configurado no bloco proxy_pass não está escutando na porta designada ou o firewall local impede a comunicação interna.
Solução: Verifique o status da aplicação interna com o comando ss -tuln | grep 8080. Certifique-se de que o backend está ativo e configurado para aceitar conexões no loopback (127.0.0.1).

Perguntas frequentes sobre Nginx Reverse Proxy com autenticação mútua TLS

O que é autenticação mútua TLS (mTLS) no Nginx?

A autenticação mútua TLS é um processo em que cliente e servidor validam mutuamente seus certificados digitais durante o handshake criptográfico. No Nginx, isso garante que apenas conexões portando um certificado emitido por uma autoridade certificadora confiável tenham acesso à aplicação.

Qual a diferença entre SSL comum e autenticação mútua TLS?

No SSL/TLS tradicional (unilateral), apenas o cliente verifica a autenticidade do servidor web antes de criptografar a conexão. Na autenticação mútua TLS (mTLS), o servidor também exige e verifica ativamente o certificado de cliente, impedindo acessos não autorizados mesmo antes de processar requisições HTTP.

Qual diretiva ativa a verificação de certificados no Nginx?

A diretiva ssl_verify_client ativa a verificação de clientes quando definida como 'on', tornando o certificado de cliente obrigatório. Ela trabalha em conjunto com ssl_client_certificate, que aponta para o arquivo contendo a cadeia da Autoridade Certificadora autorizada.

Como repassar os dados do certificado do cliente para o backend?

O Nginx permite repassar variáveis TLS nativas para o servidor de destino através de cabeçalhos HTTP usando diretivas proxy_set_header. As variáveis mais comuns são $ssl_client_s_dn (Subject DN), $ssl_client_serial e $ssl_client_verify.

Conclusão

• Mantenha a chave privada da sua Autoridade Certificadora (ca.key) com permissões restritivas e fora de diretórios expostos publicamente.
• Implemente revogação ativa utilizando listas CRL através da diretiva ssl_crl para cancelar certificados de clientes comprometidos sem precisar refazer a CA.
• Valide nos logs de auditoria do backend o recebimento correto do cabeçalho X-SSL-Client-Verify para assegurar que apenas requisições aprovadas executem rotinas críticas.

Leia também

• DNS Registro.br com Proxy Reverso Nginx sem queda
• Como configurar webhooks do WhatsApp com proxy seguro em VPS
• Guia para Configurar Limite de Taxa (Rate Limiting) no Nginx em VPS Linux e Servidor Dedicado

Precisa de ajuda com Nginx Reverse Proxy com autenticação mútua TLS?

Garanta infraestrutura com alta capacidade de processamento criptográfico, tráfego isolado e latência mínima para os proxies reversos e APIs corporativas da sua empresa.

Conheça os Planos de Servidor VPS da AviraHost