A self-service system that issued, delivered, and audited TLS certificates and keys end to end — so an unskilled user could do it safely with the touch of a button, and no one ever pasted a private key into an email again.
The closest commercial product cost about $1M and still couldn't deliver a key to a running server. This one did — and it's still in production more than fifteen years later.
See the DesignIt started with a mistake anyone could make.
Someone put the wrong TLS certificate on the wrong host. Once was enough to see it would keep happening — and to realize the problem wasn't carelessness, it was that the whole process was manual, error-prone, and unsafe. Private keys were being pasted into group emails. OpenSSL's command-line options are labyrinthine, so even careful people got them wrong. And the piece nobody had solved was the last mile: getting the right key onto the right server, safely, and proving it happened.
The first version was PKI automation that wrapped the labyrinth in a simple interface — give it a hostname, get back exactly what you need, delivered where it belongs. Word got around that there was finally a tool for TLS certificates, and a large bank's security team asked for one of their own. We built it, in the language their team could actually support, into a full encryption key management and delivery service.
Underneath, it unified two halves of a commercial PKI that had never really been married together (the vendor had bought two companies and left the seam showing), and it drove the bank's Luna hardware security modules — which the bank had purchased but couldn't figure out how to use — turning an idle hardware root of trust into something people could actually rely on. On top, an unsophisticated user could create a certificate for a hostname and deliver it to the application servers with one click. To make that last mile real, we instrumented the bank's own systems-management tooling to carry the key the final step and restart the service.
TLS certificates were only the obvious use case. Underneath, the system was a master class in what we call indirect selection: you could accomplish almost anything with it, but only by declaring exactly what you intended to do.
You never got shell access. Nothing happened without an explicit, named action — and every action left an audit trail: who did it, when, what they asked for, and what the result was, unbroken from key creation through delivery to service restart. Power was exposed only as declared, audited operations, never as open-ended access to the machine. That is what made it safe to hand something this sensitive to a user with no security background — the interface simply wouldn't let them do an undeclared, unaudited thing.
It's the same principle behind everything we build now: declared intent, no ad-hoc shell, and a complete audit trail by construction. Get the interface right — expose capability as explicit, recorded actions — and safety stops depending on the user being an expert.
~$1M commercial tool, no last mile
The one commercial offering that came close cost about $1M — and still couldn't deliver a key to a running server. This system did, end to end.
One-click issue and delivery
A user with no security background could issue a certificate and push it to the app servers safely — because the interface only allowed declared, audited actions.
In production a decade and a half on
Built once, right — last we heard it was still in daily use, and it earned the bank's highest internal service award at the time.
Secrets, keys, and privileged operations — exposed as simple, declared, fully-audited actions, so the right thing is the easy thing.
Get in Touch