Zertifikate & SSL

Status: verifiziert — sowohl der automatisch erzeugte Dev-Keystore als auch die manuelle Erstellung per securityUtility wurden real ausgeführt (Log-/Kommandozeilen-Belege unten).

Zwei Wege zu einem Liberty-Keystore

1. Automatisch (Default, was concordiaPortalServer aktuell nutzt)

Ohne explizites <keyStore>-Element erzeugt Liberty beim allerersten Start mit ssl-1.0 + konfiguriertem httpsPort automatisch ein selbstsigniertes Zertifikat mit zufälligem Passwort:

[17.08.26, 22:04:18:911 MESZ] CWPKI0803A: Das SSL-Zertifikat wurde in 5,700 Sekunden erstellt.
SSL-Schlüsseldatei: .../concordiaPortalServer/resources/security/key.p12

Praktisch für schnelles lokales Ausprobieren (genau das, was Ausbaustufe 1–3 hier nutzen), aber nicht produktionstauglich: das Passwort ist nicht bekannt/dokumentiert, und der Hostname im Zertifikat basiert auf dem Rechnernamen, nicht auf einem geplanten, im DNS registrierten Namen.

Live-Test gegen den so erzeugten Keystore:

$ curl -sk -o /dev/null -w "%{http_code}\n" https://localhost:19443/concordia-portal/health
200

(-k, weil das Zertifikat selbstsigniert ist und curl ihm nicht vertraut — genau das erwartete Verhalten für ein Dev-Zertifikat, siehe Abschnitt "Trust" unten.)

2. Verwaltet über securityUtility createSSLCertificate (der Weg für echten Betrieb)

Das Liberty-eigene CLI-Tool zur kontrollierten Zertifikatserstellung — mit definiertem Passwort, definiertem Subject-DN und definierter Gültigkeit, genau das, was ein WAS-Admin für einen produktiven Server tatsächlich verwenden würde:

$ ./securityUtility createSSLCertificate --server=concordiaCertRotationDemo \
    --password=DemoKeystore123! --validity=365 \
    --subject="CN=concordia-portal.concordia-bank.local,O=Concordia Bank AG,C=DE"

Keystore .../concordiaCertRotationDemo/resources/security/key.p12 wird erstellt.
Das SSL-Zertifikat für den Server concordiaCertRotationDemo wurde erstellt.
Das Zertifikat wird mit CN=concordia-portal.concordia-bank.local,O=Concordia Bank AG,C=DE
als SubjectDN erstellt.

Fügen Sie zum Aktivieren von SSL der Datei server.xml die folgenden Zeilen hinzu:

    <featureManager>
        <feature>transportSecurity-1.0</feature>
    </featureManager>
    <keyStore id="defaultKeyStore" password="{xor}GzoyMBQ6JiwrMC06bm1sfg==" />

Wichtige Details in dieser echten Ausgabe:

• Das Tool gibt das fertige server.xml-Snippet inklusive obfuskiertem Passwort ({xor}...) direkt aus — genau das gehört in die eingecheckte Konfiguration, NIEMALS das Klartext-Passwort.
• {xor} ist Verschleierung, keine Verschlüsselung (trivial umkehrbar) — für echten Schutz wäre --passwordEncoding=aes mit eigenem Schlüssel der richtige Weg; für ein Lern-Dev-Setup reicht xor, das ist auch Libertys Standard.
• Ausgeführt gegen einen eigens dafür angelegten Wegwerf-Server (concordiaCertRotationDemo, per server create erzeugt) statt gegen concordiaPortalServer selbst — so bleibt der laufende Dev-Server unangetastet, während der Befehl trotzdem real (nicht simuliert) demonstriert wird.

Zertifikats-Fingerabdruck prüfen (keytool)

$ keytool -list -v -keystore concordiaCertRotationDemo/resources/security/key.p12 \
    -storetype PKCS12 -storepass DemoKeystore123! -alias default

Aliasname: default
Aussteller: CN=concordia-portal.concordia-bank.local, O=Concordia Bank AG, C=DE
SHA256: 91:42:B4:C6:D8:64:C5:4F:85:B1:D1:97:29:59:60:11:6B:50:C2:71:1F:96:16:14:0F:84:C1:B1:C7:94:2E:EC
Signaturalgorithmusname: SHA256withRSA

Genau dieser Befehl ist im Alltag der Weg, um vor einer Rotation zu prüfen, welches Zertifikat aktuell wirklich im Einsatz ist (Ablaufdatum, Aussteller, Fingerabdruck) — bevor man sich auf Dokumentation verlässt, die veraltet sein könnte.

Der Rotationsprozess (dokumentiert, Ablauf-Beschreibung)

1. Neues Zertifikat erzeugen, wie oben, mit neuem Dateinamen/Server-Verzeichnis oder nach Sicherung des alten Keystores (securityUtility verweigert bewusst das Überschreiben eines bestehenden Keystores — genau das wurde hier beim ersten Versuch gegen concordiaPortalServer real erlebt: "Die Keystore-Datei ... ist bereits vorhanden" — ein Sicherheitsnetz gegen versehentliches Überschreiben, kein Bug).
2. Trust-Kette aktualisieren, falls das Zertifikat woanders vertraut werden muss — bei einer Verbindung zu DB2 for z/OS über Port 447 (siehe docs/40-bindeglied-dev-ops-db2-netzwerk/) müsste das neue Zertifikat zusätzlich im RACF-Keyring auf Mainframe-Seite hinterlegt werden — ein Zertifikatswechsel ist hier kein rein lokaler Liberty-Vorgang.
3. server.xml auf den neuen Keystore/Passwort-Hash umstellen, Server neu starten.
4. Alten Fingerabdruck dokumentieren (siehe keytool-Befehl oben) — im Incident-Fall (z. B. "Verbindung bricht nach Rotation ab") ist der Vergleich alt-vs-neu oft der schnellste Weg zur Ursache.
5. Ablaufdatum überwachen, nicht erst beim Ausfall reagieren — siehe docs/20-monitoring-tuning/ für die Monitoring-Seite dieses Themas.

Trust: warum -k/selbstsigniert hier okay ist, produktiv aber nicht

Für dieses Lernprojekt ist ein selbstsigniertes bzw. lokal per securityUtility erzeugtes Zertifikat ausreichend. In einer echten Bank-Umgebung würde das Zertifikat stattdessen von einer internen oder öffentlichen Zertifizierungsstelle (CA) signiert, damit Clients (Browser, andere Services) ihm ohne -k/"unsicher fortfahren" vertrauen — der Erstellungsmechanismus (securityUtility bzw. keytool) bleibt derselbe, nur der letzte Schritt (Signierung durch die CA statt Selbstsignatur) kommt dazu.