Java Keystore SPI implementation?

716 views
Skip to first unread message

Warren Strange

unread,
Jun 14, 2016, 7:07:28 PM6/14/16
to Vault


I am wondering if anyone has implemented, or thought of implementing an SPI provider for Vault for
Java's KeyStore SPI:   

If I understand this SPI, I *think* this would allow java programs to use Vault in a transparent 
fashion using just standard JCE API calls. I.e. swap out the usual JKS file provider for the Vault provider via a command line switch, with
no code modification.

Thoughts?



Jeff Mitchell

unread,
Jun 17, 2016, 7:15:43 AM6/17/16
to vault...@googlegroups.com
Hi Warren,

I haven't heard of anyone tackling this -- from looking at that API it
seems like the things you would be able to do would be limited but may
still be very useful for some. If you're interested in working on this
I suggest proposing a design on a GitHub issue and I'd be happy to
review it.

Best,
Jeff
> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/hashicorp/vault/issues
> IRC: #vault-tool on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Vault" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vault-tool+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vault-tool/1ee1d76a-5f3f-4a58-a149-873d5d3b5c8c%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Toon Geens

unread,
Jun 18, 2016, 2:13:18 AM6/18/16
to Vault
Hey,

I found this thread while I was actually looking around for an automated approach to create a keystore.jks for some certificates stored in Vault.

This sounds so much nicer :-)


Op vrijdag 17 juni 2016 13:15:43 UTC+2 schreef Jeff Mitchell:

Warren Strange

unread,
Mar 1, 2017, 11:24:56 AM3/1/17
to Vault


I gather the Vault pki backend does not allow reading of the private key once a key pair has been generated? (i.e. the client must
grab it when it is first issued?)

This would make it difficult to use Vault as a KeyStore provider for key pairs. That being said, I think there is still there is still utility as a trust store for certs / cert chains, and 
as a way to store secrets via the KeyStore API. 

Jeff Mitchell

unread,
Mar 1, 2017, 12:10:58 PM3/1/17
to vault...@googlegroups.com
Hi Warren,

That is correct, the backend currently does not store keys. It's not clear to me why a Java KeyStore couldn't just store the key/cert from the initial issuance, though.

Best,
Jeff

To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/de4e25e2-e758-486f-ad41-2633cb7383e6%40googlegroups.com.

Warren Strange

unread,
Mar 1, 2017, 12:35:11 PM3/1/17
to Vault


The idea was to get rid of the need for a local Java Keystore altogether by using Vault instead (via the KeyStoreSpi provider).  This solves the problem 
of distributing and maintaining keystores with the application.  When an application boots it is going to need to retrieve it's private keys - but it looks like
this is not possible. 

Would it be a reasonable RFE to have the pki backend store the keys?


Jeff Mitchell

unread,
Mar 2, 2017, 2:47:20 PM3/2/17
to vault...@googlegroups.com
Hi Warren,

I know that other users in a similar situation are currently storing generated certificates in a 'generic' mount. At an ACL policy level, it wouldn't be any easier to have it stored in the PKI backend.

Best,
Jeff

To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/b7378499-c605-43d8-b036-c09c62628c05%40googlegroups.com.

automat...@gmail.com

unread,
May 9, 2017, 3:11:45 PM5/9/17
to Vault
my team is presently looking at this. i did some research and so far i've found that:
- depending on application, it can be trivial to use a different keystore type (see kafka's configuration support for keystore type) (plus adding the spi to the jvm configuration)
- it's up to the application to reload the keystore - ie you might need to bounce the app to reload keys if you have changed the keystore file underneath (like with consul-template)
- a vault keystore impl could work, but supporting the full keystore api is nontrivial, and testing would be application specific as to which parts of the api are needed

a potential impl plan is as follows:
- initially only support token auth.
- as pki backend is clear initial target for this, handle not being able to retrieve private key by caching it and requesting a new one if you lose it. (best case. it is possible the application will necessitate persisting the keystore to disk, which is also doable, but at that point you might have a consul-template use-case.)

like i mentioned, this can get very complicated, but with a restricted scope, i'd guess this would cover the majority of cases not already covered by other tools.

not sure if we'll go this route, but glad to have it be discussed. would certainly be more attractive if we didn't solo it haha.

automat...@gmail.com

unread,
May 9, 2017, 3:13:01 PM5/9/17
to Vault
Reply all
Reply to author
Forward
0 new messages