Discover our products
Probadlo gratis

CA privadas frente a públicas: quizá se esté usando la equivocada

Los certificados de CA pública pierden el soporte de autenticación de cliente en marzo de 2027. Cuándo hace falta una CA privada y cómo automatiza SCEPman la emisión.

CA privadas frente a públicas: quizá se esté usando la equivocada

Para un equipo de TI bajo presión, una autoridad de certificación (CA) pública parece a menudo un martillo, y cualquier requisito de cifrado parece un clavo. Pero recurrir a una CA pública para cada tarea es una de las formas más habituales de romper producción sin darse cuenta.

Para qué están hechas las CA públicas

Una CA pública (como DigiCert, Sectigo o Let’s Encrypt) está diseñada para un escenario principal: establecer confianza con dispositivos que no están bajo control propio. La idea es que los usuarios externos no tengan que configurar nada por su parte para confiar en el sitio o el servicio.

Una CA pública tiene sentido cuando:

  • Se ofrecen servicios de cara al público a usuarios externos, clientes o socios sin una relación de confianza previa con la organización
  • API o servicios externos se conectan a la infraestructura sin una configuración de cliente específica
  • Un error de certificado aparecería como una advertencia del navegador ante los usuarios finales
  • Se firman correos y los destinatarios necesitan verificar la firma sin configuración previa

El CA/Browser Forum regula qué pueden emitir las CA públicas. Eso somete a la organización a unas reglas que no controla, algo que para muchos es un intercambio razonable en los escenarios anteriores. La CA pública empieza a ser un problema cuando esos mismos certificados se usan para la autenticación interna.

Para qué están hechas las CA privadas

Una CA privada es la que opera la propia organización, o la que opera un proveedor en su nombre. La política de emisión la define ella. Los certificados no son de confianza en ningún sitio de forma predeterminada. El certificado raíz de la CA privada se distribuye a los dispositivos y a los usuarios mediante directivas de grupo, Intune o la plataforma MDM correspondiente, y a partir de ahí los endpoints gestionados confían en los certificados que emite esa CA privada.

Una CA privada encaja en todo aquello en lo que solo la infraestructura propia necesita confiar en el certificado:

  • Autenticación de dispositivos, para demostrar que un equipo está gestionado y pertenece a la organización
  • Autenticación de usuario con certificado, inicio de sesión sin contraseña, equivalentes de la tarjeta inteligente o acceso a aplicaciones internas
  • Protección de las conexiones Wi-Fi (802.1X) y VPN
  • Configuración de TLS mutuo (mTLS) entre microservicios de backend
  • Firma de código para herramientas y scripts internos

El control sobre la cadena de confianza y la política de emisión sigue siendo íntegro, sin depender de la gobernanza de una CA externa.

CA pública o CA privada: comparativa rápida

CA pública CA privada
Confían en ella Cualquier dispositivo de forma predeterminada (navegadores, almacenes de raíces del sistema operativo) Solo los dispositivos configurados de forma explícita para confiar en ella
Mejor para Sitios web de cara al exterior, API para clientes, correo S/MIME Autenticación de dispositivo, autenticación de usuario, Wi-Fi/VPN (802.1X), mTLS, firma de código interna
Quién pone las reglas El CA/Browser Forum y los programas de raíces (Chrome, Mozilla, Apple, Microsoft) La propia organización (o su proveedor de PKI)
Validez del certificado Se acorta rápido: 200 días (2026), 100 días (marzo de 2027), 47 días (marzo de 2029) El periodo de validez que tenga sentido para el entorno
Autenticación de cliente (clientAuth) En retirada total de los certificados TLS públicos para marzo de 2027 Totalmente admitida, sin restricciones
Fallo típico si se usa mal Advertencias del navegador para los usuarios externos No aplica, porque nunca se expone a dispositivos fuera del control propio

Dónde empiezan los problemas

El error más habitual de los equipos de TI es usar certificados de CA pública para la autenticación interna. Las CA públicas nunca se pensaron para las cargas de trabajo internas, y dos cambios que están ocurriendo ahora mismo hacen imposible seguir ignorando ese desajuste.

1. Se acaban los EKU de Client Authentication en el TLS público

Los certificados TLS de confianza pública ya no pueden llevar el EKU de Client Authentication. Impulsadas por la votación SC-081 del CA/Browser Forum y por las actualizaciones de los principales programas de raíces, las CA públicas están retirando clientAuth antes de la fecha límite definitiva de marzo de 2027. Si la autenticación interna de dispositivos o de usuarios depende de certificados públicos, esas configuraciones dejarán de funcionar en la siguiente renovación.

