Zitat geschrieben von Raimund Sichmann
technische Info:
Der Fehler entstand dadurch, dass im Signaturkopf das DE Sicherheitsfunktion kodiert" statt mit 2 ( = Signierschlüssel) mit 1 ( = DS-Schlüssel) belegt ist.
Zur Zeit toleriert der Server die falsche Belegung wieder, allerdings sollten die betroffenen Programme an dieser Stelle angepasst werden.
@Olaf: Ich hoffe, du kannst damit etwas anfangen?
Im Moment blicke ich das noch nicht ganz. Ich denke mal, hier geht es um das Segment HNSHK, wie es in
http://www.hbci-zka.de/dokumen…ersion.pdf (Kapitel B.5.1) beschrieben ist. Das ist der Signaturkopf. Dort gibt es ein DE "Sicherheitsfunktion, kodiert", welches je nach HBCI-Version und Sicherheitsprofil mit 1 oder 2 belegt werden muss. In dem PDF findet sich die Tabelle der moeglichen Werte direkt auf Seite 2 des Kapitels B.5.1. HBCI4Java setzt den Wert wie folgt:
a) Bei DDV (Chipkarte): generell "2" -> korrekt
b) Bei RDH (in HBCI4Java nur Schluesseldatei, da solche Chipkarten ja nicht unterstuetzt werden:
- bei FinTS 3 generell "2"
- sonst generell "1"
Wenn Hibiscus also faelschlicherweise "1" verwendet statt "2", kann das ja nur bei Schluesseldatei passieren, wenn als HBCI-Version in Hibiscus irgendwas aelteres als FinTS 3 eingestellt ist. Ich weiss, das ist jetzt nicht die sauberste Loesung (hierzu muesste HBCI4Java angepasst werden). Aber als schneller Workaround sollte doch helfen, wenn der User die Detailansicht der Schluesseldatei oeffnet und dort die HBCI-Version auf "FinTS 3" stellt. Dann sendet Hibiscus als Sicherheitsfunktion "2", so wie es von der GAD erwartet wird.
Falls hier ein betroffener User mitliest - probiert das mal aus, vielleicht hilft es ja schon.