DBALException in PrestaShop: der TLS/SSL-Fehler, der alles lahmlegt

Der Shop komplett offline, ohne dass jemand etwas angefasst hat

Das Szenario irritiert: Sie haben nichts ausgerollt, nichts aktualisiert – und trotzdem zeigt der Shop eine vollflächige Fehlerseite, Frontend wie Backoffice. In den Logs steht eine DBALException der Art:

An exception occurred while establishing a connection to figure out your platform version
SQLSTATE[HY000] [2026] TLS/SSL error: invalid directory

Diese Meldung hat nichts mit einem Fehler in Ihrem Shop zu tun. Sie tritt auf, wenn Ihr Hoster den Datenbankserver auf MariaDB 11.4 oder neuer umstellt.

Was tatsächlich passiert

Zwei Mechanismen greifen ineinander.

Erster Mechanismus: Doctrine fragt die Serverversion ab. PrestaShop 1.7 und 8 nutzen Doctrine DBAL. Beim Aufbau der Verbindung setzt Doctrine eine Abfrage ab, um die Version der Datenbank-Engine zu ermitteln und seine SQL-Grammatik daran anzupassen. Genau diese Vorabfrage scheitert – daher die Formulierung „to figure out your platform version“.

Zweiter Mechanismus: MariaDB 11.4 verschärft die TLS-Prüfung. Ab dieser Version prüft der MariaDB-Client das Serverzertifikat standardmäßig. Auf einem Shared Hosting mit CloudLinux und CageFS liegt jedes Konto in einem eigenen virtuellen Dateisystem, und die Client-Bibliothek findet dort den Speicher mit den Stammzertifikaten des Systems nicht. Sie meldet deshalb invalid directory: Das Zertifikatsverzeichnis fehlt.

Der Code 2026 in der Meldung ist keine Jahreszahl, sondern der MariaDB-Client-Fehlercode für einen fehlgeschlagenen Handshake.

Lösung 1: auf die nativen Treiber umstellen

Das ist der schnellste Weg, und er fasst den Code nicht an.

Öffnen Sie im Panel Ihres Hosters die Auswahl der PHP-Version und der zugehörigen Erweiterungen. Ersetzen Sie:

• pdo_mysql durch nd_pdo_mysql
• mysqli durch nd_mysqli

Die Varianten mit „nd“ (native driver) verwenden die native Implementierung von PHP statt der MariaDB-Client-Bibliothek und sind damit nicht auf den Zertifikatsspeicher des Systems angewiesen.

Leeren Sie anschließend var/cache/prod/ und laden Sie die Seite neu. In der überwiegenden Mehrheit der Fälle ist der Shop sofort wieder da.

Bietet Ihr Hosting keine PHP-Auswahl, bitten Sie den Support um die Umstellung und nennen Sie die exakte Fehlermeldung: Der Fall ist dort bekannt.

Lösung 2: die Doctrine-Konfiguration erzwingen

Haben Sie keinen Zugriff auf die PHP-Erweiterungen, greifen Sie in der Anwendung ein, in app/config/doctrine.yml.

Die Serverversion fest angeben erspart die fehlschlagende Erkennungsabfrage:

doctrine:
    dbal:
        server_version: '11.4'

Die Zertifikatsprüfung abschalten, falls die Verbindung weiterhin abgelehnt wird:

doctrine:
    dbal:
        options:
            1007: false

Der Schlüssel 1007 entspricht der Konstante MYSQLI_OPT_SSL_VERIFY_SERVER_CERT. Setzen Sie ihn nur ein, wenn die Datenbank auf demselben Server oder in einem privaten Netz liegt: Sie schalten damit eine echte Sicherheitsprüfung ab.

Löschen Sie nach jeder Änderung den Inhalt von var/cache/. Symfony hält die kompilierte Konfiguration im Cache, sonst bleibt Ihre Änderung wirkungslos.

Prüfen, ob die Diagnose stimmt

Bestätigen Sie die Spur, bevor Sie irgendetwas umstellen:

mysql --version

Eine Version 11.4 oder höher auf Serverseite bestätigt das Szenario.

php -m | grep -i mysql

Dieser Befehl listet die aktiven Erweiterungen auf und zeigt, welche geladen ist.

Testen Sie zuletzt eine direkte Verbindung mit den Zugangsdaten aus app/config/parameters.php. Klappt die Verbindung auf der Kommandozeile, während PrestaShop scheitert, liegt es tatsächlich an der PHP-Clientschicht und nicht an den Zugangsdaten.

Diese Fehler sollten Sie vermeiden

Installieren Sie PrestaShop nicht neu. Der Fehler kommt aus der Umgebung: Eine Neuinstallation ändert nichts und kostet Sie Ihre Konfiguration.

Ändern Sie nicht die Zugangsdaten. Sie sind gültig. Die Meldung spricht von TLS, nicht von abgelehnter Authentifizierung.

Spielen Sie keine alte Sicherung zurück. Ihr Code hat sich nicht verändert. Eine Rücksicherung kostet Sie die zwischenzeitlich eingegangenen Bestellungen, ohne irgendetwas zu beheben.

Löschen Sie nicht var/cache selbst, sondern nur dessen Inhalt – sonst erzeugen Sie einen zweiten Fehler, der die Diagnose verwischt.

Der nächsten Störung zuvorkommen

Ausfälle dieser Art, ausgelöst durch eine Infrastrukturänderung beim Hoster, häufen sich, während die Serverparks migriert werden. Zwei Gewohnheiten begrenzen den Schaden:

• Die Wartungsmeldungen Ihres Hosters lesen. Migrationen der Datenbank-Engine werden angekündigt, oft mehrere Wochen im Voraus – in einer E-Mail, die niemand öffnet.
• Eine Staging-Umgebung beim selben Hoster betreiben. Sie wird in der Regel vorher oder gleichzeitig migriert und warnt Sie, bevor die Produktion ausfällt.

Für andere Störungen, die einen Shop komplett lahmlegen, beschreibt unsere Checkliste zum Fehler 500 das allgemeine Vorgehen bei der Diagnose.

Shop gerade offline?

Wir diagnostizieren Umgebungsfehler dieser Art in weniger als einer Stunde und klären bei Bedarf direkt mit Ihrem Hoster. Siehe PrestaShop-Notfallhilfe.