Nachdem ich (wie im vorherigen Artikel beschrieben) nun OpenJDK / Java 7 selber kompiliert habe, habe ich mich auf die Suche nach dem SSL Problem gemacht, dass ich mit Jameica/Hibiskus habe. (No offense, ich find es leichter OpenJDK zu übersetzen oder anzupassen als Jameica und Hibiskus zu bauen… praktischerweise bringt OpenJDK auch Netbeans Projektdateien mit, so dass es ein Klacks ist, das Projekt mit Netbeans zu verwenden.)

Nachdem ich folgenden Patch geschrieben habe habe:

diff -r 9b8c96f96a0f src/share/classes/sun/security/ssl/SSLContextImpl.java
--- a/src/share/classes/sun/security/ssl/SSLContextImpl.java	Mon Jun 27 13:21:34 2011 -0700
+++ b/src/share/classes/sun/security/ssl/SSLContextImpl.java	Mon Jul 25 19:30:11 2011 +0200
@@ -871,7 +871,7 @@
                 }
             } catch (CertPathValidatorException cpve) {
                 throw new CertificateException(
-                    "Certificates does not conform to algorithm constraints");
+                    "Certificates does not conform to algorithm constraints", cpve);
             }
         }
     }

ist jetzt auch zu sehen, was die Ursache fuer den SSL Fehler ist:

Caused by: java.security.cert.CertPathValidatorException: Algorithm constraints check failed: MD2withRSA
	at sun.security.provider.certpath.AlgorithmChecker.check(AlgorithmChecker.java:200)
	at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:870)
	... 21 more org.kapott.hbci.manager.HBCIUtils.log(HBCIUtils.java:1052)

OpenJDK kommt übrigens ohne Root Zertifikate daher, so dass man sich nicht über einen solchen Dialog wundern sollte:

Nachdem man die Exception genauer ansieht, ist man auch etwas schlauer geworden: Irgendein Zertifikat ist mit einem nicht mehr als sicher geltenden Algorithmus signiert. Das der Apobank selbst ist es offensichtlich jedoch nicht, also muss die gesamte Zertifikatskette untersucht werden.
Hier habe ich etwas Shell-Magie und das OpenSSL Kommandozeilentool verwendet:

openssl s_client -showcerts -connect hbcibanking.apobank.de:443 < /dev/null | awk -v c=-1 '/-----BEGIN CERTIFICATE-----/{inc=1;c++} inc {print > ("cert-" c ".pem")}/---END CERTIFICATE-----/{inc=0}'; for i in cert-?.pem; do openssl x509 -noout -serial -subject -issuer -in "$i"; done

Danach finden sich alle Zertifikate in cert-1.pem, cert-2.pem usw., die Ausgabe der Seriennummern, Subject und Issuer sah bei mir so aus:

serial=4FCD4C50631D3BB4C747A319E816AD5D
subject= /C=DE/ST=NRW/L=Duesseldorf/O=Deutsche Apotheker- und Aerztebank/OU=Terms of use at www.verisign.com/rpa (c)05/CN=hbcibanking.apobank.de
issuer= /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
serial=254B8A853842CCE358F8C5DDAE226EA4
subject= /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
issuer= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
serial=70BAE41D10D92934B638CA7B03CCBABF
subject= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
issuer= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

Nun müssen alle Zertifikate untersucht werden:

openssl x509 -text -in cert-0.pem

Und entsprechend für die anderen Zertifikate in der Kette. Ich wurde dann bei dem dritten Zertifikat fündig:

tkruse@charix:~$ openssl x509 -text -in cert-2.pem
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf
Signature Algorithm: md2WithRSAEncryption
Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
Validity
Not Before: Jan 29 00:00:00 1996 GMT
Not After : Aug 1 23:59:59 2028 GMT
Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority

Ein „betagtes“ altes VeriSign Zertifikat das mit MD2 und RSA signiert wurde. Auch wenn der MD2 Signaturalgorithmus noch nicht gebrochen ist, gibt es einige Angriffe, die dazu geführt haben, dass MD2 seit 2009 nicht mehr in OpenSSL verwendet wird.
Was heißt das nun für das konkrete SSL Problem? Die ApoBank wird sich eh um Januar 2012 herum spätestens ein neues SSL Zertifikat besorgen. Dann sollte der Spuk zu ende sein. Besser wäre es allerdings wenn die betroffenen Anbieter ihre SSL Zertifikate jetzt erneuern – es geht schließlich um Online Banking!
Und wieso fällt das erst seit Java 7 auf? Seit Java 7 ist offenbar die Möglichkeit neu hinzugekommen die Algorithmen zu prüfen oder wurde geändert. Eigentlich sollte seit Java 6u17 bereits MD2 nicht mehr unterstützt werden, zumindest gibt es einen entsprechenden Eintrag in den Release notes: http://www.oracle.com/technetwork/java/javase/6u17-141447.html.