{"id":14794,"date":"2026-08-05T01:50:52","date_gmt":"2026-08-05T08:50:52","guid":{"rendered":"https:\/\/omnitrust.com\/blog\/atributos-de-solicitud-de-ilm-pki-sin-la-clase-magistral-de-pki\/"},"modified":"2026-09-21T01:53:19","modified_gmt":"2026-09-21T08:53:19","slug":"atributos-de-solicitud-de-ilm-pki-sin-la-clase-magistral-de-pki","status":"publish","type":"post","link":"https:\/\/omnitrust.com\/es\/blog\/atributos-de-solicitud-de-ilm-pki-sin-la-clase-magistral-de-pki\/","title":{"rendered":"Atributos de solicitud de ILM: PKI sin la clase magistral de PKI"},"content":{"rendered":" \n

Resumen:<\/strong> Los atributos de solicitud de ILM permiten que un perfil de RA declare qu\u00e9 necesita una solicitud de certificado, de d\u00f3nde proviene cada valor y qu\u00e9 nunca puede establecer un cliente. As\u00ed, el solicitante completa un formulario breve en lugar de aprender PKI, y las garant\u00edas de confianza permanecen exactamente donde estaban.<\/p> \n\r\n

\u00a0<\/div>\r\n\r\n
\n

Nadie quiere un certificado. Quiere aquello que deja de funcionar sin \u00e9l. Cada pregunta adicional que usted haga es un costo que est\u00e1 imponiendo por su propia pol\u00edtica.<\/p> \n<\/div>\r\n\r\n

\u00a0<\/div>\r\n \n

Piense en lo que normalmente enfrenta un desarrollador al solicitar un certificado interno. \u00bfQu\u00e9 plantilla? \u00bfQu\u00e9 algoritmo y tama\u00f1o de clave? \u00bfQu\u00e9 extensiones, con qu\u00e9 usos de clave? \u00bfQu\u00e9 debe incluir el sujeto y en qu\u00e9 orden? \u00bfCu\u00e1l de los distintos tipos de nombre alternativo del sujeto corresponde aqu\u00ed?<\/p> \n \n

Cada pregunta tiene una respuesta correcta. Sin embargo, rara vez el desarrollador es la persona que la conoce. As\u00ed que la respuesta llega copiando una solicitud anterior, preguntando a un colega o adivinando. Luego la solicitud se rechaza y el ciclo se repite.<\/p> \n \n

Mientras tanto, el equipo de PKI recibe la culpa por ser lento. En realidad, se le est\u00e1 pidiendo que controle decisiones que nunca correspondieron al solicitante.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

Qu\u00e9 declaran realmente los atributos de solicitud<\/h2> \n \n

Ahora, un perfil de RA en ILM puede incluir una configuraci\u00f3n de atributos de solicitud. Esa configuraci\u00f3n es una declaraci\u00f3n de pol\u00edtica, no una definici\u00f3n de formulario. Indica qu\u00e9 atributos tiene una solicitud y vincula cada uno con una fuente de valor.<\/p> \n \n

Esos v\u00ednculos son la parte importante. Un valor puede recopilarse del solicitante, derivarse por la plataforma o fijarse mediante pol\u00edtica. Por consiguiente, el perfil codifica tres tipos diferentes de conocimiento que antes viv\u00edan en una p\u00e1gina wiki.<\/p> \n \n

\n \n \n \n \n \n \n \n
Fuente del valor<\/th> \nQui\u00e9n decide<\/th> \nEjemplo t\u00edpico<\/th> \n<\/tr> \n<\/thead> \n
Recopilado<\/td> \nEl solicitante<\/td> \nEl nombre de host para el que es el certificado<\/td> \n<\/tr> \n
Derivado<\/td> \nLa plataforma<\/td> \nPropietario y grupo, tomados de la identidad autenticada<\/td> \n<\/tr> \n
Fijado por pol\u00edtica<\/td> \nEl equipo de PKI, una sola vez<\/td> \nAlgoritmo de clave, uso de clave, conjunto de extensiones<\/td> \n<\/tr> \n<\/tbody> \n<\/table> \n
Los atributos de solicitud vinculan cada valor con quien leg\u00edtimamente es responsable de la decisi\u00f3n.<\/figcaption> \n<\/figure> \n \n

Lea la tabla como una divisi\u00f3n del trabajo. Al solicitante solo se le pregunta aquello que realmente conoce. Todo lo dem\u00e1s se deriva o ya est\u00e1 decidido.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

La pol\u00edtica llega hasta la propia solicitud<\/h2> \n \n

Un formulario que recopila los valores correctos solo resuelve la mitad del problema. Despu\u00e9s, esos valores deben llegar correctamente a la solicitud de firma de certificado.<\/p> \n \n

ILM proyecta las asignaciones de campos de atributos en la solicitud PKCS#10 generada. Por tanto, la CSR refleja la pol\u00edtica del perfil en lugar de lo que haya ensamblado una biblioteca cliente. El sujeto y las extensiones se construyen a partir de la misma declaraci\u00f3n que complet\u00f3 el solicitante.<\/p> \n \n

Las solicitudes cargadas reciben el mismo tratamiento. Si aporta su propia CSR, ILM la valida contra la pol\u00edtica de atributos de solicitud del perfil de RA en lugar de aceptarla sin m\u00e1s. Adem\u00e1s, una solicitud puede registrarse primero y emitirse despu\u00e9s, de modo que el registro previo y la emisi\u00f3n sean pasos separados cuando un flujo de trabajo lo requiera.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

Errores sobre los que un cliente de protocolo puede actuar<\/h2> \n \n

Este es el detalle que determina si todo esto se siente fluido. La mayor\u00eda de las solicitudes de certificados ni siquiera provienen de una persona. Provienen de clientes ACME, EST, SCEP o CMP que se ejecutan sin supervisi\u00f3n.<\/p> \n \n

Cuando un cliente de este tipo infringe la pol\u00edtica, un error gen\u00e9rico no sirve. El cliente no puede interpretarlo, no puede volver a intentarlo de forma \u00fatil y no puede informar nada accionable. Alguien termina leyendo un registro d\u00edas despu\u00e9s.<\/p> \n \n

ILM convierte las infracciones de la pol\u00edtica de atributos de solicitud en errores nativos de ACME, EST, SCEP y CMP. Como el error llega en el vocabulario propio del protocolo, el cliente puede comportarse correctamente. Adem\u00e1s, el conjunto de atributos de solicitud se puede resolver mediante el endpoint de atributos de CSR, para que un cliente pueda consultar qu\u00e9 se espera antes de componer nada.<\/p> \n \n

\n
\n

Preguntar a la plataforma qu\u00e9 necesita es un protocolo mejor que adivinar y ser rechazado.<\/p> \n<\/blockquote> \n<\/figure> \n\r\n

\u00a0<\/div>\r\n \n

Extensiones sin c\u00f3digo personalizado<\/h2> \n \n

Las extensiones de certificados son una raz\u00f3n habitual por la que las organizaciones acaban manteniendo herramientas a medida. Una pol\u00edtica necesita una extensi\u00f3n personalizada y, de repente, la ruta de emisi\u00f3n incorpora un parche.<\/p> \n \n

ILM ahora incorpora un registro de OID personalizados para extensiones de certificados, registra las extensiones del sistema que conoce y expone un endpoint que enumera los OID del sistema. As\u00ed, una extensi\u00f3n personalizada pasa a ser configuraci\u00f3n. Adem\u00e1s, se aceptan c\u00f3digos RDN de la plataforma como EMAIL en los nombres de sujeto, lo que elimina una clase conocida de solicitudes rechazadas.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

Fluido no significa permisivo<\/h2> \n \n

Ser\u00eda f\u00e1cil interpretar todo esto como una relajaci\u00f3n del control. Es justamente lo contrario, y la distinci\u00f3n importa.<\/p> \n \n

Antes, un solicitante pod\u00eda incluir casi cualquier cosa en una CSR, y el trabajo de la plataforma era detectarlo despu\u00e9s. Ahora el perfil establece qu\u00e9 est\u00e1 permitido, los valores que el cliente no deber\u00eda controlar se derivan o se fijan, y las solicitudes cargadas se comprueban contra la misma pol\u00edtica. En otras palabras, menos preguntas para el solicitante y menos oportunidades de equivocarse.<\/p> \n \n

La confianza en una PKI proviene de aplicar la pol\u00edtica de forma coherente. Nunca ha dependido de obligar a las personas a demostrar que la entienden. Por tanto, trasladar la dificultad al perfil aumenta la garant\u00eda en lugar de reducirla.<\/p> \n \n

Una salvedad sincera: alguien todav\u00eda tiene que redactar la pol\u00edtica. Los atributos de solicitud no deciden qu\u00e9 debe permitir su PKI. Hacen que esa decisi\u00f3n sea expl\u00edcita, reutilizable y aplicable desde un \u00fanico lugar, en vez de ser interpretada repetidamente por personas que est\u00e1n adivinando.<\/p> \n\r\n

\u00a0<\/div>\r\n
\r\n
\u00a0<\/div>\r\n\r\n
\n

Puntos clave<\/h3> \n\r\n\r\n \n