Erreur cURL error 60 SSL dans WordPress – comment corriger [Guide]

Le téléchargement a échoué. cURL error 60: SSL certificate – comment corriger dans WordPress

Erreur cURL error 60: SSL certificate problem: unable to get local issuer certificate apparaît dans WordPress généralement lors d'une tentative d'installation ou de mise à jour de plugins, de thèmes ou du noyau WordPress lui-même – c'est-à-dire partout où WordPress se connecte via HTTPS à un serveur externe (par ex. api.wordpress.org).

Que signifie exactement cette erreur

Le code 20 dans OpenSSL (unable to get local issuer certificate) signifie que le serveur ne peut pas vérifier la chaîne de certificats SSL du site cible, car le fichier local contenant les certificats racine de confiance (bundle CA) est obsolète, endommagé ou pas du tout indiqué dans la configuration PHP/cURL. Ce n'est pas un problème avec le certificat du site que WordPress essaie d'interroger – le problème vient de votre serveur.

Solution 1: mise à jour de ca-bundle.crt dans WordPress

WordPress conserve sa propre copie des certificats racine dans le fichier wp-includes/certificates/ca-bundle.crt. C'est le premier endroit à vérifier.

1. Téléchargez le fichier actuel à partir de la dernière version de WordPress (dernière archive ZIP de wordpress.org ou directement depuis le dépôt GitHub WordPress Core).
2. Remplacez le fichier sur le serveur via FTP/SFTP ou le panneau d'hébergement à l'emplacement wp-includes/certificates/ca-bundle.crt.
3. Définissez les permissions 644 sur le fichier.
4. Videz le cache d'objet éventuel (Redis/Memcached) et réessayez.

Solution 2 : mise à jour du bundle CA au niveau du serveur (système/PHP)

Si le remplacement du fichier WP ne vous aide pas, le problème se trouve dans la configuration du serveur lui-même – c'est-à-dire dans le cURL/OpenSSL système, que PHP utilise indépendamment des fichiers WordPress.

Sur les serveurs Linux (Debian/Ubuntu) :

sudo apt update sudo apt install --reinstall ca-certificates sudo update-ca-certificates

Sur les serveurs CentOS/AlmaLinux/RHEL :

sudo yum reinstall ca-certificates sudo update-ca-trust

Mise à jour manuelle de cacert.pem pour PHP

Si vous n'avez pas accès root au système (hébergement mutualisé typique), téléchargez le fichier actuel cacert.pem directement depuis curl.se :

Télécharger cacert.pem

Uploadez-le sur votre serveur (par exemple dans un répertoire en dehors de public_html, pour qu'il ne soit pas accessible publiquement) et spécifiez-le dans php.ini:

curl.cainfo = "/chemin/vers/cacert.pem" openssl.cafile = "/chemin/vers/cacert.pem"

Après la modification php.ini redémarrez PHP-FPM ou Apache, selon votre configuration :

sudo systemctl restart php8.2-fpm sudo systemctl restart apache2

Solution 3 : si vous utilisez HestiaCP ou votre propre VPS

Avec votre propre gestion de serveur, il vaut la peine de vérifier deux choses supplémentaires :

• La version d'OpenSSL – si le système est ancien (par exemple Ubuntu 18.04 sortant du support), la simple mise à jour de ca-certificates peut ne pas suffire, car les certificats root plus récents manquent dans les dépôts. Dans ce cas, seule la mise à jour du système ou l'upload manuel aide cacert.pem.
• Versions PHP séparées pour différents domaines – si vous hébergez plusieurs sites avec différentes versions de PHP, assurez-vous que curl.cainfo est configuré pour la bonne version de PHP-FPM, car chaque version a sa propre php.ini.

Comment vérifier que le problème a été résolu

Au niveau du serveur, vous pouvez vérifier la connexion SSL directement via cURL dans le terminal:

curl -v https://api.wordpress.org/

Si aucune erreur n'apparaît dans le journal unable to get local issuer certificate, la configuration est déjà correcte et WordPress devrait à nouveau télécharger les mises à jour sans problème.

De plus, il est utile de vérifier au niveau de PHP quel fichier CA est réellement utilisé :

<?php
var_dump(ini_get('curl.cainfo'));
var_dump(ini_get('openssl.cafile'));

Résumé

L'erreur cURL 60 dans WordPress est dans la plupart des cas une question de fichier de certificats root obsolète, et non une panne de [WordPressa] lui-même WordPressa.