Beginnend mit der IBM Storage Protect Version 8.1.2 wurde die automatische SSL-Verschlüsselung eingeführt. Seit diesem Zeitpunkt wird bei der Installation des ISP-Servers automatisch ein Master Encryption Key generiert und in der Schlüsseldatenbank (Key Database) dsmkeydb.kdb gespeichert. Ebenfalls bei der Installation wird auch das cert256.arm Zertifikat erstellt, welches in der Schlüsseldatenbank (Key Database) cert.kdb gespeichert wird.
Der Master Encryption Key in der dsmkeydb.kdb ist der Private Key, das cert256.arm File gespeichert in die Key Database cert.kdb ist der Public Key.
Die SSL-Kommunikation findet nur noch über die Key Databases dsmkeydb.kdb und cert.kdb statt. Das cert256.arm File wird aktiv nicht mehr verwendet. In seltenen Fällen kann es erforderlich sein, dass das cert256.arm Zertifikate mit Hilfe des dsmcert Programms (dsmcert -add -server) auf einem Client manuell in die Schlüsseldatenbank dsmcert.kdb des Clients importiert werden muss. In der Regel geschieht dies jedoch automatisch.
Key | Key Database | Key Type |
Master Encryption Key | dsmkeydb.kdb | Private Key |
cert256.arm File | cert.kdb | Public Key |
Alle relevanten Dateien befinden sich im ISP-Server Instanzverzeichnis.
Das ISP-Zertifikat cert256.arm ist abgelaufen: Works as designed?
Auf Nachfrage beim IBM-Support wurde uns bestätigt: Ja, das sei „works as designed“, die Zertifikate laufen nach 10 Jahren ohne Vorwarnung ab. Bei zwei unserer Kunden ist genau das passiert. Einer der beiden hatte „Glück“, denn es hat „nur“ den Library Manager getroffen. Der andere Kunde hatte leider nicht so viel Glück. Auf dem betroffenen ISP-Server mit der Version 8.1.12.000 wurden alle möglichen Arten von Clients gesichert, u.a. viele SAP-Systeme (BACKINT) mit Storage Agents. Ein normaler Betrieb war erst nach ca. 1,5 Tagen möglich, da nach der Erneuerung des cert256.arm Files auch alle Client Zertifikate ungültig waren.
Was passiert, wenn das IBM Storage Protect Server-Zertifikat cert256.arm abläuft?
Die Antwort ist einfach: Der Server läuft weiter, es kann aber nicht mehr darauf zugegriffen werden.
Der Server muss dann hart beendet werden.
Wenn man danach den Server im Vordergrund hochfährt, kommt bei jeder Session die Meldung ANR8583E mit dem Return Code 401 GSK_ERROR_BAD_DATE.
Wie prüft man das Ablaufdatum eines IBM Spectrum Server-Zertifikats?
Zunächst muss man wissen, dass nicht das cert256.arm Zertifikat für die SSL-Kommunikation verwendet wird.
Die SSL-Kommunikation findet über die Schlüsseldatenbank (Key Database) cert.kdb statt, in die das Serverzertifikat cert256.arm (Public Key) nach der Erzeugung importiert wurde.
Deswegen ist es zunächst wichtig, dass das richtige Zertifikat in der Schlüsseldatenbank cert.kdb auf das Ablaufdatum geprüft wird.
Dies kann mit den folgenden gsk8capicmd_64 Befehlen ermittelt werden:
Befehl zum Auslesen der cert.kdb
gsk8capicmd_64 -cert -list -db cert.kdb -stashed
Befehl zum Auslesen der cert.kdb mit Details auf das Label "TSM Server SelfSigned SHA Key"
gsk8capicmd_64 -cert -details -db cert.kdb -stashed -label "TSM Server SelfSigned SHA Key"
In diesem Beispiel ist das Zertifikat am 06.01.2023 um 15:18:50 Uhr abgelaufen.
IBM Storage Protect self-signed Zertifikat cert256.arm erneuern
Um das self-signed Zertifikat cert256.arm zu erneuern, sind folgende Schritte erforderlich:
1. ISP-Server stoppen
2. Kopie der folgenden Dateien erzeugen:cert256.armcert.kdbcert.sthcert.rdbcert.crl
3. Nur die Datei cert256.arm löschen
4. Mit folgendem Kommando das alte Server Zertifikat aus der Schlüsseldatenbank löschen:
gsk8capicmd_64 -cert -delete -db cert.kdb -stashed -label "TSM Server SelfSigned SHA Key"
5. ISP-Server im Vordergrund starten (maintenance)
Eine Empfehlung an dieser Stelle ist, den dsmserv im Maintenance Mode (dsmserv maintenance) zu starten.
Während des Startvorgangs wird ein neues Zertifikat mit dem Label „TSM Server SelfSigned SHA Key“ generiert und in der Schlüsseldatenbank cert.kdb gespeichert.
Zudem wird eine neue cert256.arm Datei erzeugt.
6. UPDATE ADMIN SESSIONSECURITY=TRANSITIONAL
Nun muss über die Konsole des Servers, der im Vordergrund gestartet wurde, der Administrator auf SESSIONSECURITY=TRANSITIONAL gesetzt werden, der für die Anmeldung verwendet werden soll, wenn das System wieder normal (im Hintergrund) gestartet wurde.
Konsole: UPDATE ADMIN admin_name SESSIONSEC=TRANS
7. ISP-Server im Vordergrund mit HALT stoppen und wieder normal starten.
8. Alle aktiven ADMINs, NODESs, SERVERs und STAs auf SESSIONSECURITY=TRANSITIONAL setzen.
9. Server to Server-Kommunikation mit der Option FORCESYNC=YES updaten.
10. Alle Client Zertifikate (für Admins und Nodes) erneuern.
Wenn ein UPDATE mit SESSIONSECURITY=TRANSITIONAL nicht reichen sollte, dann muss das neu erzeugte Zertifikat cert256.arm auf die Clients kopiert werden. Dieser Punkt ist sicherlich der aufwändigste von allen und beansprucht die meiste Zeit bei dieser Aktion.
Die Zertifikatsdateien inkl. Schlüsseldatenbank des Clients befinden sich Installationsverzeichnis.
Windows
…\baclient
Unix/Linux
…/client/ba/bin bzw. bin64
Dieses Zertifikat kann mit folgendem Befehl in die Schlüsseldatenbank des Clients hinzugefügt werden:
dsmcert -add -server <servername> -file <path_to_cert256.arm>
Aktuelles zum Thema seitens der IBM
Die IBM hat zu diesem Thema die folgende Technote bereitgestellt:
IT42905: HOW TO RENEW AN IBM SPECTRUM PROTECT SERVER SSL CERTIFICATE
Hier können Sie mitvoten, um das Thema "Abgelaufene Serverzertifikate" bei der IBM-Prioritätenliste im IBM-Ideas-Portal zu pushen:
Falls Sie in diese Situation kommen und Hilfe benötigen, oder wenn Sie Ihre Zertifikate einfach nur prüfen wollen, beraten wir Sie gerne.
