Autenticación de cliente · mTLS

Cuando el servidor también tiene que saber quién llama

Eso es la autenticación de cliente. El certificado no va en tu web: va en la máquina que se conecta —una API, un cajero, el sistema de un socio— y es lo que el otro extremo comprueba antes de abrir la conexión. Desde marzo de 2027, un certificado SSL público ya no sirve para eso.

Si ya conoces el tema La guía técnica completa

183 días

Lo que hoy autentica a tus clientes deja de servir el 15 de marzo de 2027

Chrome está quitando la autenticación de cliente a los certificados de confianza pública. Si dos de tus sistemas se identifican hoy con un certificado TLS público, ese apretón de manos falla a partir de esa fecha. No se degrada: deja de conectar.

El calendario

Cuatro fechas, dos de ellas ya pasaron

No es una recomendación de seguridad: son plazos de programas y de infraestructuras que ya están en marcha.

  • 15 · 06 · 2026

    Chrome quita la autenticación de cliente a las CA subordinadas públicas.

  • 30 · 11 · 2026

    DTCC exige mTLS sobre X9 en su entorno de pruebas.

  • 31 · 12 · 2026

    La misma exigencia de DTCC, ahora en producción.

  • 15 · 03 · 2027

    Los certificados finales públicos pierden la autenticación de cliente.

Cómo funciona

En TLS normal solo el servidor dice quién es

Tu navegador comprueba el certificado del servidor y el servidor nunca sabe quién eres — para eso vienen después la contraseña o la clave de API. En TLS mutuo los dos extremos presentan certificado, y la conexión no llega a abrirse si uno de los dos no es de confianza. Una petición no autenticada nunca toca tu código.

TLS NORMAL Cliente Servidor certificado el servidor se identifica el cliente queda anónimo TLS MUTUO · mTLS Cliente certificado X9 Servidor certificado los dos se identifican
Por eso este certificado no necesita que un navegador confíe en él. Quien tiene que confiar es el servidor del otro extremo, y esa confianza se instala.

A quién le sirve

Si algo de esto te suena, te toca

Banca y fintech

Open banking, FDX, miembros de DTCC, procesadores de pago y sus proveedores.

APIs entre empresas

Integraciones con socios, ERPs, logística, salud, seguros, remuneraciones.

Cajeros, POS e interbancario

Comunicación host a host entre instituciones y sus redes de terminales.

Quien opera una CA interna

La misma función, auditada por terceros y sin mantener la infraestructura tú.

La comparación

X9, un SSL público o tu propia CA

Las tres cosas emiten certificados y las tres sirven para algo distinto. La diferencia que decide no es técnica: es quién tiene que confiar, y quién responde por esa confianza.

X9 SSL público CA interna
Autentica clientes Solo hasta marzo de 2027
Vale entre organizaciones distintas Raíz común y auditada No, sin acuerdos uno a uno
Acepta direcciones IP Públicas y privadas Solo públicas
Quién responde por la confianza DigiCert, con auditoría WebTrust anual La autoridad emisora
Depende de un navegador No, y por eso no se rompe No
Quién la opera cada día DigiCert La autoridad emisora Tu equipo
DigiCert

Operada por DigiCert

La misma autoridad detrás de millones de certificados públicos.

Gobernada por ASC X9

Un comité de políticas del organismo de estándares del sector financiero.

Auditoría WebTrust anual

La misma auditoría independiente que pasa una CA pública.

Lista para post-cuántica

Admite algoritmos clásicos y post-cuánticos, sin esperar a un programa de navegadores.

¿No sabes por dónde empezar?

Lo más difícil de esta migración no es el certificado: es encontrar dónde estás usando autenticación de cliente y cambiarla sin cortar el servicio. Lo hacemos contigo, en los dos extremos de la conexión.

Leer la guía técnica completa →
Hablemos de tu caso