使用默认Java TrustStore(证书)打包自由应用程序的最佳方法 [英] Best way to package liberty app with default java truststore (cacerts)

问题描述

我正在打包可与Db2一起使用的自由应用程序.在本地运行时，我们配置证书以保护从应用程序到数据库的连接.

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.

现在，我正在尝试打包同一应用程序以与Db2 on Cloud服务一起使用，并且在SSL配置方面遇到问题.

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.

我认为我可以创建一个信任库，并向其中添加digicert根CA并将其与应用程序打包在一起，但是相反，我倾向于仅使用JDK的内置cacert(因为我们也有严格的防火墙规则来防止出站连接到其他主机).

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).

我在> https://github.com/OpenLiberty/open找到了极为相关的讨论-liberty/issues/4377 ，但是我似乎找不到一种很好的方法来以可移植的方式指定JDK cacert存储的路径.

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.

我尝试将其设置如下: <keyStore id="defaultKeyStore" location="${env.JAVA_HOME}/jre/lib/security/cacerts"/>

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?

此外，这仅在JAVA_HOME设置为JDK时才有效(例如在开发中).在我们的容器中，我们没有该容器，因此我们不希望路径中的jre部分.

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.

告诉Liberty仅使用JDK的默认信任库(以可移植的方式)的最简单/最简单的方法是什么?

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

推荐答案

更新:2020年2月9日:

Update: Feb 9 2020:

从Liberty 19.0.0.12版本开始，您可以使用以下xml获得相同的效果:

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.

上一个答案:

我是昨天才做的，我的建议是这样的配置:

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" />

在我的情况下，我使用生成的自签名证书对我的Liberty服务器使用https入站(我正在进行开发测试)，并且如果我将指向cacerts的defaultKeyStore设置为入站ssl损坏，因为它不包含服务器证书，可以用.相反，我只是更新了默认的ssl配置，以将cacerts用作信任存储，并保留了密钥存储.

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.

我使用了${java.home}，因为它将一直存在(除非Java摆脱了这个系统变量，但我怀疑情况并非总是如此). Liberty的服务器脚本具有多种方法来计算Java位置，因此它不需要JAVA_HOME作为环境变量.我猜在您的情况下，JAVA_HOME没有设置为env var，但是system属性将始终存在.

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.

这篇关于使用默认Java TrustStore(证书)打包自由应用程序的最佳方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！