DBALException no PrestaShop: o erro TLS/SSL que deita tudo abaixo

Um site totalmente offline sem ter mexido em nada

O cenário é desconcertante: não implementou nada, não atualizou nada e a loja mostra uma página de erro completa, front e back-office incluídos. Nos registos, uma DBALException do PrestaShop do género:

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

Esta mensagem não tem nada a ver com um bug da sua loja. Aparece quando o seu alojamento migra o servidor de bases de dados para o MariaDB 11.4 ou para uma versão mais recente.

O que se passa na realidade

Combinam-se dois mecanismos.

Primeiro mecanismo: o Doctrine consulta a versão do servidor. O PrestaShop 1.7 e o 8 usam o Doctrine DBAL. Ao abrir a ligação, o Doctrine executa uma consulta para determinar a versão do motor e adaptar a sua gramática SQL. É essa consulta preliminar que falha, daí a formulação «to figure out your platform version».

Segundo mecanismo: o MariaDB 11.4 aperta a verificação TLS. A partir desta versão, o cliente MariaDB verifica por predefinição o certificado do servidor. Num alojamento partilhado com CloudLinux e CageFS, cada conta está isolada num sistema de ficheiros virtual e a biblioteca cliente não encontra lá o repositório de certificados raiz do sistema. Devolve então invalid directory: não encontra a diretoria dos certificados.

O código 2026 na mensagem não é um ano: é o código de erro do cliente MariaDB para uma falha de handshake.

Correção 1: passar para os controladores nativos

É a correção mais rápida e não mexe no código.

No painel do seu alojamento, abra o seletor de versão de PHP e as extensões associadas. Substitua:

• pdo_mysql por nd_pdo_mysql
• mysqli por nd_mysqli

As variantes «nd» (native driver) usam a implementação nativa do PHP em vez da biblioteca cliente do MariaDB e, por isso, não dependem do repositório de certificados do sistema.

A seguir, esvazie var/cache/prod/ e recarregue a página. Na esmagadora maioria dos casos, a loja volta de imediato.

Num alojamento sem seletor de PHP, peça a alteração ao suporte, citando a mensagem de erro exata: é um caso conhecido.

Correção 2: forçar a configuração do Doctrine

Se não tem acesso às extensões de PHP, atue do lado da aplicação, em app/config/doctrine.yml.

Declarar a versão do servidor evita a consulta de deteção que falha:

doctrine:
    dbal:
        server_version: '11.4'

Desativar a verificação do certificado, se a ligação continuar a ser recusada:

doctrine:
    dbal:
        options:
            1007: false

A chave 1007 corresponde à constante MYSQLI_OPT_SSL_VERIFY_SERVER_CERT. Use-a apenas quando a base de dados está no mesmo servidor ou numa rede privada: está a desativar uma verificação de segurança real.

Depois de cada alteração, apague o conteúdo de var/cache/: o Symfony guarda em cache a configuração compilada e a sua alteração ficaria sem efeito.

Confirmar que o diagnóstico está certo

Antes de aplicar seja o que for, confirme a pista:

mysql --version

Uma versão 11.4 ou superior do lado do servidor confirma o cenário.

php -m | grep -i mysql

Este comando lista as extensões ativas e permite ver qual delas está carregada.

Por fim, teste uma ligação direta com as credenciais de app/config/parameters.php. Se a ligação pela linha de comandos funcionar e o PrestaShop falhar, o problema está mesmo na camada cliente do PHP e não nas credenciais.

Os erros a não cometer

Não reinstale o PrestaShop. O erro é do ambiente: uma reinstalação não muda nada e faz-lhe perder a configuração.

Não mude as credenciais de ligação. São válidas. A mensagem fala de TLS, não de autenticação recusada.

Não reponha uma cópia de segurança antiga. O seu código não mudou. Repor faria perder as encomendas recebidas entretanto, sem corrigir o que quer que fosse.

Não elimine a própria pasta var/cache, apenas o seu conteúdo, sob pena de gerar um segundo erro que baralha o diagnóstico.

Antecipar o próximo episódio

Este tipo de avaria, provocada por uma evolução da infraestrutura do lado do alojamento, multiplica-se à medida que os parques vão migrando. Dois hábitos limitam o impacto:

• Ler as notificações de manutenção do seu alojamento. As migrações de motor de base de dados são anunciadas, muitas vezes com semanas de antecedência, num e-mail que ninguém lê.
• Ter um ambiente de pré-produção no mesmo alojamento. Costuma ser migrado antes ou ao mesmo tempo e dá o alerta antes de a produção cair.

Para as outras avarias que deitam abaixo uma loja inteira, a nossa checklist do erro 500 cobre o método geral de diagnóstico.

Loja offline neste momento?

Diagnosticamos este tipo de avaria de ambiente em menos de uma hora e tratamos diretamente com o seu alojamento, se for preciso. Veja o suporte urgente PrestaShop.