API Gateway passa a aceitar certificado de cliente próprio para mTLS de backend

A AWS publicou um tutorial completo mostrando como importar um certificado assinado por CA própria (ou pela AWS Private CA) no ACM e usá-lo no handshake mTLS de saída das APIs REST do Amazon API Gateway, sem depender do certificado autoassinado padrão.

A AWS publicou um tutorial completo mostrando como importar um certificado assinado por CA própria (ou pela AWS Private CA) no ACM e usá-lo no handshake mTLS de saída das APIs REST do Amazon API Gateway, sem depender do certificado autoassinado padrão.

Se você mantém APIs REST no Amazon API Gateway na frente de um backend corporativo ou de parceiro, já deve ter esbarrado nessa limitação: o Gateway só conseguia apresentar um certificado SSL autoassinado na conexão de saída para mTLS. Backend que exige validação contra uma CA corporativa específica rejeitava esse certificado e o handshake mútuo falhava sempre. A AWS publicou um tutorial detalhado mostrando como resolver isso trazendo seu próprio certificado de cliente para o handshake mTLS de backend das APIs REST.

Para quem trabalha com IAM e PKI corporativa, esse é o tipo de lacuna que travava migração de gateway legado. Se a política interna exige que todo certificado de cliente venha de uma CA aprovada (e auditável), um certificado autoassinado gerado pela plataforma simplesmente não serve, e o handshake mTLS falha sem alternativa. Agora dá para usar um certificado de terceiros importado no AWS Certificate Manager (ACM) ou um emitido pela AWS Private Certificate Authority, e configurar o ARN desse certificado no estágio da API REST.

O que muda na prática

Antes, o fluxo de saída do API Gateway não tinha CA por trás: o backend não tinha como confiar no certificado apresentado. Agora, o parâmetro ClientCertificateId no estágio da API REST aponta para um certificado ACM, e o API Gateway apresenta esse certificado específico durante o handshake TLS de saída. Isso cobre dois cenários comuns: migração de APIs que vinham de um gateway legado com certificado de CA conhecida, e mandatos internos de PKI que exigem cadeia de confiança auditável.

A arquitetura da demonstração

O tutorial da AWS usa uma stack com AWS Private Certificate Authority configurada como hierarquia raiz-subordinada, emitindo tanto o certificado de cliente quanto o de servidor via ACM. O backend roda em Amazon ECS no Fargate, com um sidecar NGINX fazendo o handshake mTLS de entrada e uma aplicação validadora separada cuidando da lógica de negócio.

O caminho de uma requisição segue esta sequência:

1. O cliente chama a API REST exposta pelo API Gateway.
2. O Gateway abre a conexão de saída para um Network Load Balancer e apresenta o certificado ACM configurado no estágio.
3. O NLB faz passthrough TCP na porta 443 até o Fargate, sem terminar TLS.
4. O NGINX sidecar apresenta o certificado de servidor e valida o certificado de cliente contra um pacote de CA (cadeia raiz + subordinada) montado no container.
5. Depois da validação, o NGINX repassa a requisição e os detalhes do certificado por HTTP local para a aplicação validadora, que reconfere a janela de validade, checa o common name numa lista de permissões e devolve um JSON.

O sidecar NGINX não é obrigatório para o recurso funcionar: ele existe na demo para separar quem faz o handshake mTLS (infraestrutura) de quem decide a regra de negócio (aplicação). Em um ambiente real, essa separação facilita auditoria: o time de segurança revisa a configuração do NGINX sem mexer no código da aplicação.

Reproduzindo o teste negativo

O repositório de exemplo está em github.com/aws-samples/sample-api-backend-mtls. Depois de clonar e compilar as duas imagens de container (sidecar NGINX e aplicação validadora) com docker build e enviá-las para repositórios no Amazon ECR, o primeiro deploy sobe a stack inteira sem certificado de cliente configurado:

sam build
sam deploy \
 --stack-name $STACK_NAME \
 --resolve-s3 \
 --capabilities CAPABILITY_IAM \
 --parameter-overrides \
 NginxRepositoryUri="$NGINX_REPO_URI" \
 ValidatorRepositoryUri="$VALIDATOR_REPO_URI" \
 EnableOutboundMtls=false

