Résoudre les problèmes
Comment résoudre l'erreur cURL 60 de certificat SSL dans WordPress
Lorsque vous essayez de mettre à jour WordPress, d'installer un plugin ou de vous connecter à un service externe, vous pouvez rencontrer un message semblable à celui-ci :
Error en la actualización: Descarga fallida. cURL error 60: SSL certificate problem
L'erreur indique que PHP ou cURL n'a pas pu vérifier la chaîne de confiance du certificat présenté par le serveur distant. Cela ne signifie pas forcément que le certificat de votre propre site a expiré.
Causes possibles à vérifier
Le message est compatible avec plusieurs scénarios, mais ne permet pas d'en choisir un sans autres tests :
- Une ancienne version de WordPress avec un paquet d'autorités de certification obsolète.
- Le magasin de certificats du système d'exploitation ou de PHP est obsolète ou mal configuré.
- La date et l'heure du serveur sont incorrectes.
- Le certificat du serveur distant a expiré, ne correspond pas à son domaine ou ne fournit pas la chaîne intermédiaire complète.
- Un proxy, un antivirus, un pare-feu ou un plugin de sécurité intercepte la connexion HTTPS.
Ne désactivez pas la vérification SSL
N'utilisez pas de filtres qui forcent https_ssl_verify à false.
Désactiver la vérification permet à WordPress d'accepter des certificats non fiables et facilite les attaques de l'homme du milieu. En outre, cela masque la cause réelle et peut affecter d'autres connexions effectuées via l'API HTTP de WordPress si le filtre est appliqué de façon générale.
1. Vérifiez la date et l'URL qui échoue
Examinez le message complet pour identifier le domaine distant. Si l'erreur apparaît lors de la mise à jour de WordPress, la connexion se fait normalement vers api.wordpress.org ou downloads.wordpress.org. Si elle ne se produit qu'avec un plugin précis, elle peut concerner le service externe utilisé par ce plugin.
Vérifiez aussi que la date, l'heure et le fuseau horaire du serveur sont corrects. Un écart important peut faire paraître un certificat valide comme expiré ou pas encore valide.
2. Mettez à jour WordPress, PHP et les certificats
Avant de modifier la configuration :
- Faites une sauvegarde.
- Mettez à jour WordPress vers une version compatible et maintenue.
- Mettez à jour les plugins et thèmes concernés.
- Vérifiez que la version de PHP est toujours supportée.
WordPress inclut son propre paquet de certificats dans wp-includes/certificates/ca-bundle.crt. Ne remplacez pas uniquement ce fichier par un autre téléchargé depuis une source inconnue : mettez à jour le noyau complet pour que tous ses fichiers appartiennent à la même version.
3. Vérifiez la configuration des certificats de PHP
Dans les informations de PHP, vous pouvez vérifier les valeurs de curl.cainfo et openssl.cafile. Si elles sont définies, elles doivent pointer vers un fichier de certificats existant, lisible et à jour.
En SSH, vous pouvez aussi tester la connexion sans désactiver aucune validation :
curl -Iv https://api.wordpress.org/
Testez exactement l'URL indiquée dans l'erreur. Si la commande affiche la même erreur, examinez le magasin de certificats du serveur et la chaîne fournie par la destination. Si cela fonctionne en console mais échoue depuis WordPress, gardez à l'esprit que la console peut utiliser un autre magasin : vérifiez la configuration de la version de PHP qui exécute le site et journalisez la requête depuis WordPress avant de l'attribuer à un plugin.
4. Écartez les interférences de plugins et de proxys
Uniquement si le journal ou la configuration indiquent une possible interception, désactivez temporairement et de manière contrôlée les plugins de sécurité ou de proxy susceptibles de modifier les requêtes sortantes. Répétez la même requête avant et après ; le changement de résultat est l'élément probant utile. Ne faites pas ce test en production sans sauvegarde ni fenêtre de maintenance.
Si vous utilisez un proxy d'entreprise ou un antivirus qui inspecte le HTTPS, son autorité de certification doit être correctement installée dans le magasin utilisé par PHP.
5. Contactez le fournisseur lorsque le serveur est concerné
Si vous n'administrez pas le serveur, fournissez au fournisseur l'URL distante, le message complet, l'heure du test et la version de PHP. Il pourra vérifier le paquet de certificats, la configuration de cURL/OpenSSL et l'éventuelle interception des connexions sortantes.
La bonne solution consiste à rétablir une chaîne de confiance valide. La désactivation de la vérification SSL ne doit pas être utilisée, même comme solution temporaire.
Si la mise à jour ne peut pas non plus être téléchargée
Ne forcez pas le téléchargement sans TLS valide. Si vous devez mettre à jour le noyau manuellement, utilisez la distribution officielle, conservez d'abord une copie et suivez une procédure de mise à jour compatible avec la version installée. Une réinstallation de la même version et une mise à jour ne sont pas la même opération.
Lorsque vous partagez l'URL qui échoue, supprimez les jetons et les paramètres privés. Un curl réussi depuis votre ordinateur ne teste pas le magasin de certificats de l'hébergement ; effectuez le test depuis l'environnement où l'erreur apparaît et distinguez toujours la CLI du PHP web.
Cela peut aussi vous aider
- Des erreurs 404 sur des fichiers statiques ralentissent la navigation Repérez les ressources statiques absentes qui déclenchent PHP et consomment du CPU, servez-les comme...
- Diagnostiquer les erreurs cryptographiques de Sodium dans WordPress Distinguez l'absence de l'extension Sodium d'un argument invalide dans sodium_compat avant de modifi...
- Diagnostiquer « Planification manquée » ou « Missed schedule » Vérifiez pourquoi un article planifié n'a pas été publié avant de remplacer WP-Cron par une tâche du...
- Déboguer les erreurs dans WordPress Repérez les pages blanches et les erreurs internes de WordPress en envoyant WP_DEBUG vers un journal...
Quelque chose cloche ou a changé ? Racontez-nous et nous le vérifions.