Gekauftes Zertifikat erneuern

Diese Anleitung beschreibt ausführlich, wie ein neues SSL-Zertifikat einer Zertifizierungsstelle (CA) für den Relution-Server vorbereitet und anschließend in Traefik oder nginx eingebunden wird. Sie richtet sich an Administratoren, die den Vorgang zum ersten Mal oder nur selten durchführen. Eine Übersicht aller Installationsvarianten steht unter SSL-Zertifikat erneuern →.

Am Ende des Vorgangs liegen zwei Dateien vor:

• server.pem – die Zertifikatskette: das Serverzertifikat, gefolgt von den Zwischenzertifikaten der Zertifizierungsstelle.
• server.key – der private Schlüssel, der zum Serverzertifikat gehört.

Die Schritte 1 bis 5 gelten für jede Installation. Schritt 6 verweist auf die Anleitung für den eingesetzten Reverse Proxy, in der das Ablegen der Dateien, der Neustart und die abschließende Prüfung beschrieben sind.

1. Zertifikat in das PEM-Format umwandeln #

Zertifizierungsstellen liefern Zertifikate in unterschiedlichen Formaten aus, häufig mit den Dateiendungen .crt, .cer, .pem, .p7b oder .pfx. Der Reverse Proxy (Traefik oder nginx) erwartet das Zertifikat im PEM-Format, also als Textdatei mit Base64-kodiertem Inhalt.

Ob das Zertifikat bereits im PEM-Format vorliegt, zeigt ein Blick in die Datei, z. B. mit einem Texteditor oder mit folgendem Befehl:

head -1 zertifikat.crt

Lautet die erste Zeile -----BEGIN CERTIFICATE-----, liegt das Zertifikat bereits im PEM-Format vor. Es wird als server-cert.pem gespeichert (z. B. mit cp zertifikat.crt server-cert.pem), danach geht es mit Schritt 2 weiter. Lautet die erste Zeile -----BEGIN PKCS7----- oder zeigt die Datei unlesbare Zeichen, wird sie je nach Format mit OpenSSL umgewandelt:

Beginnt eine P7B-Datei mit -----BEGIN PKCS7-----, liegt sie bereits als Text vor; im Befehl entfällt dann die Option -inform der.

Eine PFX- bzw. P12-Datei enthält neben dem Zertifikat meist auch den privaten Schlüssel und die Zwischenzertifikate. Nach der Umwandlung gemäß Zertifikat in PEM umwandeln → liegen server.pem und server.key bereits vor. Die Schritte 2 und 3 sowie das Zusammenführen in Schritt 4 entfallen; es folgt die Kettenprüfung am Ende von Schritt 4. Fehlen dort Zwischenzertifikate, werden sie wie in Schritt 3 beschrieben bezogen und an server.pem angehängt. Anschließend wird der Schlüssel wie in Schritt 5 geprüft.

Zeilen wie subject=…, issuer=… oder Bag Attributes vor den Zertifikaten stammen aus der Umwandlung mit OpenSSL. Sie stören in der Regel nicht und können in der Datei verbleiben.

2. Aufbau des Serverzertifikats prüfen #

Nach der Umwandlung einer einzelnen Zertifikatsdatei (DER oder PEM) enthält die Datei server-cert.pem genau ein Zertifikat – das Serverzertifikat:

-----BEGIN CERTIFICATE-----
MIIGfjCCBWagAwIBAgIQD7S2kpX0nBq3Wc...
(Serverzertifikat, mehrere Zeilen Base64-kodierter Text)
...7TQxLm1Bxq2fJZ0wS9YQ==
-----END CERTIFICATE-----

Für welchen Servernamen das Zertifikat ausgestellt wurde, von wem und wie lange es gültig ist, zeigt folgender Befehl:

openssl x509 -in server-cert.pem -noout -subject -issuer -enddate
openssl x509 -in server-cert.pem -noout -text | grep -A1 "Subject Alternative Name"

Unter X509v3 Subject Alternative Name muss als DNS:-Eintrag der Hostname der External URL des Relution-Servers stehen. Die Zeile issuer nennt die Zertifizierungsstelle, deren Zwischenzertifikat im nächsten Schritt benötigt wird.

3. Zwischenzertifikate der Zertifizierungsstelle beziehen #

Das Serverzertifikat wird nicht direkt vom Root-Zertifikat der Zertifizierungsstelle signiert, sondern von einem oder mehreren Zwischenzertifikaten (Intermediate-Zertifikate). Damit Geräte und Clients dem Serverzertifikat vertrauen, muss der Reverse Proxy diese Zwischenzertifikate mit ausliefern.

Die Zwischenzertifikate lassen sich auf folgenden Wegen beziehen:

• Lieferung der Zertifizierungsstelle: Häufig liegen sie der Zertifikatslieferung bereits bei, z. B. als intermediate.crt, ca-bundle.crt oder chain.pem.

