Kein Java 7 für Jameica, Hibiscus & Co.

Wenn ihr Hibiscus verwendet, aktualisiert bitte noch nicht auf das neue Java 7. Unter Umständen wird dann beim Aufbau der Verbindung zur Bank die Fehlermeldung "Certificates does not conform to algorithm constraints" auftreten. Thomas hat das Problem in seinem Blog mal analysiert und ist zu dem Schluss gekommen, dass es durch SSL-Zertifikate ausgelöst wird, die veraltete Algorithmen verwenden. Leider sind solche aber noch bei vielen Banken im Einsatz. Da mir derzeit kein anderer Workaround bekannt ist, bleibt im Moment nur (falls eure Bank hiervon betroffen ist): Installiert nicht Java 7 sondern nutzt erstmal weiter Java 6.

Trackbacks

Trackback-URL für diesen Eintrag

Dieser Link ist nicht aktiv. Er enthält die Trackback-URI zu diesem Eintrag. Sie können diese URI benutzen, um Ping- und Trackbacks von Ihrem eigenen Blog zu diesem Eintrag zu schicken. Um den Link zu kopieren, klicken Sie ihn mit der rechten Maustaste an und wählen "Verknüpfung kopieren" im Internet Explorer oder "Linkadresse kopieren" in Mozilla/Firefox.

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Björn am :

Jameica und Hibiscus sind nicht die einzigen Programme die bisher mit Java 7 Probleme haben. Auch LibreOffice hat damit seine Probleme. ;( Deswegen bin ich von Java 7 wieder zurück auf Java 6 gewechselt.

Jörg Schlickeiser am :

In Java 7 wurde der MD2-Hash wegen Sicherheitsbedenken deaktiviert. in der Datei:
C:\Program Files (x86)\Java\jre7\lib\security\java.security die Zeile:
jdk.certpath.disabledAlgorithms=MD2 so auskommentieren #jdk.certpath.disabledAlgorithms=MD2", dann funktioniert zumindest das VISA-Script der DKB-Bank. Den TIp habe ich hier gefunden: http://www.onlinebanking-forum.de/phpBB2/viewtopic.php?p=84754

Viel Spaß,
Jörg

Olaf am :

Siehe auch http://www.willuhn.de/blog/index.php?/archives/616-Workaround-fuer-die-Java7-Problematik.html ;)

OldShatterhand am :

hm das ist natürlich grade wenn man ne rolling release distro benutzt (arch linux) nich so schön....
naja egal wechsel ich halt wieder zurück auf openjdk.. damit hats bis jetzt immer ohne probleme geklappt (ich hoffe das is ja immer noch so)

theodis am :

Also mit der SK Hannover funktioniert alles einwandfrei (Win 7 64Bit, Java 7 32Bit)

Olaf am :

Schoen zu hoeren, dass es auch Banken gibt, die saubere Zertifikate verwenden ;)

Tekin am :

Ich habe Java 7 und Java 6 Update 26 auf meinem Ubuntu installiert. Bermekte auch die Fehlermeldung und hab es gelöst indem ich die jameica.sh ein wenig anpasste mit einem absoluten Pfad zum java im Java 6 Ordner.

Harry am :

Wie kann man Jameica auf Win7 mit einer bestimmten JRE starten?

Olaf am :

Man kann beim Start von Jameica kein konkretes JRE angeben. Wenn nur ein Java installiert ist, wird das automatisch genommen. Wenn mehrere installiert sind, wird vermutlich das genommen, welches als letztes installiert wurde. Beeinflussen kannst du das vermutlich unter Windows mit der %PATH%-Umgebungsvariable. Das hier koennte da helfen: http://www.java-forum.org/einfuehrungen-erste-schritte/94072-java-umgebungsvariable-einstellen-windows-7-a.html

Harry am :

Mit der Umgebungsvariable habe ich schon probiert, geht nicht. Ich hatte zuerst nur Java 6 und habe dann Java 7 nachinstalliert. Java deinstalliert nicht automatisch alte Versionen, also hatte ich dann 6 und 7 gleichzeitig drauf.

Ich programmiere selber für die Uni mit Eclipse und nutze da gerne die neueste Version. Habe trotzdem mal die path=java6 und classpath=java6. Dann jameica.exe gestartet und trotzdem ungültiges Zertifikat beim synchronisieren.

Dann habe ich probiert mit cmd c:/jr6/java -jar c:/jameica/jameica-win32.jar, aber dann kam

