Expert GuideWie Sie 3rd-Party-Zertifikate mit IBM Storage Protect nutzen können

Vorüberlegungen

Im Beispiel gehen wir von einem frisch installierten IBM Storage Protect mit den folgenden Rahmendaten aus:

• Instanzverzeichnis: /tsminst1/
• Home-Verzeichnis: /home/tsminst1/
• Installationsverzeichnis: /opt/tivoli/tsm/
• FQDN des Servers: isp01.imperius.mtr

Der Server wurde bereits formatiert und lässt sich im Vordergrund starten, so dass sein Zertifikat erzeugt wurde. Daneben gibt es einen Client, der auf einem anderen Host als der Server läuft:

• Installationsverzeichnis: /opt/tivoli/tsm/client/

Auf dem Server wechseln wir in den Instanzbenutzer tsminst1 und das Instanzverzeichnis /tsminst1/; alle folgenden Befehle auf dem Server werden ab jetzt in diesem Kontext ausgeführt. Betrachten wir zunächst die bestehende Situation.

• gsk8capicmd_64 -cert -list -db /tsminst1/cert.kdb -stashed

Certificates found
* default, - personal, ! trusted, # secret key
*-    "TSM Server SelfSigned SHA Key"

Es ist ein Zertifikat vorhanden, das während der Installation/Formatierung von IBM Storage Protect eingerichtet wurde.

Im Instanzverzeichnis liegt die Datei cert256.arm, die das von ISP erstellte, selbstsignierte Zertifikat enthält. In unserem Beispiel haben wir sie auf den Client übertragen und dort installiert:

gsk8capicmd_64 -cert \
-add \
-db /opt/tivoli/tsm/client/ba/bin/dsmcert.kdb \
-stashed -label "TSM Server SelfSigned SHA Key" \
-file /root/files/cert256.arm \
-format ascii`

Dementsprechend ist das Zertifikat im Client vorhanden und kann angezeigt werden:

• gsk8capicmd_64 -cert -list -db /opt/tivoli/tsm/client/ba/bin/dsmcert.kdb

Dies beschert uns folgende Ausgabe:

Certificates found
* default, - personal, ! trusted, # secret key
...
!    "TSM Server SelfSigned SHA Key"

Es waren noch eine Reihe an Certificate Authorities enthalten, die wir aber ausgelassen haben (Entrust, VeriSign, Thawte).
Mit diesen Einstellungen sollte eine Verbindung per dsmadmc möglich sein, sofern ein entsprechender Zugang eingerichtet wurde.

Eine eigene Public Key Infrastructure (PKI)

Das eigentliche Ziel jedoch ist, anstelle des selbstsignierten, bei der Installation erstellten Zertifikats eine "richtige" Public Key Infrastructure (PKI) zu verwenden, d. h. außerhalb von ISP Zertifikate zu erstellen und von einer Zertifikatsauthorität (CA) beglaubigen zu lassen.

Dies kann eine firmeninterne CA oder sogar eine öffentliche CA sein, wobei wir von letzterem dringend abraten würden.

Ziel unserer Bemühungen sollen drei Zertifikate sein:

• ca.crt - das Root-Zertifikat unserer Certificate Authority
• intermediate.crt - ein Zwischenzertifikat
• isp01.imperius.mtr.01.crt - das Serverzertifikat

Alle drei Dateien liegen als PEM vor, dem 'default'-Format von openssl; die FQDN isp01.imperius.mtr dient als Serveradresse, die Sie nach eigenem Ermessen anpassen können.

Die Certificate Authority

Um kurzfristig an die oben erwähnten Dateien zu kommen, erstellen wir uns kurzerhand unsere eigene CA, ein Certificate Signing Request und signieren es mit der eigenen CA:

• openssl genrsa -out ca.key 4096 - erstellt einen Schlüssel.

Der Befehl für ein selbstsigniertes Zertifikat ist ungleich komplizierter:

openssl req \
-x509 \
-new \
-nodes \
-extensions v3_ca \
-key ca.key \
-days 1024 \
-out ca.crt \
-sha512 \
-subj="/C=DE/ST=Baden-Wuerttemberg/L=Stuttgart/O=Test Company/CN=Test Certificate Authority/"

Damit erhalten wir eine Certificate Authority (CA), die für 1024 Tage gültig ist.

Das Zwischenzertifikat

Unter die CA - auch "Root CA" genannt - hängen wir ein abhängiges Zwischenzertifikat, wie es auch in der Praxis häufig der Fall ist. Dies hat mehrere Vorteile:

1. Wir können danach den - wertvollen! - Schlüssel der CA in einen Tresor legen. Damit sinkt das Risiko, dass die ganze CA kompromittiert wird.
2. Wir können den Zertifikatsraum partitionieren, beispielsweise VPN, Server und E-Mailverschlüsselung. Sind Server und Clients richtig eingerichtet, vertraut z. B. dsmc nur Zertifikaten, die unter dem Zwischenzertifikat für Server hängen.

Auch hier erstellen wir als erstes einen Schlüssel:

• openssl genrsa -out intermediate.key 4096

Gefolgt von dem eigentlichen Zwischenzertifikat:

openssl req \
-x509 \
-new \
-nodes \
-extensions v3_ca \
-key intermediate.key \
-days 1024 \
-out intermediate.crt \
-sha512 \
-CA ca.crt -CAkey ca.key \
-subj="/C=DE/ST=Baden-Wuerttemberg/L=Stuttgart/O=Test Company/CN=Test Intermediate Certificate/"

Serverzertifikat

Wir erstellen nun zunächst einen Schlüssel für das Serverzertifikat:

• openssl genrsa -out isp01.imperius.mtr.01.key 4096

Gefolgt von dem Zertifikat selbst:

openssl req \
-x509 \
-new \
-nodes \
-key isp01.imperius.mtr.01.key \
-days 1024 \
-out isp01.imperius.mtr.01.crt \
-sha512 \
-CA intermediate.crt -CAkey intermediate.key \
-subj="/C=DE/ST=Baden-Wuerttemberg/L=Stuttgart/O=Test Company/CN=isp01.imperius.mtr/" \
-addext="subjectAltName=DNS:isp01.imperius.mtr,DNS:isp01.securezone.imperius.mtr" \
-addext="basicConstraints=critical,CA:FALSE" \
-addext="keyUsage=nonRepudiation, digitalSignature, keyEncipherment"

Interessant ist hier die Erweiterung subjectAltName, mit der wir mehrere Namen für den Server hinterlegen können, in diesem Falle isp01.imperius.mtr und isp01.securezone.imperius.mtr.

Als nächstes müssen wir die derzeit noch getrennten Dateien von Schlüssel und Zertifikat in eine einzelne Datei übertragen, da IBM Storage Protect dieses Format dieses Format benötigt. Im Verlauf müssen wir eine Passphrase eingeben, die wir uns merken müssen. Der Wert von name ist egal, wird jedoch beim Import wieder verwendet.

openssl pkcs12 -export \
-in isp01.imperius.mtr.01.crt \
-inkey isp01.imperius.mtr.01.key \
-out isp01.imperius.mtr.01.p12 \
-name "server"

Damit verfügen wir über alle der oben genannten Dateien. Bitte beachten Sie, dass es sich hierbei um eine beispielhafte CA zu Testzwecken handelt, die Sie nicht 1:1 für den Aufbau einer eigenen CA verwenden sollten. Falls Sie Unterstützung bei der Konzeptionierung einer CA benötigen, wenden Sie sich bitte an den unten genannten Kontakt.

Serverkonfiguration

Für die Serverkonfiguration haben wir entweder bereits eine funktionierende Möglichkeit, mit dsmadmc an den Server zu kommen oder lassen den Server im Vordergrund laufen.

Zunächst prüfen wir die bestehende Konfiguration im Instanzverzeichnis /tsminst1/ als Instanzbenutzer tsminst1:

gsk8capicmd_64 -cert \
-list \
-db cert.kdb \
-stashed

Auf einem frisch installierten IBM Storage Protect finden wir das vom Server selber erzeugte Zertifikat:

Certificates found
* default, - personal, ! trusted, # secret key
*-    "TSM Server SelfSigned SHA Key"

Dieser fügen wir nun das Zertifikat hinzu, dass wir vorhergehend erzeugt und in das pkcs-Format (.p12) umgewandelt haben:

gsk8capicmd_64 -cert -import \
 -file isp01.imperius.mtr.01.p12 \
 -label "server" \
 -type pkcs12 \
 -target cert.kdb \
 -target_stashed \
 -new_label "Server Certificate"

Als nächstes müssen wir sowohl das Wurzel- als auch das Zwischenzertifikat installieren:

gsk8capicmd_64 -cert \
-add \
-file ca.crt \
-db cert.kdb \
-stashed \
-label "CA Certificate"

Sowie:

gsk8capicmd_64 -cert \
-add \
-file intermediate.crt \
-db cert.kdb \
-stashed \
-label "Intermediate Certificate"

Eine entsprechende Überprüfung sollte nun das Serverzertifikat, das CA-Zertifikat und ggf. bereits bestehende Zertifikate anzeigen, in unserem Fall das selbstsignierte Zertifikat, das IBM Storage Protect selber erstellt:

• gsk8capicmd_64 -cert -list -db cert.kdb -stashed

Ergebnis:

Certificates found
* default, - personal, ! trusted, # secret key
!    "CA Certificate"
!    "Intermediate Certificate"
*-    "TSM Server SelfSigned SHA Key"
-    "Server Certificate"

Es fehlt jetzt nur noch, dass IBM Storage Protect weiß, welches Zertifikat er ab jetzt verwenden soll. Dazu muss es auf Default gesetzt werden. Ab Version 8.1.20 soll dies im IBM Storage Protect selbst geschehen. Dazu starten wir den Server im Vordergrund oder nutzen dsmadmc für eine Serververbindung, um folgenden Befehl auszuführen:

• set defaulttlscert "Server Certificate"

Dies sollte IBM Storage Protect entsprechend bestätigen:

ANR3882I SET DEFAULTTLSCERT: Certificate with label "Server Certificate" is now the default.

Falls dies nicht der Fall ist, prüfen Sie bitte folgendes:

• stimmt das Label mit dem Label in der cert.kdb überein?
• haben Sie das (richtige) CA-und Zwischenzertifikat importiert?

Im Erfolgsfall starten Sie den Server neu.

Beim Neustart im Vordergrund erscheint direkt der Verweis auf das neue Zertifikat:

ANR7800I DSMSERV generated at 04:36:59 on Dec  5 2024.

IBM Storage Protect for Linux/x86_64
Version 8, Release 1, Level 25.000

Licensed Materials - Property of IBM

(C) Copyright IBM Corporation 1990, 2024.
All rights reserved.
U.S. Government Users Restricted Rights - Use, duplication or disclosure
restricted by GSA ADP Schedule Contract with IBM Corporation.

ANR7801I Subsystem process ID is 3252.
ANR0900I Processing options file /tsminst1/dsmserv.opt.
ANR7814I Using instance directory /tsminst1.
ANR3339I Default Label in key data base is Server Certificate. 
ANR4196W TLS certificate "Server Certificate", will expire on 06/18/2025 01:08:11 PM.

Damit ist die Einrichtung auf dem Server abgeschlossen.

Der Client

Der Versuch, sich mit dsmadmc zu verbinden, wird jetzt zwangsläufig scheitern, da der Client jetzt dem Server nicht mehr vertraut. Daher importieren wir das CA-File auch auf dem Client:

gsk8capicmd_64 -cert \
-add \
-file ca.crt \
-db /opt/tivoli/tsm/client/ba/bin/dsmcert.kdb \
-stashed \
-label "CA Certificate"

Danach das Zwischenzertifikat:

gsk8capicmd_64 -cert \
-add \
-file intermediate.crt \
-db /opt/tivoli/tsm/client/ba/bin/dsmcert.kdb \
-stashed \
-label "Intermediate Certificate"

Dies überprüfen wir direkt:

• gsk8capicmd_64 -cert -list -db /opt/tivoli/tsm/client/ba/bin/dsmcert.kdb -stashed

Zumindest in unserem Falle enthielt die dscmcert.kdb eine längere Liste an vorinstallierten Zertifikaten, wichtig ist jedoch nur das Zertifikat der CA:

Certificates found
* default, - personal, ! trusted, # secret key
...
!    "TSM Server SelfSigned SHA Key"
!    "CA Certificate"
!    "Intermediate Certificate"

Danach sollte die Verbindung mit dsmadmc funktionieren.

Aufräumen

Als ordentliche Wesen beseitigen wir jetzt noch das nicht mehr benötigte Zertifikat, das IBM Storage Protect selbst erzeugt hat. Hierzu führen wir auf dem Server folgenden Befehl aus:

gsk8capicmd_64 -cert \
-delete \
-db /tsminst1/cert.kdb \
-stashed \
-label "TSM Server SelfSigned SHA Key"

Danach können wir gleiches auf dem Client tun. Der Wert von -label wird bei Ihnen allerdings höchstwahrscheinlich anders lauten, passen Sie den Wert also entsprechend an:

gsk8capicmd_64 -cert \
-delete \
-db /opt/tivoli/tsm/client/ba/bin/dsmcert.kdb \ 
-stashed \
-label "TSM Server SelfSigned SHA Key"

Fazit

Im vorliegenden Text haben wir gezeigt, wie man IBM Storage Protect auf Zertifikate umstellt, die mit einer Public Key Infrastructure erstellt wurden. Dies bringt Vorteile insofern mit sich, dass sich Server und Clients vertrauen, wenn beide die gleiche CA kennen und verwenden.

Dies kann jedoch auch von Nachteil sein, wenn die Befugnis, Zertifikate zu beantragen, nicht reglementiert ist und genau geprüft wird.