I have a ca certificate that many apps will need to use (for ldaps). What
is the correct strategy for exposing that within the containers?

I'm primarily looking at the non Java buildpacks, since that is easily
solved by adding it to the trust store.

In a non CF world on Ubuntu I would drop that into
/usr/local/share/ca-certificates and run update-ca-certificates. Having
briefly tried to do that using a php buildpack extension I see that
permissions do not allow those steps to happen.

Do certificates on the DEA's get exposed to the running containers,
therefore loading it onto the dea solves the issue?

Is there a pattern to follow here?

Thanks,
John.

Hmm,

BOSH has functionality for adding the certificate to all the deployed VMs:
https://bosh.io/docs/trusted-certs.html

I'm not sure if the Warden containers will use the system certificate store
though. They might only use the certificates found on the stack that the
application in using. In which case your best bet might be to rebuild the
stack and add the certificates you want to it.
https://github.com/cloudfoundry/stacks

Joseph
CF Release Integration Team

On Fri, Sep 18, 2015 at 1:27 AM, john mcteague <john.mcteague(a)gmail.com>
wrote:

I have a ca certificate that many apps will need to use (for ldaps). What
is the correct strategy for exposing that within the containers?

I'm primarily looking at the non Java buildpacks, since that is easily
solved by adding it to the trust store.

In a non CF world on Ubuntu I would drop that into
/usr/local/share/ca-certificates and run update-ca-certificates. Having
briefly tried to do that using a php buildpack extension I see that
permissions do not allow those steps to happen.

Do certificates on the DEA's get exposed to the running containers,
therefore loading it onto the dea solves the issue?

Is there a pattern to follow here?

Thanks,
John.

On Fri, Sep 18, 2015 at 4:27 AM, john mcteague <john.mcteague(a)gmail.com>
wrote:

I have a ca certificate that many apps will need to use (for ldaps). What
is the correct strategy for exposing that within the containers?

I'm primarily looking at the non Java buildpacks, since that is easily
solved by adding it to the trust store.

In a non CF world on Ubuntu I would drop that into
/usr/local/share/ca-certificates and run update-ca-certificates. Having
briefly tried to do that using a php buildpack extension I see that
permissions do not allow those steps to happen.

Do certificates on the DEA's get exposed to the running containers,
therefore loading it onto the dea solves the issue?

Is there a pattern to follow here?

Thanks,
John.

This probably doesn't help much, but I would say that this is an
application problem. Instead of modifying the list of system cacerts, the
app should expose the ability for you to specify a custom cacert list.
Then you could package your custom cacert with the app and make it more
portable.

Dan