TL;DR: ILM 2.19.0 turns signing and timestamping into first-class platform capabilities, and it moves PKI complexity off the person requesting a certificate. Under the surface, certificate status handling is now an explicit state machine rather than a set of scattered updates.
Most releases add features. This one mostly removes reasons to leave the platform: to sign something, to stamp a time on it, or to explain PKI to a developer who only wants a working certificate.
A release note is a list of pull requests. It rarely tells you what changed about the way you work. So rather than restate the changelog, this post walks through the four themes that actually shape day-to-day use of ILM 2.19.0, and it points at the specific changes behind each one.
The full changelog is published with the Core 2.19.0 release on GitHub. Everything described below comes from it.
Signing operations are now recorded, not just performed
ILM 2.18.0 introduced signing profile management. That gave you a place to define how signing happens. However, it left an obvious question open: what happened, when, and on whose behalf?
2.19.0 answers it. Every signing operation now produces a signing record. Furthermore, each signing profile exposes an endpoint that lists its records, and the dashboard reports signing statistics alongside the certificate and key figures already there.
This matters more than it sounds. A signing capability without an audit trail is difficult to operate and harder to defend during a review. In practice, “who signed what” is the first question an auditor asks and the last thing a bolt-on signing service can answer.
Timestamping you can actually call
Timestamping arrived in stages. TSP profile management landed in 2.18.0, and 2.19.0 completes the path to a usable service.
Three changes do the work. First, a managed TSP timestamping engine handles the operation itself. Second, callable RFC 3161 endpoints expose it to clients that already speak the standard. Third, TSP profiles gained authentication methods and Basic credentials, with a dedicated authentication filter in front of the timestamping endpoints.
Because the endpoints follow RFC 3161, existing tooling works without modification. Also, a TSP profile cache keeps the lookup off the request path, which matters when timestamping sits in a build pipeline.
Request attributes move the difficulty off the requester
This is the largest theme in the release, and it deserves its own post. Still, the shape is worth describing here.
An RA profile can now carry a request-attribute configuration with value-source bindings. Therefore the platform knows which values it must collect, which it can derive, and which it should never accept from a client. Those attribute mappings project into the generated PKCS#10 request, so the certificate signing request reflects policy rather than guesswork.
Uploaded requests are handled too. ILM validates a CSR you bring yourself against the same request-attribute policy, and it can issue a certificate from a request registered earlier. Finally, policy violations are shaped into native ACME, EST, SCEP, and CMP errors instead of surfacing as opaque failures.
That last detail is the one operators notice. A protocol client that receives a correct protocol error can act on it. One that receives an internal error cannot.
Certificate lifecycle became a state machine
Certificate status used to be updated from several places. Consequently, edge cases produced states nobody intended, and the fixes tended to be local.
2.19.0 introduces a certificate state machine for lifecycle transitions, and it routes v3 certificate registration through it. Around that, asynchronous certificate-status polling replaces synchronous waiting, and a CERTIFICATE_REGISTERED event fires when pre-registration completes. Authority instances gained v3 support for both lifecycle and provider operations.
Architecturally this is the most consequential change in the release, even though it is the least visible. An explicit state machine makes invalid transitions impossible rather than merely unlikely.
What else is worth knowing
Several smaller changes will matter to specific teams.
| Area | Change | Why it matters |
|---|---|---|
| Governance | Auditor system role, with hardened write and role-assignment authorization | Read-only oversight without handing out operational rights |
| Extensions | CERTIFICATE_EXTENSION custom-OID registry, system OID listing endpoint, registered system extensions |
Custom extensions become configuration rather than code |
| Naming | Platform RDN codes such as EMAIL accepted in subject DNs, RDN code conflicts resolved | Fewer rejected requests from ordinary subject names |
| Performance | Connector round-trips moved out of the issuance transaction; redundant metadata rewrites skipped during discovery import | Shorter transactions and faster large discoveries |
| Protocols | SCEP renewal without a challenge password, SCEP delivery to EC client keys, several CMP correctness fixes | Fewer protocol dead ends in real deployments |
The release also closes a long tail of defects across notifications, discovery, and CMP handling. If you have been working around one of those, it is worth reading the changelog in full.
How this changes what ILM is
ILM began as a certificate lifecycle platform. Over time it added keys, then secrets, then cryptographic bills of materials. 2.19.0 continues that direction, but the additions are no longer adjacent features. Signing and timestamping are separate disciplines that most organisations run on separate products.
Consolidating them has a practical consequence rather than a marketing one. One platform means one inventory, one authorization model, and one audit trail across certificates, keys, secrets, signatures, and timestamps. Therefore the question “what cryptographic operations happened last month” has a single answer instead of four partial ones.
We are honest about scope. ILM does not replace an HSM, and it does not decide your cryptographic policy for you. What it does is give those decisions one place to live and one record of being applied.
Key Takeaways
- Every signing operation now leaves a signing record, listable per signing profile and visible in dashboard statistics.
- Timestamping is callable over RFC 3161, backed by a managed engine and authenticated TSP profiles.
- RA profiles carry request-attribute policy with value-source bindings, and violations return native ACME, EST, SCEP, and CMP errors.
- Certificate lifecycle transitions run through an explicit state machine, with asynchronous status polling behind it.
- An auditor role and a custom-OID registry make oversight and certificate extensions configuration rather than custom work.
ILM is open source, so you can read every change behind this release yourself. If you want to see what the platform covers before committing to it, start with 10 things you can build with ILM, or read why we open-sourced it. To discuss a specific deployment, talk to us.
