WordPress cURL error 60: certificato SSL

Questa guida approfondisce WordPress cURL error 60 con verifiche progressive e reversibili. Non inviare password, cookie, token, chiavi private, codici 2FA o file di configurazione completi nei ticket.

Che cosa significa

Disattivare la verifica SSL elimina il controllo di identità e rende la connessione vulnerabile. È una scorciatoia insicura e non una soluzione.

WordPress usa richieste HTTPS per aggiornamenti, licenze, API, webhook e servizi esterni. Bisogna identificare l’URL esatto che genera l’errore.

Come riconoscere il problema

• Site Health o plugin mostra SSL certificate problem.
• Aggiornamenti e licenze non si verificano.
• Una API funziona nel browser ma non dal server.
• Il certificato remoto è stato rinnovato di recente.
• Il messaggio cita unable to get local issuer certificate.

Cause più frequenti

1. Catena incompleta

Il server remoto non invia gli intermedi necessari. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

2. Certificato scaduto o non ancora valido

Le date non comprendono il momento corrente. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

3. Hostname errato

Il certificato non copre il dominio richiesto. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

4. CA bundle obsoleto

Il server non riconosce la catena. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

5. Ora di sistema errata

La validità viene valutata con una data sbagliata. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

6. Proxy o ispezione TLS

Un intermediario presenta un certificato differente. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

Diagnosi passo per passo

1. Copia l’URL remoto. Individua endpoint e hostname. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
2. Controlla certificato e catena. Usa strumenti TLS e openssl dal server. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
3. Verifica SAN e date. Confronta il nome richiesto. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
4. Controlla orario del sistema. La data deve essere sincronizzata. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
5. Confronta browser e server. Possono usare trust store differenti. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
6. Verifica proxy e firewall. Cerca certificati sostituiti. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
7. Controlla plugin e URL configurato. Evita IP o hostname interni non coperti. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.

Metodo sicuro di diagnosi

Prima di modificare la configurazione, registra URL o servizio coinvolto, messaggio completo, data e ora, ultima modifica nota, client o rete e risultato ottenuto con un secondo strumento. Questa fotografia iniziale permette di confrontare i test e di tornare alla configurazione precedente quando una modifica non produce il risultato atteso.

Applica una sola correzione alla volta. Dopo ogni intervento ripeti esattamente la stessa operazione e controlla i log dello stesso intervallo temporale. Modificare contemporaneamente DNS, cache, PHP, plugin, proxy e firewall elimina la possibilità di attribuire il risultato a una causa precisa.

Controllo incrociato

Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin, Site Health e WP-CLI; per DNS interroga nameserver autoritativi e resolver pubblici; per la posta confronta Webmail, intestazioni originali e Track Delivery. Cache, TTL e code possono mostrare stati differenti per alcuni minuti.

Quando il problema sembra risolto, esegui una seconda prova con una nuova sessione, un secondo utente o una seconda rete quando applicabile. Verifica inoltre che TLS, autenticazione, WAF, permessi e controlli antispam restino attivi: una correzione che disabilita stabilmente le protezioni non è una soluzione definitiva.

Verifica prolungata dopo la correzione

Conserva temporaneamente backup, valori precedenti ed estratti dei log. Ripeti il controllo dopo il normale ciclo di cache, cron, coda o TTL. Se l’anomalia ricompare a intervalli regolari, confronta l’orario con backup, aggiornamenti, rinnovi SSL, rotazioni DNS, processi pianificati e servizi esterni.

Documenta il risultato finale con data, comando o schermata utilizzata e condizione verificata. Questa nota evita interventi duplicati e rende più rapida una futura analisi da parte dell’assistenza.

Procedura di risoluzione

1. Correggi il certificato remoto. Installa catena completa e rinnova se necessario. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
2. Usa l’hostname coperto. Non chiamare l’IP se il certificato è per il dominio. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
3. Aggiorna CA bundle e sistema. Con procedure amministrative supportate. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
4. Correggi data e NTP. Sul server che esegue la richiesta. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
5. Aggiorna plugin o endpoint. Rimuovi URL obsoleti. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
6. Configura proxy con una CA attendibile. Solo in ambienti amministrati e documentati. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
7. Mantieni SSL verification attiva. Ritesta la connessione dopo la correzione. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.

Come raccogliere prove utili

Quando riproduci il problema, conserva soltanto i dati tecnici necessari: codice di risposta, URL priva di token, orario con fuso, request ID, nome del client, dimensione del file o del messaggio e una breve descrizione dell’operazione. Evita screenshot parziali quando puoi esportare il testo originale, perché header, log e messaggi completi permettono una diagnosi più precisa.

Prima di chiudere il controllo, confronta il comportamento con una configurazione nota e funzionante. Per una API usa un payload minimo; per WordPress prova una funzione core senza plugin aggiuntivi; per DNS interroga direttamente i nameserver; per la posta usa Webmail e conserva il file `.eml`. Questo confronto riduce le ipotesi e impedisce modifiche inutili.

Controlli finali

• cURL completa la richiesta.
• Certificato valido e catena completa.
• Hostname corretto.
• Ora sincronizzata.
• Nessuna opzione sslverify=false.

Prevenzione

• Monitoraggio certificati.
• AutoSSL.
• Sistema aggiornato.
• Endpoint HTTPS documentati.
• NTP attivo.

Errori da evitare

• Non usare sslverify false.
• Non scaricare CA casuali.
• Non ignorare hostname mismatch.
• Non usare IP al posto del dominio.
• Non condividere token API.

Quando contattare l’assistenza Xlogic

Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi oppure richiede log e configurazioni non disponibili nel pannello. Indica:

• URL remoto
• errore completo
• orario
• risultato TLS
• plugin o funzione

Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.

Fonti tecniche ufficiali

• WordPress HTTP API
• libcurl error codes

Domande frequenti su WordPress cURL error 60