Com EnableOutboundMtls=false, invocar a API frontal com curl -v "$FRONT_API_URL" retorna HTTP/2 400 com o corpo 400 No required SSL certificate was sent. É o NGINX recusando a conexão porque o Gateway não apresentou certificado de cliente algum no handshake de saída. Esse teste negativo é o jeito mais direto de confirmar que a validação de CA está realmente ativa no backend antes de confiar cegamente no caminho feliz.

Ativando o certificado próprio

O segundo deploy muda um único parâmetro:

EnableOutboundMtls=true

Com isso, o estágio da API REST passa a ter o ClientCertificateId apontando para o certificado ACM emitido pela hierarquia de CA da demo. Na próxima chamada, o handshake mTLS é concluído com sucesso e a API retorna HTTP 200. A configuração do NGINX que faz essa verificação é simples:

server {
 listen 443 ssl;
 ssl_certificate /etc/nginx/certs/server.crt;
 ssl_certificate_key /etc/nginx/certs/server.key;
 ssl_client_certificate /etc/nginx/certs/ca_bundle.pem;
 ssl_verify_client on;
 ssl_verify_depth 2;
 ssl_protocols TLSv1.2;
}

Repare no ssl_verify_client on combinado com ssl_client_certificate apontando para o bundle de CA (raiz + subordinada): é essa linha que rejeitava a conexão no primeiro teste e que agora valida o certificado que o Gateway passou a apresentar.

Rotação de certificado sem downtime

Para quem administra PKI, o ponto mais relevante do anúncio não é o primeiro deploy, é a rotação. Quando o certificado muda no ACM, o API Gateway detecta a atualização e propaga o novo certificado sozinho, sem exigir reimplantação do estágio e sem derrubar a API. A AWS é direta sobre a ressalva: a propagação é eventualmente consistente, então durante a janela de rotação o backend pode receber brevemente o certificado antigo ou o novo.

Isso importa porque qualquer CA corporativa com certificado de cliente de curta validade (prática comum em ambientes que seguem mandato interno de PKI) depende dessa rotação automática para não gerar janela de indisponibilidade a cada renovação. Vale configurar alarme usando as notificações de expiração de certificado que o ACM emite via Amazon EventBridge, para saber com antecedência quando um certificado está perto de vencer, em vez de descobrir pelo handshake falhando em produção.

IAM mínimo para quem vai operar isso

O principal do IAM usado para rodar o sam deploy e gerenciar os recursos da stack precisa ter permissões para fazer as chamadas de serviço da AWS necessárias, cobrindo ACM, API Gateway, ECS, ECR e Private CA. A AWS recomenda seguir o princípio do menor privilégio, mas o tutorial não detalha uma política JSON específica nem lista as ações exatas necessárias para cada serviço; vale montar essa política com base nos recursos que a stack efetivamente cria, evitando permissões amplas como * em Action ou Resource.

Quanto à região, o exemplo do tutorial usa us-east-1 ao definir a variável REGION. Garanta que a AWS Private CA e o ACM estejam provisionados na mesma região do estágio da API, para evitar tráfego cross-region desnecessário e complicação de auditoria.

O que fica em aberto

O recurso resolve a apresentação de certificado de cliente no handshake de saída, mas a validação do lado do backend continua sendo responsabilidade de quem opera o serviço atrás do API Gateway, seja NGINX, seja outro componente. A AWS também não detalha, na publicação, limite de tamanho de cadeia de certificado nem comportamento em caso de certificado revogado via CRL ou OCSP no backend; vale testar esse cenário antes de levar para produção, principalmente se a política de segurança da empresa exige checagem de revogação.

Para quem quer reproduzir, o repositório sample-api-backend-mtls e a documentação de referência "Present client certificates to backend services with mutual TLS in API Gateway" têm o passo a passo completo, incluindo o processo de limpeza da stack com sam delete e a exclusão dos repositórios ECR ao final do teste.

Fonte: AWS Brasil — Blog