Publicado em: Fevereiro 2026 | Categoria: Segurança API | Tempo de leitura: ~20 min

mTLS e Segurança Enterprise para APIs de Assinatura Digital

Q: O mTLS é obrigatório para APIs de assinatura digital no Brasil?

Depende do setor regulado. Para participantes do Open Finance Brasil, o BACEN exige mTLS nas APIs. Outros reguladores, como a CVM (valores mobiliários) e a ANS (saúde suplementar), exigem controles fortes de segurança e autenticação, nos quais o mTLS é prática recomendada. Mesmo quando não obrigatório, mTLS é considerado uma best practice para APIs que manipulam documentos legalmente vinculantes.

Q: Com que frequência devo rotacionar certificados mTLS?

A recomendação é rotacionar certificados a cada 90-365 dias, dependendo da criticidade. O Open Finance Brasil exige validade máxima de 1 ano. Automatize a rotação com ferramentas como cert-manager (Kubernetes) ou AWS ACM PCA para evitar interrupções por certificados expirados. Implemente alertas de expiração com 30, 15 e 7 dias de antecedência.

Q: O que acontece se um certificado mTLS for comprometido?

Você deve revogá-lo imediatamente adicionando-o à CRL (Certificate Revocation List) ou atualizando o OCSP responder. Em seguida, emita um novo certificado, atualize a aplicação cliente e audite todos os acessos realizados com o certificado comprometido. Ter um processo de revogação documentado e testado regularmente é tão importante quanto o próprio mTLS.

Q: O mTLS impacta a performance da API?

O handshake mTLS adiciona uma latência de 1-3ms em comparação ao TLS unidirecional, devido à troca e validação de certificados em ambos os lados. Em cenários de alto volume, use TLS 1.3 session resumption e connection pooling para minimizar o impacto. Na prática, o overhead é negligível para a maioria das aplicações enterprise.

Q: Como testar mTLS em ambiente de desenvolvimento?

Gere certificados autoassinados com OpenSSL para sua CA interna, servidor e cliente (como demonstrado neste artigo). Use curl com os flags --cert e --key, ou configure bibliotecas HTTP (requests em Python, axios em Node.js) para enviar o certificado do cliente. Ferramentas como mkcert e step-ca facilitam a criação de PKI local para testes.

Quando uma API manipula documentos legalmente vinculantes — contratos, procurações, laudos, notas promissórias — o custo de uma violação vai além do financeiro: envolve responsabilidade civil, danos reputacionais e multas regulatórias. Nesse cenário, a segurança não pode se limitar a um token Bearer em um header HTTP. É preciso garantir, na camada de transporte, que apenas aplicações conhecidas e autorizadas consigam sequer estabelecer uma conexão.

Essa é a proposta do mTLS (mutual Transport Layer Security): antes de qualquer troca de dados, cliente e servidor apresentam certificados digitais um ao outro, criando um canal mutuamente autenticado. Neste artigo, vamos explorar como o mTLS funciona, quando ele é exigido pela regulamentação brasileira, como implementá-lo na prática e como combiná-lo com OAuth2 e uma arquitetura Zero Trust para proteger APIs de assinatura digital de ponta a ponta.

Público-alvo deste artigo: arquitetos de software, engenheiros de plataforma, CTOs e equipes de compliance que avaliam ou implementam integrações enterprise com APIs de assinatura digital.

TLS vs mTLS: Autenticação Unidirecional vs Autenticação Mútua

Para entender o mTLS, é preciso primeiro entender o TLS convencional que protege praticamente toda comunicação web hoje.

TLS convencional (unidirecional)

No handshake TLS padrão, apenas o servidor apresenta um certificado. O cliente (navegador, aplicação) valida esse certificado contra uma CA (Certificate Authority) confiável, estabelecendo que está realmente se comunicando com o servidor correto. Entretanto, o servidor não tem nenhuma garantia criptográfica sobre quem é o cliente.

# Fluxo TLS convencional (simplificado)

Cliente  ──────── ClientHello ────────────>  Servidor
Cliente  <──────── ServerHello + Certificado ──  Servidor
Cliente  ──────── Valida certificado do servidor
Cliente  ──────── Key Exchange ────────────>  Servidor
         <═══════ Canal criptografado ═══════>

# Resultado: cliente sabe quem e o servidor
#            servidor NAO sabe quem e o cliente

mTLS (autenticação mútua)

No mTLS, o handshake inclui uma etapa adicional: o servidor solicita um certificado do cliente (CertificateRequest) e o valida contra uma CA confiável antes de concluir a conexão. Se o cliente não apresentar um certificado válido, a conexão é recusada — antes mesmo de chegar à camada de aplicação.

# Fluxo mTLS (simplificado)

Cliente  ──────── ClientHello ────────────>  Servidor
Cliente  <──────── ServerHello + Certificado ──  Servidor
Cliente  <──────── CertificateRequest ────────  Servidor
Cliente  ──────── Certificado do Cliente ──>  Servidor
         ──────── Valida certificado do servidor
                                                Servidor ──── Valida certificado do cliente
Cliente  ──────── Key Exchange ────────────>  Servidor
         <═══════ Canal mutuamente autenticado ═══>

# Resultado: cliente sabe quem e o servidor
#            servidor SABE quem e o cliente

Tabela comparativa: TLS vs mTLS

Característica	TLS convencional	mTLS
Autenticação do servidor	Sim	Sim
Autenticação do cliente	Não (depende de camada de aplicação)	Sim (na camada de transporte)
Proteção contra clientes não autorizados	Fraca (qualquer um pode conectar)	Forte (conexão recusada sem certificado válido)
Complexidade de implementação	Baixa	Média (requer PKI e gestão de certificados)
Overhead de performance	Baseline	+1-3ms no handshake
Conformidade regulatória (BACEN, CVM)	Insuficiente para setores regulados	Atende requisitos de Open Finance, CVM etc.
Caso de uso típico	Websites, apps públicos, SaaS B2C	APIs B2B, Open Banking, integrações enterprise, APIs de assinatura digital

Quando o mTLS é Exigido: Requisitos Regulatórios Brasileiros

No Brasil, diversos reguladores exigem ou recomendam fortemente o uso de mTLS para APIs que tratam dados sensíveis ou operações legalmente vinculantes. Se sua integração de assinatura digital toca algum desses setores, mTLS deixa de ser uma “boa prática” e passa a ser um requisito de compliance.

Regulador / Framework	Exigência de mTLS	Detalhes
BACEN – Open Finance Brasil	Obrigatório	Todas as APIs do ecossistema Open Finance exigem mTLS com certificados emitidos pela ICP-Brasil ou por CAs reconhecidas pelo diretório de participantes. Resolução BCB nº 32/2020.
CVM – Valores Mobiliários	Obrigatório para sistemas críticos	A Resolução CVM 35/2021 (sucessora da Instrução 505) exige controles fortes de segurança e autenticação para intermediários. mTLS atende esse requisito para comunicação API-to-API.
ANS – Saúde Suplementar	Segurança forte exigida	O padrão TISS (Troca de Informações na Saúde Suplementar) exige assinatura digital das mensagens com certificado ICP-Brasil (e-CNPJ), criptografia e autenticação na troca entre operadoras e prestadores — contexto em que o mTLS é prática recomendada.
LGPD – Dados Pessoais	Implícito (medidas técnicas adequadas)	A LGPD (Lei 13.709/2018, art. 46) exige “medidas de segurança, técnicas e administrativas” proporcionais ao risco. Para APIs que tratam dados pessoais em escala, mTLS é considerado proporcional.
ICP-Brasil – Infraestrutura de Chaves Públicas	Compatível	Certificados ICP-Brasil (A1/A3) podem ser usados como certificados de cliente em mTLS, unificando autenticação de transporte e assinatura digital.

Nota prática: mesmo que sua empresa não esteja diretamente regulada pelo BACEN ou CVM, se você integra com parceiros nesses ecossistemas (bancos, fintechs, corretoras), eles provavelmente exigirão mTLS como pré-requisito para conexão às suas APIs.

Implementação Prática: Configurando mTLS com uma API de Assinatura

Vamos percorrer o fluxo completo de implementação: geração de certificados, configuração do servidor e teste da conexão. Usaremos OpenSSL para os certificados e Nginx como proxy reverso, que é o cenario mais comum em produção.

Passo 1: Criar sua CA interna (ou usar uma CA corporativa)

Para ambientes enterprise, você pode usar uma CA privada. Em produção, considere AWS Private CA, HashiCorp Vault PKI ou uma CA ICP-Brasil.

# Gerar a chave privada da CA
openssl genrsa -aes256 -out ca-key.pem 4096

# Gerar o certificado autoassinado da CA (validade: 10 anos)
openssl req -new -x509 -sha256 -key ca-key.pem \
  -out ca-cert.pem -days 3650 \
  -subj "/C=BR/ST=SP/L=Sao Paulo/O=SuaEmpresa/CN=SuaEmpresa Internal CA"

Passo 2: Gerar o CSR e certificado do cliente

Cada aplicação que consumirá a API precisa de seu próprio certificado, permitindo identificação e revogação granular.

# Gerar chave privada do cliente
openssl genrsa -out client-key.pem 2048

# Gerar CSR (Certificate Signing Request)
openssl req -new -key client-key.pem -out client.csr \
  -subj "/C=BR/ST=SP/O=SuaEmpresa/CN=api-client-producao"

# Assinar o CSR com a CA (validade: 1 ano)
openssl x509 -req -in client.csr \
  -CA ca-cert.pem -CAkey ca-key.pem \
  -CAcreateserial -out client-cert.pem \
  -days 365 -sha256

# Verificar o certificado gerado
openssl x509 -in client-cert.pem -text -noout

Passo 3: Configurar o Nginx como proxy reverso com mTLS

# /etc/nginx/conf.d/api-assinatura-mtls.conf

server {
    listen 443 ssl;
    server_name api.suaempresa.com.br;

    # Certificado do servidor (TLS padrao)
    ssl_certificate     /etc/nginx/ssl/server-cert.pem;
    ssl_certificate_key /etc/nginx/ssl/server-key.pem;

    # mTLS: CA confiavel para validar certificados de clientes
    ssl_client_certificate /etc/nginx/ssl/ca-cert.pem;
    ssl_verify_client on;
    ssl_verify_depth 2;

    # CRL para revogar certificados comprometidos
    ssl_crl /etc/nginx/ssl/ca-crl.pem;

    # TLS 1.3 apenas (maximo de seguranca)
    ssl_protocols TLSv1.3;
    ssl_prefer_server_ciphers on;

    # Propagar identidade do cliente para a aplicacao
    location /api/ {
        proxy_pass http://localhost:8080;
        proxy_set_header X-Client-CN $ssl_client_s_dn_cn;
        proxy_set_header X-Client-Serial $ssl_client_serial;
        proxy_set_header X-Client-Verify $ssl_client_verify;
    }
}

Passo 4: Testar a conexão com curl

# Requisicao com mTLS (apresentando certificado do cliente)
curl -v \
  --cert client-cert.pem \
  --key client-key.pem \
  --cacert ca-cert.pem \
  https://api.suaempresa.com.br/api/v1/documentos

# Resposta esperada: 200 OK com dados do documento

# Requisicao SEM certificado do cliente (deve falhar)
curl -v --cacert ca-cert.pem \
  https://api.suaempresa.com.br/api/v1/documentos

# Resposta esperada: 400 Bad Request ou
# SSL handshake failure (alert 40: handshake_failure)

Dica para times de QA: mantenha um conjunto de certificados de teste (válido, expirado, revogado, CN errado) para validar todos os cenários de falha do mTLS em seus testes automatizados.

Gestão de Certificados X.509: Ciclo de Vida Completo

O maior desafio do mTLS não é a configuração inicial — é a gestão contínua dos certificados. Um certificado expirado em produção é tão crítico quanto um servidor fora do ar. Veja as fases do ciclo de vida e como automatizá-las.

1. Emissão (Issuance)

Defina uma política de nomeação para o CN (Common Name) — ex.: api-client-{ambiente}-{sistema}
Registre metadata: sistema proprietário, equipe responsável, data de emissão, data de expiração
Armazene chaves privadas em HSM ou cofre de segredos (Vault, AWS Secrets Manager)
Nunca envie chaves privadas por e-mail, Slack ou repositórios Git

2. Rotação (Rotation)

Defina a validade máxima (90-365 dias, conforme criticidade)
Automatize com cert-manager (Kubernetes), AWS ACM PCA, ou scripts cron
Implemente rotacao sem downtime: o servidor deve aceitar o certificado antigo e o novo durante um período de transição (grace period)
Alerte com 30, 15 e 7 dias de antecedência antes da expiração

3. Revogação (Revocation)

Quando um certificado é comprometido ou um parceiro perde acesso autorizado, você precisa revogá-lo imediatamente. Existem dois mecanismos principais:

Mecanismo	CRL (Certificate Revocation List)	OCSP (Online Certificate Status Protocol)
Como funciona	Lista estática de certificados revogados, baixada periodicamente	Consulta em tempo real ao responder OCSP sobre o status de um certificado
Latência	Alta (depende do intervalo de publicação)	Baixa (consulta em tempo real)
Disponibilidade	Funciona offline (lista local)	Depende do responder estar online
Escala	Problemática com muitos certificados revogados	Escala melhor com OCSP Stapling
Recomendação	Usar como fallback	Preferível para ambientes enterprise

# Revogar um certificado e atualizar a CRL
openssl ca -revoke client-cert.pem \
  -keyfile ca-key.pem -cert ca-cert.pem

# Gerar CRL atualizada
openssl ca -gencrl \
  -keyfile ca-key.pem -cert ca-cert.pem \
  -out ca-crl.pem

# Recarregar Nginx para aplicar nova CRL
nginx -s reload

mTLS + OAuth2: Combinando Segurança de Transporte e Aplicação

Um erro comum é tratar mTLS e OAuth2 como alternativas mutuamente exclusivas. Na verdade, eles atuam em camadas complementares, e a combinação dos dois é o padrão gold standard para APIs enterprise.

Camada	Mecanismo	O que protege
Transporte (L4/L5)	mTLS	Identifica e autentica a aplicação cliente. Garante que apenas sistemas com certificados válidos possam conectar.
Aplicação (L7)	OAuth2 + JWT	Autoriza ações específicas: quais escopos, quais recursos, em nome de qual usuário.

RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication

A RFC 8705 define como vincular tokens OAuth2 ao certificado mTLS do cliente. O token emitido é “certificate-bound” — só pode ser usado pela aplicação que possui o certificado correspondente. Isso impede que um token roubado seja usado por outra aplicação.

# 1. Solicitar token OAuth2 com mTLS client authentication
curl -X POST https://auth.signdocs.com.br/oauth2/token \
  --cert client-cert.pem \
  --key client-key.pem \
  -d "grant_type=client_credentials" \
  -d "scope=documents:write signatures:create"

# Resposta: token certificate-bound
{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "cnf": {
    "x5t#S256": "hash-do-certificado-do-cliente"
  }
}

# 2. Usar o token para chamar a API de assinatura (com mTLS)
curl -X POST https://api.signdocs.com.br/v1/assinaturas \
  --cert client-cert.pem \
  --key client-key.pem \
  -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIs..." \
  -H "Content-Type: application/json" \
  -d '{
    "documento_id": "doc_abc123",
    "signatarios": [{"email": "assinante@empresa.com.br"}]
  }'

Com essa abordagem em duas camadas, mesmo que um atacante comprometa o token OAuth2, ele não conseguirá usá-lo sem o certificado mTLS correspondente — e vice-versa.

SignDocs: mTLS nativo como diferencial enterprise

