Custom PKI Advice (Custom Certificate Format)

Hey all,

I’ve got an interesting problem looking for a solution. I need to set up a custom PKI, really a PKI that needs to use a custom certificate format. Unfortunately X.509 certs even with additional attributes don’t help us, and for various reasons need our own certificate format.

Was hoping to use the PKI secrets engine for the key management, we can manage the certificate generation ourselves. But it doesn’t look like PKI offers a generic document signing API? We need to build two CAs actually, one for the intermediate cert (root CA is offline), and one for our application’s certs… but need to find a way to sign these custom certs ideally without pulling private keys out of Vault (though we could if we had to).

Looks like the Transit secrets engine provides signing as a service. Wondering if I can use this with my PKI managed keys to cobble together an overall solution?

At this point, looking for guidance or advice on a path forward. Ultimately we can look at creating our own custom plug-in using PKI as a model, but also looking for a short term solution we can work with using existing secrets engine(s).

Looking forward to any insight!

Hi Chris,

Unless you’d like to share your various reasons, I’d have to default to thinking that you’re just making work for yourself, and should just use X.509.

Thanks Max, agree this is making extra work for us. We are in a very bandwidth constrained scenario (beaming commands to a satellite tumbling in outer space) and have had to come up with a very small footprint on our communications.

Outside of custom formats, about the best I can offer is to use ECDSA certificates across the entire chain with minimal extra info and use binary DER format to minimize overhead. I’m getting 388 bytes for something like:

vault write pki/root/generate/exported common_name=“x1” key_type=ec key_bits=256 format=der exclude_cn_from_sans=true

(output is base64, you’d use the decoded binary value instead).

With Transit BYOK (new in 1.11), you could import leaf keys to sign arbitrary data. Note that they won’t have the associated X509 cert though, so you’d need to manage the association manually.

Use of an intermediate will increase overhead (by the size of a root), so maybe its worth eliding at the cost of making rotation harder?

Definitely wouldn’t recommend building your own format, you’d have to modify the entire stack… And at that point, why not use raw keys over certs? My 2c.

Thanks cipherboy, that’s a big improvement in cert size, I’ll run that by the team.

Yeah, I’ve just been exploring Transit secrets engine in more depth, and that looks like it could be a path forward for us if we need to stick with some form of roll-our-own cert or abandon that need entirely.

Appreciate the reply!