SSL-Verbindung zu mysql Dokumentation #50
Comments
|
@jverein Ich schließe das mal wegen Inaktivität. Funktioniert bei mir erstmal. |
|
Ich habe mir zwei volle Tage an diesem Problem den Kopf eingerannt. JVerein mit remote SQL funktioniert tadellos, SSL dazu und ich bekomme nur ich habe
... Jameica 2.8.6 |
|
Hast du versucht die erstellten Zertifikate in den Trust Store der Java Installation zu importieren? Das war bei mir die einzige Möglichkeit die Verbindung herzustellen. |
|
habe ich jetzt auch versucht, und zwar sowohl das "Jameica Certificate", "Issued for (mein Rechnername)"; als auch das "Jameica CA"-Zertifikat , mit Befehlen
|
|
Du hast aber schon den Trust Store der von jverein Client genutzten JRE genommen oder? Nur um deinen Aufbau zu verstehen: Führst du JVerein und mariadb auf dem gleichen Rechner aus? |
|
Jameica läuft lokal, auf einem Ubuntu-System, die MariaDB auf einem virtuellen Debian-Server den ich über das Internet erreiche, deswegen mein Bedarf an Verschlüsselung. Auf dem Rechner mit jverein scheint es nur eine JRE zu geben, nämlich OpenJDK 8 in der Version Jedenfalls gibt es nur ein /etc/ssl/certs/java/cacerts, wohin aus der JRE verlinkt wird. Dort habe ich die Zertifikate hinzugefügt. Ich habe jetzt mal versucht vom Client mit openssl zum Server zu verbinden und bekomme auf
ein
|
|
Scheinbar wird die Zertifikats-Kette nicht erfolgreich validiert. Kannst du auf der Server-Seite mal schauen, ob die Zertifikate gültig sind? Bei mir läuft mysql in einem Docker Container, der nach folgender Anleitung erzeugt wurde: https://techsparx.com/software-development/docker/damp/mysql-ssl-connection.html Vielleicht hilft das dargestellte Skript, um nochmal zu schauen, ob die Mysql-Konfiguration korrekt ist. |
|
Hab das mit openssl auch mal getestet. Es funktioniert bei mir, wenn ich das ca-Zertifikat explizit angebe: Vorher hab ich mit CApath getestet und einen Ordner genutzt, in dem sowohl das CA-Zertifikat, als auch Server und Client-Zertifikate lagen. Dabei ist der gleiche Fehler aufgetreten: Muss natürlich bei dir nicht auch so sein, aber ich dachte das ist vielleicht trotzdem eine wichtige Information für die Validierung der Verbindung. |
den s_client parameter habe ich geändert wie von dir vorgeschlagen, danach scheint s_client zu funktionieren (zumindest bis "read R_BLOCK", danach Fehler 104) Auf JVerein scheint das leider keine Auswirkungen zu haben. edit: ich kuck mir nochmal das Dokument betr. den Docker an, ob ich dort was entnehmen kann |
|
Trotzdem seltsam, dass openssl noch Fehlermeldungen anzeigt. Bei mir sieht das so aus: Wenn ich mich mit der MySQL Workbench verbinde, funktioniert es auch mit SSL (vielleicht noch ein guter Check, um JVerein und Java Probleme auszuschließen):
|
|
Hallo Stephan
Am 08.08.20 um 10:28 schrieb Stephan E.:
Jameica läuft lokal, auf einem Ubuntu-System, die MariaDB auf einem virtuellen Debian-Server den ich über das Internet erreiche, deswegen mein Bedarf an Verschlüsselung.
Auf dem Rechner mit jverein scheint es nur eine JRE zu geben, nämlich OpenJDK 8 in der Version 7u211-2.6.17-0ubuntu0.1.
Bist Du Dir sicher, dass sich dahinter ein Java 8 versteckt? Ich sehe da
ein Java7 u211.
Jedemfalls gibt es nur ein /etc/ssl/certs/java/cacerts, wohin aus der JRE verlinkt wird. Dort habe ich die Zertifikate hinzugefügt.
Ich habe jetzt mal versucht vom Client mit openssl zum Server zu verbinden und bekomme auf
`~/Downloads/openssl-1.1.1g$ LD_LIBRARY_PATH=. apps/openssl s_client -CApath ~/servercerts -starttls mysql -connect unseredomain.de:3306`
ein
`Verify return code: 21 (unable to verify the first certificate)`
Viele Grüße
…--
Mechtilde Stehmann
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F
|
|
Ich habe sicherheitshalber nochmal die Zertifikate neu erstellt mit Hilfe des Skriptes das Du verlinkt hast. ca.pem und client-cert.pem habe ich sowohl in den JRE-Truststore als auch per Jameica-GUI importiert. Alle Zertifikate die ich vorher hinzugefügt hatte, habe ich gelöscht. Ich habe aus Jameica das "Jameica Certificate (MeinRechnername)" und die "Jameica CA" exportiert, jeweils mit 'openssl x509' nach PEM konvertiert, auf dem Server in einen Ordner gelegt und MySQL/Mariadb den Ordner als "ssl_capath" bekannt gemacht. Weiter habe ich darauf geachtet dass alle Ordner und Verzeichnisse dem Benutzer "mysql" gehören und dieser R/W Zugriff hat. Ich kann mich jetzt mit mysql vom client zum Server verbinden: ein "status;" in der mySQL Konsole zeigt, dass die Verbindung verschlüsselt ist. JVerein besteht leider auf seiner jdbc4.CommunicationsException |
|
Mechthilde, da hatte ich mich verlesen, die 7er-Version ist nicht mehr installiert ("rc" in dkpg -l) |
|
Ok, damit sollte ja die mysql-Konfiguration als Fehlerquelle ausgeschlossen sein. Das neu generierte ca-Zertifikat hast du in Ubuntu wieder dem trust store hinzugefügt? Das war ja bei mir das Problem: Der Zertifikats-Store von Jameica war bei mir nicht ausschlaggebend. Deine openjdk-Installation verweist per Symlink auf die cacert Datei Das sollte bei dir bei normaler Installation über den Package Manager natürlich auch so aussehen. |
|
genau so ist es: `lrwxrwxrwx 1 root root 27 Aug 3 04:56 /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts -> /etc/ssl/certs/java/cacerts keytool -list -keystore /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts |
|
Und es gibt keine anderen Java-Installationen, die auf dem System aktiv sind? |
|
nope |
|
Wie ist denn der Name deiner Konfigurationsdatei, bei mir de.jost_net.JVerein.rmi.JVereinDBService.properties |
|
Ich habe mal im jverein-forum noch einen Thread aufgemacht, vielleicht hat ja dort noch jemand 'ne Idee. |
|
Ich hab das gerade mal neu auf meinem Mac eingerichtet (wollte ich eh mal machen). Ich habe gerade keinen Zugriff auf den Vereins-Rechner, wo das eigentlich läuft. Im Programmverzeichnis liegt jetzt folgende Datei:
Die Zertifikate hab ich dann erstmal nur in Jameica hinzugefügt (ca.pem und client-cert.pem). Bei mir ist das entscheidende wieder: Im Log steht auch welche Java-Version genutzt wird (ich hatte bei mir eigentlich mit meiner Amazon Corretto 8 Installation gerechnet, aber scheinbar wird unter Mac OSX eine AdoptOpenJDK mit Jameica ausgeliefert (schadet nicht auch mal bei dir nachzusehen, ob da etwas unerwartetes drinsteht). Ich hab eine ganze Weile gebraucht das herauszufinden, weil ich überall im System nach der JRE gesucht hab 🤣: Also dort das Zertifikat importiert (in meinem Fall in Und schon geht's: Bei mir war es also genau das gleiche Verhalten, wie das letzte Mal (da hab ich das unter Windows eingerichtet). |
|
im jameica.log finde ich das erwartete eine SSLHandshakeException habe ich nicht, wohl aber ein
Ich have versucht in MariaDB zusätzlich das veraltete TLS1.0 zu erlauben, aber auch das hat nichts gebracht.
edit: auch ein Einschränken der Versionen mit |
|
Ich habe neue Fehlermeldungen kennengelernt :) wenn ich die tls_version in MariaDB explizit auf nur TLSv1.0 oder nur TLSv1.1 runterzwinge, kriege ich keinen Fehler "protocol_version" mehr, sondern einen Fehler "internal_error". wenn ich zusätzlich die "ssl_cipher" auf den gleichen Wert setze, gibt es für 1.1 ein
ansonsten auch einen "internal error" |
|
Ok, aber dann wissen wir jetzt zumindest schonmal recht genau, was das Problem ist: Irgendwas mit dem TLS-Versionen zwischen Client und Server passt wohl gerade nicht. In meinem Fall unterstützt die integrierte OpenJDK-11 TLSv1.3. Bei Java 8 ist das noch TLSv.1.1 und TLSv1.2 lt. Oracle. Meine Datenbank wird mit folgenden Parametern gestartet: |
|
Ok, für diese Einstellungen kriege ich im jameica-log das bekannte "protocol_version", auf dem Server in /var/log/mysql.error.log (so ich es denn aktiviere und mich nicht auf das maulfaule journalctl verlasse) gibt es ein
|
|
Ok, das könnte ein Fortschritt sein: wenn ich sowohl tls_version als auch ssl_cipher explizit auf TLSv1.1 runterzwinge, ändert sich die Fehlermeldung zu 2020-08-08 17:37:56 87 [Warning] Access denied for user '*'@'.dynamic.kabel-deutschland.de' (using password: YES) |
|
Jetzt sieht es eher nach einem "normalen" Authentifizier-Fehler aus. Ging es mit der Konfiguration in |
|
vorher konnte ich mich per mysql-client auf den Server einloggen, das geht plötzlich nicht mehr, egal ob mit oder ohne TLS-parametern...
edit: das ist wohl "unable to get local issuer certificate". WUT? ich habe doch nichts neues erstellt seit vor 2h |
|
Dein zweites Edit versteh ich nicht. Meine mysql-Instanz ist ohne irgendwelche Besonderheiten konfiguriert. Außer den Zertifikaten gibt es wirklich nur die Start-Parameter Der Docker-Container hat natürlich eine Standard-Konfiguration, die von deiner mariadb abweichen kann. Die Defaults für die tls-Versionen sind bei mir niedriger, als ich vermutet hatte: |
|
Meine Settings sind fast identisch mit deinen, allerdings habe ich gemäß der Anleitung auf willuhn.de noch einen ssl_capath, um dort das Jameica-generierte Maschinenzertifikat und auch das Jameica-CA-Zertifikat abzulegen. "etckeeper" ist nur ein Tool um mein Konfigurationsverzeichnis sauber zu halten. Die Dateien in /etc/ssl müssen bei mir dem user "mysql" zugänglich sein, unter dem der Datenbank-Server läuft, sonst ende ich bei have_ssl DISABLED. Aber irgendwas scheine ich verbockt zu haben seit vorhin, ich bekomme selbst lokal jetzt nur noch |
|
Benutz für die Zertifikate lieber absolute Pfade. Das sieht so aus als würde er die dateien jetzt irgendwie nicht auflösen können oder? |
ich muss aufhören für heute sonst platzt mir noch 'ne Ader Danke für deine überaus geduldige Hilfe |
|
Echt ärgerlich :) Ich hab damit auch echt viel Zeit verbracht am Anfang. Vielleicht die Tage nochmal ganz in Ruhe mit Standard-Konfiguration von Anfang an. |
|
Ich hab das eben nochmal unter Ubuntu 20.04 Desktop ausprobiert. Frische Installation, lediglich openjdk-8-jdk und jameica wurde installiert. Die Installations-Schritte von der Client-Seite unterscheiden sich kaum von denen auf dem Mac. Die ca.pem muss in /etc/ssl/certs/java/cacerts importiert werden. Im Jameica Keystore hab ich ca.pem, server-cert.pem und client-cert.pem importiert. Die DB-Konfiguration wurde mit den schon besprochenen Einstellungen in Damit ist aus meiner Sicht nur die Konfiguration für mariadb ein Fragezeichen für die folgenden Tage. Die Client-Seite scheint relativ stabil konfigurierbar zu sein und verhält sich unter Windows, Mac OS und Ubuntu gleich. |
|
Ich habe nochmal alles haarklein nach Anleitung eingerichtet, und dann mit Wireshark Protokollfehler gesammelt, für verschieden Kryptoeinstellungen in MariaDB 10.5 mit OpenSSL Zusammengefasst:
Ich bin ja kein Krypto-Experte, aber ist es vielleicht möglich sein, dass Jameica unbedingt TLSv1.1 machen will, aber nur Elliptic-Curve-Ciphers drauf hat die eigentlich zur v1.2 oder später gehören (Liste s.u.)? (edit: nee da ist auch RSA dabei.) Ich glaube es müssten sich mal die Jverein-Entwickler mit MariaDB auseinandersetzen (ist immerhin Standard in Debian), bzw. sich mit den MariaDB-Entwicklern kurzschließen, denn SO kompliziert sollte es definitiv nicht sein eine SSL-Verbindung zustande zu bringen. defaults Jameica: tls_version=TLSv1.1 MariaDB: tls_version = TLSv1.1 MariaDB tls_version = TLSv1.1 Jameica: tls_version = TLSv1.0, TLSv1.1, TLSv1.2 MariaDB: protocol_version **ssl_cipher=TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:TLS_RSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:TLS_RSA_WITH_AES_128_CBC_SHA:TLS_EMPTY_RENEGOTIATION_INFO_SCSV Jameica:** tls_version:TLSv1.2 Jameica: tls_version:TLSv1.1 MariaDB: Internal Error (80) |
|
aufpassen muss man auch, ob eventuell in .jameica/cfg noch eine weitere de.jost_net.JVerein.rmi.JVereinDBService.properties liegt, neben der in "cfg" |
|
Ich habe die Verbindung jetzt durch OpenVPN getunnelt. Beim Aufsetzen der Zertifikate und Schlüssel hilft 'easy-rsa'. |
|
Ok also hat dann anschließend mit mariadb echt garnicht geklappt? @jverein liest jemand hier mit? Kann es sein, dass das jverein Team nur im Forum aktiv ist? Hab hier letztes mal leider auch keine Rückmeldung bekommen. |
|
Hallo
Ich habe Hibiskus und JVerein jeweils mit MariaDB unter Debian Buster
lauffäig.
Ich kann aus der bisherigen Beschreibung noch nicht nachvollziehen, wo
das Problem ist.
Viele Grüße
…--
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F
Am 11.08.20 um 11:54 schrieb Oliver:
Ok also hat dann anschließend mit mariadb echt garnicht geklappt?
@jverein liest jemand hier mit?
Kann es sein, dass das jverein Team nur im Forum aktiv ist? Hab hier letztes mal leider auch keine Rückmeldung bekommen.
|
|
Für mich war das jetzt deutlich einfacher mit OpenSSL zu lösen, aber wenn ich noch irgendwelche Infos liefern kann, gerne |
Bei der Nutzung einer SSL-Verschlüsselung bei der MySQL-Datenbank ist folgender Hinweis in der Dokumentation aktuell nicht zutreffend (oder ich mache etwas falsch):
Es gab weder eine Aufforderung zum Import des Zertifikates noch hat es überhaupt funktioniert, den Jameica-Zertifikats-Store zu nutzen. Am Ende war die einzige Möglichkeit das CA-Zertifikat in meinen cacerts-Keystore der Java-Installation zu importieren.
Folgende Einstellungen habe ich genutzt:
Hat jemand da ähnliche Erfahrungen gemacht?
Es wäre schon gut, wenn der Zertifikats-Store von Jameica genutzt werden könnte, ansonsten gehe ich davon aus, dass ich den CA-Import nach jedem Java-Update wiederholen muss.
The text was updated successfully, but these errors were encountered: