¿Autenticación con certificados públicos? Deténgase. Lo que debe cambiar antes de 2026
En mayo de 2026, las autoridades de certificación pública (CA) dejarán de admitir la autenticación de clientes TLS debido a las nuevas reglas del programa raíz de Chrome. Las organizaciones que dependen de certificados SSL/TLS públicos para la autenticación de usuarios, dispositivos o aplicaciones deberán cambiar a CA privadas. Este cambio afecta a las VPN, mTLS, la incorporación de Wi-Fi y mucho más. Las soluciones modernas de CA privadas, combinadas con la gestión del ciclo de vida de los certificados (CLM), ofrecen una vía segura y escalable para avanzar.
En mayo de 2026 se producirá un cambio fundamental en la infraestructura de clave pública (PKI), que la mayoría de las organizaciones no están siguiendo, pero que muchas notarán. Debido a los requisitos actualizados del Programa raíz de Chrome y a los recientes anuncios de las autoridades de certificación (CA), las CA públicas ya no emitirán certificados que admitan la autenticación de clientes TLS.
Para las organizaciones que dependen de estos certificados para autenticar usuarios, dispositivos o aplicaciones, este cambio supone una fecha límite ineludible. Los flujos de trabajo de autenticación existentes, especialmente aquellos que dependen de CA públicas gratuitas o automatizadas, comenzarán a fallar a menos que las organizaciones migren a CA privadas.
Este cambio no es una actualización de la política en casos excepcionales. Se trata de una reestructuración que redefine la forma en que se debe gestionar la autenticación en toda la infraestructura corporativa. Y llega mucho antes de lo que la mayoría cree.
El cambio de política que hay detrás
El origen de este cambio se encuentra en la Política 1.6 del Programa Root de Chrome, que exige que las jerarquías de certificados incluidas en el almacén de confianza de Chrome se dediquen exclusivamente a la autenticación de servidores TLS a partir de junio de 2026. En resumen, las CA públicas ya no podrán emitir certificados que contengan los usos de clave extendidos (EKU) id-kp-serverAuth e id-kp-clientAuth. Estos EKU definen para qué se puede utilizar un certificado y, en este caso, para la autenticación de servidores o de clientes.
La aplicación ya está en marcha.
Sectigo ha anunciado que, a partir del 15 de septiembre de 2025, dejará de incluir por defecto el EKU de autenticación de cliente en los certificados SSL/TLS recién emitidos. Y, antes del 15 de mayo de 2026, Sectigo eliminará definitivamente el EKU de autenticación de cliente de todos los certificados SSL/TLS recién emitidos. Después de esta fecha, no se concederá ninguna excepción.
Este cambio de política sigue una tendencia más amplia de los navegadores de tolerancia cero con la revocación tardía. En lugar de seguir tolerando los certificados públicos de uso mixto, Chrome ha optado por la claridad: la PKI pública es solo para la autenticación de servidores. Si necesita autenticación de clientes, utilice una CA privada.
¿Qué es la autenticación de clientes TLS y por qué podría estar utilizándola?
La autenticación de clientes TLS permite a los sistemas verificar la identidad de los clientes, usuarios, dispositivos o aplicaciones cuando intentan conectarse a un servidor. Se diferencia de la autenticación de servidores TLS (utilizada en HTTPS), más conocida, que verifica los sitios web.
Algunos casos de uso comunes son:
- Acceso VPN para emitir certificados a los portátiles de los empleados con el fin de verificar su identidad cuando se conectan de forma remota.
- Integración Wi-Fi para autenticar los dispositivos de los empleados y proteger las redes sin compartir contraseñas estáticas.
- Inicio de sesión en Salesforce u otros flujos de trabajo de SSO que dependen de certificados de cliente integrados en dispositivos finales.
- TLS mutuo (mTLS) para API, especialmente en canalizaciones CICD o entre microservicios en arquitecturas de confianza cero.
- Identidad de dispositivos o cargas de trabajo en entornos DevOps, incluidos los servicios basados en contenedores.
La cuestión clave es la siguiente: muchas organizaciones utilizan sin saberlo CA públicas para la autenticación de clientes en estos flujos de trabajo, a menudo porque es fácil, barato o viene incluido con herramientas de automatización como ACME.
Google Chrome ha convertido la eliminación de la autenticación de clientes en una condición previa para que las raíces permanezcan en el almacén de raíces de Chrome. Dado que la mayoría de los demás navegadores siguen los mismos programas de raíces, los certificados de autenticación de clientes verdaderamente fiables a nivel mundial desaparecerán.
Una vez que las principales CA de confianza pública terminen de eliminar las EKU de autenticación de clientes de sus líneas TLS en 2025/2026, las organizaciones que sigan dependiendo de un certificado de autenticación de clientes TLS para identificar a los clientes tendrán dificultades (y pronto será imposible) para encontrar sustitutos. Todas las grandes CA públicas han publicado ya un calendario de eliminación progresiva.
CA privadas modernas: ya no son tan complicadas como antes
La autenticación de clientes es, fundamentalmente, una función de seguridad interna. Requiere flexibilidad, un control minucioso y la garantía de que los certificados no serán revocados por cambios en las políticas externas. Las CA públicas nunca se diseñaron para este fin.
Hasta hace poco, muchas organizaciones las utilizaban de todos modos, a menudo sin darse cuenta de las implicaciones. Los certificados públicos eran fáciles de obtener, se podían automatizar y no requerían una infraestructura PKI interna. Pero tenían limitaciones:
- Perfiles de certificado fijos que no se pueden modificar para adaptarse a los casos de uso internos.
- Auditorías públicas y requisitos de cumplimiento del CA/Browser Forum.
- Sin control sobre los plazos de emisión, los criterios de revocación o la política de ciclo de vida.
- Exposición a cambios en las políticas de los navegadores y las plataformas, como los que se están produciendo actualmente.
Por el contrario, las autoridades de certificación privadas ofrecen a las organizaciones un control total sobre la emisión, el diseño de perfiles, la revocación, la renovación y la automatización. Y lo que es más importante, no están sujetas a restricciones externas del programa raíz. Además, hoy en día, las soluciones modernas de CA privadas son mucho más fáciles de implementar que en el pasado.
Históricamente, las CA privadas tenían fama de ser caras, difíciles de gestionar y lentas de implementar. Las organizaciones tenían que crear una infraestructura PKI desde cero, a menudo utilizando herramientas obsoletas y procesos manuales.
Eso ya no es así.
Las CA privadas modernas, especialmente las nativas en la nube como Sectigo, se pueden aprovisionar en cuestión de minutos, se escalan automáticamente y admiten protocolos como ACME, EST y SCEP para una inscripción de certificados sin problemas. Ofrecen:
- Perfiles de certificados personalizables para una amplia gama de casos de uso interno.
- CA privadas por caso de uso, si se desea separar las funciones.
- Compatibilidad total con API para la integración en DevOps, MDM y plataformas de seguridad.
- Automatización del ciclo de vida y aplicación de políticas a través de plataformas de gestión del ciclo de vida de los certificados (CLM).
Esta evolución es tan significativa que ha contribuido a desencadenar el propio cambio de política de Chrome. Como señaló Jason Soroko, Senior Fellow de Sectigo:
«Google se siente con la capacidad de hacer esto porque sabe que por fin disponemos de opciones de CA privadas ligeras y llave en mano. Si esto hubiera sido hace 15 años, no habrían podido dar el paso».
En otras palabras, la infraestructura de CA privada por fin ha alcanzado el nivel necesario para resolver el problema para el que fue creada.
Cómo completa el panorama la CLM
Pasarse a una CA privada no consiste solo en sustituir los certificados, sino en tomar el control de cómo se gestionan esos certificados.
Ahora que la vida útil de los certificados SSL/TLS es de 47 días, ya no es viable realizar un seguimiento de los certificados con hojas de cálculo o esperar que los scripts de renovación sigan funcionando. La visibilidad, la automatización y la aplicación de políticas deben integrarse desde el principio.
Ahí es donde entra en juego la gestión del ciclo de vida de los certificados (CLM). Una plataforma CLM robusta le ayuda a:
- Descubrir todos los certificados de su entorno, tanto públicos como privados.
- Clasificar y etiquetar los certificados por caso de uso, sistema y caducidad.
- Automatizar la emisión, renovación y revocación a gran escala.
- Aplicar políticas sobre la longitud de las claves, EKU, plantillas de perfiles y mucho más.
- Evitar interrupciones debidas a certificados caducados o mal configurados.
- Ver todos sus certificados desde una vista unificada en un único panel, ya sean privados o públicos.
Por muy buena que sea su CA, sin CLM le resultará difícil mantener la agilidad a medida que el panorama digital sigue evolucionando rápidamente.
«Todos los caminos conducen a CLM», como dijo Jason. «Todos los certificados deberían haberse gestionado desde el principio».
Qué debe hacer a continuación
1. Mapear su PKI interna
Empiece por identificar dónde se utiliza la autenticación de clientes TLS en su organización:
- ¿Qué dispositivos, aplicaciones o servicios se autentican con certificados?
- ¿Qué autoridades de certificación los han emitido?
- ¿Alguno de estos certificados se emite a través de flujos de trabajo ACME públicos (por ejemplo, Let's Encrypt)?
Si no está seguro, Sectigo Certificate Manager puede ayudarle a descubrir e inventariar los certificados internos en entornos cloud, locales e híbridos.
2. Evalúe el riesgo y el calendario
Como se ha mencionado, todas las CA públicas deberán eliminar por completo el soporte para la autenticación de clientes TLS antes de mayo de 2026. Cualquier certificado que admita la autenticación de clientes emitido por estas fuentes deberá sustituirse por un certificado emitido por una CA privada.
3. Implemente una CA privada moderna
La solución de CA privada basada en la nube de Sectigo le permite emitir y gestionar certificados para:
- Autenticación VPN y Wi-Fi
- Identidad de dispositivos y cargas de trabajo
- Autenticación mTLS y API
- Entornos de desarrollo y canalizaciones CI/CD
Está diseñada para una implementación rápida y se adapta a cualquier entorno. Con compatibilidad con ACME, EST y SCEP, e integraciones listas para usar en Microsoft ADCS y plataformas de identidad en la nube, puede poner en línea una PKI privada sin fricciones en la infraestructura.
4. Automatice con la gestión del ciclo de vida de los certificados
Una vez que su CA privada esté operativa, el siguiente paso es garantizar una visibilidad y automatización completas. Sectigo Certificate Manager le ofrece:
- Inventario completo de todos los certificados (públicos y privados)
- Políticas de emisión basadas en roles
- Renovación y rotación automáticas
- Alertas de caducidad y registro de auditorías
La PKI privada ya no es opcional
La eliminación gradual de la autenticación de clientes TLS de las CA públicas no es solo una actualización de la política, sino un cambio estructural en la forma en que se debe gestionar la autenticación. Elimina una muleta en la que muchas organizaciones se han apoyado sin saberlo durante años.
La buena noticia es que la CA privada ya no es la barrera que solía ser. Y con las herramientas de gestión de certificados ganando terreno, nunca ha habido un mejor momento para recuperar el control.
Si todavía está pasando contraseñas de Wi-Fi o utilizando certificados de cliente de CA públicas para autenticar ordenadores portátiles, es hora de actuar. La infraestructura que necesita está disponible y la fecha límite está fijada.
Sectigo ofrece la solución que su organización necesita para seguir cumpliendo con la normativa y ser ágil. Con una CA privada llave en mano, la mejor de su clase, independiente de CA y una plataforma segura, sencilla y escalable, puede fusionar sus certificados públicos y privados en uno solo.
