JDBC-Verbindung über SSL auf Mysql-Server (Tomcat)

Hier wurde erklärt, wie man den MySQL-Server konfiguriert, so dass in MySQL-Client SSL Verbindungen zum Server aufbauen kann.

Nun möchte ich die SSL-Verbindung in einer Java-Applikation, welche in einem Tomcat läuft, verwenden. Dazu wird eine JDBC-Connection über SSL zum MySQL Server aufgebaut.

Die Server- und Client-Zertifikate wurden hier bereits erstellt.

Dieser Beitrag basiert auf Link

KeyStore

Tomcat-Applikationen müssen die Zertifikate in einem Keystore gespeichert halten.

Client Packet

Ein Paket mit client Zertifikat und client key erstellen

MyKS.jks

Einen neuen KeyStore “MyKS.jks” erstellen, der das erstellte client paket und die CA Zertifikate enthält. Als Passwort wähle ich immer das gleiche.

Nicht vergessen die Berechtigung adäquat anzupassen

Tomcat konfigurieren

JAVA_OPTS

Keystore in Tomcat-Verzeichnis kopieren. SSL konfigurieren und den keystore anmelden. Hierzu ist auch die Angabe des oben genutzen Passwortes notwendig, so dass der Keystore gelesen werden kann. Diese Properties können z.B. in catalina.sh exportiert werden (export).

In Ubuntu 14.04 findet man das startup-File von Tomcat unter

oder als Java-Parameter:

oder man könnte dies auch in der Tomcat-Applikation als System-Properties definieren:

JDBC URL

Dann muss noch die Connection so angepasst werden, dass SSL verwendet wird (useSSL). Dies kann über einen connection-parameter gemacht werden.

Das kann entweder über die URL mit useSSL=true oder aber über die java.util.Properties (propertyuseSSL to true) Instanz, welche dem DriverManager.getConnection() mitgegeben wird, gemacht werden.

CHECK

Überprüfen ob die Verbindung auch wirklich verschlüsselt daher kommt:

Vorher

Nachher

 

Java Cryptography Extension (JCE) Unlimited Strength

Um JAVA AES mit 256-bit Schlüssel verwenden zu können, muss eine Extension installiert werden. Für Java 8 findet man die Extension hier.

Installation

  1. Alle Java Prozesse stoppen, die das JDK verwenden
  2. Unzip von jce_policy-8.zip File. Es werden zwei Jar-Files unzippt.
    1. local_policy.jar
    2. US_export_policy.jar
  3. Diese beiden Files ersetzten die Files im JDK-Verzeichnis
  4. Alle Java Prozesse wieder starten

Umgebungsvariablen und Alias

Userspezifisch

Aliase und Umgebungsvariablen können spezifisch pro User festgelegt werden. Hierzu verwendet man das ‘.bashrc’ File im eigenen Home-Verzeichnis:

Alias/Umgebungsvariable

Neue Zeile

einfügen

ll wird nun den Befehl ls -l im Terminal ausführen.

Auf diese Art und Weise können Umgebungsvariablen (z.B. JAVA_HOME) gesetzt werden:

Global

Um globale Aliase und Umgebungsvariablen zu setzen, hat man mehrere Möglichkeiten:

  • /etc/profile
  • /etc/bash.bashrc
  • /etc/environment
  • Wrapper-Skript

 

/etc/profile

Dieses File ist dann der richtige Ort, wenn man von der Console bootet und das GUI (Gnome/KDE) über startx aufruft. Das /etc/profile wird also auch dann gelanden, wenn kein Window-Manager gelanden wird.

/etc/bash.bashrc

Dieses File ist dann der richtige Ort, wenn man direkt per “Login-Manager” grafisch einloggt. Man darf aber nicht vergessen, dass dieses File ignoriert wird, sobald man ein weiteres Terminal (per Alt-F?) öffnet.

/etc/environment

Hier kann man statische Variablen definieren, die für das ganze System von Interesse sind. Als Beispiel werden hier alle Umgebungsvariablen für die Programmiersprache Java definiert, die sowohl für das Ausführen als auch die Entwicklung von Java-Programmen nötig sind. Die Variable PATH kann man auch in

definieren, sie wird aber in der Regel von der Shell wieder überschrieben. Somit ist es besser, PATH in der Datei

zu definieren und gegebenenfalls über die benutzerspezifischen Dateien

(Login-Shell) und

(interaktive Shell) anpassen.

Wrapper-Skript

Es kursiert in der Debian-Welt die Idee, dass Umgebungsvariablen für das Starten eines Programmes nicht nötig sein sollten. Aus diesem Grunde wird oft ein so genanntes Wrapper-Script erstellt, welches die nötigen Variablen setzt und danach das eigentlich gewünschte Programm aufruft. Das kann z.B. folgendermassen aussehen:

Das speichert man unter dem Namen nachdem das effektive ‘PROGRAMM’ zu ‘PROGRAMM.real’ umbenannt worden ist. Danach noch das execute-Falg setzen: