Resumen: Los atributos de solicitud de ILM permiten que un perfil de RA declare qué necesita una solicitud de certificado, de dónde proviene cada valor y qué nunca puede establecer un cliente. Así, el solicitante completa un formulario breve en lugar de aprender PKI, y las garantías de confianza permanecen exactamente donde estaban.
Nadie quiere un certificado. Quiere aquello que deja de funcionar sin él. Cada pregunta adicional que usted haga es un costo que está imponiendo por su propia política.
Piense en lo que normalmente enfrenta un desarrollador al solicitar un certificado interno. ¿Qué plantilla? ¿Qué algoritmo y tamaño de clave? ¿Qué extensiones, con qué usos de clave? ¿Qué debe incluir el sujeto y en qué orden? ¿Cuál de los distintos tipos de nombre alternativo del sujeto corresponde aquí?
Cada pregunta tiene una respuesta correcta. Sin embargo, rara vez el desarrollador es la persona que la conoce. Así que la respuesta llega copiando una solicitud anterior, preguntando a un colega o adivinando. Luego la solicitud se rechaza y el ciclo se repite.
Mientras tanto, el equipo de PKI recibe la culpa por ser lento. En realidad, se le está pidiendo que controle decisiones que nunca correspondieron al solicitante.
Qué declaran realmente los atributos de solicitud
Ahora, un perfil de RA en ILM puede incluir una configuración de atributos de solicitud. Esa configuración es una declaración de política, no una definición de formulario. Indica qué atributos tiene una solicitud y vincula cada uno con una fuente de valor.
Esos vínculos son la parte importante. Un valor puede recopilarse del solicitante, derivarse por la plataforma o fijarse mediante política. Por consiguiente, el perfil codifica tres tipos diferentes de conocimiento que antes vivían en una página wiki.
| Fuente del valor | Quién decide | Ejemplo típico |
|---|---|---|
| Recopilado | El solicitante | El nombre de host para el que es el certificado |
| Derivado | La plataforma | Propietario y grupo, tomados de la identidad autenticada |
| Fijado por política | El equipo de PKI, una sola vez | Algoritmo de clave, uso de clave, conjunto de extensiones |
Lea la tabla como una división del trabajo. Al solicitante solo se le pregunta aquello que realmente conoce. Todo lo demás se deriva o ya está decidido.
La política llega hasta la propia solicitud
Un formulario que recopila los valores correctos solo resuelve la mitad del problema. Después, esos valores deben llegar correctamente a la solicitud de firma de certificado.
ILM proyecta las asignaciones de campos de atributos en la solicitud PKCS#10 generada. Por tanto, la CSR refleja la política 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ón que completó el solicitante.
Las solicitudes cargadas reciben el mismo tratamiento. Si aporta su propia CSR, ILM la valida contra la política de atributos de solicitud del perfil de RA en lugar de aceptarla sin más. Además, una solicitud puede registrarse primero y emitirse después, de modo que el registro previo y la emisión sean pasos separados cuando un flujo de trabajo lo requiera.
Errores sobre los que un cliente de protocolo puede actuar
Este es el detalle que determina si todo esto se siente fluido. La mayoría de las solicitudes de certificados ni siquiera provienen de una persona. Provienen de clientes ACME, EST, SCEP o CMP que se ejecutan sin supervisión.
Cuando un cliente de este tipo infringe la política, un error genérico no sirve. El cliente no puede interpretarlo, no puede volver a intentarlo de forma útil y no puede informar nada accionable. Alguien termina leyendo un registro días después.
ILM convierte las infracciones de la política 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ás, el conjunto de atributos de solicitud se puede resolver mediante el endpoint de atributos de CSR, para que un cliente pueda consultar qué se espera antes de componer nada.
Preguntar a la plataforma qué necesita es un protocolo mejor que adivinar y ser rechazado.
Extensiones sin código personalizado
Las extensiones de certificados son una razón habitual por la que las organizaciones acaban manteniendo herramientas a medida. Una política necesita una extensión personalizada y, de repente, la ruta de emisión incorpora un parche.
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í, una extensión personalizada pasa a ser configuración. Además, se aceptan códigos RDN de la plataforma como EMAIL en los nombres de sujeto, lo que elimina una clase conocida de solicitudes rechazadas.
Fluido no significa permisivo
Sería fácil interpretar todo esto como una relajación del control. Es justamente lo contrario, y la distinción importa.
Antes, un solicitante podía incluir casi cualquier cosa en una CSR, y el trabajo de la plataforma era detectarlo después. Ahora el perfil establece qué está permitido, los valores que el cliente no debería controlar se derivan o se fijan, y las solicitudes cargadas se comprueban contra la misma política. En otras palabras, menos preguntas para el solicitante y menos oportunidades de equivocarse.
La confianza en una PKI proviene de aplicar la política 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ía en lugar de reducirla.
Una salvedad sincera: alguien todavía tiene que redactar la política. Los atributos de solicitud no deciden qué debe permitir su PKI. Hacen que esa decisión sea explícita, reutilizable y aplicable desde un único lugar, en vez de ser interpretada repetidamente por personas que están adivinando.
Puntos clave
- Un perfil de RA declara sus atributos de solicitud y vincula cada uno con una fuente de valor: recopilado, derivado o fijado mediante política.
- Las asignaciones de atributos se proyectan en la solicitud PKCS#10 generada, de modo que la CSR incorpora la política en lugar de depender de las suposiciones del cliente.
- Las CSR cargadas se validan contra la misma política, y las solicitudes pueden registrarse previamente y emitirse más tarde.
- Las infracciones de política devuelven errores nativos de ACME, EST, SCEP y CMP, y los clientes pueden consultar primero el conjunto de atributos esperado.
- Un registro de OID personalizados y la aceptación de códigos RDN de la plataforma convierten el manejo de extensiones en configuración.
Los atributos de solicitud se incorporaron en ILM Core 2.19.0. Para conocer el resto de esa versión, consulte qué cambió en 2.19.0. Si la reducción de la vigencia de los certificados le está impulsando hacia la automatización, lea la cuenta atrás de 47 días y 10 cosas que puede crear con ILM. Para diseñar un perfil para su propio entorno, póngase en contacto con nosotros.
