Resumen: 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ón del estado de certificados es ahora una máquina de estados explícita en lugar de un conjunto de actualizaciones dispersas.
La mayoría de las versiones añaden 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.
Una nota de versión es una lista de pull requests. Rara vez explica qué cambió en su forma de trabajar. Por eso, en lugar de repetir el registro de cambios, este artículo recorre los cuatro temas que realmente determinan el uso diario de ILM 2.19.0 y señala los cambios específicos detrás de cada uno.
El registro de cambios completo se publica con la versión Core 2.19.0 en GitHub. Todo lo descrito a continuación procede de allí.
Las operaciones de firma ahora se registran, no solo se ejecutan
ILM 2.18.0 introdujo la gestión de perfiles de firma. Eso proporcionó un lugar para definir cómo se realiza la firma. Sin embargo, dejó abierta una pregunta obvia: ¿qué ocurrió, cuándo y en nombre de quién?
2.19.0 responde a esa pregunta. Cada operación de firma produce ahora un registro de firma. Además, cada perfil de firma expone un endpoint que enumera sus registros, y el panel muestra estadísticas de firma junto a las cifras de certificados y claves que ya estaban allí.
Esto importa más de lo que parece. Una capacidad de firma sin pista de auditoría es difícil de operar y aún más difícil de defender durante una revisión. En la práctica, «quién firmó qué» es la primera pregunta que hace un auditor y lo último que puede responder un servicio de firma añadido posteriormente.
Sellado de tiempo que realmente puede invocar
El sellado de tiempo llegó por etapas. La gestión de perfiles TSP apareció en 2.18.0, y 2.19.0 completa el camino hacia un servicio utilizable.
Tres cambios hacen el trabajo. Primero, un motor administrado de sellado de tiempo TSP realiza la operación. Segundo, endpoints RFC 3161 invocables la exponen a clientes que ya hablan el estándar. Tercero, los perfiles TSP incorporaron métodos de autenticación y credenciales Basic, con un filtro de autenticación dedicado delante de los endpoints de sellado de tiempo.
Como los endpoints siguen RFC 3161, las herramientas existentes funcionan sin modificaciones. Además, una caché de perfiles TSP mantiene la búsqueda fuera de la ruta de la solicitud, algo importante cuando el sellado de tiempo forma parte de un pipeline de compilación.
Los atributos de solicitud trasladan la dificultad fuera del solicitante
Este es el tema más grande de la versión y merece su propio artículo. Aun así, conviene describir aquí su forma general.
Ahora, un perfil de RA puede incluir una configuración de atributos de solicitud con vínculos a fuentes de valor. Por tanto, la plataforma sabe qué valores debe recopilar, cuáles puede derivar y cuáles nunca debería 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ítica en lugar de las suposiciones.
Las solicitudes cargadas también se gestionan. ILM valida una CSR aportada por usted contra la misma política de atributos de solicitud y puede emitir un certificado a partir de una solicitud registrada previamente. Por último, las infracciones de política se convierten en errores nativos de ACME, EST, SCEP y CMP en lugar de aparecer como fallos opacos.
Ese último detalle es el que notan los operadores. Un cliente de protocolo que recibe un error correcto del protocolo puede actuar sobre él. Uno que recibe un error interno no puede hacerlo.
El ciclo de vida de certificados se convirtió en una máquina de estados
Antes, el estado de los certificados se actualizaba desde varios lugares. Como consecuencia, los casos límite producían estados que nadie pretendía, y las correcciones tendían a ser locales.
2.19.0 introduce una máquina de estados de certificados para las transiciones del ciclo de vida y canaliza a través de ella el registro de certificados v3. Alrededor de esto, el sondeo asíncrono del estado de certificados sustituye a la espera síncrona, y se dispara un evento CERTIFICATE_REGISTERED cuando finaliza el registro previo. Las instancias de autoridad incorporaron compatibilidad v3 tanto para operaciones de ciclo de vida como de proveedor.
Desde el punto de vista arquitectónico, este es el cambio más importante de la versión, aunque sea el menos visible. Una máquina de estados explícita hace imposibles las transiciones no válidas en lugar de hacerlas simplemente improbables.
Qué más conviene saber
Varios cambios menores serán importantes para equipos concretos.
| Área | Cambio | Por qué importa |
|---|---|---|
| Gobernanza | Rol de sistema Auditor, con autorización reforzada para escritura y asignación de roles | Supervisión de solo lectura sin conceder derechos operativos |
| Extensiones | Registro de OID personalizados CERTIFICATE_EXTENSION, endpoint de listado de OID del sistema y extensiones del sistema registradas |
Las extensiones personalizadas pasan a ser configuración en lugar de código |
| Nomenclatura | Códigos RDN de la plataforma, como EMAIL, aceptados en DN de sujeto; conflictos de códigos RDN resueltos | Menos solicitudes rechazadas por nombres de sujeto normales |
| Rendimiento | Los viajes de ida y vuelta al conector se sacaron de la transacción de emisión; se omiten reescrituras redundantes de metadatos durante la importación de descubrimientos | Transacciones más cortas y descubrimientos grandes más rápidos |
| Protocolos | Renovación SCEP sin contraseña de desafío, entrega SCEP a claves de cliente EC y varias correcciones de funcionamiento de CMP | Menos callejones sin salida de protocolo en despliegues reales |
La versión también corrige una larga lista de defectos en notificaciones, descubrimiento y gestión de CMP. Si ha estado aplicando una solución alternativa a alguno de ellos, merece la pena leer el registro de cambios completo.
Cómo cambia esto lo que es ILM
ILM comenzó como una plataforma de ciclo de vida de certificados. Con el tiempo añadió claves, después secretos y luego listas de materiales criptográficos. 2.19.0 continúa en esa dirección, pero las incorporaciones ya no son funciones adyacentes. La firma y el sellado de tiempo son disciplinas independientes que la mayoría de las organizaciones ejecutan en productos separados.
Consolidarlas tiene una consecuencia práctica, no de marketing. Una sola plataforma significa un inventario, un modelo de autorización y una pista de auditoría únicos para certificados, claves, secretos, firmas y sellos de tiempo. Por tanto, la pregunta «qué operaciones criptográficas ocurrieron el mes pasado» tiene una sola respuesta en lugar de cuatro respuestas parciales.
Somos claros con el alcance. ILM no reemplaza un HSM ni decide por usted su política criptográfica. Lo que hace es dar a esas decisiones un único lugar donde residir y un único registro de su aplicación.
Puntos clave
- Cada operación de firma deja ahora un registro de firma, enumerable por perfil de firma y visible en las estadísticas del panel.
- El sellado de tiempo puede invocarse mediante RFC 3161, respaldado por un motor administrado y perfiles TSP autenticados.
- Los perfiles de RA incluyen política de atributos de solicitud con vínculos a fuentes de valor, y las infracciones devuelven errores nativos de ACME, EST, SCEP y CMP.
- Las transiciones del ciclo de vida de certificados pasan por una máquina de estados explícita, con sondeo asíncrono del estado detrás de ella.
- Un rol de auditor y un registro de OID personalizados convierten la supervisión y las extensiones de certificados en configuración en lugar de trabajo a medida.
ILM es de código abierto, por lo que puede leer por sí mismo cada cambio detrás de esta versión. Si quiere ver qué cubre la plataforma antes de comprometerse con ella, empiece por 10 cosas que puede crear con ILM o lea por qué hicimos ILM de código abierto. Para hablar sobre un despliegue específico, hable con nosotros.
