В последнее время всё чаще приходится помогать коллегам с удалённым доступом к оборудованию через различные java-приложения.
В первую очередь этим страдают ILOM-ы, iDRAC-и, IMM-ы, switchExplorer (от Brocade), High-End HP и IBM системы хранения данных, да и многое другое оборудование, прошивки которого не самой первой свежести.
Выглядит это всё так, что если у вас java 7 или выше, при открытии сеанса удалённого подключения, java после своих обычных ошибок выводит серию ошибок, связанных с угрозой безопасности, невозможностью проверки self-signed сертификатов и прочие невнятные сообщения, которые по косвенным признакам можно отнести к работе системы безопасности.
Собственно, часть проблем обусловлена тем, что с течением времени, используемые на оборудовании алгоритмы шифрования были признаны невероятно уязвимыми и надёжная безопасная java категорически против их использования.
Чтобы убедительно попросить java или попробовать привести её в чуство, обычно помогает следующая последовательность действий.
1. Убеждаем java, что сайт, с которого будет открываться приложение действительно безопасный. Обычно он соответствует сайту, с которого нажимается кнопка "remote console", но точный адрес можно увидеть внутри jnlp файла. Чтобы это сделать, открываем jcontrol (Start->"Configure Java" в клиническом случае использования Windows). Переходим на вкладку "Security", нажимаем "Edit site list" и добавляем новый сайт. Если кнопка "Add" не нажимается, возвращаемся в jcontrol, переходим на вкладку "Advanced", прокручиваем вниз до раздела "Miscellaneous" и снимаем флажок "Store user settings in the roaming profile".
Есть ещё менее любимый программистами, но и более топорный метод -- отредактировать файл с исключениями. В него можно добавить строку с требуемым URL. На Windows и не-Windows версиях он расположен соответственно в:
%APPDATA%\..\LocalLow\Sun\Java\Deployment\security\exception.sites
$HOME/.java/deployment/security/exception.sites
2. Объясняем java, что используемые ей подходы не всегда подходят для работы в Enterprise. Для этого надо поправить файл java.security, расположенный в lib/security, внутри каталога с используемой jre. Для Windows и не-Windows версии, вероятно, его можно найти по путям:
%SYSTEMDRIVE%\Program Files\Java\jre*\lib\security
/usr/java/jre/lib/security
Ну а если у вас linux или другая UNIX-подобная поделка, можно попробовать выяснить месторасположение найдя исполняемый файл java:
$ type java
java is /usr/bin/java
$ ls -l /usr/bin/java
lrwxrwxrwx 1 root root 22 Sep 9 2007 /usr/bin/java -> /etc/alternatives/java
$ ls -l /etc/alternatives/java
lrwxrwxrwx 1 root root 39 Sep 9 2007 /etc/alternatives/java -> /usr/lib/jvm/java-8-oracle/jre/bin/java
$ ls -l /usr/lib/jvm/java-8-oracle/jre/lib/security/java.security
lrwxrwxrwx 1 root root 41 Sep 9 2007 /usr/lib/jvm/java-8-oracle/jre/lib/security/java.security -> /etc/java-8-oracle/security/java.security
или просто вручную просмотреть содержимое всех каталогов системы.
Внутри этого файла нужно привести два параметра, например, в следующий вид:
jdk.certpath.disabledAlgorithms=MD2
jdk.tls.disabledAlgorithms=DSA
Решение оставить MD2 и DSA в списке уязвимых обусловлено тем, что они-то как раз на самом деле уязвимы.
После этих нехитрых действий High-End оборудование, наконец, можно будет администрировать с лёгкостью и комфортом.
