SBC mTLS: autenticación mutua TLS para señalización SIP

TLS estándar demuestra que su controlador de borde de sesión (SBC) es el dispositivo que su nombre de host afirma ser. No demuestra nada sobre el dispositivo en el otro extremo de la conexión. Para un borde SIP expuesto a internet, eso resuelve la mitad equivocada del problema. Cualquiera en la internet pública puede abrir un socket TCP en el puerto 5061, completar un handshake TLS unidireccional contra su certificado y comenzar a enviar mensajes INVITE. TLS protege el canal, pero no autentica al par.

TLS mutuo, generalmente escrito mTLS, cierra esa brecha. Ambos terminales presentan certificados X.509 durante el handshake, y ambos validan el certificado que reciben contra su propia política de confianza. Si el par no presenta un certificado, o presenta uno que su SBC no confía, el handshake falla antes de que se intercambie un solo byte SIP. Este es el mecanismo que la mayoría de los operadores Tier 1 esperan en las interconexiones, y el mecanismo que está reemplazando gradualmente las listas de permitidos por IP como el límite de confianza predeterminado entre pares SIP.

Esta guía va más allá de la definición general. Recorre lo que realmente sucede durante el handshake mTLS, la diferencia entre un almacén de confianza (truststore) y un almacén de claves (keystore), uno de los puntos más consistentemente confundidos en implementaciones reales, los cuatro modelos de confianza entre los que puede elegir, por qué la confianza entre dos pares casi nunca es simétrica, cómo funciona la verificación de revocación en la práctica y los modos de falla específicos de mTLS en lugar de TLS en general. Para el tutorial de configuración de TLS y SRTP por troncal que sustenta todo esto, consulte la Guía de configuración de SBC TLS y SRTP.

Lo que TLS unidireccional deja expuesto

En un handshake TLS estándar con autenticación de servidor, solo un lado demuestra su identidad. Cuando un cliente SIP abre una conexión TLS a su SBC en el puerto 5061, el SBC presenta su certificado, el cliente valida ese certificado contra su truststore y se establece el túnel cifrado. El cliente nunca tiene que demostrar quién es. Desde la perspectiva del SBC, cualquier dispositivo que complete el handshake puede comenzar a enviar mensajes SIP.

Eso funciona para la web de consumo, donde el servidor es el activo que vale la pena proteger y el cliente es un navegador cuya identidad se aplica más arriba en la pila (nombres de usuario, contraseñas, cookies). No funciona para un borde SIP, donde el servidor es el activo que vale la pena proteger y el cliente es otro elemento de red sin un humano al teclado. La autenticación digest SIP existe, pero opera por encima de la capa TLS y no sustituye la autenticación del dispositivo anfitrión.

El riesgo práctico es directo. Un atacante escanea internet, encuentra su SBC en el puerto 5061, abre una conexión TLS y comienza a probar. No puede descifrar su tráfico existente, pero ahora puede iniciar llamadas SIP propias. Que esas llamadas se completen depende por completo de la autenticación, listas de permitidos y políticas que usted haya configurado por encima de TLS. mTLS lleva el límite de autenticación al handshake mismo, de modo que la conexión del atacante es rechazada antes de que la pila SIP la vea.

Cómo funciona realmente el handshake mTLS

El servidor solicita un certificado al cliente, el cliente lo proporciona y ambos lados validan lo que reciben antes de que fluyan datos de aplicación.

