WordPress cURL error 77: error setting certificate verify locations

WordPress cURL error 77 è il messaggio attorno al quale ruota questa guida. Non indica da solo una causa unica: descrive il punto in cui WordPress, WooCommerce o il servizio email non riesce a completare un’operazione. Per risolverlo in modo affidabile bisogna conservare il testo completo, l’orario e il contesto in cui compare.

Compare in Site Health, aggiornamenti, installazioni, licenze, webhook o chiamate verso API esterne quando la libreria cURL non riesce a usare il file delle autorità di certificazione configurato. Il problema è diverso da un certificato remoto scaduto: spesso riguarda un percorso locale inesistente, non leggibile o riferito a un bundle CA non valido.

La procedura seguente privilegia interventi reversibili. Prima di aggiornare file, cambiare impostazioni o intervenire sul database, crea un backup verificato e annota lo stato iniziale. Su un sito ecommerce o su una casella operativa, esegui le prove in una finestra controllata e non modificare più livelli contemporaneamente.

Che cosa significa WordPress cURL error 77

Il codice 77 di cURL corrisponde a un problema nel leggere o impostare il file delle autorità di certificazione. WordPress usa il proprio livello HTTP, ma la richiesta può passare attraverso cURL e la configurazione PHP del dominio. Se il percorso di curl.cainfo o openssl.cafile punta a un file assente, la connessione HTTPS si interrompe prima dello scambio applicativo.

Il messaggio può comparire solo su una versione PHP, solo da cron o soltanto in un plugin. Questo accade perché processi web, WP-CLI e job pianificati possono caricare configurazioni differenti. La diagnosi deve quindi identificare esattamente quale runtime produce WordPress cURL error 77.

Sintomi da riconoscere

• Site Health segnala richieste HTTP fallite con codice cURL 77.
• Aggiornamenti di core, plugin o temi non riescono a scaricare il pacchetto.
• Un plugin di backup, licenza o sicurezza non raggiunge la propria API HTTPS.
• WP-Cron registra errori mentre la stessa URL sembra aprirsi dal browser.
• L’errore compare dopo un cambio di versione PHP o una modifica a php.ini.
• Da shell una richiesta funziona, ma dal processo web fallisce oppure avviene il contrario.

I sintomi di WordPress cURL error 77 possono essere intermittenti. Un test riuscito non dimostra che il problema sia risolto se la condizione dipende da cache, processo PHP, replica del database, sincronizzazione o backend di posta. Ripeti la stessa operazione con parametri identici e confronta gli orari con i log.

Cause principali

1. Percorso curl.cainfo inesistente o errato

La direttiva può puntare a un file rimosso, rinominato o appartenente a un’altra versione PHP. cURL tenta di caricarlo e termina con codice 77.

Confronta il percorso effettivo del runtime web con quello mostrato da WP-CLI. Non presumere che tutti i processi leggano lo stesso php.ini.

2. Bundle CA vuoto, corrotto o non aggiornato

Il file può esistere ma non contenere certificati PEM validi. Un trasferimento incompleto o una modifica manuale può renderlo inutilizzabile.

Controlla dimensione, formato e provenienza del bundle. Non scaricare file CA da fonti casuali e non sostituirli senza conservare una copia.

3. Permessi o proprietario non coerenti

Il processo PHP deve poter leggere il bundle CA e attraversare le directory che lo contengono. Permessi troppo restrittivi o proprietario errato possono produrre WordPress cURL error 77.

Correggi proprietario e permessi in modo selettivo. Non usare 777 e non rendere scrivibile globalmente una directory di sistema.

4. Configurazioni PHP differenti tra web, cron e CLI

MultiPHP, PHP Selector, pool PHP-FPM o LiteSpeed possono usare file ini distinti. Una direttiva valida per CLI può essere assente nel processo che esegue WordPress.

Rileva la versione PHP effettiva dal pannello e da Site Health. Verifica poi il valore caricato nel contesto che genera l’errore.

