Listener-Zertifikat

Zielgruppe: Betreuer · Stand: 06.11.2026

Der Listener von OpenBao nutzt das Wildcard-Zertifikat *.dexpro.parts. Jeder Knoten holt es selbst und lädt OpenBao neu, sobald ein neues Zertifikat da ist. Der Reload ist allerdings noch nie im Ernstfall gelaufen.

Das aktuelle Zertifikat gilt bis 04.12.2026. Bis dahin müssen Reload-Test und Überwachung erledigt sein.

Wie es funktioniert

1. Das Modul bindet certmanager ein. Jeder Knoten holt das Zertifikat vom SSL-Service nach /var/certmanager/certs/.
2. Ein Timer prüft täglich um 03:00 Uhr. Gilt das Zertifikat weniger als 7 Tage, wird es ersetzt.
3. Eine systemd-Path-Unit (openbao-cert-reload.path) bemerkt die Änderung und lädt OpenBao neu (systemctl reload openbao).

Prüfen

echo | openssl s_client -connect openbao-lab-bre1.dexpro.parts:8200 2>/dev/null | openssl x509 -noout -enddate

Das Ablaufdatum muss auf allen drei Knoten gleich sein und nach dem Erneuern weiter in der Zukunft liegen.

Stolperfallen

• Der Weg „Zertifikat ersetzt → Path-Unit → Reload → neues Zertifikat am Listener“ ist nicht getestet. Offen ist, ob die Path-Unit Schreiben und Umbenennen gleichermaßen erkennt und ob OpenBao das Listener-Zertifikat beim Reload neu lädt.
• Es gibt noch keine Überwachung der Restlaufzeit. Vorgesehen: Warnung bei 21 Tagen, kritisch bei 7 Tagen, je Knoten.
• Die Erneuerung setzt voraus, dass der SSL-Service rechtzeitig ein neues Zertifikat bereithält.
• Das Wildcard deckt nur eine Ebene ab. Namen wie openbao.lab.bre1.dexpro.parts passen nicht.

Weiterführend

• Cluster, Storage und Seal