Kommunikation MOA-ID - Stammzahlenregisterbehörde

    Unsere MOA-ID hat ein Problem bei der Kommunikation mit dem Vollmachtenservice.


    Im Block OnlineMandates/ConnectionParameter/ClientKeyStore der MOA-ID-Konfiguration wird ja ganz normal das Zertifikat der MOA-ID (jenes von A-Trust mit Dienstleistereigenschaft) eingetragen.


    Dies bewirkt bei uns nun jedoch, dass nach der Eingabe des TANs (bei Verwendung der Handysignatur) und vor der Weiterleitung an die Stammzahlenregisterbehörde folgender Fehler auftritt:


    javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
    at.gv.egovernment.moa.id.util.client.mis.simple.MISSimpleClientException: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure


    Wo kann hier der Fehler liegen?

    Das Online-Vollmachtenservice lässt aus Sicherheitsgründen keine unsichere SSL-renegotiation zu. D.h. die Anbindung mit MOA-ID funktioniert nur wenn eine JDK mit mindestens einer der folgenden Versionen verwendet wird:


    >= JDK 6 Update 22
    >= JDK 5 Update 26
    >= JDK 1.4.2 Update 28


    Falls die Versionsnummer der verwendeten JDK kleiner ist, funktioniert es nicht, da diese keine sichere SSL renegotiation unterstützen.

    Das Testsystem sollte wieder funktionieren.


    Mit Fiddler muss in den Optionen eingestellt werden, dass HTTPs Traffic entschlüsselt wird.


    Tools -> Fiddler Options -> HTTPS -> Decrypt HTTPS Traffic


    Dann sollte im Log von der BKU ein 302 Moved Temporarily zurückkommen, wo im Tab "Headers" im Abschnitt "Transport" der Location Header steht, z.B. Location: https://vollmachten.stammzahle…/mis.do?SessionId=738e65a...

    Kann es sein, dass irgendwo ein Proxy verwendet wird, der die URLs umschreibt? z.B. im Application Server (Tomcat, ...) selbst oder im Browser/Rechner. Das ist das einzige was mir ad hoc noch einfällt, warum die absolute URL, die MOA-ID sendet, umgeschrieben wird.

    Es gibt in der Tat ein Redirect, was für diesen Fehler verantwortlich ist. Ich verstehe jedoch nicht, wieso.


    Wir haben am IIS (7.5) eine Regel, welche alle URLs, welche nach dem / ein "moa-id-auth" haben, auf https://xxx:4040/moa-id-auth... weiterleitet. Auf dem Server läuft nämlich eine Webanwendung unter Port 443 während MOA-ID nur unter 4040 konfiguriert ist. Damit von außen der Zugriff auch ohne den "exotischen" Port möglich ist, gibt es diese Regel. (Dazu mussten wir auch das Template adaptieren, damit dieses die DataURL im Form ohne den Port an MOA-ID weitergibt.)


    Nun ist für mich jedoch nicht ersichtlich, wieso die URL an das Stammzahlenregister, welche ja offensichtlich mit dem String "moa-id-auth" nichts zu tun hat, von der Regel betroffen ist. Können Sie mir vielleicht kurz den Nachrichtenaustausch umreißen oder haben Sie nach diesen Ausführungen vielleicht direkt eine Idee, warum es scheitert?

    Leider kann ich nicht beurteilen, wie die IIS Filterregel reagiert. Hier sollten sicherlich die Logs Aufschluss geben. Die URL hat aber sicherlich nichts mit dem besagten Pattern "moa-id-auth" zu tun, sondern startet mit "/mis/mis.do...".

    Die Logs geben diesbezüglich leider keinen Hinweis, da die Aufrufe /VerifyIdentityLink, /VerifyAuthBlock und /VerifyCertificate korrekt weitergeleitet werden, der nächste Schritt jedoch schon die Anforderung /mis-test/mis.do ist.


    Vielleicht bringt mich die Information weiter, wer diesen Redirect überhaupt veranlasst - die BKU oder MOA selbst?