DBALException in PrestaShop: de TLS/SSL-fout die alles platlegt

De hele site offline, terwijl u niets hebt aangeraakt

Het scenario is verwarrend: u hebt niets uitgerold, niets bijgewerkt, en toch toont de webshop een volledige foutpagina, front- en back-office. In de logs staat een DBALException van PrestaShop, in deze trant:

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

Deze melding heeft niets met een bug in uw webshop te maken. Ze verschijnt wanneer uw hostingpartij de databaseserver naar MariaDB 11.4 of hoger migreert.

Wat er werkelijk gebeurt

Twee mechanismen komen samen.

Eerste mechanisme: Doctrine vraagt de serverversie op. PrestaShop 1.7 en 8 gebruiken Doctrine DBAL. Bij het openen van de verbinding voert Doctrine een query uit om de versie van de engine te bepalen en zijn SQL-grammatica daarop af te stemmen. Precies die voorbereidende query mislukt, vandaar de formulering "to figure out your platform version".

Tweede mechanisme: MariaDB 11.4 scherpt de TLS-controle aan. Vanaf die versie controleert de MariaDB-client standaard het servercertificaat. Op gedeelde hosting met CloudLinux en CageFS zit elk account in een eigen virtueel bestandssysteem, waarin de clientbibliotheek de rootcertificaten van het systeem niet aantreft. Ze meldt dan invalid directory: de certificatenmap is niet gevonden.

De code 2026 in de melding is geen jaartal, maar de foutcode van de MariaDB-client voor een mislukte handshake.

Oplossing 1: overstappen op de native drivers

Dit is de snelste oplossing, en er komt geen code aan te pas.

Open in het beheerpaneel van uw hostingpartij de PHP-versiekiezer met de bijbehorende extensies. Vervang:

• pdo_mysql door nd_pdo_mysql
• mysqli door nd_mysqli

De "nd"-varianten (native driver) gebruiken de eigen implementatie van PHP in plaats van de MariaDB-clientbibliotheek en zijn dus niet afhankelijk van de certificatenopslag van het systeem.

Leeg daarna var/cache/prod/ en herlaad de site. In de overgrote meerderheid van de gevallen is de webshop meteen terug.

Heeft uw hosting geen PHP-keuzescherm, vraag de wijziging dan aan bij de support en noem de exacte foutmelding: dit is een bekend geval.

Oplossing 2: de Doctrine-configuratie afdwingen

Hebt u geen toegang tot de PHP-extensies, grijp dan in aan de applicatiekant, in app/config/doctrine.yml.

De serverversie vastleggen voorkomt de detectiequery die mislukt:

doctrine:
    dbal:
        server_version: '11.4'

De certificaatcontrole uitzetten als de verbinding geweigerd blijft:

doctrine:
    dbal:
        options:
            1007: false

De sleutel 1007 komt overeen met de constante MYSQLI_OPT_SSL_VERIFY_SERVER_CERT. Gebruik dit alleen wanneer de database op dezelfde server of in een privénetwerk staat: u schakelt een echte beveiligingscontrole uit.

Verwijder na elke wijziging de inhoud van var/cache/: Symfony bewaart de gecompileerde configuratie in de cache, waardoor uw aanpassing anders geen effect heeft.

Controleren of de diagnose klopt

Bevestig het spoor voordat u iets doorvoert:

mysql --version

Versie 11.4 of hoger aan de serverkant bevestigt het scenario.

php -m | grep -i mysql

Dit commando toont de actieve extensies, zodat u ziet welke er geladen is.

Test tot slot een rechtstreekse verbinding met de gegevens uit app/config/parameters.php. Werkt de verbinding via de commandoregel wel terwijl PrestaShop faalt, dan ligt het aan de PHP-clientlaag en niet aan de inloggegevens.

Wat u vooral niet moet doen

Installeer PrestaShop niet opnieuw. De fout zit in de omgeving: opnieuw installeren verandert niets en u raakt uw configuratie kwijt.

Wijzig de verbindingsgegevens niet. Die zijn geldig. De melding gaat over TLS, niet over een geweigerde authenticatie.

Zet geen oude back-up terug. Uw code is niet veranderd. Terugzetten kost u de bestellingen van sindsdien en lost niets op.

Verwijder var/cache niet zelf, alleen de inhoud ervan, anders veroorzaakt u een tweede fout die de diagnose vertroebelt.

De volgende keer voor zijn

Dit soort storingen, veroorzaakt door een infrastructuurwijziging bij de hostingpartij, komt steeds vaker voor naarmate meer serverparken worden gemigreerd. Twee gewoonten beperken de schade:

• Lees de onderhoudsmeldingen van uw hostingpartij. Migraties van de databaseserver worden aangekondigd, vaak weken van tevoren, in een e-mail die niemand leest.
• Houd een acceptatieomgeving aan bij dezelfde hostingpartij. Die wordt meestal eerder of tegelijk gemigreerd en waarschuwt u voordat de productieomgeving eruit ligt.

Voor andere storingen die een webshop volledig platleggen, beschrijft onze checklist voor de 500-fout de algemene diagnosemethode.

Ligt uw webshop er nu uit?

Wij stellen dit soort omgevingsstoringen binnen een uur vast en schakelen zo nodig rechtstreeks met uw hostingpartij. Zie PrestaShop-noodhulp.