5. Override locale in .user.ini o php.ini

Una vecchia personalizzazione può sovrascrivere il bundle di sistema con un percorso non più disponibile dopo migrazione o aggiornamento.

Cerca direttive locali nel document root e nelle directory superiori consentite. Prima di rimuoverle, annota il valore e il motivo per cui erano state introdotte.

6. Plugin che forza opzioni SSL non coerenti

Un componente può impostare un percorso CA personalizzato o usare una libreria HTTP propria. In questo caso soltanto le sue richieste falliscono.

Confronta una richiesta WordPress standard con quella del plugin e consulta i log del componente. Aggiorna o correggi il plugin invece di disattivare la verifica SSL.

Diagnosi passo passo di WordPress cURL error 77

Passaggio 1: Salvare il messaggio completo e l’URL richiesta

Annota codice 77, testo esteso, plugin o funzione coinvolta e URL remota. Il dominio remoto aiuta a distinguere un problema generale da un’integrazione specifica.

Registra data e ora con fuso orario. Se l’errore appare in un job pianificato, annota anche il nome dell’azione.

Passaggio 2: Verificare la versione PHP effettiva

Controlla in WordPress Site Health la versione usata dal sito e confrontala con quella configurata nel pannello.

Un cambio recente di versione PHP è un indizio importante, perché ogni ramo può avere direttive e bundle differenti.

Passaggio 3: Leggere curl.cainfo e openssl.cafile

Usa le informazioni PHP del dominio o un controllo temporaneo protetto per vedere i valori caricati.

Non lasciare file phpinfo pubblici. Rimuovili subito dopo il test perché espongono dettagli dell’ambiente.

Passaggio 4: Controllare esistenza e leggibilità del bundle

Verifica che il percorso sia assoluto, che il file esista e che il processo PHP possa leggerlo.

Controlla anche le directory superiori: il file può avere permessi corretti ma risultare irraggiungibile se una directory non è attraversabile.

Passaggio 5: Confrontare richiesta web e WP-CLI

Esegui una richiesta controllata tramite WordPress nel contesto web e, se appropriato, tramite WP-CLI.

Una differenza tra i due risultati conferma quasi sempre una configurazione diversa, non un problema del certificato remoto.

Passaggio 6: Controllare error_log nello stesso minuto

Cerca warning su file CA, open_basedir, permessi o caricamento della configurazione.

Il solo messaggio cURL è spesso sintetico; il log PHP può contenere il percorso esatto che non viene aperto.

Passaggio 7: Isolare plugin o integrazione in staging

Se soltanto un plugin fallisce, riproduci la chiamata in staging con lo stesso componente aggiornato.

Evita di disattivare plugin essenziali direttamente in produzione. Una prova isolata riduce l’impatto e conserva il contesto.

Passaggio 8: Ripetere il test dopo una sola correzione

Dopo aver corretto percorso, bundle o permessi, ripeti la stessa richiesta.

Conferma anche aggiornamenti, cron e Site Health: WordPress cURL error 77 può coinvolgere più funzioni che usano lo stesso trasporto.

Dove controllare log e informazioni

I punti principali sono error_log del dominio, Site Health, log del plugin e configurazione PHP caricata. In ambienti cPanel può essere utile confrontare MultiPHP Manager o PHP Selector con il runtime indicato da WordPress.

Non pubblicare un file phpinfo. Se serve verificare una direttiva, usa un controllo temporaneo protetto oppure gli strumenti del pannello e rimuovi immediatamente il file di test.

• messaggio cURL completo e URL remota;
• versione PHP del processo web;
• valori di curl.cainfo e openssl.cafile;
• percorso, dimensione e permessi del bundle CA;
• estratto di error_log nello stesso minuto;
• plugin, tema o job che avvia la richiesta.

