Chrome deja de confiar en los certificados de autenticación de cliente: qué cambia el 15 de marzo de 2027

Actualizado el 11 sep. 2026

El Chrome Root Program está quitando la autenticación de cliente a los certificados TLS de confianza pública. No es un cambio de recomendación ni un aviso de seguridad: es una fecha a partir de la cual ciertos certificados dejan de servir para lo que hoy sirven.

Si dos de tus sistemas se identifican entre sí con un certificado TLS público — un gateway de API que exige certificado de cliente, una integración con un socio, una llamada entre servicios — este artículo es para ti.

Las fechas

La última es la que corta. Desde ese día, un certificado emitido por una CA de confianza pública ya no puede usarse para autenticar a un cliente, y el apretón de manos que dependa de eso falla.

Qué se rompe y qué no

Se rompe cualquier TLS mutuo donde el certificado que presenta el cliente venga de una autoridad pública. El síntoma no es una advertencia: es una conexión rechazada.

No se rompe nada de esto:

• Los certificados de servidor. Tu sitio web sigue igual; el cambio afecta al uso de clave de autenticación de cliente, no al de servidor.
• Las CA privadas e internas. Si tus certificados de cliente los emite tu propia CA, nada cambia para ti.
• El cifrado. Esto no es un problema de algoritmos ni de fuerza: es de para qué se permite usar un certificado.

Cómo saber si te afecta

Lo más difícil de esta migración no es el certificado: es acordarse de dónde se usa. Tres lugares donde mirar:

1. Gateways de API y balanceadores. Busca la configuración que exige certificado de cliente — en nginx es ssl_verify_client on; con ssl_client_certificate; en Apache, SSLVerifyClient require con SSLCACertificateFile.
2. Llamadas entre servicios y trabajos programados. Integraciones que corren de madrugada y que nadie mira hasta que fallan.
3. Lo que te exigen tus socios. Si alguien te pidió un certificado para conectarse a su API, ese es uno.

Cuando tengas un certificado a mano, pregúntale para qué sirve:

openssl x509 -in certificado.pem -noout -ext extendedKeyUsage

Si en la respuesta aparece TLS Web Client Authentication, ese certificado hace autenticación de cliente. Ahora mira quién lo emitió:

openssl x509 -in certificado.pem -noout -issuer

Si el emisor es una autoridad pública — DigiCert, Sectigo, GlobalSign, Let's Encrypt — es uno de los que dejan de funcionar. Si es una CA tuya, respira.

Las opciones

Hay tres caminos y conviene elegir con los ojos abiertos.

Montar o mantener una CA interna. Funciona, y para comunicación estrictamente dentro de tu organización suele ser lo correcto. El costo no es el software: es operarla — rotar la raíz, distribuir la confianza, responder cuando alguien pregunte quién la audita. Y entre organizaciones distintas obliga a un acuerdo uno a uno con cada socio.

Una PKI administrada. Le pagas a alguien por operar lo anterior. Resuelve la operación, no la interoperabilidad: sigue siendo tu raíz, y el socio del otro lado tiene que aceptarla.

La PKI X9. Una infraestructura pensada precisamente para este hueco: la opera DigiCert, la gobierna un comité de políticas del Accredited Standards Committee X9 —el organismo de estándares del sector financiero— y se audita cada año bajo WebTrust, igual que una CA pública. Está deliberadamente fuera del CA/Browser Forum y de los programas de navegadores, de manera que una decisión tomada para la web no vuelva a romper la confianza entre máquinas.

La diferencia práctica con una CA interna es la raíz común: dos organizaciones que no se conocen pueden confiar la una en la otra porque confían en la misma autoridad auditada, sin negociar nada entre ellas.

Cómo migrar sin cortar el servicio

El orden importa más que la velocidad. Hecho así, los dos certificados son válidos durante todo el cambio y no hay ventana de caída.

1. Inventario. Lista cada punto donde se presenta un certificado de cliente, con qué nombre o IP se presenta, y qué autoridad lo emitió.

2. Separa lo que se rompe. Solo los emitidos por una CA pública. Los internos quedan fuera.

3. Pide el certificado nuevo con los nombres o direcciones IP que presenta cada cliente y el uso de clave de autenticación de cliente. En X9 el certificado admite tanto nombres de dominio como direcciones IP, incluidas las de rangos privados.

4. Instala la raíz nueva en el lado del servidor, junto a la que ya está. Este es el paso que evita la caída: el servidor pasa a aceptar las dos.

   Copy

   # nginx: un solo archivo con las dos raíces concatenadas
   ssl_client_certificate /etc/ssl/certs/raices-confiables.pem;
   ssl_verify_client on;
   

5. Cambia los certificados de cliente, uno por uno, comprobando cada conexión.

6. Solo entonces quita la raíz antigua del almacén de confianza.

Si te saltas el paso 4 y cambias primero los certificados, el servidor rechaza a los clientes nuevos hasta que alguien se acuerde de la raíz — y eso se descubre en producción.

Preguntas frecuentes

¿Esto afecta a mi sitio web? No. El certificado de tu sitio hace autenticación de servidor, y eso no cambia.

¿Los navegadores van a confiar en la raíz X9? No, y es a propósito. Un certificado X9 sirve para autenticar sistemas entre sí; si lo pones en un sitio web, el navegador lo rechaza. Para un sitio web necesitas un SSL normal.

¿Puedo seguir usando mi CA interna? Sí. Si toda la comunicación es dentro de tu organización, es una opción legítima y no te afecta ninguna de estas fechas.

¿Y si no llego al 15 de marzo de 2027? Las conexiones que dependan de un certificado público para autenticar clientes empiezan a fallar. No se degradan: dejan de conectar.

Dónde seguir

En TiendaSSL vendemos el certificado X9 de autenticación de cliente, con validación de organización y emisión en uno o dos días hábiles. Si prefieres no hacer la migración tú, nuestro servicio de instalación cubre los dos extremos de la conexión.