Mises à jour impossibles sous MAMP // résolu

Bonjour tout le monde,

[ OSX Catalina, MAMP 6.5, PHP 7.4.21, SPIP 3.2.11 et 4.0.0 ]

Depuis 2 jours, sans en connaître l’origine/événement/changement, j’ai des soucis PHP liés au téléchargement / copie de fichiers SPIP externes :


Sur des sites installés et fonctionnels :

  • spip_loader.php → page blanche → php_error.log ApacheException levée ligne 278function SL_lister_versions_spip()
  • mises à jour de plugins via SVP → :Pri:ERREUR: Erreur connexion 0 et :Pri:ERREUR: ECHEC init_http https://files.spip.org/...
  • ajout d’un dépôt → L’adresse « https://files.spip.org/core/archives.xml » est incorrecte

Dans un répertoire vide avec uniquement un spip_loader.php :

  • Error Impossible d’écrire le fichier https://www.spip.net/spip-dev/INSTALL/spip_loader_list.json

Les autres fonctionnalités des différents sites locaux restent normales. L’ajout d’images / documents aux articles fonctionne : les copies locales fonctionnent donc bien.
Les droits des répertoires n’ont pas changés depuis longtemps : d’ailleurs, tout fonctionne très bien tous les jours depuis longtemps.

Comme si function SL_init_http() ne pouvait pas s’executer.

Est-ce que tout ces éléments vous permettent de me proposer une piste pour corriger ma configuration locale ?

Merci !
françois

Comme tu es sous MacOS, peut-être que openssl - Git for windows: SSL certificate problem: certificate has expired - Stack Overflow traite de ton problème.

Voir aussi https://discuter.spip.net/t/problemes-avec-mirror-php

En essayant d’installer un plugin directement depuis sont URL HTTPS : Télécharger un plugin depuis son archive, toujours la même erreur.

Par contre en utilisant l’URL directe du plugin en HTTP, le téléchargement fonctionne :wink:

Il y a bien une histoire de SSL quelque part : côté serveur SPIP ou serveur local.

Pourtant un curl sur fichier https://files.spip.org/… depuis le terminal OSX fonctionne :frowning:

Comme indiqué dans https://discuter.spip.net/t/problemes-avec-mirror-php
pour résoudre le problème dans SPIP il faut modifier le fichier cacert de MAMP pour enlever le vieux certificat périmé :

$ diff /Applications/MAMP/Library/OpenSSL/certs/cacert.pem-avantedit /Applications/MAMP/Library/OpenSSL/certs/cacert.pem
517,536d516
< DST Root CA X3
< ==============
< -----BEGIN CERTIFICATE-----
< MIIDSjCCAjKgAwIBAgIQRK+wgNajJ7qJMDmGLvhAazANBgkqhkiG9w0BAQUFADA/MSQwIgYDVQQK
< ExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMTDkRTVCBSb290IENBIFgzMB4X
< DTAwMDkzMDIxMTIxOVoXDTIxMDkzMDE0MDExNVowPzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1
< cmUgVHJ1c3QgQ28uMRcwFQYDVQQDEw5EU1QgUm9vdCBDQSBYMzCCASIwDQYJKoZIhvcNAQEBBQAD
< ggEPADCCAQoCggEBAN+v6ZdQCINXtMxiZfaQguzH0yxrMMpb7NnDfcdAwRgUi+DoM3ZJKuM/IUmT
< rE4Orz5Iy2Xu/NMhD2XSKtkyj4zl93ewEnu1lcCJo6m67XMuegwGMoOifooUMM0RoOEqOLl5CjH9
< UL2AZd+3UWODyOKIYepLYYHsUmu5ouJLGiifSKOeDNoJjj4XLh7dIN9bxiqKqy69cK3FCxolkHRy
< xXtqqzTWMIn/5WgTe1QLyNau7Fqckh49ZLOMxt+/yUFw7BZy1SbsOFU5Q9D8/RhcQPGX69Wam40d
< utolucbY38EVAjqr2m7xPi71XAicPNaDaeQQmxkqtilX4+U9m5/wAl0CAwEAAaNCMEAwDwYDVR0T
< AQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFMSnsaR7LHH62+FLkHX/xBVghYkQ
< MA0GCSqGSIb3DQEBBQUAA4IBAQCjGiybFwBcqR7uKGY3Or+Dxz9LwwmglSBd49lZRNI+DT69ikug
< dB/OEIKcdBodfpga3csTS7MgROSR6cz8faXbauX+5v3gTt23ADq1cEmv8uXrAvHRAosZy5Q6XkjE
< GB5YGV8eAlrwDPGxrancWYaLbumR9YbK+rlmM6pZW87ipxZzR8srzJmwN0jP41ZL9c8PDHIyh8bw
< RLtTcm1D9SZImlJnt1ir/md2cXjbDaJWFBM5JDGFoqgCWjBH4d1QB7wCCZAA62RjYJsWvIjJEubS
< fZGL+T0yjWW06XyxV3bqxbYoOb8VZRzI9neWagqNdwvYkQsEjgfbKbYK7p2CNTUQ
< -----END CERTIFICATE-----
<

et en enlevant ces lignes donc, SPIP arrive à nouveau à récupérer un dépot dans SVP et tout le toutim

Pour être complet et éviter que tous les SPIP soient bloqués partout, je viens de modifier la chaine des certificats délivrés par le serveur pour enlever le vieux certificat.

Du coup ça va débloquer les mises à jour de SPIP et des plugins par SVP

MAIS

  • c’est une solution temporaire, au prochain renouvellement ça va revenir
  • sans faire la modif ci-dessus dans le cacert ou mettre à jour le serveur qui héberge SPIP, tous les sites syndiqués en https seront bloqués également…

Merci Cerdic pour cette précision : c’est parfait :wink: