I think it depends on what language / runtime / library and where it's
looking for the default set of certs. It's easy with Java because it uses
it's own cert store and that file is owned by the vcap user. If a language
/ runtime / library is looking at `/etc/ssl/certs`, you can't change that
as a user (at least not from staging / runtime).

The best thing, just like Java, is if your applications provides you with
the facilities to configure its usage of certs. I'd imaging that all
language / runtime / libraries provide you with a way to override the
defaults and use your own certs.

Besides that, you might be able to set various environment variables to
point the default cert store to a different location. I'm not aware of a
standard one though, so it's likely going to depend on the specific
language / runtime / library and what it supports.

Dan


On Mon, Dec 14, 2015 at 6:01 PM, john mcteague <john.mcteague(a)gmail.com>
wrote:

Previous threads have focused on adding a trusted CA to the JDK's trust
store at application startup, a pattern that I have employed also.

We are facing increased demand from our non-Java developers to have the
same functionality. Whether it be custom CA's, certs for authentication
(against something like MQ for example) or for our internal LDAP server
which requires ldaps, we need a way to add user defined certificates at app
deploy time based on user requirements.

My work with Java buildpacks has resulted in a certificate as a service
style function; declare which cert from a certificate store should be
injected into the app at runtime. What I lack for non-java runtimes is a
reliable way to get those certs into the correct linux container directory
either during staging or at app startup.

Have others been able to establish a pattern around this? Without this
abiity we go from a polygot platform to simply Java only.

Thanks,
John