TL;DR: ILM request attributes let an RA profile declare what a certificate request needs, where each value comes from, and what a client may never set. So the requester answers a short form instead of learning PKI, and the trust guarantees stay exactly where they were.
Nobody wants a certificate. They want the thing that stops working without one. Every question you ask beyond that is a tax you are charging for your own policy.
Consider what a developer usually faces when requesting an internal certificate. Which template? Which key algorithm and size? Which extensions, with which key usages? What belongs in the subject, and in which order? Which of the several subject alternative name types applies here?
Each question has a correct answer. However, the developer is rarely the person who knows it. So the answer arrives by copying a previous request, asking a colleague, or guessing. Then the request is rejected, and the cycle repeats.
Meanwhile the PKI team gets the blame for being slow. In reality they are being asked to police decisions that were never the requester’s to make.
What request attributes actually declare
An RA profile in ILM can now carry a request-attribute configuration. That configuration is a policy statement, not a form definition. It says which attributes a request has, and it binds each one to a value source.
Those bindings are the important part. A value can be collected from the requester, derived by the platform, or fixed by policy. Consequently the profile encodes three different kinds of knowledge that used to live in a wiki page.
| Value source | Who decides | Typical example |
|---|---|---|
| Collected | The requester | The hostname the certificate is for |
| Derived | The platform | Owner and group, taken from the authenticated identity |
| Fixed by policy | The PKI team, once | Key algorithm, key usage, extension set |
Read the table as a division of labour. The requester is asked only for what they genuinely know. Everything else is either derived or already decided.
The policy reaches the request itself
A form that collects the right values is only half the problem. The values must then reach the certificate signing request correctly.
ILM projects the attribute field mappings into the generated PKCS#10 request. Therefore the CSR reflects the profile’s policy rather than whatever a client library happened to assemble. The subject and extensions are built from the same declaration the requester filled in.
Uploaded requests get the same treatment. If you bring your own CSR, ILM validates it against the RA profile’s request-attribute policy instead of accepting it on trust. Also, a request can be registered first and issued later, so pre-registration and issuance are separate steps when a workflow needs them to be.
Errors that a protocol client can act on
Here is the detail that decides whether any of this feels seamless. Most certificate requests do not come from a person at all. They come from ACME, EST, SCEP, or CMP clients running unattended.
When such a client violates policy, a generic failure is useless. The client cannot interpret it, cannot retry usefully, and cannot report anything actionable. Someone reads a log days later.
ILM shapes request-attribute policy violations into native ACME, EST, SCEP, and CMP errors. Because the error arrives in the protocol’s own vocabulary, the client can behave correctly. Furthermore the request-attribute set is resolvable over the CSR-attributes endpoint, so a client can ask what is expected before it composes anything.
Asking the platform what it needs is a better protocol than guessing and being rejected.
Extensions without custom code
Certificate extensions are a common reason organisations end up maintaining bespoke tooling. A policy needs one custom extension, and suddenly the issuance path has a patch in it.
ILM now carries a custom-OID registry for certificate extensions, registers the system extensions it knows about, and exposes an endpoint listing system OIDs. So a custom extension becomes configuration. Additionally, platform RDN codes such as EMAIL are accepted in subject names, which removes a familiar class of rejected request.
Seamless is not the same as lax
It would be easy to read all of this as loosening control. The opposite is true, and the distinction matters.
Before, a requester could put almost anything in a CSR, and the platform’s job was to catch it afterwards. Now the profile states what is allowed, values the client should not control are derived or fixed, and uploaded requests are checked against the same policy. In other words, fewer questions for the requester and fewer opportunities to get it wrong.
Trust in a PKI comes from the policy being applied consistently. It has never come from making people prove they understand it. Therefore moving the difficulty into the profile raises assurance rather than lowering it.
One honest caveat: someone still has to write the policy. Request attributes do not decide what your PKI should permit. They make that decision explicit, reusable, and enforced in one place instead of interpreted repeatedly by people who are guessing.
Key Takeaways
- An RA profile declares its request attributes and binds each to a value source: collected, derived, or fixed by policy.
- Attribute mappings project into the generated PKCS#10 request, so the CSR carries policy rather than client guesswork.
- Uploaded CSRs are validated against the same policy, and requests can be pre-registered then issued later.
- Policy violations return native ACME, EST, SCEP, and CMP errors, and clients can query the expected attribute set first.
- A custom-OID registry and accepted platform RDN codes turn extension handling into configuration.
Request attributes shipped in ILM Core 2.19.0. For the rest of that release, see what 2.19.0 changed. If shorter certificate lifetimes are pushing you toward automation, read the 47-day countdown and 10 things you can build with ILM. To design a profile for your own estate, get in touch.
