DBALException in PrestaShop: the TLS/SSL error that takes everything down

A site entirely offline, without anyone touching it

The scenario is disorientating: you have deployed nothing, updated nothing, and the store is showing a full error page, front office and back office alike. In the logs, a PrestaShop DBALException along these lines:

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

This message has nothing to do with a bug in your store. It shows up when your host migrates the database server to MariaDB 11.4 or later.

What is actually happening

Two mechanisms combine.

First mechanism: Doctrine asks the server for its version. PrestaShop 1.7 and 8 use Doctrine DBAL. As the connection opens, Doctrine runs a query to determine the engine version so it can adapt its SQL grammar. It is that preliminary query which fails, hence the wording "to figure out your platform version".

Second mechanism: MariaDB 11.4 tightens TLS verification. From that version onwards, the MariaDB client verifies the server certificate by default. On shared hosting running CloudLinux and CageFS, each account is confined to a virtual file system, and the client library cannot find the system's root certificate store there. So it returns invalid directory: it cannot find the certificate directory.

The 2026 in the message is not a year: it is the MariaDB client error code for a failed handshake.

Fix 1: switch to the native drivers

This is the fastest fix, and it touches no code.

In your host's control panel, open the PHP version selector and the associated extensions. Replace:

• pdo_mysql with nd_pdo_mysql
• mysqli with nd_mysqli

The "nd" (native driver) variants use PHP's own implementation rather than the MariaDB client library, so they do not depend on the system certificate store.

Then empty var/cache/prod/ and reload. In the vast majority of cases, the store comes straight back.

On hosting with no PHP selector, ask support to make the change and quote the exact error message: it is a known case.

Fix 2: force the Doctrine configuration

If you have no control over the PHP extensions, work at application level in app/config/doctrine.yml.

Declaring the server version avoids the detection query that fails:

doctrine:
    dbal:
        server_version: '11.4'

Disabling certificate verification if the connection is still refused:

doctrine:
    dbal:
        options:
            1007: false

The 1007 key maps to the MYSQLI_OPT_SSL_VERIFY_SERVER_CERT constant. Use it only when the database sits on the same server or on a private network: you are switching off a genuine security check.

After each change, delete the contents of var/cache/: Symfony caches the compiled configuration, and your change would otherwise have no effect.

Confirming the diagnosis

Before applying anything, confirm you are on the right track:

mysql --version

Version 11.4 or above on the server side confirms the scenario.

php -m | grep -i mysql

This command lists the active extensions and shows which one is loaded.

Finally, test a direct connection with the credentials from app/config/parameters.php. If the command-line connection works while PrestaShop fails, the PHP client layer is to blame, not the credentials.

Mistakes to avoid

Do not reinstall PrestaShop. The error is environmental: reinstalling changes nothing and loses your configuration.

Do not change the connection credentials. They are valid. The message is about TLS, not a rejected login.

Do not restore an old backup. Your code has not changed. Restoring would lose every order taken since, and fix nothing.

Do not delete var/cache itself, only its contents, or you will generate a second error that muddies the diagnosis.

Getting ahead of the next episode

This kind of outage, triggered by an infrastructure change on the host's side, is becoming more common as server estates migrate. Two habits limit the damage:

• Read your host's maintenance notices. Database engine migrations are announced, often weeks in advance, in an email nobody reads.
• Keep a staging environment on the same hosting. It is usually migrated first or at the same time, and warns you before production goes down.

For the other faults that take a store down completely, our 500 error checklist covers the general diagnostic method.

Store offline right now?

We diagnose this kind of environment failure in under an hour, and deal directly with your host where necessary. See PrestaShop emergency support.