Zur Verwaltung von Brocade SAN Switches benötigt man auf dem Client das Java Runtime Environment (JRE). Dies funktionierte jahrelang recht gut, doch in jüngerer Vergangenheit hatte Oracle die Sicherheit verschärft. Dies ist zwar prinzipiell eine gute Idee, aber ein echtes PITA wenn man unterschiedliche Versionen und Anwendungen mit dieser JRE verwalten muss. Beim Zusammenspiel mit des Brocade Fabric OS (FOS) und Java gibt es viele Fallstricke.
- FOS fordert ab Version 6.3 eine Mindestversion des JRE
- Oracle hat das JRE ab Version 7 Update 21 (7u21) mit einem hart codierten Verfallsdatum ausgestattet.
- Software Zertifikate mit veralteter Signatur oder zu geringer Schlüssellänge werden nicht mehr unterstützt.
- FOS Zertifikate haben ein Ablaufdatum
Das alles endet in einem Sumpf aus Updates und Warnungen. Applikationen seien nicht mehr vertrauenswürdig und dürfen daher nicht mehr gestartet werden. An dieser Stelle brachte mich der lesenswerte Blogartikel von Erwin van Londen weiter.
3 billion flies eat shit
Wir alle lieben diese Information beim Java Update und mir fällt jedesmal die Analogie zu den Fliegen und dem Dung ein. Wird meine Anwendung nach dem Update noch funktionieren? Diese bange Frage hielt mich oft von einer Aktualisierung ab. Aber angesichts der massiven Sicherheitslücken in Java muss man unbedingt zur Installation von Patches raten.
Jede FOS Version hat in ihren Spezifikationen eine Mindestanforderung an das JRE. Diese Korrelationen sind in der Tabelle unten dargestellt. (Quelle: Brocade FOS Release Notes)
| FOS | Minimum JRE | Bemerkung |
| vor 6.3 | – | keine Angabe |
| 6.3 | 1.6.0 Update 13 | – |
| 6.4 | 1.6.0 Update 16 | – |
| 7.0.1 | 1.6.0 Update 24 | – |
| 7.1.0 | 1.7.0 Update 9 | – |
| 7.2.1a | 1.7.0 Update 25, 45, 51 | Warnung bei Update 51 |
| 7.3.0 | 1.7.0 Update 60 | – |
Dies zeigt, daß man zum Beispiel ein FOS 7.1 mit einem Java 6 schon nicht mehr administrieren kann.
JAVA Haltbarkeitsdatum
Seit Version 1.7 Update 21 ist in die Java Runtime ein festgelegtes Verfalldatum einprogrammiert (Tabelle unten). Ist dieses Überschritten, so muss man Java aktualisieren. Damit ergeben sich zwei Notwendigkeiten, die voneinander abhängen:
- Mindestanforderung an Java durch die Version des FOS
- Zwang zur Aktualisierung der JRE durch ein Verfallsdatum
| JRE | Expiration Date |
| 7u71, 8u25 | 20.01.2015 |
| 7u67, 8u20 | 14.10.2014 |
| 7u65, 8u11 | 14.10.2014 |
| 7u60 | 15.07.2014 |
| 7u55, 8u5 | 15.07.2014 |
| 7u51 | 15.04.2014 |
| 7u45 | 14.02.2014 |
| 7u40 | 10.12.2013 |
| 7u25 | 15.11.2013 |
| 7u21 | 18.06.2013 |
| 7u17 | – |
Zertifikatsprobleme
Zu allem Überfluss kommt noch ein weiterer Parameter hinzu: Moderne JRE Versionen lehnen diverse Verschlüsselungs-Algorithmen und zu kurze Schlüssellängen ab. Dazu gehören (Stand 7u67) folgende Einschränkungen:
- DES
- MD2
- RSA mit Schlüssellänge < 2048
Genau hier liegt das Problem bei der Administration älterer FOS Versionen mit aktuellem JRE. Deren Schlüssellänge ist oft unter 2048, weswegen Java die Ausführung des Applets verweigert.
Abhilfe
Das hier beschriebene Verfahren wurde auf Windows7 x64 mit JRE 7u67 getestet.
Zunächst muss die Sicherheitsstufe der JRE auf ein Mindestmaß (Mittel) reduziert werden.
Im zweiten Schritt müssen die abgelehnten Verschlüsselungsverfahren wieder akzeptiert werden. Dazu editiert man die Datei java.security im Verzeichnis:
C:\Program Files (x86)\Java\jre7\lib\security
Folgende Zeile muss auskommentiert (#) werden:
#jdk.certpath.disabledAlgorithms=MD2, DSA, RSA keySize < 2048
Danach startet auch ein älteres Applet wieder unter aktueller JRE. 🙂
Links
- Storage and Beyond – Brocade Webtools and Java
- Oracle – Java 7 Release Changes