c:\Program Files\Java\jre6\bin>java -jar D:\Programme\jameica\jameica-win32.jar
[Tue Oct 04 16:49:59 CEST 2011][INFO][de.willuhn.jameica.system.StartupParams.] starting in STANDALONE mode
[Tue Oct 04 16:49:59 CEST 2011][INFO][de.willuhn.jameica.system.StartupParams.] workdir: null
[Tue Oct 04 16:49:59 CEST 2011][INFO][de.willuhn.jameica.system.Application.init] starting jameica...
[Tue Oct 04 16:49:59 CEST 2011][INFO][de.willuhn.jameica.system.Platform.getWorkdir] using workdir: C:\Users\Karlsberg\.jameica
[Tue Oct 04 16:49:59 CEST 2011][INFO][de.willuhn.util.Session.] creating new session. default timeout: 1800000 millis
[Tue Oct 04 16:49:59 CEST 2011][INFO][de.willuhn.util.Session$Worker.] Starting Session Worker Thread
[Tue Oct 04 16:49:59 CEST 2011][INFO][de.willuhn.jameica.system.Config.getLocale] configured language: de
[Tue Oct 04 16:49:59 CEST 2011][INFO][de.willuhn.jameica.system.Config.getLocale] configured country: DE
[Tue Oct 04 16:49:59 CEST 2011][INFO][de.willuhn.jameica.system.Config.getLocale] checking resource bundle for language
java.io.IOException: manifest c:\Program Files\Java\jre6\bin\plugin.xml not readable
at de.willuhn.jameica.plugin.Manifest.(Manifest.java:71)
at de.willuhn.jameica.system.Application.getManifest(Application.java:461)
at de.willuhn.jameica.gui.SplashScreen.(SplashScreen.java:89)
at de.willuhn.jameica.system.ApplicationCallbackSWT.getStartupMonitor(ApplicationCallbackSWT.java:173)
at de.willuhn.jameica.system.Application.init(Application.java:96)
at de.willuhn.jameica.system.Application.newInstance(Application.java:86)
at de.willuhn.jameica.Main.main(Main.java:78)
[Tue Oct 04 16:49:59 CEST 2011][INFO][de.willuhn.jameica.system.Config.getLocale] active language: Deutsch (Deutschland)
[Tue Oct 04 16:49:59 CEST 2011][INFO][de.willuhn.util.I18N.] loading resource bundle lang/system_messages for locale de_DE
[Tue Oct 04 16:49:59 CEST 2011][ERROR][de.willuhn.jameica.system.Application.startupError] FATAL ERROR WHILE JAMEICA STARTUP
java.io.IOException: manifest c:\Program Files\Java\jre6\bin\plugin.xml not readable
at de.willuhn.jameica.plugin.Manifest.(Manifest.java:71)
at de.willuhn.jameica.system.Application.getManifest(Application.java:461)
at de.willuhn.jameica.gui.SplashScreen.(SplashScreen.java:89)
at de.willuhn.jameica.system.ApplicationCallbackSWT.getStartupMonitor(ApplicationCallbackSWT.java:173)
at de.willuhn.jameica.system.Application.init(Application.java:96)
at de.willuhn.jameica.system.Application.newInstance(Application.java:86)
at de.willuhn.jameica.Main.main(Main.java:78)

Olaf am :

> Dann habe ich probiert mit cmd c:/jr6/java -jar
> c:/jameica/jameica-win32.jar,

Da fehlt vorher noch ein

cd \Programme\jameica

... damit die Libs im Programm-Ordner von Jameica gefunden werden.

Harry am :

Jo, aber wenn ich in den jameica Ordner gehe, kann ich mit "java -jar" nicht die jre6 erzwingen, das geht nur, wenn ich im Ordner jre6 bin. Habe auch keinen Option wie "java -use jre6 -jar jameica.jar" gefunden. Oder wie meinst du das?

Jedenfalls habe ich letzten endes aufgegeben und java7 deinstalliert :(

Olaf am :

> Jo, aber wenn ich in den jameica Ordner gehe, kann
> ich mit "java -jar" nicht die jre6 erzwingen

Na klar geht das:

cd \Programme\jameica
c:\Programme\Java\jre6\bin\javaw.exe -Xmx256m -jar jameica-win32.jar

Harry am :

Ah lol, das hatte ich schon probiert, ging aber irgendwie nicht, hatte mich bestimmt vertippt oder so, also kann man so java7 weiter auf dem rechner lassen, cool :) danke

Harry am :

Ach und sry:

Version: 2.1.0-nightly
SWT-Version: 3650 / win32
Build: 437 [Datum 20111003]

Software-Version: 2.1.0-nightly
Datenbank-Version: 35
Build: 358 [Datum 20111003]

btw: Im "Über" Fenster geht strg+c nicht :)

Dieter Mosbach am :

Ich habe das Problem aber auch mit Java 1.6:

