OpenLiberty выбрасывает javax. net .ssl.SSLHandshakeException - PullRequest
Новая
       98

OpenLiberty выбрасывает javax. net .ssl.SSLHandshakeException

0 голосов
/ 08 мая 2020

Я пытаюсь запустить микросервис (на основе Eclipse Microprofile) на OpenLiberty (v20.0.0.1 / wlp-1.0.36.cl200120200108-0300) на Eclipse OpenJ9 VM, версия 1.8.0_242-b08 (en_US))

Я запускаю сервер как официальный образ Docker (open-liberty: kernel)

В моем сервисе я пытаюсь подключиться к другому сервису отдыха через HTTPS 

Client client = ClientBuilder.newClient();
client.target("https://myservice.foo.com/").request(....);

Это вызывает следующее исключение: 

javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: PKIX path building failed: 
        sun.security.provider.certpath.SunCertPathBuilderException: 
        unable to find valid certification path to requested target

Я уже добавил на сервер функции 'transportSecurity-1.0' и 'ssl-1.0'. xml файл: 

<featureManager>
  <feature>jaxrs-2.1</feature>
  <feature>microProfile-2.2</feature>
  <feature>transportSecurity-1.0</feature>
  <feature>ssl-1.0</feature>
</featureManager>

и я также настроил файл jvm.options следующим образом: 

-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=7777
-Dhttps.protocols=TLSv11,TLSv12
-Djdk.tls.client.protocols=TLSv11,TLSv12
-Dhttps.protocols=TLSv11,TLSv12
-Dcom.ibm.jsse2.overrideDefaultProtocol=TLSv11,TLSv12

Но ничто не помогает избавиться от исключения.

Как правильно настроить OpenLiberty для разрешения исходящих ssl-соединений?

Ответы [ 2 ]

2 голосов
/ 10 мая 2020

Liberty не доверяет чему-либо по ssl по умолчанию, поэтому, если служба, к которой вы подключаетесь, не использует идентичный файл хранилища ключей / доверенного хранилища, или если вы каким-то образом настроили свою службу на доверие микросервису, вы можете получить это исключение. Если проблема в этом, то в messages.log, вероятно, также будет отображаться что-то вроде этого:

com.ibm.ws.ssl.core.WSX509TrustManager E CWPKI0823E: ОТКАЗ HANDSHAKE SSL: подписавший с SubjectDN [CN = localhost, OU = oidcdemo_client, O = ibm, C = us] был отправлен с хоста [localhost: 19443]. Подписавшего, возможно, потребуется добавить в локальное хранилище доверенных сертификатов [/Users/tester/tmp/liberty/20003wlp/wlp/usr/servers/urlcheck/resources/security/key.p12], расположенное в псевдониме конфигурации SSL [defaultSSLConfig]. Расширенное сообщение об ошибке из исключения подтверждения SSL: [Ошибка построения пути PKIX: sun.security.provider.certpath.SunCertPathBuilderException: невозможно найти действительный путь сертификации к запрошенной цели].

Как вручную исправить Здесь задокументировано хранилище доверенных сертификатов

https://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_add_trust_cert.html

, но то, что вы, вероятно, захотите сделать в среде docker, - это изменить свои изображения, чтобы включить общее хранилище ключей / truststore или прочтите его извне (например, секрет кубернетов). По умолчанию каждый образ docker создает свой собственный уникальный ключ / хранилище доверенных сертификатов, и они не смогут «общаться» по ssl.

Если вам нужно взаимодействовать только со службами, у которых есть сертификат, подписанный известным органом, вы можете добавить

ENV SEC_TLS_TRUSTDEFAULTCERTS = true

в свой Dockerfile (20,0003 +), чтобы включить это.

1 голос
/ 12 мая 2020

Как упоминал Брюс в ответе выше, Liberty по умолчанию не доверяет никаким сертификатам. Если вы выполняете исходящие соединения от Liberty к серверу, вам либо нужно добавить их сертификат в настроенное хранилище доверенных сертификатов, либо вам нужно доверять cacerts JRE, если удаленная конечная точка использует сертификат от известного CA.

Когда вы говорите, что используете сертификаты Let's Encrypt, вы имеете в виду, что их использует удаленная конечная точка или ваш сервер Liberty?

Если удаленная конечная точка - это, большинство cacerts JRE включают Let's Encrypt в их cacerts. Если сервер Liberty использует сертификат, подписанный Let's Encrypt, это на самом деле не влияет на исходящее соединение, если только вы не используете взаимную проверку подлинности SSL.

К сведению, если вы используете сертификат, подписанный Let's Encrypt in Liberty в качестве сертификата по умолчанию, мы добавим встроенную поддержку протокола ACME в нескольких выпусках. Смотрите здесь: https://github.com/OpenLiberty/open-liberty/issues/9017

...