Hallo ich benutze seit Januar Hibiscus/Jameica mit der GLS-Bank. Manchmal werde ich aufgefordert ein neues Zertifikat zu akzeptieren, dass nicht mit dem Web-Zertifikat übereinstimmt. Ich habe es nie akzeptiert. Leider habe ich die Informationen nicht festgehalten.

Der Support am Telefon war auch ratlos. Heute hatte ich 3mal versucht mit der GLS Bank zu synchronisieren und immer kam das "falsche" Zertifikat. Nach dem Anruf beim Support und einer neuen Internetverbindung (Wlan-switch) ging es plötzlich wieder einwandfrei.

Dieses Problem hatte ich for ca 5 Wochen schonmal und ganz am Anfang als das Konto neu war.

Entschuldigung für die chaotische Beschreibung, aber ich kenne mich in diesem Bereich noch kaum aus.

Hallo,

wenn Du Java 7 nutzt und die Fehlermeldung ungefähr so klang: "java.security.cert.CertificateException: Certificates does not conform to algorithm constraints", dann kannst Du hier: http://www.willuhn.de/blog/ind…matik.html nachlesen, wie Du das Problem lösen kannst.

Ansonsten Vorschlag: Wenn das Problem das nächste mal wieder auftritt, unbedingt Status-Meldungen kopieren/aufschreiben und hier posten.

Viele Grüße,
Michael

Mach auch mal nen Screenshot des Dialogs mit dem unbekannten Zertifikat. Dann koennen wir die MD5- und SHA1-Checksumme vergleichen und feststellen, ob es das richtige Zertifikat ist.

Ich meine mich zu erinnern, dass wir sowas in der Vergangenheit schonmal bei einer Bank hatten - allerdings weiss ich nicht mehr, welche Bank das war. Dort trat das auch nur sporadisch auf. Ein User hatte das naeher analysiert und festgestellt, dass in einem von 4 Faellen die Chain in den uebertragenen Zertifikaten eine andere Reihenfolge hatten, was wohl dazu fuehrte, dass der Java-Trustmanager die Vertrauenskette nicht pruefen konnte und Hibiscus deshalb den Hinweis anzeigte. Da lag die Vermutung nahe, dass einer der HBCI-Server im Cluster der Bank irgendwie falsch konfiguriert war.

@Raimund: Ist dir hier irgbendwas bekannt? Hast du sowas in letzter Zeit noch von einem anderen User gehoert?

nicht wirklich, wir haben x300 hierhin heute extra eingeladen. Gaaaanz ratlos waren wir ja nicht, denn das Forum ist doch ein sehr guter Rat, oder? ). Nunja, die Java-Problematik hätte ich aus dem Stegreif nicht erklären können.

Bei Zertifehlern hat man natürlich immer seine üblichen Verdächtigen aus der Windows-Welt: Falsches Systemdatum, Virus oder verkonfiguriertes Security-Tool.

Aber mal was anderes: Kann es hier ein MTU-Problem geben mit fragmentierten Paketen? Das ist so ein klassisches Problem, was wirklich schwer zu packen ist. Allerdings habe ich in dem Zusammenhang noch nie etwas von einem Zertifikatsfehler gehört.
http://wireless.subsignal.org/…ter_Seiten

Gruß
Raimund

Falsches Systemdatum kann in der Tat eine Ursache sein. In dem Fall sollte in dem Zertifikatsdialog in Hibiscus folgender Text in Rot angezeigt werden: "Zertifikat abgelaufen oder noch nicht gültig!"

Virus bzw. DNS-Spoofing kann man natuerlich nicht ausschliessen. Waere allerdings das erste mal, dass ich von so einem Angriff tatsaechlich in der Praxis hoere.

Von dem MTU-Problem hab ich noch nie gehoert. Allerdings kann ich mir nicht vorstellen, dass das eine moegliche Ursache sein kann. Unter Umstaenden kann sowas vielleicht die Datenuebertragung generell kaputt machen. Dann waere das Programm aber gar nicht erst bis zur Anzeige des Zertifikates gekommen sondern haette schon vorher abgebrochen.

Also, wie gesagt: Wenn die Checksummen des angezeigten Zertifikates korrekt sind, dann ist vermutlich lediglich die Zertifikatspruefung von dem in Java direkt integrierten Trustmanager auf die Nase gefallen, weil er die Kette der Zertifikate vom Server bis zur obersten CA in genau der Ausstellungsreihenfolge erwartet. Ob das bei allen Java-Versionen so ist, kann ich nicht sagen. Kann durchaus sein, dass manche Java-Versionen da toleranter sind.

Zum Virus: Hab selbst einen "manipulierten" Netgear-Router gesehen, bei dem der DNS-Eintrag durch einen Virus manipuliert war. Da kann auch schon mal einfach alles umgeleitet werden, in dem Fall war es allerdings ein massiver Porno-Spam-Verteiler Proxy. War schon irgendwie lustig, wie die Ehefrau den armen Mann immer mehr verdächtigte...

An die MTU-Geschichte glaub ich in dem Zusammenhang eigentlich auch nicht wirklich, es ist ja unwahrscheinlich, dass da ausgerechnet beim Schlüssel-Prüfen etwas am Zertifkat fehlt.

Merkwürdig ist, dass die Zertifikatsfehler bei anderen Programmen eigentlich unbekannt sind. Wenn das also ein Fehler am HBCI-Server bei der GAD wäre, müsste das doch eigentlich bei allen irgendwann auftreten, oder?

Gruß
Raimund

Armer Ehemann



Falls das wirklich die Ursache ist.
Ich weiss gar nicht, ob die Reihenfolge der Zertifikate in der Chain ueberhaupt vorgeschrieben ist oder ob hier lediglich einige Java-Versionen besonders pingelig sind. Zumal die Zertifikate auch dann korrekt geprueft werden koennten, wenn die Reihenfolge nicht korrekt ist.

Um genauere Aussagen treffen zu koennen, braeuchte man aber eine jameica.log mit DEBUG-Level in dem der Fehler auch tatsaechlich mal aufgetreten ist.

Vielen Dank
für die Hinweise der Fehler ist wieder aufgetreten mit dem gleichen "falschen" Zertifikat

http://imgur.com/7loKRrh

Das Zertifikat ist jedenfalls das korrekte. Ich hab https://hbci-pintan.gad.de/ mal im Browser eingegeben und mir von dort die Pruefsummen anzeigen lassen (siehe Attachment). Sind die selben Werte. Kannste auch selbst einfach testen - idealerweise von einem anderen Rechner mit anderem Internet-Zugang um wirklich sicherzugehen, dass kein Schaedling DNS-Spoofing macht.

Also liegt es eventuell wirklich an der Chain, die den Java-Trustmanager ins Straucheln bringt. Klick auf "Ja", um dem Zertifikat zu vertrauen. Dabei wird es in den Jameica-eigenen Truststore importiert. Anschliessend sollte es nicht mehr zu diesem Verhalten kommen. Selbst wenn Java bei der Pruefung scheitert, erkennt in dem Fall Jameica selbst, dass diesem Zertifikat vertraut werden kann.

das normale Zertifikat ist folgendes:

https://internetbanking.gad.de/ptlweb/WebPortal?bankid=4967

http://imgur.com/8L62nOg

mit dem passenden Schlüssel der auch von GLS-Bank zur Kontrolle angegeben wird. Das ist auch das Zertifikat was normalerweise von Jameica benutzt wird. Jedoch alle paar Wochen/Tage kommt das andere zur manuellen Bestätigung.

Das ist das Zertifikat fuer "internetbanking.gad.de". Das ist die Bank-Webseite, nicht der HBCI-Server. Dieses Zertifikat hat nichts mit dem des HBCI-Servers zu tun.