{"id":14802,"date":"2026-08-04T01:01:55","date_gmt":"2026-08-04T08:01:55","guid":{"rendered":"https:\/\/omnitrust.com\/blog\/ilm-2-19-0-firma-sellado-de-tiempo-y-atributos-de-solicitud\/"},"modified":"2026-09-21T01:53:20","modified_gmt":"2026-09-21T08:53:20","slug":"ilm-2-19-0-firma-sellado-de-tiempo-y-atributos-de-solicitud","status":"publish","type":"post","link":"https:\/\/omnitrust.com\/es\/blog\/ilm-2-19-0-firma-sellado-de-tiempo-y-atributos-de-solicitud\/","title":{"rendered":"ILM 2.19.0: Firma, sellado de tiempo y atributos de solicitud"},"content":{"rendered":" \n

Resumen:<\/strong> ILM 2.19.0 convierte la firma y el sellado de tiempo en capacidades de primera clase de la plataforma y elimina complejidad de PKI para la persona que solicita un certificado. Bajo la superficie, la gesti\u00f3n del estado de certificados es ahora una m\u00e1quina de estados expl\u00edcita en lugar de un conjunto de actualizaciones dispersas.<\/p> \n\r\n

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

La mayor\u00eda de las versiones a\u00f1aden funciones. Esta, sobre todo, elimina razones para salir de la plataforma: firmar algo, ponerle un sello de tiempo o explicar PKI a un desarrollador que solo quiere un certificado que funcione.<\/p> \n<\/div>\r\n\r\n

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

Una nota de versi\u00f3n es una lista de pull requests. Rara vez explica qu\u00e9 cambi\u00f3 en su forma de trabajar. Por eso, en lugar de repetir el registro de cambios, este art\u00edculo recorre los cuatro temas que realmente determinan el uso diario de ILM 2.19.0 y se\u00f1ala los cambios espec\u00edficos detr\u00e1s de cada uno.<\/p> \n \n

El registro de cambios completo se publica con la versi\u00f3n Core 2.19.0<\/a> en GitHub. Todo lo descrito a continuaci\u00f3n procede de all\u00ed.<\/p> \n\r\n

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

Las operaciones de firma ahora se registran, no solo se ejecutan<\/h2> \n \n

ILM 2.18.0 introdujo la gesti\u00f3n de perfiles de firma. Eso proporcion\u00f3 un lugar para definir c\u00f3mo se realiza la firma. Sin embargo, dej\u00f3 abierta una pregunta obvia: \u00bfqu\u00e9 ocurri\u00f3, cu\u00e1ndo y en nombre de qui\u00e9n?<\/p> \n \n

2.19.0 responde a esa pregunta. Cada operaci\u00f3n de firma produce ahora un registro de firma. Adem\u00e1s, cada perfil de firma expone un endpoint que enumera sus registros, y el panel muestra estad\u00edsticas de firma junto a las cifras de certificados y claves que ya estaban all\u00ed.<\/p> \n \n

Esto importa m\u00e1s de lo que parece. Una capacidad de firma sin pista de auditor\u00eda es dif\u00edcil de operar y a\u00fan m\u00e1s dif\u00edcil de defender durante una revisi\u00f3n. En la pr\u00e1ctica, \u00abqui\u00e9n firm\u00f3 qu\u00e9\u00bb es la primera pregunta que hace un auditor y lo \u00faltimo que puede responder un servicio de firma a\u00f1adido posteriormente.<\/p> \n\r\n

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

Sellado de tiempo que realmente puede invocar<\/h2> \n \n

El sellado de tiempo lleg\u00f3 por etapas. La gesti\u00f3n de perfiles TSP apareci\u00f3 en 2.18.0, y 2.19.0 completa el camino hacia un servicio utilizable.<\/p> \n \n

Tres cambios hacen el trabajo. Primero, un motor administrado de sellado de tiempo TSP realiza la operaci\u00f3n. Segundo, endpoints RFC 3161 invocables la exponen a clientes que ya hablan el est\u00e1ndar. Tercero, los perfiles TSP incorporaron m\u00e9todos de autenticaci\u00f3n y credenciales Basic, con un filtro de autenticaci\u00f3n dedicado delante de los endpoints de sellado de tiempo.<\/p> \n \n

Como los endpoints siguen RFC 3161, las herramientas existentes funcionan sin modificaciones. Adem\u00e1s, una cach\u00e9 de perfiles TSP mantiene la b\u00fasqueda fuera de la ruta de la solicitud, algo importante cuando el sellado de tiempo forma parte de un pipeline de compilaci\u00f3n.<\/p> \n\r\n

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

Los atributos de solicitud trasladan la dificultad fuera del solicitante<\/h2> \n \n

Este es el tema m\u00e1s grande de la versi\u00f3n y merece su propio art\u00edculo. Aun as\u00ed, conviene describir aqu\u00ed su forma general.<\/p> \n \n

Ahora, un perfil de RA puede incluir una configuraci\u00f3n de atributos de solicitud con v\u00ednculos a fuentes de valor. Por tanto, la plataforma sabe qu\u00e9 valores debe recopilar, cu\u00e1les puede derivar y cu\u00e1les nunca deber\u00eda aceptar de un cliente. Esas asignaciones de atributos se proyectan en la solicitud PKCS#10 generada, de modo que la solicitud de firma de certificado refleja la pol\u00edtica en lugar de las suposiciones.<\/p> \n \n

Las solicitudes cargadas tambi\u00e9n se gestionan. ILM valida una CSR aportada por usted contra la misma pol\u00edtica de atributos de solicitud y puede emitir un certificado a partir de una solicitud registrada previamente. Por \u00faltimo, las infracciones de pol\u00edtica se convierten en errores nativos de ACME, EST, SCEP y CMP en lugar de aparecer como fallos opacos.<\/p> \n \n

Ese \u00faltimo detalle es el que notan los operadores. Un cliente de protocolo que recibe un error correcto del protocolo puede actuar sobre \u00e9l. Uno que recibe un error interno no puede hacerlo.<\/p> \n\r\n

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

El ciclo de vida de certificados se convirti\u00f3 en una m\u00e1quina de estados<\/h2> \n \n

Antes, el estado de los certificados se actualizaba desde varios lugares. Como consecuencia, los casos l\u00edmite produc\u00edan estados que nadie pretend\u00eda, y las correcciones tend\u00edan a ser locales.<\/p> \n \n

2.19.0 introduce una m\u00e1quina de estados de certificados para las transiciones del ciclo de vida y canaliza a trav\u00e9s de ella el registro de certificados v3. Alrededor de esto, el sondeo as\u00edncrono del estado de certificados sustituye a la espera s\u00edncrona, y se dispara un evento CERTIFICATE_REGISTERED<\/code> cuando finaliza el registro previo. Las instancias de autoridad incorporaron compatibilidad v3 tanto para operaciones de ciclo de vida como de proveedor.<\/p> \n \n

Desde el punto de vista arquitect\u00f3nico, este es el cambio m\u00e1s importante de la versi\u00f3n, aunque sea el menos visible. Una m\u00e1quina de estados expl\u00edcita hace imposibles las transiciones no v\u00e1lidas en lugar de hacerlas simplemente improbables.<\/p> \n\r\n

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

Qu\u00e9 m\u00e1s conviene saber<\/h2> \n \n

Varios cambios menores ser\u00e1n importantes para equipos concretos.<\/p> \n \n

\n \n \n \n \n \n \n \n \n \n
\u00c1rea<\/th> \nCambio<\/th> \nPor qu\u00e9 importa<\/th> \n<\/tr> \n<\/thead> \n
Gobernanza<\/td> \nRol de sistema Auditor, con autorizaci\u00f3n reforzada para escritura y asignaci\u00f3n de roles<\/td> \nSupervisi\u00f3n de solo lectura sin conceder derechos operativos<\/td> \n<\/tr> \n
Extensiones<\/td> \nRegistro de OID personalizados CERTIFICATE_EXTENSION<\/code>, endpoint de listado de OID del sistema y extensiones del sistema registradas<\/td> \nLas extensiones personalizadas pasan a ser configuraci\u00f3n en lugar de c\u00f3digo<\/td> \n<\/tr> \n
Nomenclatura<\/td> \nC\u00f3digos RDN de la plataforma, como EMAIL, aceptados en DN de sujeto; conflictos de c\u00f3digos RDN resueltos<\/td> \nMenos solicitudes rechazadas por nombres de sujeto normales<\/td> \n<\/tr> \n
Rendimiento<\/td> \nLos viajes de ida y vuelta al conector se sacaron de la transacci\u00f3n de emisi\u00f3n; se omiten reescrituras redundantes de metadatos durante la importaci\u00f3n de descubrimientos<\/td> \nTransacciones m\u00e1s cortas y descubrimientos grandes m\u00e1s r\u00e1pidos<\/td> \n<\/tr> \n
Protocolos<\/td> \nRenovaci\u00f3n SCEP sin contrase\u00f1a de desaf\u00edo, entrega SCEP a claves de cliente EC y varias correcciones de funcionamiento de CMP<\/td> \nMenos callejones sin salida de protocolo en despliegues reales<\/td> \n<\/tr> \n<\/tbody> \n<\/table> \n
Cambios seleccionados en ILM 2.19.0 m\u00e1s all\u00e1 de los cuatro temas principales.<\/figcaption> \n<\/figure> \n \n

La versi\u00f3n tambi\u00e9n corrige una larga lista de defectos en notificaciones, descubrimiento y gesti\u00f3n de CMP. Si ha estado aplicando una soluci\u00f3n alternativa a alguno de ellos, merece la pena leer el registro de cambios completo.<\/p> \n\r\n

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

C\u00f3mo cambia esto lo que es ILM<\/h2> \n \n

ILM comenz\u00f3 como una plataforma de ciclo de vida de certificados. Con el tiempo a\u00f1adi\u00f3 claves, despu\u00e9s secretos y luego listas de materiales criptogr\u00e1ficos. 2.19.0 contin\u00faa en esa direcci\u00f3n, pero las incorporaciones ya no son funciones adyacentes. La firma y el sellado de tiempo son disciplinas independientes que la mayor\u00eda de las organizaciones ejecutan en productos separados.<\/p> \n \n

Consolidarlas tiene una consecuencia pr\u00e1ctica, no de marketing. Una sola plataforma significa un inventario, un modelo de autorizaci\u00f3n y una pista de auditor\u00eda \u00fanicos para certificados, claves, secretos, firmas y sellos de tiempo. Por tanto, la pregunta \u00abqu\u00e9 operaciones criptogr\u00e1ficas ocurrieron el mes pasado\u00bb tiene una sola respuesta en lugar de cuatro respuestas parciales.<\/p> \n \n

Somos claros con el alcance. ILM no reemplaza un HSM ni decide por usted su pol\u00edtica criptogr\u00e1fica. Lo que hace es dar a esas decisiones un \u00fanico lugar donde residir y un \u00fanico registro de su aplicaci\u00f3n.<\/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