Linux-Dienst: TLS-Zertifikat austauschen

Diese Anleitung gilt für jeden Linux-Dienst, der Zertifikats- und Schlüsseldateien liest - einen Mailserver, einen Verzeichnisdienst, eine Java-Anwendung oder Ihren eigenen Daemon. Die Dokumentation des Dienstes bestimmt Format, Pfade, wer den Schlüssel lesen können muss und ob ein Reload das Zertifikat neu einliest. Die Schritte unten sind der sichere Rahmen darum.

VoraussetzungenCopy Anchor Link

• Ermitteln Sie den Prozess, seine systemd-Unit, die Konfigurationsdirektiven für Zertifikat und Schlüssel und das Konto, unter dem er läuft (systemctl show -p User <unit> oder ps -o user= -p <pid>).
• Prüfen Sie, ob er in einem chroot oder Container läuft, wo die Pfade anders sind als auf dem Host.
• Notieren Sie aktuelle Pfade, Besitzer, Rechte und Symlink-Ziele (ls -lL) und behalten Sie die aktuellen Dateien: Die Schritte unten legen die neuen in ein neues Verzeichnis.

Zertifikat Schritt für Schritt austauschenCopy Anchor Link

1. Format ermitteln in der Dokumentation des Dienstes und bei Bedarf umwandeln:

   Der Dienst erwartet	So erzeugen Sie es
   Getrennte Dateien für Zertifikat, Kette und Schlüssel (PEM)	Dateien so verwenden, wie sie geliefert wurden
   Vollständige Kette (Serverzertifikat zuerst) und Schlüssel	cat leaf.pem intermediates.pem > fullchain.pem
   Eine Datei mit Kette und Schlüssel	cat leaf.pem intermediates.pem private.key > bundle.pem
   PKCS#12	openssl pkcs12 -export -in leaf.pem -certfile intermediates.pem -inkey private.key -out cert.p12
   Java-Keystore	keytool -importkeystore -srckeystore cert.p12 -srcstoretype PKCS12 -destkeystore keystore.jks

2. Prüfen Sie Namen, Daten, Kette und Schlüssel:

   Copy Text

   openssl x509 -in leaf.pem -noout -subject -enddate -ext subjectAltName
   openssl verify -untrusted intermediates.pem leaf.pem
   openssl pkey -in private.key -pubout | sha256sum
   openssl x509 -in leaf.pem -noout -pubkey | sha256sum

   openssl verify muss OK ausgeben; die beiden Hashes müssen gleich sein.

3. Mit den richtigen Rechten installieren, in ein neues Verzeichnis:

   Copy Text

   install -d -m 0750 -g <dienst-gruppe> /etc/myservice/tls/2026
   install -m 0644 fullchain.pem /etc/myservice/tls/2026/fullchain.pem
   install -m 0640 -g <dienst-gruppe> private.key /etc/myservice/tls/2026/private.key
   restorecon -Rv /etc/myservice/tls/2026   # nur SELinux-Systeme

   Liest der Dienst den Schlüssel als root, bevor er seine Rechte abgibt, genügt 0600 root:root. Liest er ihn mit seinem eigenen Konto, braucht dieses Konto (oder seine Gruppe) Lesezugriff - wie oben. Machen Sie einen privaten Schlüssel nie für alle lesbar.

4. Umschalten des Symlinks, auf den die Konfiguration zeigt, und die Konfiguration mit der eigenen Prüfung des Dienstes testen, falls es eine gibt (etwa postfix check, nginx -t):

   Copy Text

   ln -sfn /etc/myservice/tls/2026 /etc/myservice/tls/current

   Der laufende Prozess merkt vom Umschalten nichts, bis er neu lädt; ein Test nach dem Umschalten ist also gefahrlos. Scheitert der Test, stellen Sie den Symlink zurück.

5. Aktivieren: systemctl reload <unit>, wenn der Dienst sein Zertifikat beim Reload neu einliest (das sagt seine Dokumentation), sonst systemctl restart <unit>. Bei mehreren Knoten einen nach dem anderen, und jeden prüfen, bevor der nächste dran ist.

Neues Zertifikat prüfenCopy Anchor Link

Prüfen Sie das ausgelieferte Zertifikat mit einem Client, der das Protokoll spricht:

openssl s_client -connect service.example.com:443 -servername service.example.com </dev/null   # HTTPS / TLS
openssl s_client -connect mail.example.com:25  -starttls smtp </dev/null   # SMTP STARTTLS
openssl s_client -connect mail.example.com:143 -starttls imap </dev/null   # IMAP STARTTLS
openssl s_client -connect ldap.example.com:389 -starttls ldap </dev/null   # LDAP StartTLS

Prüfen Sie Antragsteller und SAN, Aussteller, Ablaufdatum und Kette, auf jedem Knoten direkt und über die öffentliche Adresse. Prüfen Sie auch das Log des Dienstes auf TLS-Fehler.

RollbackCopy Anchor Link

Symlink auf das vorherige Verzeichnis zurückstellen, testen und auf dieselbe Weise neu laden oder neu starten. Behalten Sie das alte Verzeichnis, bis das neue Zertifikat geprüft ist.

Häufige ProblemeCopy Anchor Link

• Der Dienst erwartet ein anderes Format oder eine andere Reihenfolge der Kette.
• Die Datei stimmt auf dem Host, ist aber in einem chroot oder Container nicht sichtbar.
• Besitzer, Rechte, ACL oder SELinux-Label hindern den Dienst am Lesen des Schlüssels.
• Ein Reload lässt diesen Dienst sein Zertifikat nicht neu einlesen - starten Sie ihn neu.
• Der Dienst löst den Symlink nur beim Start auf und behält bis zu einem Neustart das alte Ziel.

Zertifikatstausch mit aethercert automatisierenCopy Anchor Link

Das aethercert-Deployment-Ziel „Custom Linux“ schreibt Zertifikat, Kette und Schlüssel an die konfigurierten Pfade und kann einen von der Administration vorgegebenen Reload-Befehl ausführen. Befehl und Pfade müssen zum dokumentierten Verhalten des Dienstes passen.

Unter Deployment-Ziele finden Sie die Felder dieser Vorlage, die Voraussetzungen auf dem Host und den Stand der Verifizierung.

QuellenCopy Anchor Link

• OpenSSL: s_client
• OpenSSL: verify
• systemd: systemctl