Uma conexão TLS padrão criptografa o tráfego, mas não prova, na maioria dos cenários, quem o cliente realmente é. Senhas, chaves de API, allowlists de IP e controles baseados em token adicionam camadas de segurança, mas podem ser compartilhados, vazados, copiados ou usados no contexto errado. O mTLS, por outro lado, verifica que o cliente possui a chave privada, produzindo um sinal de identidade mais forte no nível de conexão.
Em APIs B2B, fluxos de pagamento, compartilhamento de dados de saúde, tráfego de dispositivos IoT e acesso a interfaces de gerenciamento, essa diferença é crítica. Cada parceiro, dispositivo ou administrador chega com seu próprio certificado; vida útil do certificado, cadeia de CA, CN, fingerprint e resultado de verificação são todos auditáveis. No entanto, exigir que cada aplicação analise essas informações de forma independente adiciona complexidade operacional.
Em implantações mTLS tradicionais, gerenciamento de bundle de CA, seleção de modo de verificação, códigos de erro, extração de campos de certificado e encaminhamento dessas informações para a aplicação são preocupações fragmentadas. Um ambiente pode exigir um certificado obrigatório enquanto outro precisa de modo optional durante uma transição. Cadeias de CA legadas, certificados de teste e migrações de parceiros exigem um equilíbrio delicado entre validação estrita e tolerância controlada.
A abordagem correta é gerenciar o mTLS como um perfil de serviço. Modo de verificação, arquivo CA, estratégia de erro de CA, encaminhamento de campos de certificado ao backend e políticas de acesso condicional do AAM devem todos viver no mesmo modelo.
A Autenticação de Certificado de Cliente TLS / mTLS do TR7 entrega esse modelo: extrai o certificado de cliente do controle em nível de conexão e o transforma em um objeto de identidade utilizável tanto para serviços de backend quanto para políticas de acesso.
O TR7 aplica a verificação mTLS junto com modo de verificação por serviço, gerenciamento de CA, encaminhamento de campos de certificado e política de acesso do AAM em um único modelo coeso.
Com os modos none, optional e required, cada serviço pode aplicar sua própria política mTLS. Os certificados podem ser tornados obrigatórios, mantidos opcionais durante uma transição ou desabilitados inteiramente para um determinado serviço.
Código de verificação, fingerprint SHA1, CN e campos adicionais do certificado podem ser mapeados para headers HTTP. O backend lê as informações de identidade diretamente sem analisar o certificado por conta própria.
Os headers de certificado podem ser analisados em campos como present, verified, verify, sha1 e cn. Mesmo quando a verificação falha, os dados do certificado podem ser registrados e passados ao motor de decisão de forma controlada.
Erros de validação de CA podem ser rejeitados inteiramente, tolerados em massa durante uma transição ou relaxados apenas para códigos de erro específicos. Isso permite que políticas de staging, migração de parceiros e produção coexistam no mesmo modelo mTLS.
A Autenticação de Certificado de Cliente TLS / mTLS verifica, analisa, registra e compartilha o certificado de cliente com o backend — tudo na borda.
O TR7 gerencia o comportamento de autenticação de certificado de cliente de forma independente para cada serviço. No modo none, nenhum certificado é solicitado. No modo optional, um certificado é analisado quando apresentado; se ausente, a conexão pode continuar. No modo required, qualquer conexão que não apresente um certificado é rejeitada. Essa estrutura proporciona segurança estrita em produção, flexibilidade em staging e rollout gradual durante migração. Serviços diferentes na mesma plataforma podem impor requisitos mTLS diferentes.
O TR7 pode validar certificados de cliente contra arquivos CA por serviço. A cadeia de CA do Parceiro A pode ser usada em um serviço enquanto a cadeia do Parceiro B é aplicada a outro. Essa separação permite que diferentes parceiros de negócios ou grupos de dispositivos sejam gerenciados isoladamente no mesmo ADC, sem depender de uma única lista de CA global. Uma raiz de confiança distinta é definida por serviço.
O TR7 pode entregar o status de verificação do certificado de cliente ao backend via headers como x-ssl-verify. Verificação bem-sucedida, ausência de certificado ou uma falha de verificação específica é visível para a aplicação. O backend pode tomar decisões com base no status mTLS da conexão sem lidar com a stack TLS ou o parsing de certificado.
O TR7 pode extrair o Common Name e o fingerprint SHA1 do certificado de cliente e encaminhá-los como headers ao backend. O CN pode servir como identificador de parceiro, dispositivo, usuário ou serviço. O fingerprint SHA1 oferece uma chave prática para cenários de allowlisting, auditoria, correspondência ou revogação rápida. Os fingerprints são normalizados para que diferentes estilos de formatação não produzam valores de identidade diferentes.
caErrorStrategy permite diferentes respostas a falhas de validação de CA. ignoreAll pode tolerar todos os erros de CA em cenários temporários de debug ou migração; manualIgnoreList limita a tolerância a códigos de erro de validação específicos. Em produção, essa flexibilidade pode ser desabilitada para impor tolerância zero. O modelo cria um equilíbrio controlado entre segurança estrita e necessidades reais de migração.
O TR7 não apenas solicita certificados de clientes que chegam — ele também pode apresentar um certificado de cliente ao se conectar a um serviço de backend. A conexão voltada ao backend pode ser configurada com verificação obrigatória, um arquivo CA e um certificado de cliente do ADC. Isso habilita políticas de confiança TLS independentes tanto no leg cliente-para-TR7 quanto no TR7-para-backend. O tráfego pode ser inspecionado na borda enquanto a conexão interna permanece totalmente segura.
Um certificado de cliente é um sinal de identidade forte, mas não precisa carregar a decisão de acesso completa por conta própria. O TR7 pode usar dados de certificado como uma entrada para as políticas de acesso condicional do AAM. Certificado, endereço IP, postura de dispositivo, grupo de usuário, horário e status de MFA podem ser todos avaliados juntos. O mTLS se torna um componente de uma decisão de acesso zero-trust mais ampla.
Uma verificação de certificado bem-sucedida não torna automaticamente uma requisição segura — os controles de conteúdo e volume continuam a ser aplicados. O TR7 executa a camada de identidade mTLS junto com análise de WAAP, DDoS e comportamento de bots. O mTLS estabelece quem é o cliente; o WAAP avalia o que a requisição está fazendo; a camada DDoS avalia o volume de tráfego. Todos os três controles podem operar juntos na frente do mesmo serviço.
No modo optional, parceiros que apresentam um certificado são processados com identidade mTLS enquanto clientes cuja migração de certificado ainda não foi concluída podem passar para um mecanismo de autenticação alternativo. Esse padrão permite que grandes migrações B2B sejam implantadas com segurança sem forçar todos os parceiros para mTLS no mesmo dia. O backend pode decidir entre fluxos baseados em certificado e baseados em chave de API com base na presença do header x-ssl-verify. Após a conclusão da migração, o serviço pode ser movido para o modo required.
Para conexões mTLS, campos como subject do certificado, emissor, janela de validade, resultado de verificação e fingerprint podem ser registrados. Em um SIEM, fica claro qual parceiro acessou qual serviço com qual certificado. Eventos como certificado expirado, auto-assinado ou falhas de emissor podem ser analisados separadamente. Esses registros produzem uma trilha de auditoria robusta para conformidade, investigação de incidentes e auditoria de parceiros.
A operação mTLS é coberta de ponta a ponta: comportamento de bind, códigos de verificação, detecção de certificado baseada em header, normalização de fingerprint, escopo de arquivo CA e validação de SNI/Host.
O comportamento de verificação none, optional ou required é definido no ponto de entrada do serviço. No modo required, uma conexão de cliente que não apresenta certificado é rejeitada. No modo optional, um certificado é analisado se presente; se ausente, a requisição pode continuar para um fluxo de política alternativo.
O resultado de verificação do certificado pode ser expresso como um código de erro numérico. Zero representa verificação bem-sucedida; outros valores indicam condições como emissor não encontrado, certificado expirado, certificado ainda não válido ou certificado auto-assinado. Esse valor pode ser encaminhado ao backend como um header.
Se x-ssl-verify está vazio ou indica que nenhum certificado foi usado, o cliente é tratado como não tendo apresentado nenhum certificado. Um valor de 0 significa que o certificado foi verificado com sucesso. Qualquer outro valor significa que os dados do certificado podem estar presentes, mas a verificação falhou — isso pode ser tratado separadamente em logs e decisões de política.
Os valores de fingerprint podem chegar com capitalização mista e formatação separada por dois pontos. O TR7 normaliza o valor para que operações de comparação e allowlist funcionem de forma consistente. O mesmo certificado não é tratado como uma identidade diferente por causa de uma diferença de formatação.
Cada serviço pode usar seu próprio bundle de CA, o que permite que as raízes de confiança sejam isoladas entre parceiros, grupos de dispositivos e serviços internos. As mudanças de CA devem ser planejadas considerando o impacto no serviço e devem ser auditadas.
Em serviços que usam mTLS, a validação de SNI e Host pode ser habilitada além da verificação de certificado. Quando certificado, SNI e Host são avaliados juntos, a identidade da requisição, o domínio alvo e a intenção de roteamento HTTP são todos validados em combinação. Esse modelo ajuda a reduzir o risco de abuso no estilo domain fronting.
Cada parceiro se conecta à API com um certificado de cliente único. O TR7 registra valores de CN e fingerprint SHA1, os encaminha ao backend e torna as decisões de auditoria e rate-limit por parceiro mais simples.
Cada dispositivo pode se conectar ao TR7 usando um certificado único carregado na fábrica. O número de série do dispositivo é transportado no campo CN, e o allowlisting por fingerprint torna os fluxos de revogação e restrição de acesso mais rápidos de gerenciar.
Organizações de saúde podem usar mTLS ao compartilhar dados com sistemas de provedor para autenticar no nível de conexão. Quando um certificado expira ou a verificação falha, o acesso pode ser cortado automaticamente sem intervenção manual.
Administradores de sistema podem se conectar à interface de gerenciamento do TR7 usando um certificado de cliente. Quando combinado com MFA e postura de dispositivo via AAM, um único laptop, um certificado específico e uma identidade de administrador verificada são todos confirmados juntos.
Verifique o certificado de cliente na borda, encaminhe-o ao seu backend e combine-o com a política do AAM. Vamos fazer uma configuração ao vivo nos seus próprios serviços.