DBALException PrestaShop : l'erreur TLS/SSL qui coupe tout

Un site entièrement hors ligne, sans avoir rien touché

Le scénario est déroutant : vous n'avez rien déployé, rien mis à jour, et la boutique affiche une page d'erreur complète, front et back-office compris. Dans les logs, une DBALException PrestaShop du type :

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

Ce message n'a rien à voir avec un bug de votre boutique. Il apparaît quand votre hébergeur migre le serveur de bases de données vers MariaDB 11.4 ou une version plus récente.

Ce qui se passe réellement

Deux mécanismes se combinent.

Premier mécanisme : Doctrine interroge la version du serveur. PrestaShop 1.7 et 8 utilisent Doctrine DBAL. À l'ouverture de la connexion, Doctrine exécute une requête pour déterminer la version du moteur, afin d'adapter sa grammaire SQL. C'est cette requête préliminaire qui échoue, d'où la formulation « to figure out your platform version ».

Second mécanisme : MariaDB 11.4 durcit la vérification TLS. À partir de cette version, le client MariaDB vérifie par défaut le certificat du serveur. Sur un hébergement mutualisé utilisant CloudLinux et CageFS, chaque compte est cloisonné dans un système de fichiers virtuel, et la bibliothèque cliente n'y trouve pas le magasin de certificats racine du système. Elle renvoie donc invalid directory : elle ne trouve pas le répertoire de certificats.

Le code 2026 dans le message n'est pas une année : c'est le code d'erreur client MariaDB pour un échec de handshake.

Correctif 1 : basculer sur les pilotes natifs

C'est le correctif le plus rapide, et il ne touche pas au code.

Dans le panneau de votre hébergeur, ouvrez le sélecteur de version PHP et les extensions associées. Remplacez :

• pdo_mysql par nd_pdo_mysql
• mysqli par nd_mysqli

Les variantes « nd » (native driver) utilisent l'implémentation native de PHP plutôt que la bibliothèque cliente MariaDB, et ne dépendent donc pas du magasin de certificats système.

Videz ensuite var/cache/prod/ et rechargez. Dans l'immense majorité des cas, la boutique revient immédiatement.

Sur un hébergement sans sélecteur PHP, demandez la manipulation au support en citant le message d'erreur exact : c'est un cas connu.

Correctif 2 : forcer la configuration Doctrine

Si vous n'avez pas la main sur les extensions PHP, intervenez côté application dans app/config/doctrine.yml.

Déclarer la version du serveur évite la requête de détection qui échoue :

doctrine:
    dbal:
        server_version: '11.4'

Désactiver la vérification du certificat si la connexion reste refusée :

doctrine:
    dbal:
        options:
            1007: false

La clé 1007 correspond à la constante MYSQLI_OPT_SSL_VERIFY_SERVER_CERT. À n'utiliser que lorsque la base est sur le même serveur ou sur un réseau privé : vous désactivez une vérification de sécurité réelle.

Après chaque modification, supprimez le contenu de var/cache/ : Symfony met en cache la configuration compilée, et votre changement resterait sans effet.

Vérifier que le diagnostic est le bon

Avant d'appliquer quoi que ce soit, confirmez la piste :

mysql --version

Une version 11.4 ou supérieure côté serveur confirme le scénario.

php -m | grep -i mysql

Cette commande liste les extensions actives et permet de vérifier laquelle est chargée.

Testez enfin une connexion directe avec les identifiants de app/config/parameters.php. Si la connexion en ligne de commande fonctionne alors que PrestaShop échoue, c'est bien la couche cliente PHP qui est en cause, et non les identifiants.

Les erreurs à ne pas commettre

Ne réinstallez pas PrestaShop. L'erreur est environnementale : une réinstallation ne change rien et vous fait perdre votre configuration.

Ne changez pas les identifiants de connexion. Ils sont valides. Le message parle de TLS, pas d'authentification refusée.

Ne restaurez pas une sauvegarde ancienne. Votre code n'a pas changé. Restaurer ferait perdre les commandes reçues depuis, sans rien corriger.

Ne supprimez pas var/cache lui-même, seulement son contenu, sous peine de générer une seconde erreur qui brouille le diagnostic.

Anticiper le prochain épisode

Ce type de panne, déclenchée par une évolution d'infrastructure côté hébergeur, se multiplie à mesure que les parcs migrent. Deux réflexes limitent l'impact :

• Lire les notifications de maintenance de votre hébergeur. Les migrations de moteur de base de données sont annoncées, souvent plusieurs semaines à l'avance, dans un e-mail que personne ne lit.
• Disposer d'une préproduction sur le même hébergement. Elle est généralement migrée avant ou en même temps, et vous alerte avant que la production ne tombe.

Pour les autres pannes qui coupent totalement une boutique, notre checklist erreur 500 couvre la méthode générale de diagnostic.

Boutique hors ligne en ce moment ?

Nous diagnostiquons ce type de panne d'environnement en moins d'une heure, et traitons directement avec votre hébergeur si nécessaire. Voir le dépannage PrestaShop.