Summary: ILM 2.19.0 makes signing and timestamping platform-first capabilities and removes PKI complexity for the certificate requester. Under the surface, certificate state management is now an explicit state machine rather than a set of scattered updates.
Most versions add features. This one, above all, eliminates reasons to leave the platform: signing something, timestamping it, or explaining PKI to a developer who just wants a working certificate.
A release note is a list of pull requests. It rarely explains what changed in how you work. So, instead of simply repeating the changelog, this article walks through the four themes that truly define the day-to-day use of ILM 2.19.0 and points out the specific changes behind each one.
The full changelog is published with Core version 2.19.0 on GitHub. Everything described below comes from there.
Signature operations are now logged, not just executed
ILM 2.18.0 introduced signature profile management. This provided a way to define how a signature is performed. However, it left an obvious question unanswered: what happened, when, and on whose behalf?
Version 2.19.0 answers that question. Each signing operation now produces a signing record. In addition, each signing profile exposes an endpoint that lists its records, and the dashboard displays signing statistics alongside the certificate and key counts that were already there.
This matters more than it seems. A signing capability without an audit trail is difficult to operate and even more difficult to defend during a review. In practice, «who signed what» is the first question an auditor asks and the last thing a signing service added later can answer.
Time sealing that can actually be invoked
Timestamping came in stages. TSP profile management appeared in 2.18.0, and 2.19.0 completes the path to a usable service.
Three changes make it work. First, a managed TSP timestamping engine performs the operation. Second, callable RFC 3161 endpoints expose it to clients that already speak the standard. Third, TSP profiles incorporate Basic authentication and credential methods, with a dedicated authentication filter in front of the timestamping endpoints.
Because the endpoints follow RFC 3161, existing tools work without modification. Furthermore, a TSP profile cache keeps the lookup off the request path, which is important when timestamping is part of a build pipeline.
The request attributes shift the difficulty away from the requester
This is the biggest issue with this version and deserves its own article. Even so, it’s worth describing its general form here.
Now, an AR profile can include a configuration of request attributes with links to value sources. Therefore, the platform knows which values to collect, which to derive, and which to never accept from a client. These attribute assignments are projected onto the generated PKCS#10 request, so the certificate signing request reflects the policy rather than assumptions.
Uploaded requests are also handled. ILM validates a CSR you provide against the same request attributes policy and can issue a certificate from a previously registered request. Finally, policy violations are now treated as native errors in ACME, EST, SCEP, and CMP instead of appearing as opaque failures.
That last detail is what operators notice. A protocol client that receives a valid protocol error can act on it. One that receives an internal error cannot.
The certificate lifecycle became a state machine
Previously, certificate status was updated from multiple locations. As a result, edge cases produced unintended statuses, and corrections tended to be local.
Version 2.19.0 introduces a certificate state machine for lifecycle transitions and channels v3 certificate registration through it. Asynchronous certificate state polling replaces synchronous waiting, and an event is triggered CERTIFICATE_REGISTEREDwhen pre-registration is complete. Authority instances incorporated v3 support for both lifecycle and provider operations.
From an architectural standpoint, this is the most significant change in this version, even if it’s the least visible. An explicit state machine makes invalid transitions impossible rather than merely improbable.
What else is useful to know
Several minor changes will be important for specific teams.
| Area | Change | Why it matters |
|---|---|---|
| Governance | Auditor system role, with enhanced authorization for writing and role assignment | Read-only supervision without granting operational rights |
| Extensions | Registration of custom OIDs CERTIFICATE_EXTENSION, system OID listing endpoint, and registered system extensions |
Custom extensions become configuration rather than code |
| Nomenclature | Platform RDN codes, such as EMAIL, accepted in subject DN; RDN code conflicts resolved | Fewer applications rejected due to normal subject names |
| Performance | Round trips to the connector were removed from the issuance transaction; redundant metadata rewrites are omitted during discovery import. | Shorter transactions and faster big discoveries |
| Protocols | SCEP renewal without challenge password, SCEP delivery to EC client keys, and various CMP functionality fixes | Fewer protocol dead ends in real-world deployments |
This release also fixes a long list of bugs in notifications, discovery, and CMP management. If you’ve been using a workaround for any of these, it’s worth reading the full changelog.
How does this change what ILM is?
ILM began as a certificate lifecycle platform. Over time, it added keys, then secrets, and then cryptographic BOMs. Version 2.19.0 continues in that direction, but the additions are no longer adjacent features. Signing and timestamping are independent disciplines that most organizations run in separate products.
Consolidating them has a practical consequence, not a marketing one. A single platform means a single inventory, authorization model, and audit trail for certificates, keys, secrets, signatures, and timestamps. Therefore, the question «what cryptographic transactions occurred last month» has a single answer instead of four partial ones.
We’re clear about the scope. ILM doesn’t replace an HSM or decide your cryptographic policy for you. What it does is give those decisions a single place to reside and a single record of your application.
Key points
- Each signing operation now leaves a signature record, enumerable by signature profile and visible in the dashboard statistics.
- Timestamping can be invoked via RFC 3161, supported by a managed engine and authenticated TSP profiles.
- RA profiles include request attribute policy with links to value sources, and violations return native errors from ACME, EST, SCEP, and CMP.
- Certificate lifecycle transitions go through an explicit state machine, with asynchronous state polling behind it.
- A custom auditor role and OID registry turn monitoring and certificate extensions into a tailored workplace configuration.
ILM is open source, so you can read about every change behind this version yourself. If you want to see what the platform covers before committing, start with 10 things you can create with ILM or read why we made ILM open source . To discuss a specific deployment, contact us .
