bg-tutorials

Wie man einen CSR auf IBM HTTP Server generiert

Diese Anleitung zeigt Ihnen wie Sie eine CSR (Certificate Signing Request) auf IBM HTTP Server (IHS) erzeugen, und wie Sie dieselbe Aufgabe auf HCL Domino (früher IBM Domino) durchführen.

IBM HTTP Server speichert Schlüssel und Zertifikate in einer CMS-Schlüsseldatenbank (eine .kdb-Datei plus ein .sth-Stash), die Sie mit dem grafischen Tool IKEYMAN oder dem Kommandozeilen-Dienstprogramm gskcapicmd aus dem IBM Global Security Kit (GSKit) verwalten, das mit IHS ausgeliefert wird.

Die folgenden Schritte behandeln beide Wege auf IHS 9.0.5.x (der aktuell unterstützten Version) sowie anschließend die beiden CSR-Abläufe für HCL Domino: die klassische Datenbank Server Certificate Administration (für Legacy-Installationen beibehalten) und die moderne Aufgabe Certificate Manager mit certstore.nsf, die HCL für Domino 12 und höher empfiehlt.

Eine CSR auf IBM HTTP Server erzeugen

Wenn Sie Ihre CSR bereits erzeugt haben, springen Sie direkt zu wie man ein SSL-Zertifikat auf IBM HTTP Server installiert.

Sie können die Anfrage auf IHS auf zwei Arten erstellen: über die grafische Oberfläche IKEYMAN (das klassische Point-and-Click-Dienstprogramm) oder mit gskcapicmd auf der Kommandozeile. Beide schreiben den privaten Schlüssel in dieselbe CMS-Schlüsseldatenbank und erzeugen eine PKCS #10-Anfrage als .arm-Datei, die Sie bei Ihrer Zertifizierungsstelle einreichen. Wählen Sie die GUI auf einem Desktop oder einem Server mit Display; wählen Sie die CLI auf einer Headless-Maschine oder wenn Sie ein wiederholbares Skript wünschen.

Voraussetzungen: IBM HTTP Server ist installiert, GSKit ist auf dem System vorhanden (es wird im IHS-Paket mitgeliefert), und das IHS-Verzeichnis bin befindet sich in Ihrem PATH oder Sie kennen dessen vollständigen Pfad (typischerweise /opt/IBM/HTTPServer/bin/ unter Linux/AIX oder C:Program FilesIBMHTTPServerbin unter Windows). Sie benötigen außerdem ein Arbeitsverzeichnis, in dem Sie die neue Schlüsseldatenbank und die CSR-Datei schreiben können, sowie einen Ort, an dem Sie das Passwort der Schlüsseldatenbank vermerken.

Methode 1: Eine CSR mit IKEYMAN erzeugen (GUI)

Schritt 1: Eine neue CMS-Schlüsseldatenbank (.kdb) erstellen

  • Starten Sie IKEYMAN. Öffnen Sie unter Windows Start > IBM HTTP Server > Start Key Management Utility. Unter Linux, AIX oder anderen UNIX-Systemen führen Sie ikeyman aus dem IHS-Verzeichnis bin aus (zum Beispiel /opt/IBM/HTTPServer/bin/ikeyman); Sie benötigen dafür ein funktionierendes X11-Display.
  • Wählen Sie im Menü Key Database File > New.
  • Wählen Sie im Dropdown-Menü Key database type die Option CMS. Dies ist das Format, das IBM HTTP Server liest.
  • Geben Sie unter File Name einen Namen für die neue Datenbank ein (zum Beispiel key.kdb).
  • Verweisen Sie unter Location auf einen Ordner, den Sie später wiederfinden (zum Beispiel /opt/IBM/HTTPServer/ssl/ unter Linux oder C:IBMHTTPServerssl unter Windows). Klicken Sie auf OK.
  • Legen Sie ein starkes Passwort fest und aktivieren Sie dann Stash password to a file, damit IKEYMAN eine passende .sth-Stash-Datei neben der .kdb-Datei schreibt. IHS liest den Stash beim Start, sodass Sie das Passwort nicht bei jedem Serverstart eingeben müssen. Klicken Sie auf OK.

