SBC mTLS: autenticação Mutual TLS para sinalização SIP

O TLS padrão prova que o seu Controlador de Borda de Sessão (SBC) é o dispositivo que seu hostname afirma ser. Ele não prova nada sobre o dispositivo na outra ponta da conexão. Para uma borda SIP exposta à internet, isso resolve a metade errada do problema. Qualquer pessoa na internet pública pode abrir um socket TCP na porta 5061, completar um handshake TLS unidirecional com o seu certificado e começar a enviar mensagens INVITE. O TLS protege o canal, mas não autentica o peer.

O Mutual TLS, geralmente escrito como mTLS, fecha essa lacuna. Ambos os endpoints apresentam certificados X.509 durante o handshake, e ambos validam o certificado recebido contra sua própria política de confiança. Se o peer não apresentar um certificado, ou apresentar um que o seu SBC não confia, o handshake falha antes que um único byte SIP seja trocado. Este é o mecanismo que a maioria das operadoras Tier 1 exige em interconexões, e o mecanismo que vem substituindo de forma constante as allowlists de IP como limite de confiança padrão entre peers SIP.

Este guia vai além da definição superficial. Ele explica o que realmente acontece durante o handshake mTLS, a diferença entre truststore e keystore (um dos pontos mais consistentemente confusos em implantações reais), os quatro modelos de confiança entre os quais você pode escolher, por que a confiança entre dois peers quase nunca é simétrica, como a verificação de revogação funciona na prática, e os modos de falha específicos do mTLS em relação ao TLS em geral. Para o passo a passo de configuração TLS e SRTP por tronco que fundamenta tudo isso, consulte o Guia de configuração SBC TLS e SRTP.

O que o TLS unidirecional deixa em aberto

Em um handshake TLS padrão com autenticação de servidor, apenas um lado prova sua identidade. Quando um cliente SIP abre uma conexão TLS com o seu SBC na porta 5061, o SBC apresenta seu certificado, o cliente valida esse certificado contra seu truststore, e o túnel criptografado é estabelecido. O cliente nunca precisa provar quem é. Do ponto de vista do SBC, qualquer dispositivo que completar o handshake pode começar a enviar mensagens SIP.

Isso funciona para a web de consumo, onde o servidor é o ativo que vale a pena proteger e o cliente é um navegador cuja identidade é aplicada em camadas superiores da pilha (nomes de usuário, senhas, cookies). Não funciona para uma borda SIP, onde o servidor é o ativo que vale a pena proteger e o cliente é outro elemento de rede sem nenhum humano no teclado. A autenticação digest SIP existe, mas opera acima da camada TLS e não substitui a autenticação do dispositivo host.

O risco prático é direto. Um atacante escaneia a internet, encontra seu SBC na porta 5061, abre uma conexão TLS e começa a sondar. Ele não pode descriptografar seu tráfego existente, mas pode iniciar chamadas SIP por conta própria. Se essas chamadas são completadas depende inteiramente da autenticação, allowlisting e políticas que você configurou acima do TLS. O mTLS empurra a fronteira de autenticação para dentro do próprio handshake, de modo que a conexão do atacante é rejeitada antes que a pilha SIP sequer a veja.

Como o handshake mTLS realmente funciona

O servidor solicita um certificado do cliente, o cliente fornece um, e ambos os lados validam o que recebem antes que qualquer dado de aplicação trafegue.

