DBALException en PrestaShop: el error TLS/SSL que lo tumba todo

Una tienda entera fuera de línea sin haber tocado nada

El escenario desconcierta: usted no ha desplegado nada, no ha actualizado nada, y la tienda muestra una página de error completa, front-office y back-office incluidos. En los logs aparece una DBALException del estilo:

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

Este mensaje no tiene nada que ver con un fallo de su tienda. Aparece cuando su proveedor de alojamiento migra el servidor de bases de datos a MariaDB 11.4 o a una versión posterior.

Qué ocurre en realidad

Se combinan dos mecanismos.

Primer mecanismo: Doctrine pregunta por la versión del servidor. PrestaShop 1.7 y 8 usan Doctrine DBAL. Al abrir la conexión, Doctrine lanza una consulta para determinar la versión del motor y adaptar así su gramática SQL. Es esa consulta previa la que falla, de ahí la expresión «to figure out your platform version».

Segundo mecanismo: MariaDB 11.4 endurece la verificación TLS. A partir de esa versión, el cliente de MariaDB verifica por defecto el certificado del servidor. En un alojamiento compartido que usa CloudLinux y CageFS, cada cuenta queda aislada en un sistema de archivos virtual y la biblioteca cliente no encuentra allí el almacén de certificados raíz del sistema. Devuelve entonces invalid directory: no encuentra el directorio de certificados.

El código 2026 del mensaje no es un año: es el código de error del cliente MariaDB para un handshake fallido.

Solución 1: cambiar a los controladores nativos

Es la solución más rápida y no toca el código.

En el panel de su proveedor, abra el selector de versión de PHP y sus extensiones. Sustituya:

• pdo_mysql por nd_pdo_mysql
• mysqli por nd_mysqli

Las variantes «nd» (native driver) usan la implementación nativa de PHP en lugar de la biblioteca cliente de MariaDB, así que no dependen del almacén de certificados del sistema.

Vacíe después var/cache/prod/ y recargue. En la inmensa mayoría de los casos, la tienda vuelve al instante.

En un alojamiento sin selector de PHP, pida el cambio al soporte citando el mensaje de error exacto: es un caso conocido.

Solución 2: forzar la configuración de Doctrine

Si no tiene control sobre las extensiones de PHP, actúe desde la aplicación, en app/config/doctrine.yml.

Declarar la versión del servidor evita la consulta de detección que falla:

doctrine:
    dbal:
        server_version: '11.4'

Desactivar la verificación del certificado si la conexión sigue rechazándose:

doctrine:
    dbal:
        options:
            1007: false

La clave 1007 corresponde a la constante MYSQLI_OPT_SSL_VERIFY_SERVER_CERT. Úsela solo cuando la base de datos esté en el mismo servidor o en una red privada: está desactivando una verificación de seguridad real.

Después de cada cambio, borre el contenido de var/cache/: Symfony guarda en caché la configuración compilada y su modificación no surtiría ningún efecto.

Confirmar que el diagnóstico es correcto

Antes de aplicar nada, confirme la hipótesis:

mysql --version

Una versión 11.4 o superior en el servidor confirma el escenario.

php -m | grep -i mysql

Este comando lista las extensiones activas y permite ver cuál está cargada.

Pruebe por último una conexión directa con las credenciales de app/config/parameters.php. Si la conexión por línea de comandos funciona mientras PrestaShop falla, el problema está en la capa cliente de PHP y no en las credenciales.

Los errores que no debe cometer

No reinstale PrestaShop. El fallo es del entorno: reinstalar no cambia nada y le hace perder su configuración.

No cambie las credenciales de conexión. Son válidas. El mensaje habla de TLS, no de autenticación rechazada.

No restaure una copia de seguridad antigua. Su código no ha cambiado. Restaurar le haría perder los pedidos recibidos desde entonces sin corregir nada.

No borre var/cache en sí, solo su contenido, o generará un segundo error que enturbiará el diagnóstico.

Anticipar el próximo episodio

Este tipo de avería, provocada por un cambio de infraestructura del proveedor, se multiplica a medida que los parques se van migrando. Dos reflejos limitan el impacto:

• Leer los avisos de mantenimiento de su proveedor. Las migraciones del motor de base de datos se anuncian, a menudo con semanas de antelación, en un correo que nadie lee.
• Tener una preproducción en el mismo alojamiento. Suele migrarse antes o a la vez, y le avisa antes de que caiga la producción.

Para las demás averías que dejan una tienda completamente parada, nuestra checklist del error 500 recoge el método general de diagnóstico.

¿Tienda fuera de línea ahora mismo?

Diagnosticamos este tipo de avería de entorno en menos de una hora y hablamos directamente con su proveedor de alojamiento si hace falta. Consulte el soporte urgente de PrestaShop.