IKEYMAN erstellt zwei Dateien in diesem Ordner: die Datenbank selbst (key.kdb) und den Stash (key.sth). Behandeln Sie beide als geheim. Halten Sie ihre Dateiberechtigungen streng (nur vom IHS-Benutzer lesbar) und sichern Sie sie an einem sicheren Ort, denn ohne sie können Sie den privaten Schlüssel nicht wiederherstellen.

Schritt 2: Die Zertifikatsanfrage erstellen

  • Suchen Sie bei geöffneter neuer Datenbank das Dropdown-Menü Key database content und ändern Sie es auf Personal Certificate Requests.
  • Klicken Sie auf New. Der Dialog Create New Key and Certificate Request öffnet sich.

Füllen Sie die Felder nur mit Standard-ASCII-Zeichen aus; nicht-lateinische Buchstaben führen dazu, dass die Anfrage fehlschlägt:

  • Key Label: eine kurze Kennung für dieses Zertifikat innerhalb der Schlüsseldatenbank, zum Beispiel www.example.com. Auf diese Kennung verweisen Sie später in httpd.conf mit der Direktive SSLServerCert.
  • Key Size: wählen Sie 2048. Dies ist das aktuelle Minimum, das jede öffentliche Zertifizierungsstelle akzeptiert. Wählen Sie 3072 oder 4096 nur, wenn Ihre Richtlinie einen größeren Schlüssel vorschreibt; der Kompromiss ist ein etwas langsamerer TLS-Handshake.
  • Signature Algorithm: wählen Sie SHA256WithRSA (oder stärker, wie SHA384WithRSA). Vermeiden Sie alles mit SHA-1; öffentliche Zertifizierungsstellen stellen dagegen keine Zertifikate mehr aus.
  • Common Name: der vollqualifizierte Domainname (FQDN), den Sie absichern möchten, zum Beispiel www.example.com. Für ein Wildcard-Zertifikat setzen Sie einen Stern vor die Domain, zum Beispiel *.example.com.
  • Organization: der vollständige rechtliche Name Ihres Unternehmens, genau wie eingetragen. Erforderlich für OV- und EV-Zertifikate; wird bei DV ignoriert.
  • Organizational Unit: dieses Attribut ist für öffentliche Zertifikate veraltet (das CA/Browser Forum hat es abgeschafft). Lassen Sie es leer oder geben Sie eine kurze Bezeichnung wie IT ein.
  • Locality: der vollständige Stadtname (zum Beispiel Seattle, nicht SEA).
  • State/Province: der vollständige Bundesstaat- oder Provinzname (zum Beispiel Washington, nicht WA).
  • Country: der zweibuchstabige ISO-Ländercode, zum Beispiel US, GB oder DE.
  • Subject Alternative Names (SAN): fügen Sie jeden Hostnamen hinzu, der auf dem Zertifikat erscheinen soll, einschließlich des im Feld Common Name eingetragenen Werts. Moderne Browser ignorieren den Common Name und validieren nur gegen die SAN-Liste, sodass ein Zertifikat mit mehreren Namen hier entsprechende Einträge benötigt.
  • Enter the name of a file in which to store the certificate request: ein Pfad und Name, der auf .arm endet, zum Beispiel /opt/IBM/HTTPServer/ssl/www_example_com.arm. Speichern Sie ihn im selben Ordner wie die Schlüsseldatenbank, damit beide zusammenbleiben.

Klicken Sie auf OK. IKEYMAN erzeugt das Schlüsselpaar innerhalb der Schlüsseldatenbank, speichert die Anfrage als ausstehenden Eintrag und schreibt die PKCS #10-CSR in die von Ihnen benannte .arm-Datei.