[09.11.2011 00:03:44] fetching BPD
[09.11.2011 00:03:44] erzeuge HBCI-Nachricht DialogInitAnon
[09.11.2011 00:03:44] creating a connection to https://hbci-pintan-rp.s-hbci.de:443/PinTanServlet and checking the certificate
[09.11.2011 00:03:44] versende HBCI-Nachricht
[09.11.2011 00:03:44] Fehler beim Senden der HBCI-Nachricht zum Server
[09.11.2011 00:03:44] Certificates does not conform to algorithm constraints
[09.11.2011 00:03:44] Certificates does not conform to algorithm constraints
[09.11.2011 00:03:44] beende Dialog
[09.11.2011 00:03:44] kann HBCI-Wert für MsgHead.dialogid nicht auf null setzen
[09.11.2011 00:03:44] fetching BPD failed: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints org.kapott.hbci.manager.HBCIInstitute.fetchBPD(HBCIInstitute.java:250)
[09.11.2011 00:03:44] Abholen der BPD fehlgeschlagen


C:\Dokumente und Einstellungen\mosbachd>java -version
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
Java HotSpot(TM) Client VM (build 20.4-b02, mixed mode, sharing)

Olaf am :

Ich hab die gleiche Java-Version. Bei mir tritt der Fehler nicht auf. Auch mit meiner Sparkasse nicht - obwohl die auch solche alten Zertifikate verwenden. Falls du also wirklich sicher bist, dass du nicht vielleicht doch versehentlich Java 7 verwendest (vielleicht hast du ja beide Versionen parallel installiert und nur Hibiscus verwendet Java 7, die Konsole aber nicht), koenntest du hoechstens noch versuchen, eine aeltere Java-Version zu installieren.

Ich kann da leider nichts in Jameica oder Hibiscus machen. Das Problem kann durch eine aeltere Java-Version geloest werden. Oder durch neue Zertifikate bei der Bank (die nicht mehr diese veralteten Algorithmen verwenden). Siehe auch

http://everflux.de/ssl-problem-mit-java-7-1855/

Dieter Mosbach am :

Wie kann ich rausfinden, welche Java-Version Hibiscus verwendet?
Stört viielleicht das Java-SDK 7 für Eclipse?

Olaf am :

Die Java-Version wird in der jameica.log beim Start gleich am Anfang ausgegeben.

Wenn du parallel noch ein Java 7 fuer Eclipse installiert hast, koennte das schon ne Ursache sein.

Dieter Mosbach am :

Ja, das war die Ursache.
Das SDK7 downgegradet auf 6u29, und schon funktioniert Hibiscus wieder!
Wieso allerdings in der commandline und in Jameica unterschiedliche Java-Versionen verwendet werden....
Vielen Dank für die Hilfe!

Olaf Willuhn am :

Prima.

Es kann sein, dass der EXE-Launcher fuer die Wahl der Java-Version nicht %PATH% nimmt sondern in die Registry schaut. Der Launcher ist mit "launch4j" erstellt.

Carsten am :

Gibt es zu diesem Thema eigentlich Neuigkeiten? Oder zumindest eine (einfache) Variante, Hibiscus mitzuteilen, bitte eine bestimmte Java Version zu verwenden?

Manchmal benötigt man eben doch für bestimmte Sachen auch ein Java 1.7...

Olaf am :

Die Verantwortung liegt hier eigentlich bei den Banken. Die muessen dafuer sorgen, dass sie korrekte Zertifikate mit aktuellen Hash-Algorithmen verwenden.

Du kannst Jameica auch mit expliziter Java-Version starten. Hierzu muesstest du sicherstellen, dass in der Systemumgebungsvariable $PATH (Linux) bzw. %PATH (Windows) der Pfad zum "java"-Binary bzw. zu java.exe von der gewuenschten Version steht. Jameica verwendet einfach die als Default eingestellte Java-Version. Also google z.Bsp. mal nach "mehrere Java versionen parallel". Das ist nichts Jameica-spezifisches.

Carsten am :

Ja ich habe das per .bat gelöst. Finde ich aber nicht hübsch. Könnte sowas nicht in den .exe Starter eingebaut werden? Logisch gesehen muss der auf die "korrekte" Java-Version prüfen und diese auswählen, bzw. warnen, wenn es keine passende findet...

Olaf am :

> Könnte sowas nicht in den .exe Starter eingebaut
> werden?

Ne, das geht nicht. Der Starter ist mit "Launch4J" erstellt. Dort kann man zwar eine Minimal- und Maximal- Java-Version angeben, aber keine bevorzugte Version. Und da Java 7 ja nur dann ein Problem ist, wenn die Bank veraltete Zertifikate verwendet (Jameica und Hibiscus selbst laufen problemlos mit dieser Java-Version), kann ich Java 7 auch nicht grundsaetzlich via Max-Version ausfiltern. Schliesslich kann es ja sein, dass ein User nur Java 7 installiert hat, das bei ihm aber gar kein Problem ist, weil seine Bank korrekte Zertifikate verwendet.