• Website der Zertifizierungsstelle: Die Zertifizierungsstellen stellen ihre Zwischenzertifikate zum Download bereit. Maßgeblich ist das Zwischenzertifikat, dessen Name mit der Zeile issuer aus Schritt 2 übereinstimmt.

• Verweis im Zertifikat: Die meisten Serverzertifikate enthalten eine Download-Adresse für das ausstellende Zwischenzertifikat (CA Issuers):

  openssl x509 -in server-cert.pem -noout -text | grep "CA Issuers"
  

  Die so heruntergeladene Datei liegt oft im DER-Format vor und wird wie in Schritt 1 beschrieben in PEM umgewandelt.

Das Root-Zertifikat der Zertifizierungsstelle wird nicht benötigt; es ist auf den Geräten bereits vorhanden.

4. Serverzertifikat und Zwischenzertifikate zusammenführen #

Serverzertifikat und Zwischenzertifikate werden zu einer einzigen Datei server.pem zusammengeführt. Die Reihenfolge ist dabei entscheidend: zuerst das Serverzertifikat, danach die Zwischenzertifikate. Bei mehreren Zwischenzertifikaten folgt zuerst dasjenige, welches das Serverzertifikat ausgestellt hat, danach das jeweils übergeordnete.

cat server-cert.pem intermediate.pem > server.pem

Die fertige Datei ist wie folgt aufgebaut:

-----BEGIN CERTIFICATE-----
MIIGfjCCBWagAwIBAgIQD7S2kpX0nBq3Wc...
(Serverzertifikat)
...7TQxLm1Bxq2fJZ0wS9YQ==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEyDCCA7CgAwIBAgIQDPW9BitWAvR6uF...
(Zwischenzertifikat)
...kXmcO7hOt9fyQXaU2Xg2Ug==
-----END CERTIFICATE-----

Die Markierungen -----BEGIN CERTIFICATE----- und -----END CERTIFICATE----- stehen jeweils auf einer eigenen Zeile. Endet eine Ausgangsdatei ohne abschließenden Zeilenumbruch, landen -----END CERTIFICATE----------BEGIN CERTIFICATE----- beim Zusammenführen auf einer Zeile; der Reverse Proxy kann das Zertifikat dann nicht laden. In diesem Fall wird an der Stelle in einem Texteditor ein Zeilenumbruch eingefügt.

Ob die Kette vollständig ist, lässt sich mit folgendem Befehl prüfen. Er gibt alle Zertifikate der Datei der Reihe nach mit Inhaber (subject) und Aussteller (issuer) aus:

openssl crl2pkcs7 -nocrl -certfile server.pem | openssl pkcs7 -print_certs -noout

Der issuer eines Zertifikats entspricht jeweils dem subject des nachfolgenden. Der issuer des letzten Zertifikats ist das Root-Zertifikat der Zertifizierungsstelle. Steht das Root-Zertifikat selbst in der Datei (erkennbar an identischem subject und issuer), wird es nicht benötigt und kann mit seinem Block von -----BEGIN CERTIFICATE----- bis -----END CERTIFICATE----- in einem Texteditor entfernt werden.

5. Privaten Schlüssel prüfen #

Neben server.pem wird der private Schlüssel benötigt, der beim Erstellen der Zertifikatsanforderung (CSR) erzeugt wurde. Wurde das neue Zertifikat mit derselben CSR wie das bisherige ausgestellt, bleibt der bisherige Schlüssel server.key unverändert.

Der private Schlüssel muss im PEM-Format und ohne Passwort vorliegen, da der Reverse Proxy beim Start kein Passwort abfragen kann. Die erste Zeile lautet dann -----BEGIN PRIVATE KEY-----, -----BEGIN RSA PRIVATE KEY----- oder -----BEGIN EC PRIVATE KEY-----. Lautet sie -----BEGIN ENCRYPTED PRIVATE KEY----- oder folgt auf die erste Zeile eine Zeile Proc-Type: 4,ENCRYPTED, ist der Schlüssel mit einem Passwort geschützt. Das Passwort wird dann entfernt (es wird dabei abgefragt):

openssl pkey -in key.pem -out server.key

Ob Zertifikat und Schlüssel zusammengehören, zeigt ein Vergleich der beiden Prüfsummen; sie müssen identisch sein:

openssl x509 -in server.pem -noout -pubkey | openssl sha256
openssl pkey -in server.key -pubout | openssl sha256

6. Zertifikat im Reverse Proxy einbinden #

Mit server.pem und server.key wird das Zertifikat im Reverse Proxy der Installation eingebunden. Vor dem Austausch werden die bisherigen Dateien server.pem und server.key gesichert, damit sie bei Problemen zurückgespielt werden können. Die Anleitungen beschreiben jeweils das Ablegen der Dateien, den Neustart und die abschließende Prüfung:

• Docker mit Traefik: Traefik: Zertifikat erneuern →
• Docker mit nginx: nginx: Zertifikat erneuern →
• Native Installation unter Windows oder Linux: Native Installation: Zertifikat erneuern →