mTLS en apps móviles: autenticar al cliente, no solo al servidor

Qué es mTLS

TLS mutuo (mutual TLS o mTLS) es TLS estándar con la autenticación de cliente activada. Durante el handshake el servidor pide un certificado, el cliente lo presenta y demuestra que posee la clave privada correspondiente. Si algo falla, la conexión se corta antes de que viaje un solo byte de la petición HTTP.

No es un protocolo nuevo ni propietario: está en TLS desde el principio y tu servidor web ya sabe hacerlo. Lo que históricamente ha impedido usarlo en apps de consumo no es el protocolo, sino la logística de emitir, distribuir, renovar y revocar un certificado por dispositivo.

Qué problema resuelve en una app móvil

El backend de una app móvil no tiene forma fiable de saber quién le está hablando. La cabecera User-Agent se falsifica, una API key incrustada en el binario se extrae con herramientas estándar, y un token de sesión solo demuestra que alguien se autenticó antes, no qué cliente lo está usando ahora.

Un certificado por dispositivo cambia la pregunta: en vez de comprobar un secreto compartido que viaja en cada petición, se comprueba la posesión de una clave privada que nunca sale del dispositivo.

El problema real: el ciclo de vida del certificado

Aquí es donde fracasan la mayoría de los intentos caseros de mTLS en móvil. Emitir el primer certificado es fácil; lo difícil es todo lo demás.

• Aprovisionamiento: cómo obtiene su certificado una instalación nueva sin que ese proceso sea, a su vez, un endpoint abierto al abuso.
• Almacenamiento: la clave privada debe generarse y quedarse en el almacén de claves del sistema, idealmente con respaldo por hardware.
• Rotación: los certificados de corta duración reducen el daño de una filtración, pero exigen renovación automática y silenciosa.
• Revocación: hace falta un mecanismo, típicamente OCSP, para invalidar el certificado de un dispositivo concreto sin esperar a que caduque.

Cómo encaja con tu backend

La validación la hace tu propio servidor de entrada. En Nginx se traduce en indicar la cadena de CA que se acepta y exigir el certificado en las rutas que lo requieran; el resto de tu arquitectura no cambia.

Como la comprobación ocurre en el borde y en la capa de transporte, el tráfico rechazado no llega a tu aplicación: no consume trabajadores, ni conexiones a base de datos, ni cuota de tu proveedor de SMS.