Hallo,
heute bin wieder auf den
Fehler bei der SSL-Zertifikatsprüfung , gestossen, über den ich hier bereits berichtet
hatte. Es scheint nun sicher, daß es tatsächlich an der Reihenfolge der gesendeten Zertifikate liegt.
Hier nochmal die Fakten:
Ich versuche eine -Hibiscus/HBCI4Java unabhängige- SSL-Verbindung zu hbci-pintan.gad.de:443 aufzubauen. Das funktioniert
unter SunJDK, schlägt jedoch -die meiste Zeit- unter OpenJDK mit der Meldung fehl:
sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException:
Path does not chain with any of the trust anchors
Zur Analyse des Datenverkehrs nutze ich die beiden Tools SSLPoke und InstallCert.
Bei eingeschaltetem SSL Debug (-Djavax.net.ssl.debug=ssl) kann man die Reihenfolge der
gesendeten Zertifikate erkennen. Im Fehlerfall, wird folgende Reihenfolge angezeigt:
chain [0] = [
Subject: CN=HBCI-PINTAN.GAD.DE, OU=PRDSYSINT, O=GAD EG, L=MUENSTER, ST=NRW, C=DE
chain [1] = [
Subject: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE
chain [2] = [
Subject: CN=VR IDENT SSL CA 2011, OU=VR IDENT, O=GAD EG, C=DE
chain [3] = [
Subject: CN=VR IDENT EXTERNAL ROOT CA 2011, OU=VR IDENT, O=GAD EG, C=DE
Unter SunJDK konnte die SSL-Verbindung auch bei dieser Reihenfolge der Zertifikate aufgebaut werden ! Der o.g. Fehler ist niemals aufgetreten.
Wenn es jedoch auch unter OpenJDK klappte (sporadisch), dann zeigte sich eine andere Reihenfolge der gesendeten Zertifikate:
chain [0] = [
Subject: CN=HBCI-PINTAN.GAD.DE, OU=PRDSYSINT, O=GAD EG, L=MUENSTER, ST=NRW, C=DE
chain [1] = [
Subject: CN=VR IDENT SSL CA 2011, OU=VR IDENT, O=GAD EG, C=DE
chain [2] = [
Subject: CN=VR IDENT EXTERNAL ROOT CA 2011, OU=VR IDENT, O=GAD EG, C=DE
chain [3 ] = [
Subject: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE
Ich vermute daher, daß der Zertifikats-Check unter OpenJDK strenger implementiert ist
und auch die Reihenfolge berücksichtigt ... scheinbar sogar in Übereinstimming mit der Spezifikation.
Zur Kontrolle habe ich dann Jameica/Hibiscus unter OpenJDK neu installiert und gestartet. Lege ich nun einen entsprechenden GAD-relevanten Bankzugang an erscheint der Dialog der den Nutzer auffordert, das Zertifikat von HBCI-PINTAN.GAD.DE zu bestätigen. Hier wurde die geworfene SSLException so interpretiert, dass dem Nutzer das -von OpenJDK abgelehnte- Zertifikat zur Bestätigung präsentiert wird. Unter SunJDK erscheint dieser Dialog nicht, da ja in der darunterliegenden Schicht, die SSL-Exception nicht auftrat.
Ich habe nun erstmal auf dem System (Ubuntu 12.04) das SunJDK installieren lassen, damit laufen die Geschäftsvorfälle wieder und ein -Hibiscus/HBCI4Java unabhängiges- SSL Connect zur GAD klappt wieder.
Kommen wir nun jedoch zum eigentlichen Anliegen, der Reihenfolge der Zertifikate wie sie der/die GAD Server ausliefert. Können die hier akkreditierten GAD Mitarbeiter dieser Sache einmal nachgehen
da mir die Ursache des o.g. SSL-Fehlers in der Konfiguration der GAD Systeme zu liegen scheint.
Mit freundlichen Grüßen
Dominik Hirt
heute bin wieder auf den
Fehler bei der SSL-Zertifikatsprüfung , gestossen, über den ich hier bereits berichtet
hatte. Es scheint nun sicher, daß es tatsächlich an der Reihenfolge der gesendeten Zertifikate liegt.
Hier nochmal die Fakten:
Ich versuche eine -Hibiscus/HBCI4Java unabhängige- SSL-Verbindung zu hbci-pintan.gad.de:443 aufzubauen. Das funktioniert
unter SunJDK, schlägt jedoch -die meiste Zeit- unter OpenJDK mit der Meldung fehl:
Code
sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException:
Path does not chain with any of the trust anchors
Zur Analyse des Datenverkehrs nutze ich die beiden Tools SSLPoke und InstallCert.
Bei eingeschaltetem SSL Debug (-Djavax.net.ssl.debug=ssl) kann man die Reihenfolge der
gesendeten Zertifikate erkennen. Im Fehlerfall, wird folgende Reihenfolge angezeigt:
Code
chain [0] = [
Subject: CN=HBCI-PINTAN.GAD.DE, OU=PRDSYSINT, O=GAD EG, L=MUENSTER, ST=NRW, C=DE
chain [1] = [
Subject: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE
chain [2] = [
Subject: CN=VR IDENT SSL CA 2011, OU=VR IDENT, O=GAD EG, C=DE
chain [3] = [
Subject: CN=VR IDENT EXTERNAL ROOT CA 2011, OU=VR IDENT, O=GAD EG, C=DE
Unter SunJDK konnte die SSL-Verbindung auch bei dieser Reihenfolge der Zertifikate aufgebaut werden ! Der o.g. Fehler ist niemals aufgetreten.
Wenn es jedoch auch unter OpenJDK klappte (sporadisch), dann zeigte sich eine andere Reihenfolge der gesendeten Zertifikate:
Code
chain [0] = [
Subject: CN=HBCI-PINTAN.GAD.DE, OU=PRDSYSINT, O=GAD EG, L=MUENSTER, ST=NRW, C=DE
chain [1] = [
Subject: CN=VR IDENT SSL CA 2011, OU=VR IDENT, O=GAD EG, C=DE
chain [2] = [
Subject: CN=VR IDENT EXTERNAL ROOT CA 2011, OU=VR IDENT, O=GAD EG, C=DE
chain [3 ] = [
Subject: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE
Ich vermute daher, daß der Zertifikats-Check unter OpenJDK strenger implementiert ist
und auch die Reihenfolge berücksichtigt ... scheinbar sogar in Übereinstimming mit der Spezifikation.
Zur Kontrolle habe ich dann Jameica/Hibiscus unter OpenJDK neu installiert und gestartet. Lege ich nun einen entsprechenden GAD-relevanten Bankzugang an erscheint der Dialog der den Nutzer auffordert, das Zertifikat von HBCI-PINTAN.GAD.DE zu bestätigen. Hier wurde die geworfene SSLException so interpretiert, dass dem Nutzer das -von OpenJDK abgelehnte- Zertifikat zur Bestätigung präsentiert wird. Unter SunJDK erscheint dieser Dialog nicht, da ja in der darunterliegenden Schicht, die SSL-Exception nicht auftrat.
Ich habe nun erstmal auf dem System (Ubuntu 12.04) das SunJDK installieren lassen, damit laufen die Geschäftsvorfälle wieder und ein -Hibiscus/HBCI4Java unabhängiges- SSL Connect zur GAD klappt wieder.
Kommen wir nun jedoch zum eigentlichen Anliegen, der Reihenfolge der Zertifikate wie sie der/die GAD Server ausliefert. Können die hier akkreditierten GAD Mitarbeiter dieser Sache einmal nachgehen
da mir die Ursache des o.g. SSL-Fehlers in der Konfiguration der GAD Systeme zu liegen scheint.
Mit freundlichen Grüßen
Dominik Hirt
