Una conexión TLS estándar cifra el tráfico pero no demuestra, en la mayoría de los escenarios, quién es realmente el cliente. Las contraseñas, las claves API, las listas de IPs permitidas y los controles basados en tokens añaden capas de seguridad, pero pueden compartirse, filtrarse, copiarse o usarse en el contexto equivocado. mTLS, por el contrario, verifica que el cliente posee la clave privada, produciendo una señal de identidad más fuerte a nivel de conexión.
En las APIs B2B, los flujos de pago, el intercambio de datos de salud, el tráfico de dispositivos IoT y el acceso a interfaces de administración, esa diferencia es crítica. Cada socio, dispositivo o administrador llega con su propio certificado; la vida útil del certificado, la cadena CA, el CN, la huella digital y el resultado de verificación son todos auditables. Sin embargo, requerir que cada aplicación analice esa información de forma independiente añade complejidad operacional.
En los despliegues tradicionales de mTLS, la gestión del bundle CA, la selección del modo de verificación, los códigos de error, la extracción de campos del certificado y el reenvío de esa información a la aplicación son cuestiones fragmentadas. Un entorno puede requerir un certificado obligatorio mientras que otro necesita el modo optional durante una transición. Las cadenas CA legacy, los certificados de prueba y las migraciones de socios exigen un equilibrio fino entre validación estricta y tolerancia controlada.
El enfoque correcto es gestionar mTLS como un perfil de servicio. El modo de verificación, el archivo CA, la estrategia de errores CA, el reenvío de campos del certificado al backend y las políticas de acceso condicional AAM deben vivir todos en el mismo modelo.
TR7 TLS / mTLS Client-Cert Authentication ofrece este modelo: saca el certificado de cliente del control a nivel de conexión y lo convierte en un objeto de identidad utilizable para los servicios backend y las políticas de acceso por igual.
TR7 aplica la verificación mTLS junto con el modo de verificación por servicio, la gestión CA, el reenvío de campos del certificado y la política de acceso AAM en un único modelo cohesivo.
Con los modos none, optional y required, cada servicio puede aplicar su propia política mTLS. Los certificados pueden hacerse obligatorios, mantenerse opcionales durante una transición, o deshabilitarse por completo para un servicio dado.
El código de verificación, la huella digital SHA1, el CN y los campos adicionales del certificado pueden mapearse a cabeceras HTTP. El backend lee la información de identidad directamente sin analizar el certificado por sí mismo.
Las cabeceras del certificado pueden analizarse en campos como present, verified, verify, sha1 y cn. Incluso cuando la verificación falla, los datos del certificado pueden registrarse y pasarse al motor de decisiones de forma controlada.
Los errores de validación CA pueden rechazarse por completo, tolerarse en bloque durante una transición, o relajarse solo para códigos de error específicos. Esto permite que las políticas de staging, migración de socios y producción coexistan en el mismo modelo mTLS.
TLS / mTLS Client-Cert Authentication verifica, analiza, registra y comparte el certificado de cliente con el backend — todo en el edge.
TR7 gestiona el comportamiento de autenticación por certificado de cliente de forma independiente para cada servicio. En el modo none no se solicita ningún certificado. En el modo optional se analiza un certificado cuando se presenta; si está ausente, la conexión puede continuar. En el modo required cualquier conexión que carezca de un certificado se rechaza. Esta estructura proporciona seguridad estricta en producción, flexibilidad en staging y despliegue gradual durante la migración. Diferentes servicios en la misma plataforma pueden aplicar diferentes requisitos mTLS.
TR7 puede validar certificados de cliente contra archivos CA por servicio. La cadena CA del Socio A puede usarse en un servicio mientras la cadena del Socio B se aplica a otro. Esta separación permite gestionar en aislamiento diferentes socios comerciales o grupos de dispositivos en el mismo ADC, sin depender de una única lista CA global. Se define una raíz de confianza distinta por servicio.
TR7 puede entregar el estado de verificación del certificado de cliente al backend mediante cabeceras como x-ssl-verify. La verificación exitosa, la ausencia del certificado o un fallo de verificación específico es visible para la aplicación. El backend puede tomar decisiones basadas en el estado mTLS de la conexión sin lidiar con el stack TLS o el análisis de certificados.
TR7 puede extraer el Common Name y la huella digital SHA1 del certificado de cliente y reenviarlos como cabeceras al backend. El CN puede servir como identificador de socio, dispositivo, usuario o servicio. La huella digital SHA1 ofrece una clave práctica para los escenarios de listas de permitidos, auditoría, coincidencia o revocación rápida. Las huellas digitales se normalizan para que los diferentes estilos de formato no produzcan valores de identidad diferentes.
caErrorStrategy permite diferentes respuestas a los fallos de validación CA. ignoreAll puede tolerar todos los errores CA en escenarios de debug temporal o migración; manualIgnoreList limita la tolerancia a códigos de error de validación específicos. En producción esta flexibilidad puede deshabilitarse para aplicar tolerancia cero. El modelo crea un equilibrio controlado entre la seguridad estricta y las necesidades de migración del mundo real.
TR7 no solo solicita certificados de los clientes entrantes — también puede presentar un certificado de cliente al conectarse a un servicio backend. La conexión orientada al backend puede configurarse con verify required, un archivo CA y un certificado de cliente ADC. Esto habilita políticas de confianza TLS independientes tanto en las patas cliente-a-TR7 como TR7-a-backend. El tráfico puede inspeccionarse en el edge mientras la conexión interna permanece totalmente asegurada.
Un certificado de cliente es una señal de identidad fuerte, pero no necesita cargar la decisión de acceso completa por sí solo. TR7 puede usar los datos del certificado como una entrada a las políticas de acceso condicional AAM. El certificado, la dirección IP, la postura del dispositivo, el grupo de usuarios, la hora del día y el estado MFA pueden evaluarse todos conjuntamente. mTLS se convierte en un componente de una decisión de acceso zero-trust más amplia.
Una verificación de certificado exitosa no hace automáticamente que una solicitud sea segura — los controles de contenido y volumen continúan aplicándose. TR7 ejecuta la capa de identidad mTLS junto con WAAP, DDoS y el análisis de comportamiento de bots. mTLS establece quién es el cliente; WAAP evalúa qué está haciendo la solicitud; la capa DDoS evalúa el volumen de tráfico. Los tres controles pueden operar juntos frente al mismo servicio.
En el modo optional, los socios que presentan un certificado se procesan con identidad mTLS mientras los clientes cuya migración de certificados aún no está completa pueden caer a un mecanismo de autenticación alternativo. Este patrón permite que las grandes migraciones B2B se desplieguen de forma segura sin forzar a todos los socios a mTLS el mismo día. El backend puede decidir entre flujos basados en certificado y en clave API según la presencia de la cabecera x-ssl-verify. Una vez completada la migración, el servicio puede pasarse al modo required.
Para las conexiones mTLS, campos como el sujeto del certificado, el emisor, la ventana de validez, el resultado de verificación y la huella digital pueden registrarse. En un SIEM, queda claro qué socio accedió a qué servicio con qué certificado. Los eventos como expirado, auto-firmado o fallos de emisor pueden analizarse por separado. Estos registros producen un sólido rastro de auditoría para el cumplimiento, la investigación de incidentes y la auditoría de socios.
La operación mTLS se cubre de extremo a extremo: comportamiento de bind, códigos de verificación, detección de certificados mediante cabeceras, normalización de huella digital, alcance del archivo CA y validación SNI/Host.
El comportamiento verify none, optional o required se establece en el punto de entrada del servicio. En el modo required una conexión de cliente que no presenta ningún certificado se rechaza. En el modo optional se analiza un certificado si está presente; si está ausente, la solicitud puede continuar a un flujo de política alternativo.
El resultado de verificación del certificado puede expresarse como un código de error numérico. Cero representa la verificación exitosa; otros valores indican condiciones como emisor no encontrado, certificado expirado, certificado aún no válido o certificado auto-firmado. Este valor puede reenviarse al backend como cabecera.
Si x-ssl-verify está vacío o indica que no se usó ningún certificado, se trata al cliente como si no hubiera presentado ningún certificado. Un valor de 0 significa que el certificado ha sido verificado con éxito. Cualquier otro valor significa que los datos del certificado pueden estar presentes pero la verificación falló — esto puede manejarse por separado en los logs y las decisiones de política.
Los valores de huella digital pueden llegar con mayúsculas y minúsculas mezcladas y formato separado por dos puntos. TR7 normaliza el valor para que las operaciones de comparación y lista de permitidos funcionen de forma consistente. El mismo certificado no se trata como una identidad diferente debido a una diferencia de formato.
Cada servicio puede usar su propio bundle CA, lo que permite aislar las raíces de confianza entre socios, grupos de dispositivos y servicios internos. Los cambios en la CA deben planificarse teniendo en cuenta el impacto en el servicio y deben auditarse.
En los servicios que usan mTLS, la validación SNI y Host puede habilitarse además de la verificación del certificado. Cuando el certificado, SNI y Host se evalúan conjuntamente, la identidad de la solicitud, el dominio de destino y la intención de enrutamiento HTTP se validan todos en combinación. Este modelo ayuda a reducir el riesgo de abuso tipo domain fronting.
Cada socio se conecta a la API con un certificado de cliente único. TR7 registra los valores CN y SHA1, los reenvía al backend y hace más sencillas las decisiones de auditoría y rate-limiting por socio.
Cada dispositivo puede conectarse a TR7 usando un certificado único cargado en fábrica. El número de serie del dispositivo se transporta en el campo CN, y la lista de permitidos por huella digital hace más rápidos los flujos de revocación y restricción de acceso.
Las organizaciones de salud pueden usar mTLS al compartir datos con sistemas de proveedores para autenticar a nivel de conexión. Cuando un certificado expira o la verificación falla, el acceso puede cortarse automáticamente sin intervención manual.
Los administradores de sistemas pueden conectarse a la interfaz de administración de TR7 usando un certificado de cliente. Cuando se combina con MFA y la postura del dispositivo a través de AAM, un único portátil, un certificado específico y una identidad de administrador verificada se confirman todos juntos.
Verifique el certificado de cliente en el edge, reenvíelo a su backend y combínelo con la política AAM. Permítanos mostrarle una configuración en vivo sobre sus propios servicios.