Closed skuppa closed 10 years ago
Actually not only is there no problem keeping certificates under source control (they're the public half of a public/private key pair) it's a good idea to keep anything that is required for an application to run under source control so that it can be reproduced at a later date. A byproduct of using a fork of the buildpack for this is that the buildpack can be reused for entire classes of applications rather than each application doing its own thing. This means that auditing, updates, etc. can be handled in a more centralized manner.
The recommended way to influence the contents of the JVM is to use the copy_resources()
functionality included in the buildpack. The short explanation is that the resources
directory can contain a directory that will be overlaid on top of the component's sandbox directory. So in this case you can put a custom cacerts
file into resources/open_jdk//lib/security
and it will be copied into <open-jdk-sandbox>/lib/securtity/cacerts
. This strategy has been used successfully before to add JCE Unlimited Strength.
For information about the differences in the compile
and release
phases of the buildpack lifecycle you can either the documentation for buildpack components or the original Heroku documentation for buildpacks.
Let me know if the resources
strategy works for you.
Hi Ben Hale,
Thanks for the detailed explanation. It really helps and I will try it out soon.
The location of certificate does not matter, whether it is under application or java-buildpack. The consumer of java-buildpack can workout the security concern separately depends on where the certificate lives.
Thanks, -Sridharan
if the custom buildpack is referenced from private git repository behind self signed SSL, where to put the certificate so during staging CF will download the buildpack from custom repository? like https://myrepo.internal/CF/javabuild-pack.git
thanks, Mart
An alternative is to have the Java application itself programmatically manage the key store.
If this may help, we had developed a spring boot library at https://github.com/Orange-OpenSource/spring-boot-ssl-truststore-gen for doing this, before realizing this had also been done into https://github.com/pivotal-cf/cloudfoundry-certificate-truster (with a different config mechanism )
/CC @s-bortolussi
@gberche-orange is there a way to load client keys in the same way you do it with trusted keys, I need to use CA cert to authenticate BOSH and at the moment I put keystore to jar file and use custom buildpack, which doesn't seem right to me. Thank you!
I am looking for a way to import custom root certificates into JVM's castore. Is there any convention or hook available to add these certificates? If this is not available, I would like to add this feature. There are couple option available,
Option 1: Have a new directory under java-buildpack,
java-buildpack/resources/certs
and user can place custom certificates under this resource directory. During the compile time, these certificates will be imported into JVM's castore. The disadvantage is, user needs to fork and add certificates and it is not best idea to add certificates under SCM. Also, not all application require the extra root certificates.Option 2: Application
MANIFEST
's can specify the certs location. After compilation, during release cycle the java-buildpack can read the file and import into JVMS's castore. This is most preferred way since application can specify its custom root certificate if require.BTW, I am looking information what is the difference between compile and release life cycle in
java-buildpack.
Thanks, -Sridharan