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.

    Normalerweise sollte MOA-ID die Weiterleitung auf das Online-Vollmachtenservice korrekt über einen HTTP 302 Redirect durchführen.


    Was steht bei der HTTP Redirect response im "Location" Header für ein Wert?

    Ich bin mir nicht ganz sicher wo/wie ich das feststellen kann - ich bekomme weder über ein HTTP-Capturing Tool (Fiddler) noch über die Logs der MOA gewünschte Information.

    Während das Produktivsystem nicht umleitet erhalte ich am Testsystem (mis-test)


    Fehler bei der Anmeldung
    Bei der Anmeldung ist ein Fehler aufgetreten.


    Invalid HTTP response code 500

    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?

    Grundsätzlich beide. Der Redirect wird von MOA-ID veranlasst und an die BKU weitergeleitet, welche diesen dann an den Browser übermittelt.