Emisión y plantillas de certificado

Un certificado no solo dice «esta clave es de este nombre»: dice también para qué se puede usar esa clave. Lo hacen dos extensiones del perfil del RFC 5280. El uso de la clave (keyUsage) indica operaciones como firmar o cifrar. El uso extendido (extendedKeyUsage, EKU) indica el propósito de alto nivel: autenticar a un servidor, autenticar a un cliente, firmar código, proteger correo. Quien valida el certificado comprueba también el propósito: un certificado de servidor no debería servir para firmar un programa.

La plantilla es donde se fija ese propósito. Una plantilla que permite «cualquier uso» elimina esa frontera: el mismo certificado sirve para todo, y si su clave se pierde, el daño no está acotado a una función.

El nombre que va en el certificado (el SAN, el nombre alternativo del sujeto) es lo que un cliente comprueba al conectarse. Si la plantilla deja que el solicitante escriba el nombre, la autoridad firma lo que le pidan: cualquier persona con permiso de solicitar puede pedir un certificado válido para cualquier nombre de la zona. La emisión es automática y correcta; lo que falla es la regla que la gobierna.

Un diseño sano hace que el nombre salga de una fuente que ya valida la identidad: el directorio, un inventario de servicios, o una aprobación humana del dueño del nombre. Abre plantillas.txt y mira la columna que dice quién define el nombre.

Una plantilla pensada para administradores de TI que sirve «para todo» parece cómoda: un solo molde y menos plantillas que mantener. Pero la comodidad se paga en acotación: ese certificado puede presentarse como servidor, como cliente o como cualquier otra cosa que una aplicación acepte, y sus 730 días de vigencia alargan el tiempo durante el que un error se queda vivo. La regla práctica es una plantilla por propósito, con la vigencia más corta que el oficio tolere.

Revisa la columna de usos permitidos de las cinco plantillas.

Auditar una emisión es cruzar dos listas: lo que se pidió y de quién es lo pedido. solicitudes.log muestra quién pidió cada certificado y para qué nombre. duenos-de-nombres.txt dice qué equipo es responsable de cada nombre interno. Si la plantilla deja que el solicitante escriba el nombre y la aprobación es automática, la autoridad no tiene cómo distinguir una petición legítima de una que no lo es: lo único que lo revela es este cruce.

Esto es una lectura de registros, no una prueba contra ningún sistema: se trata de ver, con los datos que la propia autoridad guarda, si el control de nombres se cumple.

La plantilla de servidores deja pedir cualquier nombre con aprobación automática. Hay tres arreglos posibles. Quitar el permiso de solicitar a todos es radical y paraliza a los equipos. Pedir al solicitante que «escriba bien» el nombre no cambia el diseño. Lo que cierra la brecha es mover el control a la plantilla: que el nombre salga de una fuente verificada (inventario de servicios o directorio) o que la solicitud pase por aprobación del dueño del nombre, y que el registro de dueños sea parte de la emisión, no un documento aparte.