1. El ClientHello abre la conexión y ofrece las versiones de TLS compatibles del cliente, suites de cifrado y extensiones. Aún no se intercambia ningún certificado.
2. El ServerHello y el certificado del servidor siguen una vez que el SBC ha seleccionado una suite de cifrado, y el SBC presenta su propia cadena de certificados en esta etapa. Este es el mismo paso que se ve en TLS unidireccional.
3. Se envía un CertificateRequest en lugar de finalizar el handshake, solicitando al cliente que presente su propio certificado. El mensaje incluye una lista de autoridades de certificación aceptables para que el cliente sepa cuál de sus certificados elegir.
4. Los mensajes de certificado del cliente y CertificateVerify regresan juntos: el cliente devuelve su certificado (y la cadena intermedia) junto con un mensaje CertificateVerify que contiene una firma sobre la transcripción del handshake, realizada con la clave privada que coincide con el certificado. Esto demuestra que el cliente realmente posee la clave, no solo una copia del certificado de otra persona.
5. El paso de validación mutua ocurre en ambos lados simultáneamente. El SBC valida la cadena del cliente contra su truststore, verifica el período de validez, comprueba la firma CertificateVerify y (si está configurado) realiza una verificación de revocación. El cliente realiza la misma validación contra el certificado del SBC. Cualquier falla aborta el handshake con una alerta TLS.
6. Los mensajes Finished se intercambian en ambos lados, el canal de aplicación cifrado se abre y comienza el tráfico SIP.

Dos implicaciones importan operativamente. Primero, mTLS es bidireccional por construcción: una mala configuración en cualquier lado rompe la conexión, y la superficie de error vive en la capa TLS, no en la capa SIP. Herramientas como una traza SIP le dirán que la llamada nunca comenzó; solo una captura a nivel TLS (o el registro de errores TLS del SBC) le dirá por qué. Segundo, cada llamada exitosa en una troncal protegida con mTLS ya ha demostrado, en la etapa del handshake, que el par posee una clave privada que coincide con un certificado que su SBC eligió confiar. Esa es una afirmación mucho más fuerte que “la IP de origen está en la lista de permitidos”.

Las cuatro piezas de una configuración mTLS

La mayor parte de la confusión operativa sobre mTLS proviene de colapsar conceptos distintos en uno solo. Hay cuatro piezas independientes, y cada una vive en una parte diferente de la configuración del SBC.

Identidad del servidor es el certificado propio del SBC y la clave privada correspondiente, utilizados cuando el SBC actúa como servidor TLS (un par se conecta de entrada al puerto 5061). El SAN debe incluir cada FQDN que los pares de entrada utilizarán para comunicarse con usted. Para implementaciones multi-tenant, un certificado comodín o multi-SAN es común; consulte la guía de SBC multi-tenant para Teams Direct Routing para el patrón de certificado comodín que Microsoft espera.

Identidad del cliente es el certificado que el SBC presenta cuando actúa como cliente TLS (el SBC está iniciando una conexión TLS saliente hacia un operador o hacia Teams). Frecuentemente es el mismo certificado que la identidad del servidor en implementaciones más pequeñas, y un certificado diferente en las más grandes donde el tráfico saliente utiliza una identidad dedicada. En cualquier caso, debe almacenarse como un certificado más la clave privada correspondiente, no solo un archivo de certificado.

Almacén de confianza (truststore) cubre qué autoridades de certificación (o certificados individuales de pares) aceptará el SBC al validar un par. Esto es independiente de su propia identidad. Un truststore que contiene “cualquier CA pública que el sistema operativo confía” es demasiado permisivo para SIP, porque autoriza a cada certificado de Let’s Encrypt y DigiCert en internet a comunicarse con usted. Un truststore SIP correcto lista solo las CA que emiten certificados a sus pares reales.

Política por troncal vincula los tres elementos anteriores a troncales SIP específicas.

La confusión entre keystore y truststore merece entenderse porque produce una clase específica de falla. Si el certificado propio del SBC y la clave privada se archivan en el truststore en lugar del keystore, el SBC no tiene identidad que presentar: la pila TLS típicamente no logra levantar el listener, o aborta el handshake con un handshake_failure genérico (alerta 40) antes de que se intercambie cualquier certificado. Si mTLS está configurado y la CA de un par se archiva en el keystore en lugar del truststore, el SBC no confiará en el certificado que ese par presente durante la autenticación de cliente, y el handshake falla con unknown_ca (alerta 48).

Cómo elegir un modelo de confianza

