Date 1 - 5 of 5
Making your landscape trust a certain certificate authority
Mathias Essenpreis <esse@...>
we want to make the apps on our landscape trust a certain ca certificate of a ca we run internally. I came across the instructions on how to do this for the JRE buildpack: https://github.com/cloudfoundry/java-buildpack/blob/master/docs/jre-open_jdk_jre.md#custom-ca-certificates
I understand doing this once in the JRE buildpack will directly make all the java apps that of course need to make use of the JRE buildpack trusting our internal ca. Is that correct or do I need to change other buildpacks as well?
However this implies performing a fork of the JRE buildpack. A fork means that we always need to synchronize manually with the newer versions of the build pack.
How do you approach this problem in your organization? I suppose you also have internal certificate authorities that need to be trusted, right?
Also I am asking myself whether there is a way to enhance the default buildpack allowing an application (instead of the buildpack) to bring their own, additional certificates?
A couple options...toggle quoted message Show quoted text
1.) If you only need the cert for one or a couple apps and / or you don't
want to manage a fork, you can package the CA cert with the application.
Then add a `.profile.d` script  that sets up the certificate that you
packaged with the app. I don't have an example off-hand, but the
.profile.d script could call keytool and import your ca cert or just move a
keystore containing your ca cert from the app files and overwrite the JVM
2.) Write your application so that it can utilize it's own truststore.
It's a little more work, but most things that use a truststore in the JVM
allow you to customize the behavior specifying your own truststore. If the
app were to do this, it could then expose a configuration option through
which it's users could set their own truststore. Then users wouldn't need
to depend on what certs are installed by default.
 - https://devcenter.heroku.com/articles/profiled (CF honors them too)
On Tue, Sep 29, 2015 at 4:50 PM, Mathias Essenpreis <esse(a)gmx.de> wrote:
I am trying to implement option 1 above but I am struggling from where to pick up the certificate files which I have packaged with my application (for experimentation I put the certificates both in the .profile.d directory and a ssl folder in my webapp).
I tried the following variants
keytool -keystore ... -storepass ... -importcert -alias MyCert -file MyCert.crt
keytool -keystore ... -storepass ... -importcert -alias MyCert -file /home/vcap/app/.java-buildpack/tomcat/webapps/ROOT/ssl/MyCert.crt
keytool -keystore ... -storepass ... -importcert -alias MyCert -file /home/vcap/app/ssl/MyCert.crt
I all cases I am getting
(No such file or directory)[App/0] OUT keytool error: java.io.FileNotFoundException: ...MyCert.crt (or similar)
( I checked using cf files myapp app/.profile.d that the files are deployed)
Does someone have an idea how to address within the profile.d script files from the deployed application?
PS: I had to put the profile.d folder into the web app root folder in order to be picked up, which makes it a public resource. The documentation is also not very clear where to put it. Any ideas in this direction would also be appreciated.
Some comments inline...
On Fri, Oct 2, 2015 at 5:02 AM, Eric Westenberger <
Hello,This is a little tricky with Java apps because of how they get packaged
up. You need to make sure that `.profile.d` is included at the root of
your WAR file. If you run `jar tf file.war` it should list `.profile.d/`
and nothing in the path before that.
When your app gets uploaded to CF, the files are extracted from the WAR and
you end up with an exploded WAR director at `/home/vcap/app`. Since
`.profile.d` is at the root of your WAR, that means
`/home/vcap/app/.profile.d` is where you should be able to find your script
and anything else you put in that directory.
I tried the following variantsIf I understand your comment above, I'd have expected the last one to
work. You said that you put a `ssl` director at the root of your WAR file
and that contained the certs. I'd also expect the path
`/home/vcap/app/.profile.d/MyCert.crt` to work since you said you put the
certs into the `.profile.d` folder too.
A few tips for debugging `.profile.d` scripts.
1.) Put `sleep 2` as the first line of the script, right after the
`#!/bin/bash`. This works around a known issue with logging, which can
sometimes cause log entries to be lost.
2.) Add copious echo statements to your script. You can also do things
like run `ls` and `pwd` to inspect the environment. Anything that writes
to STDOUT should show up when the script runs.
3.) You can use environment variables like `$PWD` and `$HOME` so you don't
have to deal with full paths. `$HOME` points to `/home/vcap/app` and
`$PWD` points to the working directory, which should also be
You're close. Try adding some `ls` statements if you need to confirm
exactly where things are at. The output should show up when you run your
The `.profile.d` folder has to be in the root of what you push to CF.
That's the only place it will get picked up.
It depends on your app and how it's configured to serve up public files,
but you can generally put anything that you need to protect under `WEB-INF`
since that shouldn't be publicly accessible. For example if you want to
keep someone from seeing your script you could put `.profile.d/wrapper.sh`
which will get called by CF and have it call `WEB-INF/secret-script.sh`,
which is your actual script.
thanks so much for pointing me in the right direction. The following script worked for me
$HOME/.java-buildpack/open_jdk_jre/bin/keytool -keystore $HOME/.java-buildpack/open_jdk_jre/lib/security/cacerts -storepass changeit -importcert -noprompt -alias MyCert -file $HOME/WEB-INF/ssl/MyCert.crt
|1 - 5 of 5|