Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flesh out client keystore and truststores #1

Merged
merged 5 commits into from Aug 28, 2018

Conversation

Projects
None yet
2 participants
@wsargent
Copy link
Contributor

wsargent commented Jul 25, 2018

I had to get client certificates working with a CA and wanted to set up different truststores for client and server, with the trust stores containing no private keys.

I tweaked things a bit to add an organization prefix and to use the password throughout the system in both openssl, and to break statements over multiple lines where the parameter had required arguments.

Probably need a link to https://stackoverflow.com/a/907515 to expand on the problem with keytool and private keys.

There may be a way to use openssl to import certificates without private keys, but when I used -nokeys to import just the ca.pem, it would tell me there was nothing in the PKCS12 file at all. Keytool was fine with that, so I just did it in the reverse direction.

@drewfarris

This comment has been minimized.

Copy link
Owner

drewfarris commented Aug 21, 2018

Thanks for the PR @wsargent - is this good to merge as far as you are concerned?

@wsargent

This comment has been minimized.

Copy link
Contributor Author

wsargent commented Aug 22, 2018

@wsargent

This comment has been minimized.

Copy link
Contributor Author

wsargent commented Aug 23, 2018

There's only one change which I'm on the fence here The java keystore does not keep track of aliases, but defines its own explicitly -- that is, it defines alias which is not always desirable.

keytool -importkeystore \
  -srckeystore ${NAME}-server-keystore.p12 \
  -srcstorepass:env PW \
  -alias "$NAME-server" \
  -srckeypass:env PW \
  -srcstoretype pkcs12 \
  -destkeystore ${NAME}-server-keystore.jks \
  -deststoretype jks \
  -deststorepass:env PW

If you want to use the alias already existing from the pkcs12 store, you'd remove the alias / keypass:

keytool -importkeystore \
  -srckeystore ${NAME}-server-keystore.p12 \
  -srcstorepass:env PW \
  -srcstoretype pkcs12 \
  -destkeystore ${NAME}-server-keystore.jks \
  -deststoretype jks \
  -deststorepass:env PW

The issue is that pkcs12 doesn't really HAVE the concept of an alias, and so it kind of gets made up: https://stackoverflow.com/questions/25349631/keytool-list-shows-different-aliases-for-p12-keystore-depending-on-whether-you

Generally I'd use the common name as the alias and pass that through explicitly using an envvar:

CN=`openssl x509 -noout -subject -in $NAME-server.pem | sed -n '/^subject/s/^.*CN=//p'`

Anyway, more information than you ever wanted to know about keystores here:

https://tersesystems.com/blog/2018/07/28/building-java-keystores/

@drewfarris

This comment has been minimized.

Copy link
Owner

drewfarris commented Aug 23, 2018

There's only one change which I'm on the fence here The java keystore does not keep track of aliases, but defines its own explicitly -- that is, it defines alias which is not always desirable.

In practice I can't recall any time that I've used or needed the alias feature of java keystores. So I'd lean towards not being too concerned about it . Have you run into cases where the alias in the keystore is useful?

Thanks for the references, I'll take a look to see if there's new info there that might shift my thinking.

@wsargent

This comment has been minimized.

Copy link
Contributor Author

wsargent commented Aug 23, 2018

@wsargent

This comment has been minimized.

Copy link
Contributor Author

wsargent commented Aug 23, 2018

realistically, I think it's not going to be an issue so LGTM :-)

@drewfarris drewfarris merged commit fff812f into drewfarris:master Aug 28, 2018

@drewfarris

This comment has been minimized.

Copy link
Owner

drewfarris commented Aug 28, 2018

Thanks @wsargent!

@wsargent wsargent deleted the wsargent:add-java branch Aug 28, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.