2. Periodos de validez cada vez más cortos

Las CA públicas recortan sin parar las ventanas de validez de los certificados. Con SC-081v3, el límite público se fija en 200 días (2026), baja a 100 días en marzo de 2027 y llega a 47 días en marzo de 2029. Las herramientas automáticas gestionan sin problema las renovaciones a 90 días en servidores web públicos, pero repetir el enrollment de miles de portátiles o dispositivos internos cada seis semanas es una pesadilla administrativa.

Una CA privada queda fuera de esas restricciones. Como la revocación se gestiona directamente dentro del propio entorno, no hacen falta periodos de validez artificialmente cortos ni comprobaciones de validación externas. Los periodos de validez y las reglas los fija el equipo según lo que tenga sentido en su caso.

Cómo decidir cuál usar

Para cada certificado del entorno conviene preguntarse: ¿están bajo control propio todos los dispositivos o clientes que necesitan validar ese certificado?

  • En caso afirmativo: una CA privada. Se distribuye el certificado raíz de la CA, se controla qué se emite y se deja de estar sujeto a cambios de reglas externos.
  • En caso negativo: hace falta una CA pública. Quien se conecta desde fuera sin configuración previa necesita una CA en la que su dispositivo ya confíe.

La mayoría de los departamentos de TI acaban necesitando ambas: certificados públicos para los servicios de cara al exterior y certificados privados para dispositivos, usuarios y servicios internos.

Cómo encaja SCEPman

SCEPman es una CA privada nativa de la nube que se integra con Microsoft Intune y Entra ID, y también con otras plataformas MDM mediante SCEP y EST. Se encarga de la emisión automática de certificados para dispositivos y usuarios gestionados.

En entornos de Intune, SCEPman vincula la validez del certificado al estado de cumplimiento del dispositivo. Un dispositivo que se borra o deja de cumplir las directivas pierde su certificado, lo que corta automáticamente el acceso a la Wi-Fi, la VPN y las aplicaciones internas.

SCEPman también permite emitir certificados manualmente con Certificate Master. Así, los departamentos de TI pueden sustituir los certificados de CA pública en sistemas internos como portales web, aplicaciones e interfaces de gestión de dispositivos.

Por dónde empezar

Si no está claro en qué punto se encuentra el entorno, conviene empezar por un inventario de certificados:

  • Revisar los certificados activos y las CA que los han emitido.
  • Marcar los certificados procedentes de una CA pública que lleven el EKU de Client Authentication.
  • Planificar la migración de esos certificados antes de su siguiente renovación.

Si no hay una CA privada, o si se busca abandonar el Active Directory Certificate Services (ADCS) heredado on-premises, ese es un buen punto de partida para hablar sobre SCEPman.

Probad SCEPman

Una prueba de 30 días permite comprobar cómo emite y gestiona SCEPman los certificados de CA privada para dispositivos, usuarios y servicios internos, sin la carga de mantener una PKI propia.

Iniciad la prueba de 30 días de SCEPman

Preguntas frecuentes

¿Se puede seguir usando un certificado de CA pública para la autenticación interna de dispositivos después de 2027?

Para la autenticación de cliente, no. En cuanto la CA pública elimine el EKU de clientAuth (la mayoría apunta a entre finales de 2026 y marzo de 2027), los certificados que emita solo admitirán la autenticación de servidor. Los casos de uso de autenticación interna deben pasar a una CA privada antes de que llegue ese ciclo de renovación.

¿Hay que sustituir los certificados que hoy ya tienen clientAuth?

De inmediato, no. Los certificados emitidos antes de la fecha límite de la CA siguen siendo válidos hasta que caduquen. La ruptura llega con la renovación, cuando el certificado reemitido ya no incluye clientAuth. Conviene planificar la migración antes de esa renovación, no después de que falle.

¿Es el mismo cambio que el de los periodos de validez más cortos?

No. La eliminación de clientAuth procede de la política del almacén de raíces del Chrome Root Program. El acortamiento de los periodos de validez (200 días, luego 100, luego 47) procede de una votación distinta del CA/Browser Forum, la SC-081v3. Ambos empujan en la misma dirección, la de alejar los certificados públicos del uso interno, pero son dos mandatos diferentes con dos calendarios diferentes.

¿Cuál es la forma más rápida de comprobar si esto afecta a la organización?

Inventariar los certificados activos y marcar los que lleven el EKU de Client Authentication y procedan de una CA pública. Esos son los que necesitan un plan de migración antes de su siguiente renovación.

Puestos similares