Schritt 3: Die CSR kopieren und bei der Zertifizierungsstelle einreichen

Öffnen Sie die .arm-Datei in einem beliebigen Texteditor (Notepad, vi, nano). Sie sehen einen Block wie diesen:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIDXjCCAkYCAQAwgZQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApXYXNoaW5ndG9u
... (many lines of base64) ...
-----END NEW CERTIFICATE REQUEST-----

Markieren Sie den gesamten Block, einschließlich der Zeilen BEGIN und END, kopieren Sie ihn und fügen Sie ihn in das CSR-Feld Ihres Bestellformulars ein. Der private Schlüssel verbleibt in der Schlüsseldatenbank auf dem Server; nur der CSR-Text verlässt die Maschine.

Methode 2: Eine CSR mit gskcapicmd erzeugen (CLI)

Das Dienstprogramm gskcapicmd (manchmal als gskcmd für den Java-Wrapper aufgeführt, oder als gsk8capicmd_64 bei 64-Bit-GSKit-Installationen) erledigt dieselbe Arbeit wie IKEYMAN ohne grafische Sitzung. Führen Sie es aus dem IHS-Verzeichnis bin aus.

Schritt 1: Die CMS-Schlüsseldatenbank und die Stash-Datei erstellen

Wählen Sie einen Ordner für die Schlüsseldatenbank und führen Sie dann aus:

gskcapicmd -keydb -create 
  -db /opt/IBM/HTTPServer/ssl/key.kdb 
  -pw your_strong_password 
  -type cms 
  -stash

Aufschlüsselung der Argumente:

  • -db: der vollständige Pfad zur neuen .kdb-Datei.
  • -pw: das Passwort, das die Schlüsseldatenbank schützt.
  • -type cms: das Format, das IHS liest.
  • -stash: schreibt eine passende .sth-Stash-Datei neben der Datenbank, damit IHS sie beim Start ohne Nachfrage lesen kann.

Auf der Kommandozeile ist das Passwort in Prozesslisten und der Shell-Historie sichtbar. Nachdem die Datenbank existiert, ändern Sie das Passwort in eines, das nicht in der Historie vermerkt ist, mit gskcapicmd -keydb -changepw, oder übergeben Sie das Passwort über eine Umgebungsvariable und löschen diese anschließend.

Schritt 2: Die Zertifikatsanfrage erstellen

Erzeugen Sie das Schlüsselpaar und die PKCS #10-CSR in einem Schritt, mit SAN-Einträgen für jeden Hostnamen, der auf dem Zertifikat erscheinen soll:

gskcapicmd -certreq -create 
  -db /opt/IBM/HTTPServer/ssl/key.kdb 
  -pw your_strong_password 
  -label www.example.com 
  -dn "CN=www.example.com,O=Example Inc,L=Seattle,ST=Washington,C=US" 
  -size 2048 
  -sigalg SHA256WithRSA 
  -san_dnsname "www.example.com,example.com" 
  -file /opt/IBM/HTTPServer/ssl/www_example_com.arm

Aufschlüsselung der Argumente:

  • -label: die Kennung für dieses Zertifikat innerhalb der Schlüsseldatenbank. Verweisen Sie später von httpd.conf aus darauf mit der Direktive SSLServerCert.
  • -dn: der Distinguished Name, geschrieben als eine Zeichenkette mit durch Kommas getrennten Attributen. Verwenden Sie CN= für den FQDN und den zweibuchstabigen ISO-Code in C=.
  • -size: 2048 ist das Minimum. Verwenden Sie 3072 oder 4096 nur, wenn Ihre Richtlinie es vorschreibt.
  • -sigalg: SHA256WithRSA (oder SHA384WithRSA). Verwenden Sie kein SHA-1.
  • -san_dnsname: eine durch Kommas getrennte Liste jedes Hostnamens, der auf dem Zertifikat erscheinen muss. Nehmen Sie den Wert des Common Name in diese Liste auf. Browser und die meisten TLS-Bibliotheken validieren nur die SAN, nicht den CN.
  • -file: der Pfad, an dem gskcapicmd die .arm-CSR-Datei schreibt.

