API задания rundeck: javax. net .ssl.SSLHandshakeException: никаких общих наборов шифров - PullRequest
0 голосов
/ 31 января 2020

Обновлен с Rundeck 3.0.2 (API v30) до 3.2.1 (API v34) . Установка Yum / RPM, RHEL 7.

Я настроил SSL, следуя документации и моделированию Rundeck после моей существующей рабочей установки. SSL отлично работает через Интернет и работает нормально, когда я запускаю API REST задания с помощью curl, однако, когда наше приложение MuleSoft встречает REST API, происходит сбой с handshake_failure:

%% Initialized:  [Session-1, SSL_NULL_WITH_NULL_NULL]
qtp1539575645-26, fatal error: 40: no cipher suites in common
javax.net.ssl.SSLHandshakeException: no cipher suites in common
%% Invalidated:  [Session-1, SSL_NULL_WITH_NULL_NULL]
qtp1539575645-26, SEND TLSv1.2 ALERT:  fatal, description = handshake_failure
qtp1539575645-26, WRITE: TLSv1.2 Alert, length = 2
qtp1539575645-26, fatal: engine already closed.  Rethrowing javax.net.ssl.SSLHandshakeException: no cipher suites in common

Я подтвердил, что MuleSoft доверяет сертификат сервера Rundeck. Ранее я не включал / не исключал никакие наборы шифров в моей конфигурации ssl Rundeck, но я заставил MuleSoft использовать определенный набор, а затем добавил этот набор в / etc / sysconfig / rundeckd, используя параметр -Drundeck.jetty.connector.ssl.includedCipherSuites=(insert suite here), однако мы по-прежнему получаем ошибка "нет общих наборов шифров".

Добавление -Djavax.net.debug=ssl parm к /etc/sysconfig/rundeckd добавляет детали рукопожатия к service.log. Я вижу список исключенных наборов шифров, но я не вижу подтверждения, что он включает в себя те, которые я добавил. Я вижу параметр в деталях процесса работающей JVM.

Это похоже на проблему клиента на стороне MuleSoft, и мы обращаемся к поставщику, однако я нахожу странным, что когда я явно включаю набор шифров, который отправляет клиент, все еще не видит ничего общего. Возможно, я неправильно использую -Drundeck.jetty.connector.ssl.includedCipherSuites?

Мой /etc/sysconfig/rundeckd файл, с которым я сейчас тестирую, выглядит так:

export RUNDECK_WITH_SSL=true
export RDECK_HTTPS_PORT=4443
RDECK_JVM_OPTS="-Drundeck.jaaslogin=true \
       -Djava.security.auth.login.config=/etc/rundeck/jaas-multiauth.conf \
       -Dloginmodule.name=multiauth \
       -Djavax.net.ssl.trustStore=/etc/rundeck/ssl/truststore \
       -Djavax.net.ssl.trustStoreType=jks \
       -Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol \
       -Drundeck.jetty.connector.ssl.includedCipherSuites=TLS_RSA_WITH_AES_256_GCM_SHA384 \
       -Dorg.eclipse.jetty.util.ssl.LEVEL=DEBUG \
       -Djavax.net.debug=ssl"

Любые мысли приветствуются!

1 Ответ

0 голосов
/ 19 февраля 2020

Проблема заключалась в том, что клиент MuleSoft требовал, чтобы SSL-сертификат сервера Rundeck имел расширение KeyUsage = digitalSignature. Добавление этого расширения решило проблему.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...