1. O ClientHello abre a conexão e oferece as versões TLS suportadas pelo cliente, cipher suites e extensões. Nenhum certificado é trocado ainda.
2. O ServerHello e Server Certificate seguem após o SBC selecionar uma cipher suite, e o SBC apresenta sua própria cadeia de certificados nesta etapa. Esta é a mesma etapa que você vê no TLS unidirecional.
3. Um CertificateRequest é enviado em vez de finalizar o handshake, solicitando que o cliente apresente seu próprio certificado. A mensagem inclui uma lista de Autoridades Certificadoras aceitáveis para que o cliente saiba qual de seus certificados escolher.
4. As mensagens de Certificate do cliente e CertificateVerify retornam juntas: o cliente retorna seu certificado (e a cadeia intermediária) junto com uma mensagem CertificateVerify contendo uma assinatura sobre a transcrição do handshake, feita com a chave privada que corresponde ao certificado. Isso prova que o cliente realmente possui a chave, não apenas uma cópia do certificado de outra pessoa.
5. A etapa de validação mútua acontece em ambos os lados simultaneamente. O SBC valida a cadeia do cliente contra seu truststore, verifica o período de validade, verifica a assinatura CertificateVerify e (se configurado) realiza uma verificação de revogação. O cliente realiza a mesma validação contra o certificado do SBC. Qualquer falha aborta o handshake com um alerta TLS.
6. As mensagens Finished são trocadas em ambos os lados, o canal de aplicação criptografado é aberto, e o tráfego SIP começa.

Duas implicações importam operacionalmente. Primeiro, o mTLS é bidirecional por construção: uma configuração incorreta em qualquer lado quebra a conexão, e a superfície de erro vive na camada TLS, não na camada SIP. Ferramentas como um trace SIP dirão que a chamada nunca iniciou; apenas uma captura no nível TLS (ou o log de erros TLS do SBC) dirá o porquê. Segundo, toda chamada bem-sucedida em um tronco protegido por mTLS já provou, na etapa de handshake, que o peer possui uma chave privada correspondente a um certificado que o seu SBC escolheu confiar. Essa é uma declaração muito mais forte do que “o IP de origem está na allowlist.”

As quatro peças de uma configuração mTLS

A maior confusão operacional sobre mTLS vem de colapsar conceitos distintos em um só. Existem quatro peças independentes, e cada uma vive em uma parte diferente da configuração do SBC.

Identidade do servidor é o certificado do próprio SBC e a chave privada correspondente, usado quando o SBC atua como servidor TLS (um peer está se conectando de entrada na porta 5061). O SAN deve incluir todos os FQDNs que os peers de entrada usarão para alcançá-lo. Para implantações multi-tenant, um certificado wildcard ou multi-SAN é comum; consulte o guia de SBC multi-tenant para Teams Direct Routing para o padrão de certificado wildcard que a Microsoft espera.

Identidade do cliente é o certificado que o SBC apresenta quando atua como cliente TLS (o SBC está iniciando uma conexão TLS de saída para uma operadora ou para o Teams). Este é frequentemente o mesmo certificado da identidade do servidor em implantações menores, e um certificado diferente em implantações maiores onde o tráfego de saída usa uma identidade dedicada. De qualquer forma, deve ser armazenado como um certificado mais a chave privada correspondente, não apenas um arquivo de certificado.

Truststore define quais Autoridades Certificadoras (ou certificados individuais de peers) o SBC aceitará ao validar um peer. Isso é independente da sua própria identidade. Um truststore que contém “qualquer CA pública que o sistema operacional confia” é permissivo demais para SIP, porque autoriza cada certificado Let’s Encrypt e DigiCert na internet a se comunicar com você. Um truststore SIP correto lista apenas as CAs que emitem certificados para seus peers reais.

Política por tronco vincula as três peças acima a troncos SIP específicos.

A confusão entre keystore e truststore vale a pena ser entendida porque produz uma classe específica de falha. Se o certificado e a chave privada do próprio SBC estiverem no truststore em vez do keystore, o SBC não tem identidade para apresentar: a pilha TLS tipicamente falha ao iniciar o listener, ou aborta o handshake com um handshake_failure genérico (alerta 40) antes que qualquer certificado seja trocado. Se o mTLS estiver configurado e a CA de um peer estiver no keystore em vez do truststore, o SBC não confiará no certificado que o peer apresenta durante a autenticação do cliente, e o handshake falha com unknown_ca (alerta 48).

Escolhendo um modelo de confiança

Depois de decidir exigir autenticação do cliente, você tem uma decisão separada sobre quais autoridades emitem os certificados que você aceitará. Existem quatro opções práticas, e a correta depende de quem é o peer e quanto controle você tem sobre a PKI dele.

O padrão com maior probabilidade de produzir surpresas é a abordagem ampla de CA raiz pública. Colocar “DigiCert Global Root G2” no seu truststore significa que o SBC aceitará qualquer certificado emitido pela DigiCert para qualquer sujeito, incluindo atores não intencionados. A defesa é aplicar validação de FQDN sobre a validação de CA: mesmo que o certificado encadeie até uma raiz confiável, rejeite-o a menos que o SAN corresponda ao FQDN com o qual o tronco deveria estar se comunicando.

O problema da confiança assimétrica: o exemplo do Microsoft Teams

A confiança entre dois peers em mTLS raramente é simétrica, e a documentação quase nunca diz isso explicitamente. Seu SBC confia em certificados emitidos por um conjunto específico de CAs; o peer confia em certificados emitidos por um conjunto diferente (geralmente sobreposto, mas não idêntico). Ambas as listas importam, ambas podem estar erradas independentemente, e uma conexão funciona apenas quando ambas as listas aceitam o certificado que o outro lado apresenta.

Uma implementação que vem ganhando popularidade é o Teams Direct Routing da Microsoft. O truststore da Microsoft no lado do Teams aceita certificados de uma lista publicada de CAs públicas (a lista é atualizada periodicamente, mais recentemente para a atualização de CA raiz de junho de 2026). Seu SBC, por sua vez, precisa confiar na CA que assina os certificados da própria Microsoft na interface do Teams (atualmente DigiCert Global Root G2, em breve também Microsoft RSA Root Certificate Authority 2017). Se você atualizar apenas o lado do SBC ou apenas o lado do Teams, o tronco quebra. Se esquecer completamente a nova raiz da Microsoft, o estabelecimento de chamadas não será mais possível. A confiança assimétrica é a razão pela qual a mudança de certificado do Teams está sendo anunciada com meses de antecedência.

A disciplina operacional que lida bem com isso é pensar na confiança mTLS por direção em vez de por tronco. Para cada direção (entrada do peer, saída para o peer), mantenha um registro de quais CAs o SBC confia, quais CAs o peer confia, quando essas CAs rotacionam, e quem é responsável por avisá-lo quando isso acontecer. Uma vez que você tenha isso, o incidente “o handshake TLS começou a falhar durante a noite” se torna um ticket de rotina em vez de uma interrupção.

Revogação: CRL, OCSP e a escolha de soft-fail

O período de validade de um certificado indica quando ele expira naturalmente. Não indica se a CA o revogou antecipadamente por comprometimento, rescisão de contrato ou re-emissão de chaves. A revogação é aplicada por meio de um de dois mecanismos.

CRL (Certificate Revocation List) é um arquivo assinado publicado pela CA listando o número de série de cada certificado revogado. CRLs são simples e confiáveis, mas podem crescer muito e a atualidade depende do intervalo de polling.

OCSP (Online Certificate Status Protocol) é uma consulta em tempo real que o SBC envia ao respondedor OCSP da CA perguntando especificamente “este certificado ainda é válido?” A resposta é assinada e de curta duração. O OCSP stapling permite que o peer busque sua própria resposta OCSP antecipadamente e a inclua dentro do handshake TLS, para que o SBC não precise fazer sua própria consulta. O stapling é o padrão mais limpo quando o peer o suporta.

