La crisis de identidad cliente-servidor: por qué no se debería usar un solo certificado para ambas funciones

En PKI y TLS, los certificados son credenciales digitales que demuestran identidad. Si una misma credencial intenta asumir a la vez dos roles distintos y de alta confianza, como sucede al combinar los usos extendidos de clave (EKU) serverAuth y clientAuth en un único certificado, se difuminan los límites de seguridad.

Aunque es técnicamente posible y a veces conveniente, esta práctica constituye un antipatrón de seguridad. Veamos por qué es arriesgada y cómo diseñar una estrategia de certificados más segura.

El certificado “para todo”: un atajo tentador

Un uso extendido de clave (EKU) es una extensión X.509 que define la finalidad de un certificado. Los dos EKU más comunes para TLS son:

• serverAuth (OID: 1.3.6.1.5.5.7.3.1): autoriza el certificado a autenticar un servidor (por ejemplo, un sitio HTTPS).
• clientAuth (OID: 1.3.6.1.5.5.7.3.2): autoriza el certificado a autenticar un cliente (por ejemplo, un cliente de API, usuario o servicio).

Es posible crear un certificado con ambos EKU, especialmente en entornos de desarrollo o sistemas heredados:

openssl req -new -key device.key -out device.csr -addext "extendedKeyUsage = serverAuth, clientAuth"

La simplicidad es atractiva: se administra un certificado en lugar de dos. Sin embargo, esta comodidad tiene un coste de seguridad.

Problema principal: infringe el principio de mínimo privilegio

El principio de mínimo privilegio (PoLP) establece que toda entidad (usuario, sistema o certificado) debe recibir únicamente los permisos necesarios para su función prevista.

Un certificado con serverAuth y clientAuth tiene privilegios excesivos por diseño:

• Un servidor escucha y responde solicitudes; no debería tener autoridad para iniciar solicitudes como cliente autenticado.
• Un cliente inicia solicitudes a servidores de confianza; no debería poder hacerse pasar por servidor.

Si un atacante compromete un certificado de servidor que también tiene permisos clientAuth, podría utilizarlo para autenticarse en otros servicios internos que confían en certificados de cliente y desplazarse lateralmente por la red.

Analogía: la llave maestra de una bóveda bancaria (servidor) no debería abrir también todas las cajas de seguridad (cliente) que contiene.

Problemas técnicos y operativos

1. Uso de clave inadecuado: los certificados de servidor y cliente suelen tener extensiones keyUsage diferentes. Un servidor puede necesitar keyEncipherment (por ejemplo, para el intercambio de claves RSA), mientras que un cliente puede necesitar solo digitalSignature. Un certificado combinado puede tener permisos demasiado amplios.

2. Gestión del ciclo de vida compleja: si hay que rotar el certificado de un desarrollador y ese mismo certificado también se usa en un servidor crítico, la rotación se convierte en una operación compleja y de alto riesgo.

3. Dificultades de auditoría y cumplimiento: un certificado para varias funciones dificulta determinar su propósito, revisar accesos y limitar el alcance de una posible exposición.

La manera correcta: certificados dedicados

Use certificados distintos, diseñados para cada rol.

Certificado de servidor

Incluya solo el EKU de autenticación de servidor y los usos de clave adecuados:

openssl req -new -key server.key -out server.csr -subj "/CN=api.mycompany.com/O=MyOrg/OU=Server" -addext "extendedKeyUsage = serverAuth" -addext "keyUsage = digitalSignature, keyEncipherment"

Certificado de cliente

Incluya el EKU de autenticación de cliente y los usos de clave correspondientes:

openssl req -new -key client.key -out client.csr -subj "/CN=backend-service-account/O=MyOrg/OU=Client" -addext "extendedKeyUsage = clientAuth" -addext "keyUsage = digitalSignature"

Ventajas de este enfoque

• Alcance del incidente limitado: un certificado de servidor comprometido no se puede reutilizar para autenticarse como cliente.
• Control granular: los certificados de cliente y servidor se revocan y rotan de forma independiente.
• Auditoría clara: el propósito de cada certificado es explícito.
• Mejor adaptación al cumplimiento: se alinea con los marcos de seguridad modernos.

¿Hay ocasiones en las que se pueden combinar?

Las excepciones son muy poco frecuentes y requieren una justificación sólida.

• Dispositivos integrados con recursos muy limitados: en algunos escenarios IoT donde solo se puede almacenar un certificado, combinar funciones puede ser inevitable. Evalúe y mitigue cuidadosamente el riesgo.
• Proxies de malla de servicios interna: algunas arquitecturas especializadas (como Istio) usan certificados para mTLS entre proxies. En estos entornos controlados, el plano de control de la malla puede gestionar ambos roles, no los propietarios de las aplicaciones.

Para el 99 % de los casos —incluidas aplicaciones web, API, microservicios y cuentas de servicio— lo correcto es utilizar certificados separados.

Conclusión: la especialización es una virtud

En seguridad, la especialización es una fortaleza. No se usa un certificado de CA raíz para firmar correos cotidianos; del mismo modo, no se debería utilizar un solo certificado para varias identidades de máquina distintas.

Los certificados dedicados para autenticación de servidor y cliente producen sistemas más resilientes, administrables y seguros, eliminan riesgos innecesarios y respetan principios fundamentales de ciberseguridad. PKI Trust Manager ayuda a aplicar políticas y evitar malas prácticas mediante una gestión disciplinada de certificados.