2

I'm packaging a liberty application which works with Db2. When we run locally, we configure certificates to secure the connection from app to db.

Now I'm trying to package the same application for use with the Db2 on Cloud service, and I'm having trouble with the SSL configuration.

I think I could create a truststore and add the digicert root CA to it and package that with the app, but instead I was leaning toward just using the JDK's built-in cacerts (because we also have restrictive firewall rules preventing outbound connections to other hosts).

I found extremely relevant discussion at https://github.com/OpenLiberty/open-liberty/issues/4377, but I can't seem to find a nice way to specify the path to the JDK's cacert store in a portable way.

I tried setting it as follows: <keyStore id="defaultKeyStore" location="${env.JAVA_HOME}/jre/lib/security/cacerts"/>

But for some reason it doesn't resolve the environment variable. Why?

Additionally, this will only work when the JAVA_HOME is set to a JDK (like in development). In our containers, we don't have that and so we don't want the jre part in the path.

Whats the simplest/easiest way to tell Liberty just to use the JDK's default truststore (in a portable way)?

lmsurprenant
  • 1,723
  • 2
  • 14
  • 28

1 Answers1

6

Update: Feb 9 2020:

As of 19.0.0.12 release of Liberty you can get the same effect with the following xml:

<ssl id="defaultSSLConfig" trustDefaultCerts="true" />

This is set in the default server templates so new servers will have this by default. The previous answer still works.

Previous answer:

I did this just yesterday and my recommendation would be this configuration:

<ssl id="defaultSSLConfig" trustStoreRef="myTrustStore"/>

<keyStore id="myTrustStore" location="${java.home}/lib/security/cacerts" password="changeit" />

In my case I was using https inbound to my Liberty server using the generated self signed certs (I was doing development testing) and if I set defaultKeyStore pointing at cacerts inbound ssl was broken because it doesn't contain a server cert I could use. Instead I just updated the default ssl configuration to use cacerts as a trust store and left the keystore as is.

I used ${java.home} because it will always be there (well unless Java gets rid of this system variable, but I suspect that won't always be the case). Liberty's server script has a number of ways to work out the Java location so it doesn't need JAVA_HOME as an env var. I'm guessing in your case JAVA_HOME isn't set as an env var, but the system property will always be there.

lmsurprenant
  • 1,723
  • 2
  • 14
  • 28
Alasdair
  • 3,071
  • 15
  • 20
  • Thanks, that is exactly what I was looking for. In my case, I wanted to keep our base image unmodified and so I layered on the cloud configuration via a configDropin. Works locally on my mac and I think it will work well in our containers as well. – lmsurprenant Jan 04 '19 at 18:59
  • As of 19.0.0.12, it looks like you can just set `trustDefaultCerts="true"` in the ssl element of server.xml. Worth updating the answer? https://openliberty.io/blog/2019/12/06/microprofile-32-health-metrics-190012.html#ssl – lmsurprenant Feb 09 '20 at 20:56
  • Yes, and that is in new default template. – Alasdair Feb 09 '20 at 21:13