WordPress cURL error 60: SSL certificate problem

In breve: WordPress cURL error 60 significa che il client HTTP usato da PHP non riesce a verificare il certificato del server remoto. Individua l’URL chiamato, controlla corrispondenza del nome host, validità e catena TLS, confronta browser, curl CLI e WordPress, quindi verifica orologio, proxy e bundle CA. Non disattivare la verifica SSL in produzione.

WordPress cURL error 60: che cosa significa

WordPress usa la propria HTTP API per contattare aggiornamenti, licenze, webhook e servizi esterni. Quando il trasporto cURL riceve un certificato che non riesce a collegare a un’autorità attendibile, restituisce l’errore 60, spesso accompagnato da messaggi come unable to get local issuer certificate, self signed certificate o certificate has expired.

L’errore descrive la verifica eseguita dal client, non identifica da solo il componente da correggere. Il server remoto può inviare una catena incompleta; il certificato può non includere il nome richiesto; il trust store usato da PHP può essere obsoleto; un proxy può sostituire il certificato; la data di sistema può rendere non valido un certificato altrimenti corretto.

Identificare URL e client coinvolto

1. Copia il messaggio completo e individua l’host remoto. Se l’URL non è visibile, attiva per breve tempo il log del plugin in staging o usa gli strumenti diagnostici previsti.
2. Annota data, ora, fuso, operazione che genera l’errore e versione del plugin.
3. Verifica se fallisce una sola integrazione o ogni richiesta HTTPS di WordPress.
4. Riprova una volta dalla stessa funzione; non creare una raffica di webhook, ordini o chiamate API.
5. Controlla wp-content/debug.log e log PHP, eliminando token e dati personali dalle copie condivise.

Il certificato da analizzare è quello dell’host effettivamente chiamato dopo DNS, redirect e proxy. Se un endpoint reindirizza a un dominio differente, la verifica riguarda anche il nuovo hostname.

Controllare hostname e catena TLS

curl -Iv https://api.esempio.it/

openssl s_client \
  -connect api.esempio.it:443 \
  -servername api.esempio.it \
  -showcerts < /dev/null

Esegui i test dal server WordPress quando sei autorizzato, perché rete e trust store del computer locale possono essere diversi. Controlla Subject Alternative Name, date notBefore/notAfter, issuer e certificati intermedi presentati. L’opzione SNI -servername è necessaria per verificare il certificato del virtual host corretto.

Non usare curl -k come prova di validità: dimostra soltanto che la connessione riesce ignorando l’autenticità del certificato. Se con verifica attiva fallisce e con -k riesce, hai confermato un problema di trust o identità da correggere.

Confrontare browser, cURL, PHP e WordPress

Un browser verde non esclude un intermedio mancante: può averlo memorizzato o recuperato. Se curl CLI funziona ma PHP fallisce, confronta versioni, php.ini caricato, curl.cainfo, openssl.cafile e bundle incluso da WordPress.

Controllare orologio, CA bundle e proxy

Orologio di sistema

Verifica data, ora e sincronizzazione NTP. Un orologio fuori intervallo può far apparire il certificato non ancora valido o scaduto. Correggere l’orario richiede privilegi di sistema e va eseguito secondo la gestione del server.

Bundle CA

Aggiorna sistema operativo, pacchetto ca-certificates, PHP/cURL e WordPress. Non scaricare un file CA da fonti casuali e non sostituire globalmente il bundle senza backup. Nel PHP Selector assicurati che il percorso configurato esista e sia leggibile dalla versione PHP realmente usata dal sito.

Proxy e ispezione HTTPS

Un proxy aziendale o software di sicurezza può presentare un certificato firmato da una CA privata. La CA va distribuita attraverso il processo autorizzato soltanto agli ambienti che devono fidarsi del proxy; non importare il certificato del singolo sito come root globale.

Correggere senza disattivare SSL

• Catena remota incompleta: installa sul server remoto certificato e intermedi corretti.
• Hostname errato: usa l’endpoint previsto o emetti un certificato che includa quel nome.
• CA obsolete: aggiorna trust store e componenti, poi riavvia soltanto i servizi necessari.
• Certificato self-signed intenzionale: usa una CA privata gestita e distribuiscine il root, non sslverify=false.
• Proxy: correggi esclusioni o trust della CA aziendale secondo policy.

Filtri WordPress come https_ssl_verify o argomenti sslverify impostati a false abbassano la sicurezza e possono esporre token, aggiornamenti o dati a un attacco man-in-the-middle. Rimuovili dopo qualsiasi test e non inserirli in un fix permanente.

Verificare da WordPress

Esegui la stessa operazione che falliva e, se puoi usare WP-CLI in sicurezza, prova la HTTP API senza stampare segreti:

wp eval '$r=wp_remote_head("https://api.esempio.it/");
if (is_wp_error($r)) { echo $r->get_error_message(); }
else { echo wp_remote_retrieve_response_code($r); }'

• La risposta arriva senza errore 60 e con il codice HTTP previsto.
• La catena verifica con il nome host corretto e senza opzioni insecure.
• Il test riesce sia dal client di sistema sia dall’ambiente PHP usato dal sito.
• Non restano log con token, header Authorization o dati personali.

Errori da evitare

• Disattivare globalmente la verifica SSL.
• Correggere il certificato del sito locale quando l’URL fallito è un’API remota.
• Concludere che la catena sia valida perché funziona nel browser del proprio computer.
• Modificare php.ini di una versione PHP diversa da quella del sito.
• Aggiungere un certificato leaf al trust store come se fosse una CA root.

Guide Xlogic correlate

• WordPress cURL error 77: error setting certificate verify locations

Domande frequenti

Conclusione

cURL error 60 va risolto ripristinando una catena di fiducia valida per il client che esegue la richiesta. Identificare l’host, confrontare i diversi trust store e correggere certificato, CA bundle, orologio o proxy mantiene HTTPS sicuro e rende la soluzione verificabile.

Fonti tecniche

• curl — SSL CA Certificates
• WordPress Developer Resources — Making HTTP requests
• PHP Manual — cURL configuration