Enquanto a maioria das plataformas de assinatura digital no mercado brasileiro oferece apenas autenticação via API key ou OAuth2, o SignDocs suporta mTLS nativamente em seus planos Enterprise. Isso significa que sua equipe pode ativar autenticação mútua de transporte em minutos, sem proxy intermediário, com gestão de certificados integrada ao painel da API.

Se sua integração precisa atender requisitos do BACEN, CVM ou Open Finance — ou se você simplesmente quer o mais alto nível de segurança para documentos legalmente vinculantes — o SignDocs é a única plataforma brasileira de assinatura com mTLS pronto para uso.

Arquitetura Zero Trust e o Papel do mTLS na Assinatura Digital

O modelo Zero Trust (“nunca confie, sempre verifique”) assume que nenhuma requisição é confiável por padrão — mesmo que venha de dentro da rede corporativa. O mTLS é um dos pilares fundamentais dessa arquitetura, pois garante verificação criptográfica de identidade em cada conexão.

Os 5 pilares do Zero Trust aplicados a APIs de assinatura

Verificar explicitamente: Cada requisição deve ser autenticada (mTLS + OAuth2) e autorizada (escopos, RBAC), independentemente de origem de rede.
Menor privilégio: Tokens OAuth2 com escopos mínimos (transactions:read vs transactions:write). Certificados mTLS por aplicação, não compartilhados entre sistemas.
Assumir violação: Projetar a API como se o perímetro já estivesse comprometido. Criptografar dados em repouso, segmentar micro-serviços, limitar blast radius.
Microsegmentação: Em arquiteturas de microserviços, usar mTLS também para comunicação interna (service mesh com Istio, Linkerd ou Consul Connect).
Monitoramento contínuo: Correlacionar logs de mTLS (qual certificado, qual CN, qual IP) com logs de aplicação (qual endpoint, qual ação, qual documento) para detecção de anomalias.

mTLS em service mesh: se sua arquitetura usa Kubernetes, ferramentas como Istio e Linkerd aplicam mTLS automaticamente entre todos os pods, sem alterações no código da aplicação. Isso é fundamental para proteger o tráfego lateral (east-west) entre microserviços de assinatura, webhooks e processamento de documentos.

Checklist de Hardening para APIs de Assinatura Digital

O mTLS é uma peça fundamental, mas a segurança enterprise exige múltiplas camadas. Abaixo, um checklist completo para proteger sua API de assinatura digital de ponta a ponta.

Controle	Descrição	Prioridade
mTLS	Autenticação mútua na camada de transporte. Certificados X.509 por aplicação cliente.	Crítica
OAuth2 + JWT	Autorização baseada em escopos na camada de aplicação. Tokens certificate-bound (RFC 8705).	Crítica
Rate limiting	Limitar requisições por certificado/token: ex. 100 req/min para assinatura, 1000 req/min para consulta. Retornar `429 Too Many Requests` com header `Retry-After`.	Alta
IP allowlisting	Restringir conexões a ranges de IP conhecidos. Combinar com mTLS para defesa em profundidade. Ideal para parceiros com IPs fixos.	Alta
Request signing (HMAC)	Assinar o corpo da requisição com HMAC-SHA256 para garantir integridade. Previne ataques de tamper no payload.	Média
Payload encryption (JWE)	Criptografar o corpo da requisição com JWE (JSON Web Encryption) para dados ultra-sensíveis. Útil quando há intermediarios (CDN, WAF) no caminho.	Média
Audit logging	Registrar cada operação: CN do certificado, token, IP, timestamp, endpoint, payload hash. Logs imutáveis com retenção de 5+ anos.	Crítica
Input validation	Validar todos os campos de entrada (schema JSON, tamanho máximo de upload, tipos MIME permitidos). Rejeitar payloads malformados antes do processamento.	Alta
CORS restritivo	Para APIs consumidas por frontends, configurar `Access-Control-Allow-Origin` com domínios explícitos. Nunca usar `*`.	Alta
Security headers	`Strict-Transport-Security`, `X-Content-Type-Options: nosniff`, `X-Frame-Options: DENY`, `Content-Security-Policy`.	Alta
Versionamento de API	Prefixo `/v1/`, `/v2/` com sunset dates publicados. Nunca quebrar contratos sem aviso prévio de 6+ meses.	Média

