Hallo! Ich bin Andrei, Gründer von Ænix und Hauptentwickler der Plattform Cozystack. Vor Kurzem hatte ich die Aufgabe, ein veraltetes FreeIPA in einem großen Unternehmen zu aktualisieren. Diese FreeIPA-Instanz war in einem LXC-Container auf CentOS 7 installiert und funktionierte seit mehreren Monaten nicht mehr. Ich bekam ein Backup des LXC-Containers für Proxmox, und so begann die Arbeit.
Der ursprüngliche Plan:
- Das System wieder lauffähig machen.
- Die Zertifikate erneuern.
- Ein Backup erstellen.
- Das Backup auf ein modernes System migrieren, Fedora oder Rocky Linux, da der Support für CentOS ausgelaufen ist.
Doch wie so oft bei solchen Aufgaben lief etwas schief :)
Ein LXC-Container mit veraltetem systemd auf einem aktuellen Proxmox
Da das Image als archivierter LXC-Container vorlag, zeigte sich bei der Wiederherstellung, dass meine Proxmox-Version zu neu war und die systemd-Version des Containers nicht unterstützte. Das Problem: Das neue Proxmox arbeitet mit Cgroups v2, das veraltete systemd im Container unterstützt nur Cgroups v1.
Die erste Hürde war also bereits der Start des LXC-Containers. Zum Glück lief im Container nur systemd nicht (das Init-System, das alles andere startet); über eine gewöhnliche Bash-Shell war er trotzdem erreichbar.
Damit hatten wir Zugriff auf den Container und konnten versuchen, sein Betriebssystem zu aktualisieren. Dabei lässt sich ähnlich vorgehen, wie man es oft mit chroot-Umgebungen tut.
Um in Proxmox in den LXC-Container zu wechseln, genügt folgender Befehl:
pct enter 112
Anders als bei einem normalen chroot ist der Network Namespace in einem LXC-Container jedoch isoliert. Zum Glück hatte Proxmox bereits alle nötigen Interfaces angelegt, und wir mussten sie nur noch konfigurieren.
Netzwerk konfigurieren:
ip addr add 192.168.20.109/16 dev eth0
ip link set eth0 up
ip route add default via 192.168.20.1
Da CentOS sein EOL erreicht hat, sind die offiziellen Repositories unter den gewohnten Adressen nicht mehr verfügbar. Wir ersetzen sie durch die Archivadressen:
sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-*
Jetzt installieren wir ein neues systemd aus den Backports:
curl https://copr.fedorainfracloud.org/coprs/jsynacek/systemd-backports-for-centos-7/repo/epel-7/jsynacek-systemd-backports-for-centos-7-epel-7.repo -o /etc/yum.repos.d/jsynacek-systemd-centos-7.repo
yum update systemd
Im Ergebnis haben wir ein funktionierendes System mit einem aktuellen systemd, das auf dem neuen Proxmox läuft. Allerdings haben wir damit nur den Container gestartet; das eigentliche Problem, mit dem uns der Kunde beauftragt hatte, ist noch ungelöst.
Das Problem mit abgelaufenen Zertifikaten
Bei der Diagnose von FreeIPA sollten Sie als Erstes den Status der Systemzertifikate prüfen. Dazu genügt folgender Befehl:
# getcert list | grep -E "Request ID|status|certificate|expires"
In der Konsole erschien folgende Ausgabe:
Number of certificates and requests being tracked: 7.
Request ID '20180730085204':
status: CA_UNREACHABLE
certificate: type=FILE,location='/var/lib/ipa/ra-agent.pem'
expires: 2024-05-04 13:35:31 UTC
Request ID '20180730085237':
status: CA_UNREACHABLE
certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB'
expires: 2024-05-04 13:36:01 UTC
Request ID '20180730085238':
status: CA_UNREACHABLE
certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB'
expires: 2024-05-04 13:37:01 UTC
Request ID '20180730085239':
status: CA_UNREACHABLE
certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB'
expires: 2024-05-04 13:35:51 UTC
Request ID '20180730085240':
status: CA_UNREACHABLE
certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB'
expires: 2038-07-30 08:51:36 UTC
Request ID '20180730085241':
status: CA_UNREACHABLE
certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB'
expires: 2024-05-04 13:36:31 UTC
Request ID '20180730085358':
status: CA_UNREACHABLE
certificate: type=FILE,location='/va
Die Ausgabe zeigt, dass die meisten Zertifikate abgelaufen sind. Das ist der Hauptgrund, warum viele FreeIPA-Dienste nicht starten. Der Knackpunkt: Wir müssen die Zertifikate erneuern, dafür aber müssen die FreeIPA-Dienste laufen. Diese Dienste starten jedoch nicht, weil die Zertifikate abgelaufen sind und die Kommunikation zwischen ihnen deshalb scheitert.
Die Lösung ist vergleichsweise einfach: Wir ändern die Systemzeit. Da der LXC-Container die Zeit vom Host übernimmt, tun wir das direkt auf dem Hypervisor. Zusätzlich müssen wir den NTP-Dienst (Network Time Protocol) deaktivieren, damit er die Zeit nicht automatisch aus dem Internet synchronisiert und wieder auf die korrekte Zeit zurückstellt.
Deaktivieren Sie zuerst NTP. Stellen Sie dann das Datum auf einen Zeitpunkt vor dem Ablauf der Zertifikate, damit das System sie für noch gültig hält:
timedatectl set-ntp 0
date -s '2024–05–03'
Starten Sie anschließend die Dienste neu:
ipactl restart
Die Dienste sollten jetzt zwar starten, doch die Ausgabe von getcert list zeigt die erneuerten Zertifikate vermutlich nicht sofort an. Mit dem Befehl ipa-getcert resubmit -i und der Request ID aus der Ausgabe von getcert list als Argument können Sie die Erneuerung erzwingen. Prüfen Sie danach den Status erneut:
ipa-getcert resubmit -i 20240227134251
Achten Sie darauf, dass alle Zertifikate in den Zustand MONITORING wechseln. Ist die Erneuerung nicht abgeschlossen, bevor wir die Systemzeit zurückstellen, bleiben viele Dienste funktionsunfähig.
Sobald alle Zertifikate im Zustand MONITORING sind, stellen Sie die Systemzeit wieder auf die aktuelle Zeit, indem Sie NTP erneut aktivieren:
timedatectl set-ntp 1
Sehr gut! Damit sind wir einen weiteren Schritt vorangekommen und haben ein voll funktionsfähiges FreeIPA, wenn auch in einer älteren Version.
Vorbereitung der Migration auf ein neues Betriebssystem und Umstellung des nssdb-Formats
Die meisten FreeIPA-Zertifikate liegen in isolierten nssdb-Datenbanken (NSS Shared DB). Seit CentOS 7 hat nssdb das Datenbankformat vom älteren Format cert8 auf das neue, SQL-basierte Format cert9 umgestellt. CentOS 7 unterstützte das alte Format noch, in neueren Systemen ist diese Unterstützung jedoch entfallen, sodass das alte Datenbankformat dort nicht mehr nutzbar ist.
In meinem Fall nutzten einige Dienste noch das alte Speicherformat. Es ist also gut möglich, dass Sie auf dasselbe Problem stoßen. Hier die Lösung.
Suchen Sie zunächst alle diese Datenbanken (im alten und im neuen Format) im System:
find / -name cert8.db
find / -name cert9.db
- Dateien mit folgenden Namensmustern stehen für das alte Format:
cert8.db,key3.db,secmod.db. - Dateien mit diesen Mustern stehen für das neue SQL-Format:
cert9.db,key4.db,pkcs11.txt.
Prüfen Sie dann die Zertifikate in der Datenbank (ersetzen Sie EXAMPLE-ORG durch Ihre Domain).
Altes Format:
/usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-ORG -L -f /etc/dirsrv/slapd-EXAMPLE-ORG/pwdfile.txt
Neues Format:
/usr/bin/certutil -d sql:/etc/dirsrv/slapd-EXAMPLE-ORG -L -f /etc/dirsrv/slapd-EXAMPLE-ORG/pwdfile.txt
Liefert die Datenbank im neuen Format eine leere Liste, müssen Sie die Datenbank in das neue Format konvertieren. Das geht mit folgendem Befehl:
certutil -W -d sql:/etc/pki/pki-tomcat/alias -f /etc/pki/pki-tomcat/alias/pwdfile.txt -@ /etc/pki/pki-tomcat/alias/pwdfile.txt
Wichtiger Hinweis: In diesem Stadium unterstützen möglicherweise noch nicht alle Dienste das neue Format. Auf einer neuen Maschine mit einem neueren Betriebssystem sind die Komponenten aber voraussichtlich aktualisiert und verwenden das neue Format standardmäßig.
Stellen Sie vor Beginn der Migration sicher, dass alle Zertifikate aus der Datenbank im alten Format in die Datenbank im neuen Format übernommen wurden. Andernfalls kommt es auf dem neuen System wahrscheinlich zu Fehlern wie diesem:
NSS is built without support of the legacy database(DBM) directory ‘/etc/ipa/nssdb’.
Migration auf ein neues Betriebssystem
Bringen Sie vor der Migration das System und alle Pakete auf den neuesten Stand:
yum update
Damit sind wir offenbar bereit für die Migration nach Rocky Linux 8.
Erstellen Sie auf dem alten CentOS-7-System ein Backup:
ipa-backup
Kopieren Sie das Backup auf das Rocky-Linux-System. Prüfen Sie dort, ob in /etc/hosts der richtige FQDN und die richtige IP-Adresse eingetragen sind.
Starten Sie dann die Wiederherstellung der Daten aus dem Backup:
ipa-restore -v /var/lib/ipa/backup/ipa-full-2024–07–03–23–24–04/
Wegen der unterschiedlichen Formate in den Betriebssystemversionen stoßen wir auf eine fehlende Datei /var/lib/ipa/auth_backup/authselect.backup. Sie lässt sich erzeugen, indem Sie während des Vorgangs folgenden Befehl ausführen (er speichert die Einstellungen des aktuellen authselect-Profils in einer Datei):
authselect current — raw > /var/lib/ipa/auth_backup/authselect.backup
Danach bricht die Wiederherstellung in der Upgrade-Phase von FreeIPA ab, nachdem folgender Befehl ausgeführt wurde:
ipa-server-upgrade
In den Logs stellen Sie dann womöglich fest, dass [email protected] nicht startet, also der Dienst, der den CA-Listener von FreeIPA startet, der für die Ausstellung von Zertifikaten zuständig ist.
Die Logs prüfen Sie mit:
journalctl -u [email protected]
In manchen Fällen lohnt sich ein Blick in das Debug-Log der CA:
tail -f /var/log/pki/pki-tomcat/ca/debug
Bei genauer Durchsicht der Logs finden Sie möglicherweise Fehler beim Dateizugriff in /etc/sysconfig/pki-tomcat. Offenbar hat die Logik der Backup-Wiederherstellung hier nicht korrekt gearbeitet, also korrigieren wir das von Hand:
sudo chown pkiuser:pkiuser /etc/sysconfig/pki-tomcat
sudo chown -R pkiuser:pkiuser /etc/pki/pki-tomcat/alias/
Außerdem empfiehlt es sich, SELinux während der Wiederherstellung vorübergehend zu deaktivieren.
Ein weiteres Problem: Rocky Linux 8 bringt eine neuere Tomcat-Version mit als CentOS 7, und das Konfigurationsformat hat sich erheblich geändert. Die aus dem Backup wiederhergestellte alte Datei /etc/pki/pki-tomcat/server.xml ist mit dem aktualisierten Tomcat nicht kompatibel.
Eine neue, korrekt formatierte Datei erhalten Sie, indem Sie FreeIPA mit denselben Parametern initialisieren:
ipa-server-install
Tun Sie das auf einer separaten VM und kopieren Sie die erzeugte server.xml anschließend auf die VM, auf der Sie das Backup wiederherstellen.
Sind die manuellen Anpassungen erledigt, starten Sie das Upgrade erneut:
ipa-server-upgrade -v
Geschafft: FreeIPA ist erfolgreich wiederhergestellt und auf die neueste Version aktualisiert.
Zertifikate auf dem neuen Server prüfen
Prüfen Sie die Zertifikate, indem Sie den Befehl auf der neuen Maschine noch einmal ausführen:
getcert list | grep -E “Request ID|status|certificate|expires”
Einige davon hängen im Zustand NEWLY_ADDED_NEED_KEYINFO_READ_PIN fest. Das bedeutet, dass die Zertifikate gerade erst hinzugefügt wurden und eine PIN benötigen. Ein seltsames Verhalten, wie ich finde, aber gut: Wir verbuchen es unter den Unzulänglichkeiten des Wiederherstellungsskripts.
Die benötigte PIN können Sie mit folgendem Befehl angeben:
ipa-getcert start-tracking -i 20240703234954 -P “$(cat /etc/pki/pki-tomcat/alias/pwdfile.txt)”
20240703234954 ist die Request ID aus der Ausgabe des zuvor ausgeführten Befehls getcert list. Achten Sie genau auf den Speicherort des Zertifikats und geben Sie die richtige Passwortdatei aus demselben Speicher an.
Stellen Sie sicher, dass alle Zertifikate in den Zustand MONITORING wechseln. Sehen Sie Status wie CA_UNREACHABLE, müssen Sie herausfinden, warum der CA-Listener nicht funktioniert. Prüfen Sie dazu die Logs:
journalctl -u pki-tomcatd@pki-tomcat.service.d
tail -f /var/log/pki/pki-tomcat/ca/debug
Fazit
Wenn Sie Probleme mit Zertifikaten haben, führt der Weg zur Lösung fast immer über die in diesem Artikel beschriebenen Schritte.
Allgemeiner Handlungsplan:
- Prüfen Sie Tomcat und den CA-Dienst, den Tomcat startet.
- Prüfen Sie den Status der Zertifikatsanfragen mit getcert list.
- Fordern Sie die Zertifikate mit ipa-getcert resubmit oder start-tracking neu an.
Weitere Empfehlungen
Der Betrieb von FreeIPA hängt von den Zertifikaten ab, die getcert list aufführt. Im Normalfall sollte dieser Befehl alle Zertifikate im Zustand MONITORING zurückgeben. Wenn etwas schiefgeht, helfen die Tipps aus diesem Artikel. Meistens liegt das Problem beim CA-Dienst, der diese Zertifikate signiert.
Einige meiner unformatierten Notizen finden Sie in diesem Gist.
Und noch ein wichtiger Punkt: Richten Sie unbedingt ein Monitoring ein, das die Ausgabe dieses Befehls überwacht.
Von Timur Tukaev am 1. August 2024.
Exportiert von Medium am 11. Mai 2026.
Testen Sie Ihr Wissen: FreeIPA wiederherstellen und migrieren
5 questions · ~2 min
