PKI features (more details, privkey access)

[Bitsky]

Is your feature request related to a problem? Please describe.
Stored certificates lack a lot of information. There is only the certificate and its serial number in the details. That makes managing certs via the UI almost impossible without copy&pasting the certs to openssl for more information. I'm aware certs should be automated, but that is not always possible.

Describe the solution you'd like

1. Display not only the serials in the cert list, but also the common name and start/end dates.
2. Automatically show e.g. cert information like "openssl -text -noout" when accessing details.
3. Allow retrieval of private keys. With wildcard CNs and long expiry, you need the key more than once over time.

Describe alternatives you've considered
Creating an extra kv engine for storing privkeys for certificates. But it sounds error-prone and increases maintenance (e.g. kv entries need to be deleted when certs are removed).

[Godwottery]

I would like to "+1" this idea.
1 & 2 would be sufficient for me, I have no need to retrieve the private key as it is simple to generate a new certificate if the private key gets lost.

Where would someone interested in implementing this start to look?

[jefferai]

Neither of them are actually feasible at this point so I can't give you pointers for any kind of straightforward implementation, unfortunately.

[Godwottery]

Does that mean that Vault stores only the serial number and the public key? If so then I understand that this might not be feasible.

Would it be feasible to display more information when clicking on the serial number, ie under "...secrets/pki/show/cert..."?

[jefferai]

Vault lists certs in its backing storage indexed by serial number. To return more details in a list operation would require reading every single entry when building the response, which in many installs would be millions of entries.

[Bitsky]

I worked around it with an external helper script which generates a cert with key export via the api and in the process stores all relevant information in a kv under the path of the primary cert name. It's not really a pretty solution imho but at least it allows me easy access to all the cert details I need, whenever I need them, plus the history when certs get renewed. That way, only one single cert can officially be active for a given hostname.

[drawks]

@jefferai it seems like you're dismissing this as infeasible based on one, flawed, design. Sure it would be slow (perhaps too slow) to read in every cert on demand in order to present a list with details. However, it would be very cheap to populate a hash keyed on the serials with the details of each certificate when the certs are first generated/stored and then in the ui give the user some display options to make the ui work for, you know, users to interface with.... I don't know about you, but to me a huge list of 20 byte hex encoded serials is pretty much worthless to me, as a human...

[drawks]

@Godwottery That should be totally doable entirely in the display layer, since all the information you care about is encoded in the cert and should be able to trivially be programatically access/rendered using javascript.

[jefferai]

@drawks Such a hash would have to be kept in sync with the underlying state of the set of active certificates. Outside of actual coordination/sync issues that can arise, this also means at least one extra persist operation per certificate generated, but more importantly it means having to read that value out into memory when the plugin starts up, and disallowing operations in the plugin until it's read.

It's not something that can't be done. It's just not straightforward to implement, and while there's a library we have that might help here it's sort of in a transition/flux state. So there'd be a lot of work to actually get this done, it's not a trivial feature ask.

[mister2d]

@jefferai How are people retrieving known certificates? Keeping the serial numbers stored in an external database?

[adityagu0910]

HI @Bitsky
is it possible for you to share helper script that you created and also how you implemented it ?

[Bessonov]

Seems to be related: #4724

[hellobontempo]

Hi there! Thank you all for the discussion around this feature request! 😄 We're excited about the new PKI beta UI coming in 1.13

Confirming that #2 is complete: parsing certificate data was added to the UI in 1.9 #12541 and more certificate details are surfaced in the PKI beta UI released in 1.13 #18737 (see PR for screenshots)

Because there can be millions of certificates, we’re unable to show any certificate details in the LIST view and at this time don’t have a way to parse this data for the list view without negatively impacting performance.

[jpedrick]

@hellobontempo , I would think pagination would resolve the "millions of certificates" problem in the list view. This is probably my single biggest complaint about the Vault UI in general, all the information you're interested in is hidden behind random strings. Seems like the opposite of a "User Interface" to essentially have humans memorize pointers or click each and every one. shrug

[raskchanky]

@jpedrick The lack of pagination is a shortcoming of Vault itself, not of the UI. The CLI and API both lack pagination too. Rest assured that we understand it's a feature many people want, and it's on the roadmap for some time in the future.

[jpedrick]

Hi @raskchanky , glad to hear it's planned. Is there a github issue related to pagination?

[raskchanky]

@jpedrick No.

[jpedrick]

Hi @raskchanky I found a feature request issue for this: #10887

It'd be great to know what the priority is for this feature or if it's actually on the roadmap. Thanks!

[hellobontempo]

@jpedrick Thanks for linking the GH FR here. There is a feature request ticket for #10887 internally, which appears to be in "Discovery" at the moment