Dieser Artikel beschreibt, wie man ein neues SSL-Zertifikat in die Schlüsseldatenbank des IBM HTTP Servers (IHS) einspielt. Ich gehe davon aus, dass sowohl Zertifikat als auch privater Schlüssel vorliegen. Es wird kein selbst signiertes Zertifikat über den IHS erstellt. Das ist zwar auch möglich, aber auf diesem Weg liegt der komplette Prozess bei den Tools für den Keystore.
In diesem Szenario soll das Zertifikat also außerhalb von den IHS-Werkzeugen erstellt werden. Man kann natürlich trotzdem mit z.B. OpenSSL ein selbst signiertes Zertifikat erstellen, wenn dies benötigt wird – etwa für Testsysteme.
Zertifikat + Schlüssel in ein unterstütztes Format umwandeln (z.B. P12)
Der IHS nutzt eine eigene Datenbank, in der mehrere Zertifikate zusammen mit ihren privaten Schlüsseln gespeichert werden. Man kann dort nicht direkt das Zertifikat mit dem privaten Schlüssel setzen, wie man es von anderen Webservern wie z.B. Nginx her kennt. Stattdessen benötigen wir ein Format, welches beides in einer Datei zusammenführt, etwa P12. Mithilfe von OpenSSL kann man Zertifikat + privaten Schlüssel umwandeln:
openssl pkcs12 -export -inkey private.key -in cert.crt -name mein-zertifikat -out openssl-bundle.p12
Der mit -name angegebene Bezeichner wird später im IHS Schlüsselmanager verwendet, um das Zertifikat zuzuordnen. Wichtig: An dieser Stelle unbedingt ein Passwort vergeben! Leere Passwörter (= nur Enter drücken) sind zwar gültig und werden von OpenSSL akzeptiert. Allerdings funktioniert der anschließende Import in den IHS-Store nur, wenn ein Passwort gesetzt wurde.
Ein Zertifikatsbundle (P12) zum IHS Keystore hinzufügen
Um das soeben erstellte P12-Zertifikat in den Keystore des IHS zu importieren, benötigen wir gskcapicmd. Das Werkzeug ist standardmäßig im bin Ordner vorhanden. Bevor wir mit dem Store arbeiten, macht es grundsätzlich Sinn, eine Sicherungskopie von Ihm zu erstellen. In diesem Beispiel heißt er ihs-key. Ich würde daher einen Backup-Ordner anlegen und ihs-key.* dort hin kopieren.
Anschließend das Zertifikatspaket importieren:
/opt/IBM/HTTPServer/bin/gskcapicmd -cert -import -db openssl-bundle.p12 -pw "OpenSSLP12PW" -target ihs-key.kdb -target_pw "KdbPasswort"
-pw gibt das soeben per OpenSSL festgelegte Passwort für die P12-Datei an, -target_pw ist das Passwort vom IHS-Schlüsselspeicher. Man kann beide Parameter auch weglassen, damit die Passwörter nicht in der Bash-History stehen. Das Programm fragt euch dann interaktiv nach den Kennwörtern.
Vorhandene Zertifikate prüfen
Mit dem Parameter -list lässt sich prüfen, ob das neue Zertifikat hinzugefügt wurde. Und noch wichtiger: Welches Zertifikat als Standard gesetzt ist. Man kann in einem Store mehrere Zertifikate hinterlegen, allerdings wird das Standard-Zertifikat verwendet. Wenn das beispielsweise abläuft, macht es Sinn, das neue, hinzugefügte als Standard zu setzen.
/opt/IBM/HTTPServer/bin/gskcapicmd -cert -list -db ihs-key.kdb -pw "KdbPasswort" -expiry 1000
...
- altes_zertifikat
Not Before : August 18, 2016 2:00:00 AM GMT+02:00
Not After : November 17, 2018 12:59:59 AM GMT+01:00
*- aktuelles_zertifikat
Not Before : December 16, 2020 1:00:00 AM GMT+01:00
Not After : January 17, 2022 12:59:59 AM GMT+01:00
- neues_zertifikat
Not Before : December 20, 2021 1:00:00 AM GMT+01:00
Not After : January 19, 2023 12:59:59 AM GMT+01:00
Das derzeitige Standard-Zertifikat lässt sich am * links erkennen, in diesem Beispiel heißt es aktuelles_zertifikat.
Standardzertifikat setzen
Um das Standard-Zertifikat auf das neu hinzugefügte (hier mit der Bezeichnung neues_zertifikat) zu setzen, kann -setdefault genutzt werden:
/opt/IBM/HTTPServer/bin/gskcapicmd -cert -setdefault -db ihs-key.kdb -pw "KdbPasswort" -label "neues_zertifikat"
(Alte), nicht mehr benötigte Zertifikate löschen
Im obigen Beispiel besteht der Store aus drei Zertifikaten. Das oberste ist bereits 2018 abgelaufen und könnte daher bereinigt werden:
/opt/IBM/HTTPServer/bin/gskcapicmd -cert -delete -db ihs-key.kdb -pw "KdbPasswort" -label "altes_zertifikat"
So werden Änderungen im Keystore wirksam
Die Änderungen werden nicht sofort wirksam, sondern man muss den IHS neu starten. Leider blockiert
/opt/IBM/HTTPServer/bin/apachectl -k stop
# Warten, bis der IHS gestoppt wurde.
# Man kann den Befehl zum stoppen mehrfach aufrufen, bis
# "httpd (no pid file) not running" erscheint
/opt/IBM/HTTPServer/bin/apachectl -k start
Wird das neue Zertifikat ausgeliefert?
Abschließend macht es Sinn zu testen, ob das neue Zertifikat auch tatsächlich ausgeliefert wird. Gerade in Unternehmensnetzwerken sitzt ggf. ein Reverse-Proxy davor, wenn das System z.B. nach außen ins Internet erreichbar sein soll und es dafür einen Proxy-Server in der DMZ gibt. Dies kann etwa im Browser getestet werden. Gerade wenn Proxy-Server im Spiel sind, ist OpenSSL hilfreich. So kann man auch (lokale) Server anfragen und damit leichter herausfinden, welcher Server bereits das neue Zertifikat ausliefert und wo noch das alte liegt:
$ echo | openssl s_client -servername localhost -connect localhost:443 | openssl x509 -noout -dates
depth=3 C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services
verify return:1
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 CN = dein-cnx-host.de
verify return:1
DONE
notBefore=Dec 20 00:00:00 2021 GMT
notAfter=Jan 18 23:59:59 2023 GMT
Die Zertifikatskette ist dabei ebenfalls ersichtlich. Falls die nicht korrekt ist, erhaltet ihr Fehler wie „verify error:num=21:unable to verify the first certificate“.