On this page

• The key is the one thing you cannot take back
• How it works
• Nothing to install, nothing to configure
• What you can hold
• Post-quantum, today
• Certificates on the token
• Who may use which key
• Revoking takes one click
• What every key was used for
• What it is, and what it is not

The key is the one thing you cannot take back

Rotate a password and the old one is worthless. Revoke a token and it stops working. A private key is different: once a copy exists somewhere you did not intend, nothing you do afterwards makes that copy stop signing. You can revoke the certificate — and everything signed before the revocation date stays valid.

Which is why the release-signing key ends up on a build server, in a CI secret, in someone's home directory and in three backups, and why nobody can honestly answer how many copies there are. The usual fix is an HSM: real hardware, real assurance, and a project with a purchase order, a rack, a driver and a network path attached.

The Keystore takes the useful half of that idea and removes the project. The key is generated in the portal and never leaves it. Applications reach it through the same PKCS#11 interface an HSM speaks, so the tools you already use — Java, OpenSSL, osslsigncode, jarsigner, your own code — talk to it without being modified.

How it works

1. The key is created in the portal. Pick a name, an algorithm and what it may do — sign, decrypt, or both. It is encrypted at rest with your platform encryption key. Already have a key? Import it — PEM, DER, PKCS#12, or raw bytes for an AES or HMAC secret — and it becomes a key like any other, permanently marked as imported so an auditor can see it once existed elsewhere.

2. You register the application. Not the server — the application: nginx, a JVM, one signing script. Each gets its own credential, which is the PKCS#11 PIN it will use, shown once and stored only as a hash.

3. You grant it a key. One line, and the agent on that host brings up its PKCS#11 listener and installs the module. Keys and applications are many-to-many, so one signing script can hold four keys under a single PIN, exactly as a real token behaves.

4. The application signs. It calls the module, the agent forwards the request over the connection it already holds, the portal checks the credential, the calling account and the grant, does the operation and returns the result. The key stays where it was.

Nothing to install, nothing to configure

This is the part that usually decides whether a key-management project ever finishes. A PKCS#11 deployment normally means shipping a vendor library to every host, matching its version to the client, keeping it patched, and writing a configuration file per application that points at slots and token serials.

Here the module arrives with the grant. The moment a key is granted to an application on a host, the agent fetches the module from the portal and installs it at a fixed path. Revoke the last grant and the listener is torn down and the module removed. There is no package to add to your build, no version to track, and nothing to do on a new server beyond installing the agent you were installing anyway.

What the application needs to know is four values, and three of them are the same on every host:

Java's SunPKCS11 takes the same module path and the same PIN. So does OpenSSL 3 through pkcs11-provider, and every tool built on p11-kit. The module is native code with no runtime dependency of its own, and ships for Linux and Windows: the agent picks the build its host needs and writes it under the same file name either way, so the only thing that differs is the directory.

What you can hold

Every key carries a use that is enforced rather than advertised: a signing key cannot be talked into decrypting, and the constraint is checked in the database as well as the API. Supported mechanisms cover RSA PKCS#1 v1.5 and OAEP, ECDSA, AES-GCM, AES key wrap and HMAC. Key generation through PKCS#11 is deliberately absent — keys are created in the portal, where there is an operator, a policy and an audit trail, not by whatever happens to be holding a PIN.

Post-quantum, today

Signatures made now are checked years from now. That makes signing the place where post-quantum stops being a 2030 problem: firmware, releases, archived documents and long-lived attestations all have to survive whatever exists at the far end of their life, not today.

ManageLM offers ML-DSA — the NIST standard, FIPS 204 — in all three strengths, alongside RSA and EC on the same page, with the same grants and the same module. Creating a post-quantum key is choosing a different entry in a dropdown. Two things are worth planning for: ML-DSA signs only, so replacing an RSA key that also decrypts means two keys; and its signatures are kilobytes rather than bytes, so check that whatever stores them has room.

Certificates on the token

A key signs on its own, but most consumers will not touch one without a certificate saying whose signature it is. Java will not even present the key as usable, and the code-signing tools need the chain to build a signature at all. So each key holds its certificate chain, and the module serves it over PKCS#11 as a real certificate object paired with the key — which is what makes the tools see one entry rather than an orphaned key.

1. Create the CSR from the key. Fill in the subject, send the request to your CA. The key never has to exist anywhere for this to happen.

2. Upload the answer. PEM, DER, PKCS#7 or PKCS#12, whole chain or just the leaf. The leaf is matched against the key's own public half — a certificate belonging to a different key is refused — then the chain is put in order for you.

3. Watch it expire. The key's row shows valid, expiring or expired at a glance, and Replace installs the renewal without touching the key or any grant.

Who may use which key

The unit of authorisation is one application on one host, not the host. nginx and a JVM on the same machine are two different principals with two different credentials, and neither can use the other's keys. Two independent things have to agree before an operation happens:

Refusals tell the caller nothing. Whatever the real reason — wrong PIN, wrong account, suspended grant, disabled key, no such key — the application gets one undifferentiated error, so something that can reach the socket cannot map out which credentials exist or which account would have worked. The real reason is in the portal, for you.

Revoking takes one click

Nothing is cached, and every operation is authorised from scratch — so each of these takes effect on the very next signature, with no restart and no propagation delay:

• Suspend a grant — that application loses that key and keeps the rest.
• Disable a key — every application loses it at once, and it stops even being listed on the token.
• Disable an application — it loses every key on that host, while its configuration survives for when the incident is over.
• Rotate its credential — the old PIN stops working immediately.

All four are reversible with the same click, which is the point: during an incident you want the fastest thing that is also undoable. And because the key never left the portal, revoking access is genuinely revoking access — there is no copy on a host still able to sign after you have finished.

What every key was used for

The Usage tab counts operations per key, per application, per mechanism, per day — how many succeeded, how many were turned down. Expand a line with refusals and it shows the most recent reason, the account that asked and when: the reason the application itself was never told.

Counts rather than a line per signature, deliberately. A key signing a million times a day costs exactly the same as one signing twice, so a busy application can never crowd out the rest of the history and the record stays useful for a year rather than a fortnight. It also makes the awkward questions answerable in one query — what is still signing with SHA-1, which application has been failing since Tuesday, has this key been touched at all since we created it.

What it is, and what it is not

Three limits are worth stating plainly, because knowing them is what makes the feature useful in the right place: