Certificados X9 para mTLS: qué son, cómo se piden y cómo se usan
Un certificado X9 no sirve para poner un candado en tu sitio web. Sirve para lo contrario: para que un servidor sepa quién es el cliente que está llamando. Este artículo explica qué es esa PKI, cómo se pide y cómo se usa.
Si lo que quieres es saber si el cambio de Chrome te afecta, empieza por Chrome deja de confiar en los certificados de autenticación de cliente y vuelve aquí después.
Qué es la PKI X9
ASC X9 es el comité de estándares acreditado para servicios financieros en Estados Unidos —el que define, entre otras cosas, los formatos de mensajería entre bancos—. Su PKI es una jerarquía de certificados propia del sector financiero, con su propia raíz, pensada para que las instituciones se identifiquen entre sí.
DigiCert opera esa PKI y emite los certificados bajo ella.
Ningún navegador confía en esa raíz, y es a propósito
Esto es lo primero que hay que entender, porque es donde la gente se equivoca.
La raíz X9 no está en los almacenes de confianza de Chrome, Firefox, Safari ni Edge. Si instalas un certificado X9 en un sitio web público, el navegador lo rechaza con una advertencia de sitio no seguro. No es un defecto: es que ese certificado no está hecho para navegadores.
La confianza aquí es al revés de la del web público. En un sitio web, tu navegador confía en el servidor porque una autoridad pública lo firmó. En una PKI cerrada, las dos partes acuerdan de antemano en qué raíz confían y la instalan en sus sistemas. Por eso funciona entre instituciones que ya tienen una relación, y no funciona con un visitante anónimo.
Para qué se usa
Para mTLS: TLS mutuo, donde el cliente también presenta un certificado y el servidor lo verifica antes de dejarlo entrar.
El caso típico es una API entre instituciones financieras. El servidor no quiere sólo cifrar la conexión: quiere saber que quien llama es ese banco y no otro, y quiere saberlo antes de mirar las credenciales de la aplicación. Un certificado de cliente resuelve eso en la capa de transporte, sin tokens que se filtran ni contraseñas que rotar.
DTCC —la depositaria de valores de Estados Unidos— es el ejemplo con fechas: pidió a sus participantes migrar a certificados X9, con el entorno de pruebas (UAT) el 30 de noviembre de 2026 y producción el 31 de diciembre de 2026. Si trabajas con ellos, ese es tu calendario.
Cómo se pide
Necesitas tres cosas:
- Un CSR. Se genera igual que el de cualquier certificado: una llave privada de 2048 bits o más y una solicitud con los datos de tu organización. La llave privada no sale nunca de tu servidor.
- Los datos de la organización, exactos. Nombre legal, dirección y país tal como están registrados. La validación compara contra el registro oficial, y una abreviatura distinta retrasa la emisión.
- Los nombres que va a llevar. El certificado se emite para uno o varios identificadores; si necesitas más de uno, se agregan como SAN al hacer el pedido.
Nosotros procesamos estos pedidos de forma asistida: compras, nos envías el CSR y los datos, y llevamos la validación con la autoridad.
Cómo se usa
Del lado del cliente —el que llama—, instalas la llave privada y la cadena completa que te entregamos, y configuras tu cliente HTTP para presentarlas. En curl es --cert y --key; en Java se cargan en un keystore; en Python requests acepta la tupla cert=(crt, key).
Del lado del servidor —el que recibe—, hay que exigir el certificado y decirle en qué raíz confiar. En nginx:
ssl_client_certificate /ruta/cadena-x9.pem;
ssl_verify_client on;
ssl_verify_depth 3;
En Apache:
SSLCACertificateFile /ruta/cadena-x9.pem
SSLVerifyClient require
SSLVerifyDepth 3
Y después, en tu aplicación, lee el asunto del certificado para saber quién entró: nginx lo expone en $ssl_client_s_dn y Apache en SSL_CLIENT_S_DN.
Preguntas frecuentes
¿Puedo usarlo también para el sitio web? No. Necesitas un certificado TLS público aparte para el servidor; son dos certificados con dos propósitos.
¿Sirve el certificado de servidor que ya tengo para autenticar clientes? Hasta el 15 de marzo de 2027, en algunos casos sí. Después no: Chrome deja de aceptar el uso de autenticación de cliente en certificados públicos, y por eso existe esta migración.
¿Cuánto dura? Un año.
¿Cuántos nombres cubre? Uno, más los SAN adicionales que contrates.
¿Qué pasa si mi contraparte no tiene la raíz X9 instalada? No podrá verificarte. La instalación de la raíz en el lado que verifica es parte del acuerdo, y normalmente la exige quien opera el servicio.
Siguiente paso
Mira la ficha de DigiCert X9 Client Authentication (mTLS), donde están la garantía, los plazos y la opción de dominios adicionales. Si no sabes cuántos nombres necesitas o con qué contraparte vas a hablar, escríbenos antes de comprar.
