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

Feature Request: Handle Java (and possibly other platforms) which has its own cert store #18

Open
amouat opened this issue Jul 1, 2024 · 8 comments

Comments

@amouat
Copy link
Collaborator

amouat commented Jul 1, 2024

To add certificates to a Java image you need to use "keytool" e.g:

keytool -import -alias $filename -file $filename -keystore /etc/ssl/certs/java/cacerts -storepass changeit -noprompt

There are probably other platforms with similar bespoke solutions. In these cases we could add a flag (e.g. --add-java-cert) or try to detect if a Java image was being used.

@xnox
Copy link

xnox commented Jul 2, 2024

I know of 4 keystores:

  • single certificate bundle
  • optional by-cert-hash symlinks (for speed of lookup, see cert rehash tool)
  • java keystore
  • mono (C#) keystore

See

$ curl -s http://archive.ubuntu.com/ubuntu/dists/oracular/Contents-amd64.gz | gzip -d | grep etc/ca-certificates/update.d
etc/ca-certificates/update.d/jks-keystore		    misc/ca-certificates-java
etc/ca-certificates/update.d/mono-keystore		    universe/cli-mono/ca-certificates-mono

For the java & mono keystores, and ca-certificates itself handles the mega bundle & symlinks.

Wildcards:

  • web-browsers (firefox & chromium-based) have different ways to create user-profile, and import certs into them. Not sure if we need to support that too for some of our images that have those engines used.

@amouat
Copy link
Collaborator Author

amouat commented Jul 2, 2024

Thanks @xnox !

@hslatman
Copy link
Contributor

hslatman commented Jul 2, 2024

At Smallstep we have a package for interacting with (some of) those stores: https://github.com/smallstep/truststore. It's based on mkcert, but adapted for use as a library. It might be useful for this use case. If you miss functionality, we can likely add it 🙂

@amouat
Copy link
Collaborator Author

amouat commented Jul 2, 2024

Oh, nice! Thanks @hslatman.

Just to be clear, this is a "backlog" issue, I'm not sure when we'll be able to prioritise it. That being said, if anyone reads this and needs this functionality, please comment or leave an emoji.

@anoncam
Copy link

anoncam commented Jul 3, 2024

+1 this feature.

@xnox
Copy link

xnox commented Jul 11, 2024

@amouat @pnasrat also for java, i think we may need more that one type of java keystore. As I think jdk & jdk-fips images expect keytool certs in different store types possibly?

I.e. keytool -importcert -v -trustcacerts -file "cacert.pem" -alias ca -keystore "mySrvTruststore.bks" -provider org.bouncycastle.jce.provider.BouncyCastleProvider -providerpath "bcprov-jdk16-145.jar" -storetype BKS -storepass testtest

Possibly nss-db certs too in the future, to basically have equivalent of cert store procedures that others do by hand for other container types.

@xnox
Copy link

xnox commented Jul 19, 2024

https://github.com/docker-library/docs/blob/master/eclipse-temurin/README.md#can-i-add-my-internal-ca-certificates-to-the-truststore

Note that eclipse-temurin java image has hooks to allow on-the-fly creation of the java truststore with injected certs.

See implementation at

https://github.com/adoptium/containers/blob/0062d7960c45bb5a7f35f831ea43e0b4b894a5c7/8/jre/alpine/entrypoint.sh#L15

I guess we could do something similar in our images entrypoint too, to be compatible.

@amouat
Copy link
Collaborator Author

amouat commented Jul 24, 2024

Also note this issue on adoptium about handling certs: adoptium/containers#573

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants