Zitat geschrieben von chabar
Etwas problematisch hierbei ist leider die Tatsache, dass sich das automatisch erstellte Jameica-Zertifikat nicht innerhalb von Jameica löschen lässt...
Und das ist auch gut so!
Der Schreibzugriff auf das Systemzertifikat ist ganz bewusst in Jameica deaktiviert. Denn das bildet die Grundlage fuer andere in Jameica und Hibiscus darauf aufbauende Crypto. Siehe auch
http://www.willuhn.de/wiki/dok…geschuetzt
Wenn du das Zertifikat loeschst, verlierst du den Zugriff auf alle verschluesselt in Jameica gespeicherten Daten, da sie dann nicht mehr entschluesselt werden koennen. Das betrifft u.a. die Passport-Dateien in Hibiscus, das Wallet mit gespeicherten Credentials, eine ggf. vorhandene lokale H2-Datenbank mit Konten und Umsaetzen. Heisst: Wenn du mit dem Keytool die jameica.keystore editierst, spielst du mit dem Feuer.
Aber zum eigentlichen Problem: Das Problem ist nicht, dass Jameica seinem eigenen Zertifikat nicht vertraut (das ist falsch) sondern dass der *MySQL-Treiber* dem Jameica-Zertifikat nicht vertraut. Bei der fehlgeschlagenen Zertifikatsvalidierung war Jameica ueberhaupt nicht involviert. Erkennst du auch daran, dass in dem Stacktrace an den relevanten Stellen gar keine Klassen-Namen von Jameica (die mit "de.willuhn.jameica" beginnen) auftauchen. Und das liegt daran, weil der MySQL-Treiber leider nicht den existierenden SSL-Context der JVM-Instanz verwendet (welcher von Jameica beim Start so konfiguriert wird, dass die Zertifikatspruefung ueber Jameica laeuft) sondern einen eigenen SSL-Context samt eigener SSLSocketFactory erzeugt. Genau diese Problematik hatte ich zu Beginn dieses Threads auch schonmal erlaeutert. Die Zertifikats-Pruefung von Jameica laeuft so ab, dass erst geprueft wird, ob Java selbst das Zertifikat verifizieren kann. Kann es das nicht, wird nicht sofort aufgegeben. Stattdessen springt Jameica ein, faengt den Fehler und leitet die Vertrauensfrage an den User weiter. Das ist genau der Dialog "Moechten Sie diesem Zertifikat vertrauen? ...", der dann von Jameica angezeigt wird. Und das Standard-Verhalten von Java selbst ist so, dass ein Zertifikat als nicht vertrauenswuerdig eingestuft wird, wenn es von keiner vertrauenswuerdigen CA signiert ist.
Da der MySQL-Treiber nun aber eben nicht den existierenden SSL-Context verwendet, sondern einen eigenen erzeugt, kann Jameica mit dem Fallback nicht einspringen. Stattdessen wird der Fehler sofort geworfen und der gesamte Vorgang abgebrochen.
Heisst: Das Problem hat eigentlich gar nichts mit Jameica zu tun. Denn das ist in dem Fall ueberhaupt nicht in den Verifizierungsprozess involviert. Und daher ist es auch eigentlich ueberhaupt nicht sinnvoll, dennoch die Jameica-Systemzertifikate fuer MySQL zu verwenden. Das bringt aus genau diesem Grund ueberhaupt keinen Mehrwert.
Stattdessen waere es viel einfacher, komplett eigene Client-, Server- und CA-Zertifikate fuer MySQL zu erstellen (egal ob direkt mit OpenSSL, dem "jameica.ca" Plugin oder irgend einem anderen Zertifikats-Tool), diese im MySQL-Server einzurichten und sie in jameica.keystore zu importieren (sowohl Client- als auch CA-Zertifikat). Ob man sie nun in jameica.keystore importiert oder hierfuer einen eigenen zusaetzlichen Keystore einrichtet, spielt keine Rolle. Wichtig ist nur, dass er beim Start von Jameica mit den bereits hier im Thread genannten "-D"-Parametern dem MySQL-Treiber bekannt gemacht werden. Das ist eine Sache zwischen MySQL-Server und MySQL-Treiber. Jameica fungiert hier lediglich als funktionsloser Container, in dem ganze ablaeuft.
PS: Ich weiss, dass das in der Anleitung im Wiki unter
http://www.willuhn.de/wiki/doku.php?id=support:mysql-ssl mit Jameica-Zertifikaten beschrieben ist. Die Anleitung stammt jedoch nicht von mir selbst sondern von einem User, der das bei sich so eingerichtet hatte. Ich selbst benutze das nicht und will MySQL over SSL eigentlich auch gar nicht unterstuetzen. Schlicht aus dem Grund, weil sich der MySQL-Treiber aufgrund seines eigenen SSLContext hier so quer stellt und Jameica da ohnehin nichts richten kann.
ops: