Ich brauchte mittlerweile unbedingt JAVA 1.7 auf meinem Rechner.

Hibiscus WIKI, JAVA-FAQ etc. kenne ich, mit meiner Bank (DKB) läuft der HBCI Zugriff via Chipkarte unter JAVA 1.7 auch problemlos.

Wie im Wiki dokumentiert funktioniert aber das DKBVISA Skript leider noch nur unter 1.6, hier bekommt man den "bekannten" javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints Fehler.

Soweit so gut. Meine Idee war jetzt, Hibiscus isoliert mittels eines Wrapper Skripts die JRE 1.6_45 zu geben. Das kenne ich von anderen JAVA Applikationen, läuft sonst überall über die Umgebungsvariable JAVA_HOME.

Mein Wrapper Skript sieht so aus:

@echo off
SET JAVA_HOME=C:\Progra~1\Java\jre6
set PATH=%JAVA_HOME%\bin;%PATH%
cd <HIBISCUS_PROGRAMMDIRECTORY>
.\jameica-win64.exe
pause

Hibiscus scheint aber JAVA_HOME zu ignorieren, daher meine Frage an Olaf:

Mach ich was falsch oder gibt es einen anderen Trick, Hibiscus bei mehreren JREs/JDKs auf eines seiner Wahl zu lenken?

machst du dass ganze jetzt eigentlich nur wegen dem DKBVisa Script? ich weiß jetzt nicht grad welchen Wiki-Eintrag du da meinst und wie alt der ist.

Aber bei mir laufen alle Scripts unter 1.7.0_05 (in 64bit!) oder unter 1.7.0_17 (in 32bit!) problemlos! welche Bit hast du denn installiert? (meine Jameica-Installation unter Win7-64bit verwendet auch meine 64bit-Javaversion)

Hat ja auch weniger mit dem Script (JavaScript nicht Java) selbst zu tun als wenn dann mit HTMLUnit (Java-Bibliotheken) und wie gesagt da achte ich im Moment wenig auf die Java-Version?!

Zudem gibts da doch einen Workaround um bei Java 1.7 die alte SSL wieder einzuschalten?! steht auch hier im Forum ... (aber wie gesagt hab ich bestimmt nicht für ein Script so gemacht)

Gruss TheDudge

Wie TheDudge schon schrieb: Der Workaround, um den alten Hash-Alg MD2 wieder zu aktivieren (wie hier beschrieben: http://www.willuhn.de/wiki/dok…onstraints), sollte auch bei dem Script funktionieren, da es in der gleichen JVM laeuft wie Hibiscus selbst und sich das Setting auf die ganze JVM auswirkt.

Also....

ich habe jetzt mal von "manuell" installierter HTMUnit und DKBVISA.js auf die Repository-Variante umgestellt:

HTMLUnit 2.10
DKBVISA 1.26
(JAVA 1.7.0_21-b11)

Ergebnis: Ohne den JAVA7 "Workaround", also Erlauben von MD2, läuft da bei DKBVISA gar nichts.

Wie früher gesagt: DKB HBCI Zugriff mit JAVA 7 problemlos.

DKBVISA macht jetzt aber letztendlich doch nicht anderes, als sich beim Browser-Banking anzumelden, einen CSV-Export der Umsätze anzustarten und diesen dann in Hibiscus-Umsätze zu verarbeiten.

Wenn ich mit Firefox am Browser-Banking der DKB anmelde, dann zeigt mir FF an, dass ich per RC4 verbunden bin. Entsprechend der jüngsten ct' Artikel, dass RC4 mittlerweile zumindest theoretisch auch schon
kompromittiert ist, habe ich da vor einiger Zeit schon geprüft, das auch Verbindungen über AES möglich sind.

Also an der DKB liegt das Problem (diesmal) wohl kaum.

So wie ich das verstehe, ist die HMTLUnit doch so was wie ein "Browser für Skripts", gibts da nicht irgendwo Optionen, welche Verschlüsselung bevorzugt genutzt werden soll?
Ich habe mich mal oberflächlich in die Dokus zu HMTLUnit eingelesen, da kann man den gewünschten Browser als Parameter übergeben: Wäre z.B. für IE8 im DKBVISA.js im Aufruf des Clients, Zeile 435:

webClient = new WebClient(BrowserVersion.INTERNET_EXPLORER_8);

IE9 und der in der Doku angegebene FF 17 werden von HMTLUnit 2.10 anscheinend noch nicht unterstützt.

Sei es aber drum, ändert noch nichts am Problem

Hat TheDudge da evtl. noch eine Idee?


Daneben würde mich nach wie vor interssieren, wie Jameica "seine" JRE auswählt. Da JAVA_HOME ein Flop war, hab ich weiter gesucht und glaube verstanden zu haben, dass diese Variable nur für JDKs, nicht für JREs ausgewertet wird. Anscheinend wird unter Win7 64 über den Wrapper "jameica-win64.exe" auf die Windows-Registry zugegriffen und die dort als Default eingetragene JVM gestartet.

Kann man das beeinflussen?

das java 7 hbci problem hat ja mit dem script nix zu tun. das macht doch nix mit hbci sondern nur mit https.

und dass man da nix am java einstellen muss hab ich ja schon geschrieben ...

thedudge: Wie kann ich Dich überzeugen, dass das Skript NICHT mit JAVA 7 OHNE den Workaround mit erlaubter MD2 Verschlüsselung läuft?

Vielleicht durch den Log-Auszug?

[Tue Apr 30 17:55:42 CEST 2013][ERROR][de.willuhn.jameica.scripting.messaging.InvokeMessageConsumer.handleMessage] error while executing script method wiedenhoeftNet_dkbVisa_Js_kontoSync, adding exception to return list
javax.script.ScriptException: sun.org.mozilla.javascript.internal.WrappedException: Wrapped javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints (<Unknown source>#575) in <Unknown source> at line number 575


Wie gesagt, es sieht so aus, als würde die HTMLUnit per Default MD2 haben "wollen", was die DKB (noch) unterstützt.

Noch - daher finde ich dieses Problemchen trotz Workaround dennoch spannend und nachverfolgenswert. Und helfe dabei, wenn möglich, gerne mit.

hmm wahrscheinlich gar nicht weil ich wie ich schon geschrieben habe, dieses auch (wie auch die meisten anderen) unter windows 7 64 mit java 7 (genauso wie du)

aber ohne irgend einen Workaround am laufen habe

daher bin ich der Meinung dass dies kein allgemeines Problem ist lasse mich aber gerne eines besseren belehren
dafür bräuchte ich aber mehr Hintergrund-Informationen oder auch mal einen anderen Benutzer bei dem dieses Problem auftritt um die Bedingung fest setzten zu können.

Bei Linux geschieht das ueber die Variable $PATH. Bei Windows sucht der Launcher die passende Java-Version. Wie genau das implementiert ist und welche Registry-Zweige da gelesen werden, kann ich dir auch nicht sagen. Die EXE-Datei erzeuge ich mit "Launch4J". Die zugehoerige Config-Datei findest du hier: https://github.com/willuhn/jam…-win32.xml