Una vez que ha decidido requerir autenticación de cliente, tiene una decisión separada sobre qué autoridades emiten los certificados que aceptará. Hay cuatro opciones prácticas, y la correcta depende de quién es el par y cuánto control tiene sobre su PKI.

El patrón con mayor probabilidad de producir sorpresas es el enfoque amplio de raíz de CA pública. Colocar “DigiCert Global Root G2” en su truststore significa que el SBC aceptará cualquier certificado emitido por DigiCert para cualquier sujeto, incluidos actores no deseados. La defensa es agregar validación de FQDN sobre la validación de CA: incluso si el certificado encadena a una raíz de confianza, rechácelo a menos que el SAN coincida con el FQDN con el que se supone que la troncal debe comunicarse.

El problema de confianza asimétrica: el ejemplo de Microsoft Teams

La confianza entre dos pares en mTLS rara vez es simétrica, y la documentación casi nunca lo dice explícitamente. Su SBC confía en certificados emitidos por un conjunto específico de CA; el par confía en certificados emitidos por un conjunto diferente (generalmente superpuesto pero no idéntico). Ambas listas importan, ambas pueden estar equivocadas independientemente, y una conexión funciona solo cuando ambas listas aceptan el certificado que el otro lado presenta.

Una de esas implementaciones que está ganando popularidad es Microsoft Teams Direct Routing. El truststore de Microsoft en el lado de Teams acepta certificados de una lista publicada de CA públicas (la lista se actualiza periódicamente, más recientemente para la actualización de CA raíz de junio de 2026). Su SBC, mientras tanto, debe confiar en la CA que firma los certificados propios de Microsoft en la interfaz de Teams (actualmente DigiCert Global Root G2, próximamente también Microsoft RSA Root Certificate Authority 2017). Si actualiza solo el lado del SBC o solo el lado de Teams, la troncal se rompe. Si olvida la nueva raíz de Microsoft por completo, el establecimiento de llamadas ya no será posible. La confianza asimétrica es la razón por la que el cambio de certificado de Teams se anuncia con meses de anticipación.

La disciplina operativa que maneja esto bien es pensar en la confianza mTLS por dirección en lugar de por troncal. Para cada dirección (entrante del par, saliente al par), mantenga un registro de qué CA confía el SBC, qué CA confía el par, cuándo esas CA rotan y quién es responsable de informarle cuando lo hagan. Una vez que tenga eso, el incidente de “el handshake TLS empezó a fallar anoche” se convierte en un ticket de rutina en lugar de una interrupción.

Revocación: CRL, OCSP y la decisión de falla permisiva

El período de validez de un certificado le indica cuándo expira naturalmente. No le indica si la CA lo ha revocado anticipadamente por compromiso, terminación de contrato o renovación de claves. La revocación se aplica mediante uno de dos mecanismos.

CRL (Certificate Revocation List) es un archivo firmado publicado por la CA que enumera el número de serie de cada certificado revocado. Los CRL son simples y confiables, pero pueden crecer mucho y la frescura depende del intervalo de consulta.

OCSP (Online Certificate Status Protocol) es una consulta en tiempo real que el SBC envía al respondedor OCSP de la CA preguntando específicamente “¿sigue siendo válido este certificado?”. La respuesta es firmada y de corta duración. El OCSP stapling permite al par obtener su propia respuesta OCSP por adelantado e incluirla dentro del handshake TLS, de modo que el SBC no necesite hacer su propia consulta. El stapling es el patrón más limpio cuando el par lo admite.

La decisión que importa más que CRL versus OCSP es la política de falla permisiva (soft-fail) versus falla estricta (hard-fail). Si el respondedor OCSP no es accesible o el punto de distribución de CRL agota su tiempo, ¿acepta la conexión (soft-fail) o la rechaza (hard-fail)? Hard-fail es más seguro, porque un atacante de red no puede bloquear las verificaciones de revocación para mantener vivo un certificado comprometido. Soft-fail es más disponible, porque una interrupción del lado de la CA no afecta su servicio de voz. La mayoría de las interconexiones entre operadores usan soft-fail; las implementaciones de alta seguridad y los flujos de firma STIR/SHAKEN usan hard-fail. Cualquiera que elija, hágalo deliberadamente, y monitoree las fallas de verificación de revocación para que un soft-fail silencioso no oculte un problema real.

Rotación de certificados sin interrumpir llamadas

Todo certificado eventualmente expira. El problema de rotación es más difícil para mTLS que para TLS unidireccional, porque ambos pares deben rotar en coordinación: cuando usted reemplaza su certificado de cliente, cada par que haya fijado su certificado anterior debe agregar el nuevo a su truststore antes de que usted haga el cambio, y cuando un par rota, usted debe agregar el nuevo certificado antes de que ellos hagan el cambio. Olvidar cualquier paso y la troncal queda en silencio.

El patrón limpio es la ventana de doble confianza. Durante al menos 30 días antes de una rotación, tanto el certificado anterior como el nuevo (o tanto la CA emisora anterior como la nueva) se confían en ambos lados. El par presenta el nuevo certificado tan pronto como se aprovisiona; el SBC lo acepta porque la nueva CA ya está en el truststore. Una vez que cada par ha confirmado que está presentando el nuevo certificado, el certificado anterior se elimina del truststore. Esto evita cualquier momento de todo-o-nada.

Para certificados presentados por el SBC, el mismo patrón se aplica a la inversa. Aprovisione el nuevo certificado junto al anterior, cambie cada troncal al nuevo certificado durante una ventana de bajo tráfico, monitoree fallas de handshake de pares que no han actualizado su truststore y elimine el certificado anterior solo después de que cada troncal haya sido cambiada limpiamente. Algunos SBC (incluido ProSBC) le permiten preparar un nuevo certificado y vincularlo a una troncal sin reiniciar el servicio, de modo que la rotación ocurre a nivel de conexión en lugar de a nivel de proceso.

La disciplina de calendario importa más que el mecanismo. Registre las fechas de vencimiento por certificado, alerte a los 90, 60 y 30 días, y trate cualquier certificado dentro de los 14 días de su vencimiento como un incidente activo. La cantidad de incidentes de falla de handshake TLS que resultan ser “olvidamos que el certificado expiraba hoy” es sorprendentemente alta.

Modos de falla específicos de mTLS

La mayoría de las guías de solución de problemas TLS cubren las fallas de handshake de forma genérica. Las fallas enumeradas a continuación son las que ocurren específicamente porque mTLS requiere que ambos lados estén de acuerdo, y se ven diferentes de los errores TLS estándar.

Una alerta “no certificate available” significa que la identidad de cliente del par está ausente o es ilegible. En una implementación nueva, esto generalmente significa que el certificado fue cargado sin la clave privada correspondiente, o los permisos del archivo de clave privada impiden que el proceso del SBC lo lea. El registro TLS del par mostrará el CertificateRequest llegando y un mensaje Certificate vacío regresando.

Una alerta “unknown CA” cubre el caso donde el certificado que el par presentó encadena a una CA que el SBC no confía. La solución casi siempre es agregar la raíz o intermediaria faltante al truststore, no debilitar la política de validación. Si no reconoce la CA emisora, no confíe en ella.

Una alerta “certificate verify failed” significa que la firma CertificateVerify no coincidió con la clave pública del certificado. Esto es más raro y generalmente ocurre porque el par está presentando un certificado cuya clave privada no posee realmente (frecuentemente porque alguien copió un archivo de certificado entre hosts pero no su clave). Trátelo como un evento de seguridad, no como una desviación de configuración.

Un desajuste de FQDN a pesar de una cadena válida significa que la cadena se valida y el certificado está vigente, pero el SAN no incluye el FQDN que su SBC está marcando. Este es el modo de falla que demuestra que usted está verificando el SAN, lo cual es correcto. El par necesita un certificado con el SAN correcto, no un truststore más amplio de su lado.

