Мы запускаем скрипт JMeter, который отправляет данные json во внутреннюю конечную точку https. Но мы запускаем javax.net.ssl.SSLHandshakeException с перерывами (примерно в 3 раза из 100 вызовов) во время запуска скрипта.
Эта проблема очень похожа на следующий вопрос SO, но все решения, обсуждаемые там, t для меня: javax.net.ssl.SSLHandshakeException: handshake_failure при использовании JMeter с SSL (JDK8)
Я использую JDK8 и последнюю версию JMeter 4.0 , Я включил отладку ssl и от сообщений ClientHello и ServerHello, похоже, что сервер поддерживает набор шифрования TLS 1.2 и TLS_RSA_WITH_AES_128_CBC_SHA, который также поддерживается JMeter.
Но я вижу следующее в журналах SSL для неудачных запросов JMeter :
WRITE: TLSv1.2 Рукопожатие, длина = 64
READ: TLSv1.2 Alert, length = 2
RECV TLSv1.2 ALERT: фатальный, handshake_failure
%% Invalidated: [Session-17, TLS_RSA_WITH_AES_128_CBC_SHA]
Я пробовал следующие решения:
1. Добавлен серверный сертификат jre cacerts
2. Загруженные локальные банки политики для неподдерживаемых шифров и скопировали их в папку безопасности jre lib
3. Обновите банку httpclient (4.5) для JMeter
4. Явно включил TLS 1.2 в конфигурации JMeter
Я использовал TestSSLServer для проверки возможности SSL нашего сервера, и это то, что он возвращает:
SSLv3: выбор сервера: обеспечение предпочтений сервера
3- - (ключ: RSA) RSA_WITH_RC4_128_SHA
3-- (ключ: RSA) RSA_WITH_AES_128_CBC_SHA
3-- (ключ: RSA) RSA_WITH_AES_256_CBC_SHA
3-- (ключ: RSA) RSA_WITH_3DES_EDE_CBC_SHA
TLSv1.0: idem
TLSv1.2: выбор сервера: настройка предпочтений сервера
3-- (ключ: RSA) RSA_WITH_RC4_128_SHA
3-- (ключ: RSA) RSA_WITH_AES_128_CBC_SHA
3-- (ключ: RSA) RSA_WITH_AES_256_CBC_SHA
3-- (ключ: RSA) RSA_WITH_3DES_EDE_CBC_SHA
3-- (ключ: RSA) RSA_WITH_AES_128_CBC_SHA256
3-- (ключ: RSA) RSA_WITH_AES_256_CBC_SHA256
Любые идеи относительно что может пойти не так?
Я не мог понять, в чем причина, но теперь есть идея, что может пойти не так. Как предложил Дейв, я включил SSL-отладку и просмотрел все журналы и сравнил неудавшиеся запросы с успешными.
Для неудачных запросов это то, что я видел в журналах:
Как вы можете видеть, сервер для некоторых причина не отвечает. После некоторого googling я наткнулся на следующий форум по вопросам SSL f5. Наше обслуживание тоже проходит через f5. Я не могу подтвердить, поскольку у меня нет большого контроля над нашей серверной частью, но ниже проблема выглядит аналогичной:
https://devcentral.f5.com/questions/big-ip-proxy-ssl- 121-рукопожатие безотказного-47464
Это известная проблема, описанная в идентификаторе ошибки 563488 для версий BIG-IP раньше 13.0, как описано в K34019109.