Блог

Мы запускаем устаревшее приложение на сервере Apache v7.0.47 за прокси-сервером Apache2 HTTPD (v2.4.23). Я пытаюсь обновить версию Java на сервере (используемом как прокси, так и tomcat) с версии v1.8.0_181 до версии v1.8.0_303.

После этого обновления Tomcat больше не отвечает на переданные запросы Apache (само приложение запускается и работает нормально).

Как Apache на своей обращенной к сети стороне, так и Apache и Tomcat друг среди друга были настроены на «разговор» TLS1.2 уже некоторое время, поэтому я не думаю, что отключение TLSv1.0 и TLSv1.1 в более поздней версии Java является причиной проблемы здесь. И в журналах нет сообщения об ошибке, дающего какую-либо подсказку. Единственным признаком является то, что кот, похоже, закрывает и разрывает соединение без какого-либо ответа после получения запроса. Похоже, это происходит уже на уровне SSL, поскольку в журнале доступа (Tomcat) нет записи.

Переключение обратно на «старую» Java заставляет все снова работать, поэтому брандмауэр, сеть и т. Д. Здесь определенно НЕ проблема. В более новой версии Java снова выполняется настройка подключения, в результате чего HTTPD выдает ошибку «502 Плохой шлюз».

Есть идеи, кто-нибудь, что может заставить Tomcat отклонять запросы HTTPD только на основе версии Java? Дополнительные проверки SSL, включенные по умолчанию в новом стеке? Я тщательно искал, но пока не обнаружил ни одного подозреваемого.

Более позднее дополнение: пытаясь определить проблему, я обнаружил, что с Java v1.8.0_231 все еще работает, с v1.8.0_241 и выше это не удается. Изучите примечания к выпуску сейчас, чтобы найти подсказку…

У кого-нибудь есть идеи или опыт по этому обновлению?

Просто для протокола — на случай, если кто-то еще наткнется на этот вопрос:

Проблема здесь заключалась в том, что начиная с версии Java v1.8.0_241 и выше безопасность Java проверяет, что цепочка сертификатов, считанная из хранилища сертификатов, основана на сертификате CA, который имеет соответствующий флаг CA. Поскольку мы использовали старое хранилище сертификатов и доверия, созданное с использованием старого выпуска java keytool, этот флаг отсутствовал, и новая версия Java, таким образом, отклонила все записи в этом файле сертификата. Таким образом, он прервал настройку SSL-соединения и просто закрыл соединение без какого-либо ответа или указания.

Существует опция виртуальной -Djdk.security.allowNonCaAnchor=true машины, которую можно добавить в переменную JAVA_OPTS Tomcat (обычно в файле setenv.sh ), чтобы отключить эту проверку. После добавления этого наш кот снова отвечал на SSL-запросы и снова работал нормально.

Кстати: при попытке проанализировать проблемы SSL, подобные описанным выше, опция -Djavax.net.debug=all:handshake:verbose оказалась настоящей экономией времени! С помощью этой опции вы получаете очень подробный вывод журнала и можете подробно следить за SSL-квитанциями и настройками подключения. Как только я, наконец, получил первое полезное сообщение об ошибке, указывающее на эту проблему с флагом CA, поиск решения (или, скорее, обходного пути в этом случае) оказался проще по сравнению с первоначальным поиском того, в чем может быть проблема здесь.