A decisão que importa mais do que CRL versus OCSP é a política de soft-fail versus hard-fail. Se o respondedor OCSP estiver inacessível ou o ponto de distribuição CRL expirar o tempo, você aceita a conexão (soft-fail) ou a rejeita (hard-fail)? Hard-fail é mais seguro, porque um atacante de rede não pode bloquear verificações de revogação para manter vivo um certificado comprometido. Soft-fail tem maior disponibilidade, porque uma interrupção do lado da CA não derruba seu serviço de voz junto. A maioria das interconexões de operadoras usa soft-fail; implantações de alta segurança e fluxos de assinatura STIR/SHAKEN usam hard-fail. Qualquer que seja sua escolha, faça-a deliberadamente e monitore falhas de verificação de revogação para que um soft-fail silencioso não esconda um problema real.

Rotacionando certificados sem derrubar chamadas

Todo certificado eventualmente expira. O problema de rotação é mais difícil para mTLS do que para TLS unidirecional, porque ambos os peers precisam rotacionar de forma coordenada: quando você substitui seu certificado de cliente, cada peer que fixou seu certificado antigo precisa adicionar o novo ao seu truststore antes de você fazer a troca, e quando um peer rotaciona, você precisa adicionar o novo certificado antes que ele faça a troca. Esqueça qualquer uma das etapas e o tronco fica silencioso.

O padrão limpo é a janela de confiança dupla. Por pelo menos 30 dias antes de uma rotação, tanto o certificado antigo quanto o novo (ou tanto a CA emissora antiga quanto a nova) são confiáveis em ambos os lados. O peer apresenta o novo certificado assim que ele é provisionado; o SBC o aceita porque a nova CA já está no truststore. Quando todos os peers confirmarem que estão apresentando o novo certificado, o certificado antigo é removido do truststore. Isso evita qualquer momento de tudo-ou-nada.

Para certificados apresentados pelo SBC, o mesmo padrão se aplica ao inverso. Provisione o novo certificado junto com o antigo, troque cada tronco para o novo certificado durante uma janela de baixo tráfego, monitore falhas de handshake de peers que não atualizaram seu truststore, e remova o certificado antigo somente depois que todos os troncos forem migrados de forma limpa. Alguns SBCs (incluindo o ProSBC) permitem que você provisione um novo certificado e o vincule a um tronco sem reiniciar o serviço, de modo que a rotação acontece no nível da conexão em vez do nível do processo.

Disciplina de calendário importa mais do que o mecanismo. Rastreie datas de expiração por certificado, alerte em 90, 60 e 30 dias, e trate qualquer certificado dentro de 14 dias da expiração como um incidente ativo. O número de incidentes de falha de handshake TLS que se revelam ser “esquecemos que o certificado expirou hoje” é desanimadoramente alto.

Modos de falha específicos do mTLS

A maioria dos guias de troubleshooting TLS cobre falhas de handshake de forma genérica. As falhas listadas abaixo são as que ocorrem especificamente porque o mTLS exige que ambos os lados concordem, e parecem diferentes dos erros TLS padrão.

Um alerta “no certificate available” significa que a identidade de cliente do peer está ausente ou ilegível. Em uma implantação nova, isso geralmente significa que o certificado foi carregado sem a chave privada correspondente, ou as permissões do arquivo de chave privada impedem o processo do SBC de lê-lo. O log TLS do peer mostrará o CertificateRequest chegando e uma mensagem Certificate vazia retornando.

Um alerta “unknown CA” cobre o caso em que o certificado que o peer apresentou encadeia até uma CA na qual o SBC não confia. A correção quase sempre é adicionar o intermediário ou raiz faltante ao truststore, não enfraquecer a política de validação. Se você não reconhece a CA emissora, não confie nela.

Um alerta “certificate verify failed” significa que a assinatura CertificateVerify não correspondeu à chave pública do certificado. Isso é mais raro e geralmente acontece porque o peer está apresentando um certificado cuja chave privada ele não possui de fato (frequentemente porque alguém copiou um arquivo de certificado entre hosts, mas não sua chave). Trate isso como um evento de segurança, não como um desvio de configuração.

Uma incompatibilidade de FQDN apesar de uma cadeia válida significa que a cadeia valida e o certificado está dentro da data, mas o SAN não inclui o FQDN que o seu SBC está discando. Este é o modo de falha que prova que você está verificando o SAN, o que é correto. O peer precisa de um certificado com o SAN correto, não de um truststore mais amplo no seu lado.

O clássico sintoma “funcionava ontem, quebrou hoje, sem mudança de configuração” quase sempre remonta a um certificado que expirou, uma CRL que o SBC não conseguiu atualizar, ou uma raiz de CA na qual o SBC confia que foi removida do truststore do peer (o caso do Microsoft Teams é o exemplo canônico). Verifique datas de expiração e acessibilidade da fonte de revogação antes de qualquer outra coisa.

Um sucesso de handshake unidirecional acontece quando o certificado do SBC é confiável para o peer, mas o SBC rejeita o certificado do peer. O tronco funciona em uma direção e falha na outra. Esta é a falha de confiança assimétrica da seção anterior, e quase sempre significa uma CA faltante em um dos lados.

Onde o mTLS se encaixa em uma defesa em camadas

O mTLS autentica a conexão. Ele não aborda, por si só, a maioria das outras ameaças na borda SIP. Uma postura completa de segurança do SBC trata o mTLS como uma de várias camadas.

Acima do mTLS, o SBC ainda precisa policiar o comportamento na camada SIP: limites de taxa em INVITEs, REGISTERs e OPTIONS, blacklisting dinâmico para fontes que excedem limites, e proteção contra mensagens malformadas. Um peer que completa o mTLS com sucesso e depois inunda você com INVITEs está autenticado, mas ainda é abusivo.

Ao lado do mTLS, o caminho de mídia precisa de sua própria criptografia. O mTLS protege a sinalização SIP. O tráfego de mídia RTP real flui sobre UDP e é protegido por SRTP, com chaves trocadas em SDES (dentro da sinalização protegida por TLS) ou via DTLS-SRTP (handshake no próprio caminho de mídia). Criptografar apenas a sinalização é um erro comum; as chaves SDES trafegam na sinalização, então sinalização não criptografada derrota o SRTP também.

Abaixo do mTLS, os controles de rede ainda importam. Allowlists de IP são mais fracas que autenticação criptográfica, mas reduzem o nível de ruído mantendo tráfego aleatório da internet longe da pilha TLS. A combinação de “IP deve estar na allowlist e certificado deve ser confiável” é significativamente mais forte do que qualquer um isoladamente, e ambos falham em modo fechado.

Monitoramento e alertas específicos para mTLS

O monitoramento SIP genérico informa quando chamadas falham. O monitoramento consciente de mTLS informa por que um tronco protegido por TLS falhou antes que a chamada fosse sequer tentada, e fornece aviso antecipado antes que o próximo certificado expire.

Quatro sinais valem a pena ter alertas específicos. O primeiro é expiração do certificado do peer por tronco, exibida como dias restantes. Esta é a única forma de detectar um peer que está prestes a rotacionar um certificado sem avisá-lo, e deve ser medida lendo o certificado que o peer realmente apresenta, não confiando na documentação contratual. O segundo é taxa de falha de handshake por peer, detalhada por motivo de alerta TLS. Um pico súbito de alertas “unknown CA” de um peer quase sempre significa que ele rotacionou sua CA sem coordenar. O terceiro é taxa de falha de verificação de revogação, separada da taxa de falha de handshake. Uma política de soft-fail esconde interrupções de CRL/OCSP dentro de handshakes bem-sucedidos, então a taxa de falha é a única forma de vê-las. O quarto é dias para expiração do seu próprio certificado, com alertas em 90, 60, 30 e 14 dias. Renovar com antecedência é simples; renovar na véspera da expiração é um incidente que afeta chamadas.

Para provedores de serviços executando isso em escala, o Monitoring as a Service pode consolidar sinais de expiração de certificado, falha de handshake e falha de revogação no mesmo dashboard que métricas de qualidade de chamada, com alertas por email, Slack ou Teams. Fazer isso bem internamente também é viável se você se comprometer com inspeção de certificado por tronco em vez de polling por servidor.

Casos de uso além do Microsoft Teams

O Teams Direct Routing é o caso de uso que colocou o mTLS no radar da maioria dos operadores de SBC, mas não é o único e não deveria ser o único que seu projeto considera.

Interconexões de operadoras estão sendo cada vez mais construídas com mTLS em vez de allowlists de IP. Operadoras Tier 1 publicam peering com exigência de mTLS há vários anos; operadoras de médio porte começaram a seguir. A vantagem para ambos os lados é que um tronco vinculado a certificado sobrevive a uma renumeração de IP com uma mudança de configuração em vez de uma revisão de segurança.

Implantações de BYOC para contact center (Genesys, Five9, NICE, Talkdesk nos troncos SIP próprios de uma operadora) usam mTLS para autenticar o SBC na plataforma CCaaS sem depender de infraestrutura de IP compartilhada. O padrão CPaaS e BYOC é funcionalmente similar ao Teams Direct Routing sem os requisitos específicos da Microsoft.

Federação SIP B2B entre duas empresas, ou entre uma empresa e uma plataforma UCaaS, é uma opção natural para mTLS porque ambos os lados têm uma identidade conhecida e um FQDN estável. É aqui que a pinagem ou uma CA privada tende a funcionar melhor do que uma CA pública, porque o certificado não é visível para ninguém fora do relacionamento.

Implantações MSP multi-tenant usam mTLS mais um certificado wildcard para autenticar o tráfego de cada tenant cliente em um SBC compartilhado. A disciplina de confiança assimétrica é mais importante aqui, porque a falha do certificado de um tenant não deve afetar os outros.

Indústrias reguladas (saúde, serviços financeiros, governo) tratam o mTLS como uma base em vez de um recurso, frequentemente combinado com revogação hard-fail, CAs privadas e pinagem de certificado para as conexões mais sensíveis. Os frameworks de conformidade raramente exigem mTLS pelo nome, mas os controles que exigem (autenticação mútua, custódia de chaves, aplicação de revogação) somam-se a ele na prática.

mTLS no ProSBC

O ProSBC gerencia todas as quatro peças de configuração (identidade do servidor, identidade do cliente, truststore, política por tronco) através de seu gerenciamento de certificados padrão e configuração de Network Access Point (NAP). As configurações relevantes ficam junto à configuração TLS por tronco coberta no guia de configuração SBC TLS e SRTP, então esta seção foca no que é específico do mTLS em vez de repassar a configuração TLS por tronco.

O truststore pode conter qualquer combinação de CAs públicas, CAs privadas e certificados de peer fixados, com seleção por tronco de quais entradas são válidas para qual NAP. Isso evita o modo de falha amplo de “confiar em toda CA pública” permitindo que diferentes troncos aceitem diferentes autoridades. Por exemplo, CAs raiz e uma CA interna privada podem coexistir no mesmo SBC sem que uma enfraqueça a outra.

Cada NAP carrega sua própria política TLS com as quatro configurações padrão (sem TLS, TLS sem autenticação de cliente, TLS com autenticação de cliente opcional, TLS com autenticação de cliente obrigatória), para que o mesmo SBC possa servir uma interconexão de operadora com mTLS estrito, uma janela de migração com mTLS opcional e um tronco legado com TLS unidirecional simultaneamente. A política por NAP também torna possível aplicar diferentes políticas de revogação por tronco, se necessário.

Para provedores de serviços e MSPs sem equipe dedicada de PKI, o ProSBC Managed Service inclui suporte ao ciclo de vida de certificados como parte da cobertura de engenharia Nível 3, o que remove o ônus de coordenação de rotação da operadora. Para implantações auto-hospedadas, a licença ProSBC Lab é suficiente para validar uma configuração mTLS de ponta a ponta contra um tenant de teste do Teams ou uma operadora sandbox antes de implantar em produção.

Perguntas frequentes