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

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

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

Я думаю, что мог бы создать хранилище доверенных сертификатов, добавить в него корневой ЦС digicert и упаковать его вместе с приложением, но вместо этого я склонялся к использованию только встроенных cacerts 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 по умолчанию (переносимым способом)?


websphere-liberty open-liberty
person lmsurprenant    schedule 04.01.2019    source источник

Ответы (1)


arrow_upward
6
arrow_downward

Обновление: 9 февраля 2020 г.:

Начиная с версии Liberty 19.0.0.12 вы можете получить тот же эффект с помощью следующего xml:

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

Это установлено в шаблонах серверов по умолчанию, поэтому новые серверы будут иметь это по умолчанию. Предыдущий ответ все еще работает.

Предыдущий ответ:

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

<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 в качестве переменной окружения. Я предполагаю, что в вашем случае JAVA_HOME не установлен как env var, но системное свойство всегда будет там.

person Alasdair    schedule 04.01.2019
comment
Спасибо, это именно то, что я искал. В моем случае я хотел сохранить наш базовый образ без изменений, поэтому я использовал облачную конфигурацию через configDropin. Работает локально на моем Mac, и я думаю, что он будет хорошо работать и в наших контейнерах. - person lmsurprenant; 04.01.2019
comment
Начиная с 19.0.0.12, похоже, вы можете просто установить trustDefaultCerts="true" в элементе ssl server.xml. Стоит обновить ответ? openliberty.io/blog/2019/ 06.12. - person lmsurprenant; 09.02.2020
comment
Да, и это в новом шаблоне по умолчанию. - person Alasdair; 10.02.2020