Quando copi un errore in un ticket, rimuovi password, cookie, token, chiavi API, chiavi private e codici 2FA. Sono invece utili il dominio, il percorso del file, la riga, l’ora con fuso orario, la versione del componente e una sequenza breve per riprodurre il problema.

Come risolvere WordPress cURL error 77

Soluzione 1: Correggere il percorso del bundle CA

Imposta un percorso assoluto valido per il runtime PHP del dominio, preferendo il bundle gestito dal sistema.

Dopo la modifica riavvia o ricarica il processo PHP quando previsto dall’ambiente e verifica che il nuovo valore sia effettivamente caricato.

Soluzione 2: Rimuovere un override locale obsoleto

Se .user.ini o php.ini forza un file inesistente, elimina o aggiorna soltanto quella direttiva.

Conserva una copia della configurazione precedente e verifica che altri domini non dipendano dallo stesso file.

Soluzione 3: Ripristinare un bundle CA integro

Sostituisci un file vuoto o corrotto con una copia affidabile fornita dal sistema o dal vendor.

Non disabilitare la verifica SSL e non usare un bundle scaricato da fonti non verificate.

Soluzione 4: Correggere permessi e proprietario

Rendi il file leggibile dal processo PHP mantenendo permessi minimi.

Verifica anche il contesto CloudLinux e le restrizioni del dominio, senza allargare i permessi oltre il necessario.

Soluzione 5: Allineare web, cron e CLI

Assicurati che il job che fallisce usi la stessa versione PHP e la stessa configurazione prevista per il sito.

Un cron di sistema con binario differente può continuare a generare l’errore anche dopo la correzione del processo web.

Soluzione 6: Aggiornare il componente che forza la configurazione

Se un plugin usa un proprio client o percorso CA, installa una versione compatibile o applica la correzione indicata dal vendor.

Non modificare direttamente i file del plugin senza una patch tracciata, perché l’aggiornamento successivo sovrascriverebbe la modifica.

Soluzione 7: Verificare la catena remota senza confondere i codici

Controlla il certificato remoto solo dopo aver confermato che il bundle locale è leggibile.

Un certificato remoto non valido produce in genere errori diversi; cambiare il certificato del sito non risolve un percorso CA locale errato.

Soluzione 8: Aprire un ticket con dati tecnici completi

Invia dominio, versione PHP, percorso configurato, orario e messaggio completo.

Il supporto può verificare il runtime e il bundle di sistema senza ricevere password o accessi al pannello.

Controlli specifici su hosting Xlogic

Su hosting Xlogic, WordPress può usare LiteSpeed e una versione PHP selezionata per il dominio. È quindi importante verificare il ramo PHP reale e gli override locali prima di modificare file di sistema.

L’assistenza può controllare configurazione, permessi e coerenza del bundle CA lato account. Non è necessario inviare password WordPress o cPanel.

• versione PHP assegnata al dominio;
• eventuali .user.ini o php.ini locali;
• valore effettivo di curl.cainfo e openssl.cafile;
• error_log nello stesso intervallo;
• job cron o plugin che genera la richiesta;
• esito di Site Health dopo la correzione.

L’assistenza Xlogic opera tramite ticket o email. Per accelerare l’analisi indica un solo intervallo temporale preciso e un solo caso di prova. Non inviare credenziali: quando serve una modifica lato account, il supporto comunica la procedura sicura da seguire.

Errori da evitare durante la diagnosi

Disattivare globalmente TLS, WAF o controlli di sicurezza

Una disattivazione generale può nascondere il problema e aumentare il rischio. Isola il componente o la regola coinvolta e applica, quando necessario, un’eccezione limitata e documentata.

Usare permessi 777

I permessi 777 non sono una soluzione e rendono i file modificabili da soggetti non autorizzati. Mantieni proprietario e permessi coerenti con l’ambiente hosting.

Cambiare più impostazioni nello stesso test

Se modifichi PHP, plugin, cache e DNS contemporaneamente non puoi sapere quale intervento abbia prodotto il risultato. Procedi per una variabile alla volta.

Cancellare log o dati prima di salvarli

Prima di pulire cache, code o log, conserva l’estratto relativo all’errore. I dati temporali sono spesso l’unico modo per collegare il sintomo alla causa.

Inviare credenziali al supporto

Password, cookie, token, chiavi private e codici 2FA non devono essere inclusi nel ticket. Usa identificativi tecnici e messaggi di errore privi di segreti.

Disattivare la verifica SSL nel codice

Filtri o opzioni che impostano verify=false eliminano un controllo essenziale e trasformano un errore di configurazione in un rischio di sicurezza. Correggi il bundle CA invece di aggirarlo.

Prevenzione e monitoraggio

1. Aggiornare in staging

Prova aggiornamenti e cambi di configurazione in un ambiente di staging rappresentativo, soprattutto quando sono coinvolti plugin critici, checkout o integrazioni esterne.

2. Mantenere backup verificati

Conserva backup giornalieri e verifica periodicamente che sia possibile ripristinare file e database. Un backup non testato non è una garanzia operativa.

3. Documentare le modifiche

Registra data, componente, versione e motivo delle modifiche. Una cronologia minima riduce drasticamente i tempi di diagnosi.

4. Monitorare errori e code

Controlla error_log, Site Health, azioni pianificate e log applicativi dopo aggiornamenti importanti o migrazioni.

5. Ridurre componenti ridondanti

Plugin duplicati o sovrapposti aumentano le dipendenze e rendono più difficile individuare il responsabile di un errore.

6. Usare test ripetibili

Definisci una procedura breve con dati di prova non sensibili, così ogni modifica può essere verificata nelle stesse condizioni.

Checklist finale

• messaggio e URL remota salvati;
• versione PHP effettiva identificata;
• curl.cainfo e openssl.cafile controllati;
• bundle CA esistente, integro e leggibile;
• override locali verificati;
• richiesta web e cron ritestate;
• Site Health senza nuovo WordPress cURL error 77.

La checklist è completa solo quando WordPress cURL error 77 non ricompare nella stessa operazione, i log non mostrano nuovi errori correlati e la funzione coinvolta resta stabile anche dopo svuotamento delle cache applicative pertinenti e una nuova sessione di prova.

Verifica dopo la correzione

Dopo ogni intervento su WordPress cURL error 77, ripeti esattamente il caso iniziale senza introdurre altre modifiche. Controlla il risultato nel frontend o nel client, quindi confronta error_log, code e stato applicativo con lo stesso intervallo temporale. Una correzione è valida soltanto se elimina il sintomo e non produce errori collaterali.

Esegui inoltre un secondo test da una nuova sessione o da un contesto indipendente, così da escludere cache locale, cookie o dati temporanei. Nei flussi critici verifica anche l’operazione successiva: per esempio aggiornamento completato, ordine sincronizzato, messaggio spostato o job pianificato eseguito.

Conserva una nota finale con impostazione precedente, modifica applicata, orario e risultato. Questa registrazione permette di ripristinare rapidamente la configurazione se il problema ricompare e aiuta il supporto a distinguere una regressione da un evento nuovo.

Quando aprire un ticket

Apri un ticket quando il percorso configurato sembra corretto ma il processo PHP continua a non leggere il bundle, oppure quando il file CA è gestito a livello di sistema e non è modificabile dall’account.

Indica dominio, URL remota, data e ora, versione PHP, valori delle direttive e testo completo. Non allegare chiavi API o token del servizio esterno.

Domande frequenti su WordPress cURL error 77

Conclusione

Per risolvere WordPress cURL error 77 servono dati coerenti, una prova ripetibile e una correzione mirata. Evita scorciatoie che disattivano controlli di sicurezza o nascondono il sintomo. Verifica sempre il risultato sullo stesso percorso che generava l’errore e conserva una breve nota delle modifiche effettuate.