Drei Major-Versionen in einer Nacht: Passbolt von 4.11 auf 5.11 und Debian 11 auf 13.

Manchmal beginnen Projekte mit einer kleinen Warnung. In diesem Fall war es eine Zeile beim SSH-Login auf den Passbolt-Server eines Kunden:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.

Was als Frage nach dieser Warnung begann, wuchs schnell zu einem Bild, das viele kennen werden: Ein Server, der seit Jahren zuverlässig läuft, aber den die Zeit überholt hat.

Die Ausgangslage #

Der Kunde betreibt seinen Passwortmanager als zentrales Werkzeug für ein kleines Team. Alles funktionierte – nur eben auf einem Stack, der gleich an mehreren Stellen am Ende seiner Lebenszeit angekommen war:

• Debian 11 (Bullseye) – kurz vor dem LTS-Ende
• PHP 7.4 – seit 2022 ohne Sicherheitsupdates
• MariaDB 10.5 – EOL seit Mitte 2025
• Passbolt CE 4.11.1 – Stand mitten in der 4er-Reihe, während die 5er-Reihe längst Standard war
• OpenSSH 8.4 – ohne jegliche Post-Quantum-Unterstützung

Ein klassischer Fall von „läuft ja". Bis es eines Tages eben nicht mehr läuft – oder bis ein Auditor vorbeischaut.

Die Strategie: Kleine Schritte statt Big Bang #

Es gab drei realistische Wege: Neuaufbau auf frischer VM, alles auf einmal upgraden, oder schrittweise vorgehen. Ich entschied mich für den schrittweisen Weg – mit klaren Zwischenständen, die jederzeit testbar bleiben:

1. Backup und Snapshot – DB-Dump, GPG- und JWT-Keys, KVM-Snapshot. Der wichtigste Teil eigentlich.
2. Passbolt 4.11 → 4.12 – letzte 4er-Version, noch auf PHP 7.4
3. Debian 11 → 12 (Bookworm) – bringt PHP 8.2 und MariaDB 10.11
4. Passbolt 4.12 → 5.11 – Major-Sprung mit Encrypted Metadata, jetzt mit passendem PHP
5. Debian 12 → 13 (Trixie) – PHP 8.4, OpenSSH 9.9 mit ML-KEM by default

Klingt nach vielen Schritten. Genau das war der Punkt: Jeder Schritt für sich überschaubar, jederzeit prüfbar – und wenn etwas schiefläuft, weiß man genau, in welcher Phase.

Stolperfallen, die man kennt – und die, die man nicht erwartet #

Die Klassiker waren da: ein leerer Datenbank-Dump, weil die Passbolt-DB nicht wie der User hieß. Eine .bak-Datei in /etc/nginx/sites-enabled/, die nginx als zweite Config las und ein „duplicate listen options" warf. Der PHP-FPM-Socket-Pfad, der nach jedem PHP-Sprung in der nginx-Config neu zu setzen war – einmal nach 7.4→8.2, einmal nach 8.2→8.4.

Spannender waren die unerwarteten Sachen:

• Das Zabbix-Repository des Kunden nutzte einen SHA1-signierten Key – seit Februar 2026 verweigert Trixies neues apt/sqv solche Keys grundsätzlich. Zabbix 6.4 war ohnehin EOL, also pragmatisch deaktiviert.
• Der Passbolt-Repo-Key lag im legacy trusted.gpg-Keyring, den Trixie nicht mehr akzeptiert. Lösung: Key neu holen, in /etc/apt/keyrings/ ablegen, in der Sources-Liste mit signed-by= explizit verweisen.
• Die Hetzner-Mirror-Listen mussten bei jedem Distro-Sprung manuell mitgezogen werden – deb.debian.org hat man im Blick, die zusätzlichen Quellen vergisst man leicht.

Das Ergebnis #

Login funktioniert, Passwörter lassen sich entschlüsseln, der Server-GPG-Key hat alle Sprünge überlebt. Und beim nächsten SSH-Login war die Post-Quantum-Warnung weg – der Anlass, der das Projekt ins Rollen gebracht hat.

Die Erkenntnisse #

Schrittweise statt heroisch. Drei Major-Sprünge in einer Nacht sind machbar – aber nur, wenn jeder einzelne Schritt eigenständig validiert wird. Big-Bang-Migrationen scheitern nicht an den großen Dingen, sondern an der einen Kleinigkeit, die im Rauschen untergeht.

Wer alte Server hat, hat alte Repositories. Ein Distro-Upgrade ist auch immer ein Upgrade aller Drittanbieter-Quellen, ihrer GPG-Keys und ihrer Konventionen. Diese Nebenkriegsschauplätze kosten oft mehr Zeit als das eigentliche apt full-upgrade.