Wenn man von einem Java-Client aus via SSL auf einen Server zugreifen möchte, der kein „offiziell ge-trustetes“ Zertifikat besitzt, dann kann man

1. Die Prüfung des Zertifikats abschalten. Das ist aber keine gute Idee, weil dann die Sicherheit (fast) völlig dahin ist. Selbst, wenn es „nur“ um eine sichere Test-Umgebung geht, dann könnte es passieren, dass man hier SSL-Probleme nicht bemerkt, die dann erst in der Produktivumgebung auftreten. also keine gute Idee.
2. Oder: Man macht Java die Zertifizierungsstelle bekannt, mit der das Zertifiakt des Servers unterschrieben ist. Da das ohne Eingriff in den Java-Code geht, ist das wirklich eine „saubere Sache“.

Das Herunterladen und Bekanntmachen der Zertifizierungsinstanz geht so:

• Zertifikate direkt vom Server herunterladen (mit ctrl-C abbrechen):

openssl s_client -connect nerdblog.steinkopf.net:443 -showcerts > certs.crt 2>&1

• In certs.txt befinden sich nun die Zertifikate des Servers – noch im „falschen“ Format.
• In der Regel ist das oberste das Zertifikat des Servers. Darunter kommen weitere Zertifikate der Zertifizierungsinstanzen (Issuer). Mit einem Text-Editor sucht man sich dasjenige heraus, das man braucht. (Bei mir war es das zweite von zweien, weil das eigentliche Zertifikat von einer nicht öffentlichen Instanz unterschrieben war.)
• Jetzt benutzen wir das keytool aus dem Java JDK/JRE, um einen Java „keystore“ zu erstellen (dabei wird man nach einem Passwort gefragt, mit dem der keystore zu schützen ist):

keytool -import -alias nerdblog-cert -file certs.crt -keystore /path/to/certs.keystore

• Anschauen kann man sich den keystore auch nochmal zur Sicherheit (-v macht das mehr „verbose“):

keytool -list -keystore certs.keystore

• Jetzt kann man den keystore Java „vorsetzen“, in dem man diese System-Properties setzt:

javax.net.ssl.trustStore=/path/to/certs.keystore
javax.net.ssl.trustStorePassword=mykeystoresecret

• Ggf. ein Neustart der Anwendung aktiviert das Ganze.

Ergebnis: Sichere SSL-Kommunikation ohne den Java-Code anzufassen 🙂