Problem EBICS mit Raifeisenlandesbank Oberösterreich

peer not authenticated

 
stefangr
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 3
Dabei seit: 11 / 2009
Betreff:

Problem EBICS mit Raifeisenlandesbank Oberösterreich

 · 
Gepostet: 19.11.2009 - 16:23 Uhr  ·  #1
Hallo Forum!

Wir haben regelmäßig ein sporadisches Problem EBICS mit Raifeisenlandesbank Oberösterreich. Der Kunde hat SFirm32 2.2.2 (Client/Netzwerk) im Einsatz mit einigen Banken über EBICS etc., nur bei der oben genannten Bank funktioniert das ganze nicht wie es soll. Die Raiffeisenbank Oberösterreich schiebt die Schuld auf SFirm32.

1. Problembeschreibung in Zusammenarbeit mit dem Hersteller BIVG (diverse Tickets):


Regelmäßiger, sporadisch auftretender Fehler bei der Übertragung an die Raiffeisenlandesbank Oberösterreich:
---
A) Fehler bei Übertragung:
Code: 8, de.ppi.fis.trafic.ebics.kernel.transport.CommunicationException: Bei der Kommunikation mit https://banking.multicash.at/: peer not authenticated - Testen Sie das SSL Zertifikat

B) Fehler beim Test des SSL-Zertifikats:
Code: 8, Fehler bei der Kommunikation mit https://banking.multicash.at/:HTTP/1.1 406 Not Acceptable

URL für EBICS: https:/banking.multicash.at/
Host: RLBBHP

C) Detaillierte Beschreibung:
Generell oder sporadisch tritt der Fehler "peer not authenticated" bei der Raiffeisenlandesbank Oberösterreich auf. Die URL des HOST ist zusätzlich zum Zeitpunkt des Fehlers nicht erreichbar. Die Prüfung wurde über den Browser und über das interne Prüfprogramm von SFirm32 durchgeführt. Ein manueller Import des Zertifikats löste ebenfalls das Problem nicht. Der HOST-Rechner ist somit nicht erreichbar oder nicht in der Lage auf die Anfrage zu antworten. Ähnliche sporadische Probleme wurden bereits bei Kunden von Banken, welche Bankrechner der Firma Omikron im Einsatz haben, festgestellt. Es wird vermutet dass bei der Raiffeisenbank Oberösterreich ebenfalls Bankrechner der Firma Omikron im Einsatz sind. Der Grund des Problems ist unbekannt.

2. Informationen zum Problem - soweit derzeit dem Hersteller BIVG bekannt


In Deutschland gibt es derzeit zwei große Hersteller von Bankrechnern. Die Firma PPI (Marktführer) und die Firma Omikron. Laut Hersteller gibt es derzeit vermehrt sporadische Verbindungsprobleme bei Banken, welche mit EBICS in Verbindung mit Bankrechnern der Firma Omikron arbeiten. Diese Probleme haben derzeit alle Software-Produkte, welche den EBICS-Kernel der Firma PPI einsetzen. SFirm32 nutzt ebenfalls diesen Kernel. Dieser Kernel hält sich an alle Standards des ZKA und sollte somit 100% kompatibel mit allen Bankrechnern sein. Der EIBCS-Kernel der Firma PPI, welcher in SFirm32 im Einsatz ist, sollte laut Herstelleraussage nicht für den Fehler verantwortlich sein. Jedoch wurde der Fehler von der Fima PPI an Omikron zur Prüfung weitergeleitet. Eine Lösung wird zur Zeit gemeinsam mit den Hersteller des Bankrechners Omikron und Firma PPI erarbeitet.

Die Firma BIVG kann somit keine genaue Aussage zu dem Fehler treffen, nur bestätigen dass SFirm32 hierbei keine Schuld treffen sollte.

3. Lösungungsansätze
A) Mehrfacher Versuch zur Übertragung einer Zahlung an einen HOST-Rechner der Fa. Omrikon, bis es funktioniert (Zufallsprinzip)

B) Wechsel des Sicherheitsmediums auf FINTS (PIN/iTAN, chipTAN, HBCI-Chipkarte, Sicherheitsdatei) bis der Fehler behoben wurde

C) Kontaktaufnahme mit der Raifeisenlandesbank Oberösterreich. Diese soll das Problem in Zusammenarbeit mit ihrem Rechenzentrum prüfen und um Abhilfe/Mithilfe sorgen.

Kann mir jemand den oben dargestellten Sachverhalt bestätigen? Hat jemand ein ähnliches Problem mit Omikron Bankrechnern via EBICS?

Vielen Dank vorab für die Hilfe!

Gruß

Stefan Gruber
Captain FRAG
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Westfalen
Beiträge: 5096
Dabei seit: 05 / 2003
Betreff:

Re: Problem EBICS mit Raifeisenlandesbank Oberösterreich

 · 
Gepostet: 19.11.2009 - 16:42 Uhr  ·  #2
Dann müsste den Geno-Kollegen aus dem Süden (Fiducia) das Problem sehr bekannt sein. Dort ist ein Omikron Bankrechner zusammen mit dem PPI Client Kernel in Proficash im Verbund im Einsatz.
Oder alle SFirm oder ProfiCash Versionen, in denen eine Fiducia, ex Dresdner oder DeuBa EBICS-Bank eingerichtet ist.

Nur: Wenn zum Zeitpunkt des Problems auch kein Kontakt über den Browser möglich ist, kann der Fehler nur auf Bankseite oder in der Inetrnet-Verbidung des Kunden begründet sein. Da brauche ich mit über Sfirm32 oder jeden anderen Client keine weiteren Gedanken machen.
Holger Fischer
Benutzer
Avatar
Geschlecht:
Herkunft: Korschenbroich
Alter: 53
Beiträge: 6205
Dabei seit: 02 / 2003
Betreff:

Re: Problem EBICS mit Raifeisenlandesbank Oberösterreich

 · 
Gepostet: 19.11.2009 - 16:56 Uhr  ·  #3
Hi Captain,

Zitat geschrieben von Captain FRAG
Dann müsste den Geno-Kollegen aus dem Süden (Fiducia) das Problem sehr bekannt sein. Dort ist ein Omikron Bankrechner zusammen mit dem PPI Client Kernel in Proficash im Verbund im Einsatz.

Die Info musst Du in irgendeiner Höhle noch in Keilschrift gefunden haben 😉

Bei der FIDUCIA stehen schon lange Multicom Rechner von Coconet.

Gruß

Holger
ottoager
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Saxony
Beiträge: 679
Dabei seit: 09 / 2003
Betreff:

Re: Problem EBICS mit Raifeisenlandesbank Oberösterreich

 · 
Gepostet: 20.11.2009 - 08:33 Uhr  ·  #4
Zitat geschrieben von Captain FRAG
Oder alle SFirm oder ProfiCash Versionen, in denen eine Fiducia, ex Dresdner oder DeuBa EBICS-Bank eingerichtet ist.


IMO hat die Dresdner ebenso (wie Holger bereits schrieb) die Fiducia mittlerweile den CoCoNet-Bankrechner; die Deutsche Bank setzt für EBICS eine speziell angepasste Version des PPI-Systems ein.

Den Omikron-Bankrechner setzen nach meinem Kenntnisstand im EBICS-Bereich mittlerweile nur noch ein paar Landesbanken und vielleicht ein paar kleinere KI's ein (die LBBW z.B.); ich habe es in meiner Praxis bisher immer nur mit PPI und CoCoNet-Systemen zu tun gehabt...

Otto
Captain FRAG
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Westfalen
Beiträge: 5096
Dabei seit: 05 / 2003
Betreff:

Re: Problem EBICS mit Raifeisenlandesbank Oberösterreich

 · 
Gepostet: 20.11.2009 - 09:08 Uhr  ·  #5
Scheinbar hab ich wohl gedanklich gewürfelt...

Trotz allem: Wenn der Browserzugriff auch sporadisch bzw. zum gleichen Zeitpunkt nicht funktioniert, kann die Ursache eigentlich nur auf Verbindungs-/Leitungs- oder Serverseite liegen.

Oder übersehe ich etwas?
stefangr
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 3
Dabei seit: 11 / 2009
Betreff:

Antwort der Fa. Omikron an unseren Kunden

 · 
Gepostet: 24.11.2009 - 16:41 Uhr  ·  #6
Sehr geehrter Herr XXXX,

zunächst einmal möchte ich festhalten, dass selbstverständlich auch unser Bankrechner EBICS-konform arbeitet (und u.a. für alle deutschen Privatbanken von der BV-Zahlungssysteme GmbH abgenommen ist). Wie in der Antwort der Sparkasse richtig dargestellt wird, treten diese Probleme ausschließlich mit Kundensystemen auf, die einen EBICS-Kernel der Firma PPI verwenden. Dieses Problem hat sich mit der Einführung einer neuen Client-Version offenbar extrem verstärkt.

Wir haben das Problem deshalb analysiert und folgende Hypothese zur Ursache gebildet.

1. Der PPI-EBICS-Kernel baut (neuerdings?) mehrere TLS-Verbindungen für eine Kommunikation auf. Das rührt möglicherweise daher, dass auf http 1.1 umgestellt wurde, wo 5 gleichzeitige Verbindungen zulässig sind (wenn auch im EBICS-Kontext nicht sinnvoll).

2. Es wurden zunächst von PPI mit einem Testprogramm und danach von uns mit einem anderen Testtool Lasttests für den TLS-Verbindungsaufbau durchgeführt (100 – 500 parallele Verbindungen). Dabei konnte die unten beschriebene Situation bei Kommunikation über das Internet (nicht jedoch über interne Netzwerkstrecken) produziert werden, die bzgl. der Symptome zu den Beobachtungen passt:

3. In unserem Gateway wurde bzgl. der IP-Socket-Verarbeitung eine ältere Windows-Voreinstellung benutzt, bei der die interne Liste der im Socket-Buffer zur Verarbeitung anstehenden, aber von der Applikationsschicht noch nicht entgegen genommen Verbindungen auf 5 begrenzt war. Wenn nun schneller Verbindungen aufgebaut werden, als von der internen Applikation innerhalb einer recht kurzen Zeitspanne (10 Sekunden) zur Verarbeitung angenommen werden, löst die Windows-Netzwerkschicht ein Reset-Kommando für die noch nicht endgültig angenommenen Verbindungen aus. Dies führt offenbar dazu, dass der PPI-Kernel oder SFIRM alle aufgebauten Verbindungen beendet und mit der Meldung „peer not authenticated“ abbricht.


4. Es gibt aber mehrere Beobachtungen von Seiten der BIVG (Hersteller SFIRM), die nicht so recht zu dieser Hypothese passen:

a) Dass ein Reset durch die oben beschriebene Situation ausgelöst wird, können wir bei einer Vielzahl von parallelen Verbindungsaufbauten erklären. Es wurden aber wohl solche Abbrüche auch beobachtet, wenn nur ein Clientsystem eine Verbindung aufgebaut hat und keine Last auf dem System war.

b) BIVG hat auch ähnliche Tests gegen andere unserer Banksysteme (mit gleicher Konfiguration) durchgeführt, bei denen dieses Problem nicht beobachtete wurden.

Ich möchte betonen: Dies ist unser Analyseergebnis und wurde bisher von PPI nicht kommentiert. Wir haben trotzdem ein entsprechendes Service-Pack für den Bankrechner und ein neues Release des Gateways mit den oben beschriebenen Änderungen erstellt. Ich schlage vor, dass Sie dieses in Abstimmung mit meinen Kollegen vom Service-Team installieren. Es wäre schön, wenn Sie uns auch im positiven Fall über das Ergebnis informieren könnten.

Mit freundlichen Grüßen / Best Regards,
Helmut Knester

-------------------------------------------------------------
Omikron Systemhaus
Von-Huenefeld-Strasse 55
D-50829 Koeln


=> Abwarten und auf Update der Hersteller Omikron/PPI warten
bongo
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Ober-Mörlen
Beiträge: 10
Dabei seit: 05 / 2005
Betreff:

Re: Problem EBICS mit Raifeisenlandesbank Oberösterreich

 · 
Gepostet: 15.12.2009 - 12:47 Uhr  ·  #7
Hallo Forum,

wir haben einen Bankrechner der Fa. Omikron im Einsatz. Die hier generellen Probleme mit S-Firm und dem Omikron Bankrechner kann ich wie hier beschrieben wird nicht bestätigen, auch was den von ottoager beschriebenen Einsatz des Systems betrifft (c;

Was mir im Praxisbetrieb auffällt ist, dass es gelegentlich bei S-Firm Installationen zu Problemen mit dem SSL-Zertifikat kommt (peer not...), welches jedoch in jedem Browser bei einem direkten Aufruf ohne Probleme akzeptiert wird. Beim letzten half ein Neustart des Kundensystems(!) und das Zertifikat wurde wieder von S-Firm akzeptiert...

Gruß
Gewählte Zitate für Mehrfachzitierung:   0