Wenn Sie statt RSA einen ECDSA-Schlüssel benötigen, ersetzen Sie -sigalg SHA256WithRSA durch -sigalg SHA256WithECDSA und passen Sie -size an Ihre gewünschte Kurve an (-size 256 für P-256, -size 384 für P-384). Die unterstützten Kurven sind secp256r1 (P-256), secp384r1 (P-384) und secp521r1 (P-521). Die ECDSA-Unterstützung in IHS wird nur vollständig über gskcapicmd bereitgestellt; IKEYMAN erlaubt bei älteren IHS-Versionen keine Auswahl von ECDSA. Für ECDSA auf einer bestimmten IHS-Version folgen Sie IBMs Anleitung zum Zertifikatsmanagement.

Schritt 3: Die Anfrage auflisten und überprüfen

Bestätigen Sie, dass die Anfrage zur Schlüsseldatenbank hinzugefügt wurde:

gskcapicmd -certreq -list 
  -db /opt/IBM/HTTPServer/ssl/key.kdb 
  -pw your_strong_password

Um die CSR erneut auszulesen und den Common Name, die SAN-Einträge, die Schlüsselgröße und den Signaturalgorithmus zu prüfen:

gskcapicmd -certreq -details 
  -db /opt/IBM/HTTPServer/ssl/key.kdb 
  -pw your_strong_password 
  -label www.example.com

Öffnen Sie dann die .arm-Datei in einem Texteditor, kopieren Sie den vollständigen Block von BEGIN NEW CERTIFICATE REQUEST bis END NEW CERTIFICATE REQUEST, und reichen Sie ihn auf Ihrem CA-Bestellformular ein.

Die CSR vor dem Einreichen prüfen (optional)

Wenn Sie OpenSSL installiert haben, führen Sie dies auf derselben Maschine aus, um den Subject, die SAN-Liste und die Schlüsselgröße zu bestätigen:

openssl req -noout -text -in www_example_com.arm

Bevorzugen Sie ein Online-Tool? Fügen Sie den Inhalt der Anfrage in SSL Dragons CSR Decoder ein, um dieselben Details auszulesen. Bestätigen Sie, dass der Common Name mit dem Hostnamen übereinstimmt, den Clients verwenden werden, und dass jeder erforderliche Hostname unter Subject Alternative Name erscheint.

Nachdem die Zertifizierungsstelle Ihr Zertifikat ausgestellt hat

Das signierte Zertifikat muss zurück in die gleiche Schlüsseldatenbank, aus der die CSR stammt, unter derselben Kennung. Empfangen Sie es mit der CLI:

gskcapicmd -cert -receive 
  -db /opt/IBM/HTTPServer/ssl/key.kdb 
  -pw your_strong_password 
  -file www_example_com.crt

Oder machen Sie dasselbe in IKEYMAN unter Personal Certificates > Receive. Fügen Sie zuerst das Root- und die Zwischenzertifikate als Signaturzertifikate hinzu, aktualisieren Sie dann httpd.conf mit den Direktiven KeyFile und SSLServerCert, und starten Sie IHS neu. Die vollständige Vorgehensweise ist beschrieben unter wie man ein SSL-Zertifikat auf IBM HTTP Server installiert.

Eine CSR auf HCL Domino erzeugen

Hinweis: IBM Domino heißt jetzt HCL Domino. HCL schloss die Übernahme des Collaboration-Portfolios von IBM (einschließlich Notes/Domino) am 1. Juli 2019 ab. Bei Domino 12 und höher empfiehlt HCL die Aufgabe Certificate Manager (mit certstore.nsf und TLS-Credentials-Dokumenten) für alle neuen TLS-Arbeiten. Die klassische Datenbank Server Certificate Administration (CERTSRV.NSF) funktioniert weiterhin bei Legacy-Installationen und wird nachfolgend dokumentiert, aber neue Bereitstellungen sollten den Certificate Manager verwenden.

Methode A: Eine CSR mit Certificate Manager erstellen (Domino 12+ / 14.x)

  • Fügen Sie die Aufgabe CertMgr auf Ihrem dafür vorgesehenen Certificate-Manager-Server hinzu, damit sie certstore.nsf erstellt. Führen Sie CertMgr auch auf jedem Domino-Server aus, der TLS-Schlüssel lesen muss, damit sich die Datenbank repliziert.
  • Öffnen Sie certstore.nsf, gehen Sie zu TLS Credentials und klicken Sie auf Add TLS Credentials.
  • Host names: geben Sie den genauen FQDN ein, den Clients verwenden werden, und fügen Sie jeden zusätzlichen Hostnamen als Subject Alternative Name hinzu.
  • Servers with access: wählen Sie die Domino-Server aus, die den privaten Schlüssel lesen können müssen.
  • Certificate Provider: wählen Sie Manual für jede Drittanbieter-Zertifizierungsstelle. (Wählen Sie Let’s Encrypt nur, wenn CertMgr automatisch ein kostenloses, per ACME ausgestelltes Zertifikat beziehen soll.)
  • Key type: wählen Sie RSA oder ECDSA.
  • RSA: wählen Sie 2048 Bit (oder größer, falls Ihre Richtlinie es erfordert).
  • ECDSA: wählen Sie eine Kurve (P-256 oder P-384; P-384 ist der angegebene Standard).
  • Klicken Sie auf Submit Request. CertMgr erzeugt das Schlüsselpaar, signiert die CSR, und das Dokument wechselt zu Status = Waiting.
  • Öffnen Sie das Dokument, kopieren Sie den Wert von Certificate signing request (CSR) (oder verwenden Sie die Aktion Copy CSR, die nach der Verarbeitung erscheint), und fügen Sie den PEM-Block in Ihr CA-Bestellformular ein.

Der private Schlüssel verbleibt in certstore.nsf, verschlüsselt für die von Ihnen autorisierten Server. Sie exportieren ihn niemals. Wenn die Zertifizierungsstelle Ihr Zertifikat ausstellt, fügen Sie das signierte Zertifikat (zusammen mit der ausstellenden Kette) zurück in dasselbe TLS-Credentials-Dokument ein, und CertMgr installiert es für Sie. Die vollständige Referenz finden Sie in HCLs Dokumentation zum Certificate Manager.

Methode B: Klassische Server Certificate Administration (Legacy-Domino)

Verwenden Sie diese Methode nur bei Domino-Versionen, die noch auf Key-Ring-Dateien (.kyr + .sth) angewiesen sind. HCL kennzeichnet sie bei Domino 12 und höher als Legacy.

  • Öffnen Sie im Domino Administrator-Client Server Certificate Administration.
  • Wählen Sie Create Key Ring. Geben Sie einen Key-Ring-Namen und ein starkes Passwort ein.
  • Key Size: wählen Sie 2048 Bit.
  • Füllen Sie den Distinguished Name aus:
  • Common Name: der FQDN, den Sie absichern möchten, zum Beispiel www.example.com.
  • Organization: der vollständige rechtliche Name Ihres Unternehmens.
  • Organizational Unit: leer lassen oder eine kurze Bezeichnung wie IT eingeben (das Attribut ist für öffentliche Zertifikate veraltet).
  • City or Locality: der vollständige Stadtname, zum Beispiel Seattle.
  • State or Province: der vollständige Name des Bundesstaats, zum Beispiel Washington.
  • Country: der zweibuchstabige ISO-Code, zum Beispiel US.
  • Überprüfen Sie die Angaben und klicken Sie auf Continue. Domino erstellt die Key-Ring-Datei.
  • Wählen Sie Create Certificate Request. Wählen Sie unter Method die Option Paste into form on CA’s site. Domino zeigt den CSR-Text an.
  • Kopieren Sie den gesamten CSR-Block (einschließlich der Zeilen BEGIN und END) und fügen Sie ihn in Ihr CA-Bestellformular ein.

Klassische Key-Ring-Dateien unterstützen in diesem Dialog keine SAN-Einträge. Wenn Sie ein Zertifikat mit mehreren Namen benötigen, wechseln Sie zu Certificate Manager (Methode A) oder erzeugen Sie die CSR außerhalb des Servers.

Häufig gestellte Fragen

Was ist eine CMS-Schlüsseldatenbank und warum benötigt IHS sie?

IBM HTTP Server liest PEM-Schlüssel- und Zertifikatsdateien nicht so, wie es der Standard-Apache tut. Sein TLS-Stack (mod_ibm_ssl, unterstützt von GSKit) speichert Schlüssel, Zertifikatsanfragen und ausgestellte Zertifikate in einer einzigen CMS-Schlüsseldatenbankdatei mit der Erweiterung .kdb. Eine passende Stash-Datei (.sth) enthält das Datenbankpasswort in einer Form, die IHS beim Start lesen kann. Sie verweisen IHS mit der Direktive KeyFile in httpd.conf auf die Datenbank und referenzieren ein bestimmtes Zertifikat darin mit SSLServerCert.

Sollte ich IKEYMAN oder gskcapicmd verwenden?

Beide schreiben in dieselbe Schlüsseldatenbank, also funktionieren beide. IKEYMAN ist praktisch auf einem Desktop oder einem Server mit X11-Display und führt Sie durch den Dialog. gskcapicmd ist die bessere Wahl auf Headless-Servern, bei der Automatisierung und für ECDSA-Schlüssel, die die GUI bei älteren IHS-Versionen nicht anbietet. Viele Administratoren erstellen die Datenbank mit der CLI und verwenden IKEYMAN später nur zur Kontrolle.

Wofür dient die Stash-Datei (.sth)?

Die Stash-Datei enthält das Passwort der Schlüsseldatenbank in verschleierter Form, damit IBM HTTP Server die Datenbank beim Start ohne interaktive Abfrage öffnen kann. Es handelt sich nicht um Verschlüsselung: Jeder mit Lesezugriff auf die Datei kann das Passwort wiederherstellen. Halten Sie sowohl die .kdb– als auch die .sth-Datei nur für den IHS-Benutzer lesbar, speichern Sie die Datenbank auf dem lokalen Dateisystem (nicht auf einer öffentlich lesbaren Freigabe) und sichern Sie das Paar an einem sicheren Ort.

Warum heißt gskcapicmd auf meinem System gsk8capicmd_64?

Das ist die Binärdatei, die mit dem 64-Bit-GSKit 8.x ausgeliefert wird, gebündelt mit WebSphere Application Server 9 und IBM HTTP Server 9.0. GSKit 10 (gebündelt mit WebSphere 10 und höher) folgt derselben Konvention. Der Name gskcapicmd in dieser Anleitung ist der von IHS mitgelieferte Wrapper, der die richtige Binärdatei für Ihre Installation aufruft; gsk8capicmd_64 ist dasselbe Tool unter seinem versionierten Namen. Beide funktionieren mit der oben gezeigten Syntax.

Sparen Sie 10% auf SSL-Zertifikate, wenn Sie noch heute bestellen!

Schnelle Ausstellung, starke Verschlüsselung, 99,99% Browser-Vertrauen, engagierter Support und 25-tägige Geld-zurück-Garantie. Gutscheincode: SAVE10

A detailed image of a dragon in flight
Geschrieben von

Erfahrener Content-Autor, spezialisiert auf SSL-Zertifikate. Verwandeln Sie komplexe Cybersicherheitsthemen in klare, ansprechende Inhalte. Tragen Sie durch wirkungsvolle Narrative zur Verbesserung der digitalen Sicherheit bei.