El clásico síntoma de “funcionaba ayer, está roto hoy, sin cambio de configuración” casi siempre se remonta a un certificado que expiró, un CRL que el SBC no pudo actualizar, o una raíz de CA que el SBC confía y que fue eliminada del truststore del par (el caso de Microsoft Teams es el ejemplo canónico). Verifique las fechas de vencimiento y la accesibilidad de la fuente de revocación antes que nada.

Un handshake unidireccional exitoso ocurre cuando el certificado del SBC es confiado por el par, pero el SBC rechaza el certificado del par. La troncal funciona en una dirección y falla en la otra. Esta es la falla de confianza asimétrica de la sección anterior, y casi siempre significa una CA faltante en un lado.

Dónde pertenece mTLS en una defensa por capas

mTLS autentica la conexión. Por sí solo, no aborda la mayoría de las otras amenazas en el borde SIP. Una postura de seguridad SBC completa trata a mTLS como una de varias capas.

Por encima de mTLS, el SBC todavía debe vigilar el comportamiento a nivel SIP: límites de tasa en INVITE, REGISTER y OPTIONS, listas de bloqueo dinámicas para fuentes que excedan umbrales, y protección contra mensajes malformados. Un par que completa mTLS exitosamente y luego lo inunda con INVITE está autenticado, pero sigue siendo abusivo.

Junto a mTLS, la ruta de medios necesita su propio cifrado. mTLS protege la señalización SIP. El flujo de medios RTP real viaja por UDP y está protegido por SRTP, con claves intercambiadas ya sea en SDES (dentro de la señalización protegida por TLS) o mediante DTLS-SRTP (handshake en la ruta de medios misma). Cifrar solo la señalización es un error común; las claves SDES viajan en la señalización, por lo que una señalización sin cifrar anula también SRTP.

Por debajo de mTLS, los controles de red siguen importando. Las listas de permitidos por IP son más débiles que la autenticación criptográfica, pero reducen el ruido de fondo al mantener el tráfico aleatorio de internet lejos de la pila TLS. La combinación de “la IP debe estar en la lista de permitidos y el certificado debe ser confiado” es significativamente más fuerte que cualquiera de los dos por separado, y ambos fallan de forma cerrada.

Monitoreo y alertas específicos de mTLS

El monitoreo SIP genérico le indica cuándo fallan las llamadas. El monitoreo con reconocimiento de mTLS le indica por qué una troncal protegida con TLS falló antes de que la llamada siquiera se intentara, y le da advertencia anticipada antes de que expire el siguiente certificado.

Cuatro señales merecen alertas específicas. La primera es el vencimiento del certificado del par por troncal, expresado en días restantes. Esta es la única forma de detectar a un par que está a punto de rotar un certificado sin avisarle, y debe medirse leyendo el certificado que el par realmente presenta, no confiando en la documentación del contrato. La segunda es la tasa de falla de handshake por par, desglosada por razón de alerta TLS. Un pico repentino de alertas “unknown CA” de un par casi siempre significa que rotaron su CA sin coordinarse. La tercera es la tasa de falla de verificación de revocación, separada de la tasa de falla de handshake. Una política de soft-fail ocultará las interrupciones de CRL/OCSP dentro de handshakes exitosos, por lo que la tasa de falla es la única forma de verlas. La cuarta es los días para el vencimiento de su propio certificado, con alertas a los 90, 60, 30 y 14 días. Renovar con anticipación es sencillo; renovar al día menos uno del vencimiento es un incidente que afecta llamadas.

Para proveedores de servicios que ejecutan esto a escala, el Monitoreo como servicio puede integrar las señales de vencimiento de certificados, falla de handshake y falla de revocación en el mismo panel que las métricas de calidad de llamadas, con alertas por correo electrónico, Slack o Teams. Hacerlo bien internamente también es factible si se compromete con la inspección de certificados por troncal en lugar de la consulta por servidor.

Casos de uso más allá de Microsoft Teams

Teams Direct Routing es el caso de uso que puso a mTLS en el radar de la mayoría de los operadores de SBC, pero no es el único y no debería ser el único que su diseño considere.

Las interconexiones entre operadores se construyen cada vez más sobre mTLS en lugar de listas de permitidos por IP. Los operadores Tier 1 han publicado requisitos de peering con mTLS durante varios años; los operadores de nivel medio han comenzado a seguirlos. La ventaja para ambos lados es que una troncal vinculada a certificado sobrevive una renumeración IP con un cambio de configuración en lugar de una revisión de seguridad.

Las implementaciones BYOC de centros de contacto (Genesys, Five9, NICE, Talkdesk en las troncales SIP propias del operador) utilizan mTLS para autenticar el SBC ante la plataforma CCaaS sin depender de infraestructura IP compartida. El patrón de CPaaS y BYOC es funcionalmente similar a Teams Direct Routing menos los requisitos específicos de Microsoft.

La federación SIP B2B entre dos empresas, o entre una empresa y una plataforma UCaaS, es un ajuste natural para mTLS porque ambos lados tienen una identidad conocida y un FQDN estable. Aquí es donde la fijación o una CA privada tiende a funcionar mejor que una CA pública, porque el certificado no es visible para nadie fuera de la relación.

Las implementaciones multi-tenant de MSP utilizan mTLS más un certificado comodín para autenticar el tráfico de cada tenant cliente en un SBC compartido. La disciplina de confianza asimétrica importa más aquí, porque la falla del certificado de un tenant no debe afectar a los demás.

Las industrias reguladas (salud, servicios financieros, gobierno) tratan a mTLS como un requisito base en lugar de una funcionalidad, frecuentemente combinado con revocación hard-fail, CA privadas y fijación de certificados para las conexiones más sensibles. Los marcos de cumplimiento rara vez exigen mTLS por nombre, pero los controles que sí exigen (autenticación mutua, custodia de claves, aplicación de revocación) suman lo mismo en la práctica.

mTLS en ProSBC

ProSBC maneja las cuatro piezas de configuración (identidad del servidor, identidad del cliente, truststore, política por troncal) a través de su gestión estándar de certificados y la configuración de Network Access Point (NAP). Las configuraciones relevantes se encuentran junto a la configuración TLS por troncal cubierta en la guía de configuración de SBC TLS y SRTP, por lo que esta sección se centra en lo específico de mTLS en lugar de recorrer nuevamente la configuración TLS por troncal.

El truststore puede contener cualquier combinación de CA públicas, CA privadas y certificados de pares fijados, con selección por troncal de qué entradas son válidas para cada NAP. Esto evita el modo de falla amplio de “confiar en cada CA pública que el sistema operativo confía” al permitir que diferentes troncales acepten diferentes autoridades. Por ejemplo, CA raíz y una CA interna privada pueden coexistir en el mismo SBC sin que una debilite a la otra.

Cada NAP lleva su propia política TLS con las cuatro configuraciones estándar (sin TLS, TLS sin autenticación de cliente, TLS con autenticación de cliente opcional, TLS con autenticación de cliente requerida), por lo que el mismo SBC puede servir una interconexión con operador bajo mTLS estricto, una ventana de migración con mTLS opcional y una troncal legacy bajo TLS unidireccional simultáneamente. La política por NAP también permite aplicar diferentes políticas de revocación por troncal si es necesario.

Para proveedores de servicios y MSP sin personal dedicado de PKI, el Servicio administrado de ProSBC incluye soporte de ciclo de vida de certificados como parte de la cobertura de ingeniería de Nivel 3, lo que elimina la carga de coordinación de rotación del operador. Para implementaciones auto-hospedadas, la licencia de ProSBC Lab es suficiente para validar una configuración mTLS de extremo a extremo contra un tenant de prueba de Teams o un operador sandbox antes de la implementación en producción.

Preguntas frecuentes