# Exemplo: headers de seguranca recomendados para API de assinatura

# Nginx configuration
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Cache-Control "no-store, no-cache, must-revalidate" always;

# Rate limiting por certificado CN
limit_req_zone $ssl_client_s_dn_cn zone=api_limit:10m rate=100r/m;

location /api/ {
    limit_req zone=api_limit burst=20 nodelay;
    limit_req_status 429;
    # ... proxy_pass config ...
}

Perguntas Frequentes sobre mTLS e Segurança de APIs

Qual a diferença entre TLS e mTLS?

No TLS convencional, apenas o servidor apresenta um certificado ao cliente (autenticação unidirecional). No mTLS (mutual TLS), ambos os lados apresentam certificados: o cliente autentica o servidor e o servidor autentica o cliente. Isso garante que apenas aplicações autorizadas, com certificados válidos emitidos por uma CA confiável, possam consumir a API de assinatura digital.

O mTLS é obrigatório para APIs de assinatura digital no Brasil?

Depende do setor regulado. Para participantes do Open Finance Brasil, o BACEN exige mTLS nas APIs. Outros reguladores, como a CVM (valores mobiliários) e a ANS (saúde suplementar), exigem controles fortes de segurança e autenticação, nos quais o mTLS é prática recomendada. Mesmo quando não obrigatório, mTLS é considerado uma best practice para APIs que manipulam documentos legalmente vinculantes.

Posso usar mTLS junto com OAuth2?

Sim, e essa é a abordagem recomendada. O mTLS atua na camada de transporte (identifica a aplicação cliente), enquanto o OAuth2 atua na camada de aplicação (autoriza escopos e permissões). A RFC 8705 define o padrão OAuth 2.0 Mutual-TLS Client Authentication, que vincula tokens ao certificado do cliente, impedindo o uso de tokens roubados por aplicações não autorizadas.

Com que frequência devo rotacionar certificados mTLS?

A recomendação é rotacionar certificados a cada 90-365 dias, dependendo da criticidade. O Open Finance Brasil exige validade máxima de 1 ano. Automatize a rotação com ferramentas como cert-manager (Kubernetes) ou AWS ACM PCA para evitar interrupções por certificados expirados. Implemente alertas de expiração com 30, 15 e 7 dias de antecedência.

O que acontece se um certificado mTLS for comprometido?

Você deve revogá-lo imediatamente adicionando-o à CRL (Certificate Revocation List) ou atualizando o OCSP responder. Em seguida, emita um novo certificado, atualize a aplicação cliente e audite todos os acessos realizados com o certificado comprometido. Ter um processo de revogação documentado e testado regularmente é tão importante quanto o próprio mTLS.

O mTLS impacta a performance da API?

O handshake mTLS adiciona uma latência de 1-3ms em comparação ao TLS unidirecional, devido à troca e validação de certificados em ambos os lados. Em cenários de alto volume, use TLS 1.3 session resumption e connection pooling para minimizar o impacto. Na prática, o overhead é negligível para a maioria das aplicações enterprise.

Como testar mTLS em ambiente de desenvolvimento?

Gere certificados autoassinados com OpenSSL para sua CA interna, servidor e cliente (como demonstrado neste artigo). Use curl com os flags --cert e --key, ou configure bibliotecas HTTP (requests em Python, axios em Node.js) para enviar o certificado do cliente. Ferramentas como mkcert e step-ca facilitam a criação de PKI local para testes.

Pronto para integrar com segurança enterprise?

O SignDocs é a única plataforma brasileira de assinatura digital com suporte nativo a mTLS, OAuth2 certificate-bound tokens e arquitetura Zero Trust. Proteja seus documentos com o mesmo nível de segurança exigido pelo Open Finance Brasil.

Comece grátis Fale com nossa equipe sobre a API Enterprise