Лучший способ упаковать приложение liberty с хранилищем доверенных сертификатов java по умолчанию (cacerts) - PullRequest
Новая
       17

Лучший способ упаковать приложение liberty с хранилищем доверенных сертификатов java по умолчанию (cacerts)

0 голосов
/ 04 января 2019

Я упаковываю приложение свободы, которое работает с Db2. Когда мы работаем локально, мы настраиваем сертификаты для защиты соединения от приложения к БД.

Сейчас я пытаюсь упаковать то же приложение для использования со службой Db2 on Cloud, и у меня возникают проблемы с настройкой SSL.

Я думаю, что мог бы создать хранилище доверенных сертификатов и добавить к нему корневой CA digicert и упаковать его вместе с приложением, но вместо этого я склонялся к использованию только встроенных в JDK каскадов (поскольку у нас также есть ограничительные правила брандмауэра, предотвращающие исходящие соединения). другим хостам).

Я нашел чрезвычайно актуальное обсуждение на https://github.com/OpenLiberty/open-liberty/issues/4377,, но я не могу найти хороший способ указать путь к хранилищу JDK cacert в переносимом виде.

Я попытался установить его следующим образом: <keyStore id="defaultKeyStore" location="${env.JAVA_HOME}/jre/lib/security/cacerts"/>

Но по какой-то причине он не разрешает переменную среды. Почему?

Кроме того, это будет работать, только если для JAVA_HOME задан JDK (как в разработке). В наших контейнерах этого нет, поэтому мы не хотим, чтобы часть jre находилась на пути.

Какой самый простой / простой способ сказать Liberty просто использовать хранилище доверенных сертификатов JDK по умолчанию (в переносном виде)?

1 Ответ

0 голосов
/ 04 января 2019

Я сделал это только вчера, и моя рекомендация будет такой: 

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

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

В моем случае я использовал https, входящий на мой сервер Liberty, используя сгенерированные самозаверяющие сертификаты (я проводил тестирование разработки), и если я установил defaultKeyStore, указывающий на cacerts, входящий ssl был прерван, потому что он не содержит сертификат сервера. мог бы использовать. Вместо этого я просто обновил конфигурацию ssl по умолчанию, чтобы использовать cacerts в качестве хранилища доверенных сертификатов, и оставил хранилище ключей как есть.

Я использовал ${java.home}, потому что он всегда будет там (ну, если Java не избавится от этой системной переменной, но я подозреваю, что это не всегда так). У серверного скрипта Liberty есть несколько способов определить расположение Java, поэтому ему не нужен JAVA_HOME в качестве env var. Я предполагаю, что в вашем случае JAVA_HOME не установлен как env var, но системное свойство всегда будет там.

...