Laurens am :

Man kann diesen Java-Check manuell deaktivieren, auch wenn das der Idee dahinter widerspricht:

http://www.richardnichols.net/2012/08/arrrggh-java-security-cert-certificateexception-certificates-does-not-conform-to-algorithm-constraints/

Unter Windows liegt die Datei entsprechend unter Programme\Java\...

Olaf am :

Genau das selbe steht auch in dem Blog-Beitrag, den ich weiter oben in meinem Kommentar 1.1.1 verlinkt habe: http://www.willuhn.de/blog/index.php?/archives/616-Workaround-fuer-die-Java7-Problematik.html

Melchior Blausand am :

Nach der Serie schwerer Sicherheitslöcher in Java ist das Vertrauen in die virtuelle Maschine am Boden. Selbst das Bundesministerium für Sicherheit in der Informationstechnik (BSI) rät inzwischen zur Deinsallation von Java als Ganzes.

Hier auf willuhn.de dagegen liest man immernoch, statt Java 1.7 möge man lieber weiter 1.6 benutzen. Dieser letzte bLog-Eintrag ist von 2011, sein letzter Kommentar von vor 3 Monaten.

Was sollen wir nun denken, Herr Willuhn? Die einzige wirklich freie, weil unkommerzielle online-Banking-Software im deutschen Sprachraum ist gestorben?
Ich möchte sehr gerne weiterarbeiten, und ich denke, viele andere Anwender auch.
Lassen Sie uns nicht im Stich. Von mir aus rufen Sie zu Spenden auf, aber lassen Sie bitte dringend etwas zur Aktualisierung Ihrer Software hören!
Keiner will ein totes Pferd reiten.

Olaf Willuhn am :

> Nach der Serie schwerer Sicherheitslöcher in Java ist das
> Vertrauen in die virtuelle Maschine am Boden.

Extra fuer dich habe ich jetzt eine Wiki-Seite angelegt, um endlich mit diesen Missverstaendnissen aufzuraeumen, dass diese Sicherheitsloecher irgendwas mit Hibiscus zu tun haben:
http://www.willuhn.de/wiki/doku.php?id=support:javafaq

> Hier auf willuhn.de dagegen liest man immernoch, statt Java
> 1.7 möge man lieber weiter 1.6 benutzen. Dieser letzte bLog-Eintrag
> ist von 2011, sein letzter Kommentar von vor 3 Monaten.

Also der letzte Blog-Beitrag unter www.willuhn.de/blog stammt vom 27. Februar und ist damit gerade mal 14 Tage alt. Dass es in diesem Blog-*Beitrag* keine Updates gibt, liegt daran, dass es ein Blog ist. Dort aktualisiert man Postings nicht rückwirkend. Das ist wie bei einer Zeitung. In der Ausgabe von letzter Woche wird doch auch nicht der Wetter-Bericht aktualisiert.

> Was sollen wir nun denken, Herr Willuhn? Die einzige wirklich
> freie, weil unkommerzielle online-Banking-Software im deutschen
> Sprachraum ist gestorben?

Hä? Wieso denn das? Hibiscus wird aktiv wie eh und je weiterentwickelt. Und wenn du Java 7 verwenden willst, dann tu das. Wenn es zu Problemen kommt, liegt das nicht an Hibiscus sondern an deiner Bank. Das steht auch in diesem Blog-Beitrag. Und ich bin es echt leid, dass immer wieder Leute glauben, dass ich hier irgend eine Bringschuld hätte. Nochmal: Einige Banken verwenden veraltete SSL-Zertifikate, die von Java 7 nicht akzeptiert werden. Daran kann ich nichts ändern sondern nur die Bank.

> Ich möchte sehr gerne weiterarbeiten, und ich denke, viele andere
> Anwender auch. Lassen Sie uns nicht im Stich.

Ich lasse doch niemanden im Stich. Und ich weiss auch nicht, wie dieser Eindruck entstehen konnte. Seit nunmehr fast 10 Jahren gibt es ca. 2 neue Releases pro Jahr. Und das wird auch so bleiben. Wenn irgendwelche Banken nicht in der Lage sind, ihre Zertifikate auf einen für Java 7 brauchbaren und zeitgemäßen Stand zu bringen, dann ist doch nicht meine Schuld.

> Keiner will ein totes Pferd reiten.

Hibiscus ist kein totes Pferd, verdammt nochmal!!

PS: Weil mit diese dauernden Missverständnisse inzwischen echt auf den Wecker gehen, deaktiviere ich jetzt die Kommentar-Funktion für diesen Blog-Beitrag.

Die Kommentarfunktion wurde vom Besitzer dieses Blogs in diesem Eintrag deaktiviert.