Venerdì sera, ore 18:30. Il deploy in produzione è appena terminato. Tutto sembrava perfetto nell'ambiente di staging, ma improvvisamente i log iniziano a riempirsi di errori rossi fiammanti. Il sistema di pagamento non comunica più con l'API esterna, i webhook restano appesi e il cliente ti scrive su Slack chiedendo perché il checkout è bloccato. Guardi il log e trovi quella riga maledetta: SSL Certificate Problem Unable To Get Local Issuer Certificate. In preda al panico, inizi a cercare su Google e la prima cosa che trovi è un suggerimento su StackOverflow che ti dice di impostare CURLOPT_SSL_VERIFYPEER a false. Lo fai, l'errore sparisce, il sistema riparte e tu torni a casa pensando di aver risolto il problema. In realtà, hai appena aperto una falla di sicurezza grande quanto un portone, lasciando la tua infrastruttura vulnerabile ad attacchi man-in-the-middle che potrebbero costare all'azienda migliaia di euro in sanzioni GDPR o perdita di dati sensibili. Ho visto questa scena ripetersi decine di volte in dieci anni di consulenza e ogni volta il costo per rimediare al "fix rapido" è stato triplo rispetto a fare le cose per bene fin dall'inizio.
Il mito del file cacert.pem universale e perché copiarlo a caso non funziona
Uno degli errori più comuni che vedo commettere dai sistemisti junior è scaricare l'ultimo bundle di certificati CA da un sito web qualsiasi e puntare la propria configurazione PHP o Python a quel file. Pensano che avere un database aggiornato di autorità di certificazione risolva magicamente ogni intoppo. Non è così semplice. Il problema spesso non è nel fatto che il tuo sistema non conosca l'autorità, ma nel fatto che il server a cui ti stai connettendo sta inviando una catena di certificati incompleta.
Se il server remoto non invia i certificati intermedi, il tuo client cercherà di verificare l'identità del sito usando solo il certificato finale e quello radice che ha nel suo archivio locale. Quando manca l'anello di congiunzione — l'intermedio — la verifica fallisce miseramente. Invece di limitarti a scaricare un file .pem a caso, devi capire quale catena manca. Ho lavorato su un progetto di integrazione bancaria dove il team ha passato tre giorni a aggiornare i pacchetti del sistema operativo (Ubuntu 22.04), convinti che fosse un bug di OpenSSL. Alla fine, il problema era semplicemente un certificato intermedio di Sectigo che non era stato configurato correttamente sul bilanciatore di carico del fornitore.
Il costo di questo errore non è solo il tempo perso. È l'illusione di stabilità. Se forzi l'uso di un file locale senza capire la gerarchia, al prossimo rinnovo del certificato del partner, la tua applicazione si romperà di nuovo nello stesso identico modo, magari durante il picco di vendite del Black Friday.
SSL Certificate Problem Unable To Get Local Issuer Certificate e il disastro della disabilitazione della verifica
Questa è la sezione dove dobbiamo essere onesti: disabilitare la verifica SSL è il peccato originale del web development. Quando scrivi quella riga di codice che ignora la validità dei certificati, stai dicendo al tuo server di fidarsi di chiunque dichiari di essere il destinatario. Chiunque, compreso un malintenzionato che si frappone tra il tuo server e l'API di destinazione.
Perché lo fai e perché è un suicidio professionale
Lo fai perché hai fretta. Lo fai perché pensi che "tanto siamo in una rete privata". Ho visto aziende perdere contratti di fornitura milionari perché durante un audit di sicurezza è emerso che i loro script interni usavano connessioni non verificate per trasferire dati dei clienti. Non è un problema tecnico, è un problema di negligenza professionale. Se non riesci a stabilire una connessione sicura, il problema non è la sicurezza troppo stretta, è la tua configurazione che è sbagliata.
In un caso specifico, un'azienda di e-commerce italiana ha subito un furto di credenziali API proprio perché un bot aveva intercettato le chiamate verso un fornitore logistico. Il loro sviluppatore aveva usato il trucco della disabilitazione per superare un intoppo durante la migrazione dei server. Hanno scoperto il furto solo dopo sei mesi, quando il danno era ormai strutturale. La soluzione non è mai abbassare le difese, ma elevare la configurazione al livello richiesto dagli standard moderni.
L'errore di configurazione nel file php.ini e i percorsi fantasma
In ambiente Windows, specialmente con stack come XAMPP o WAMP, questo intoppo è un classico intramontabile. Lo sviluppatore modifica il file php.ini, aggiunge il percorso a curl.cainfo, riavvia il server e... non succede nulla. L'errore persiste. Perché? Spesso perché stanno modificando il file sbagliato o usando percorsi che il sistema non può leggere correttamente.
Ho visto gente impazzire per ore solo per scoprire che PHP stava caricando una versione diversa del file di configurazione rispetto a quella visualizzata nell'interfaccia grafica del tool. Oppure, peggio ancora, il percorso conteneva spazi o caratteri speciali che non venivano interpretati bene. La soluzione pratica qui non è tentare a caso, ma usare uno script di una riga per verificare esattamente cosa vede il motore di esecuzione: php -i | grep "cafile". Se l'output è vuoto o punta a un file inesistente, hai trovato il colpevole senza dover tirare a indovinare.
Il tempo medio perso in questi giri a vuoto è di circa 4 ore per sviluppatore. Se consideri una tariffa oraria media di 50 euro, ogni volta che questo intoppo si presenta, stai buttando 200 euro nel cestino solo per pigrizia nel non controllare i log di avvio del servizio.
Confronto reale tra un approccio amatoriale e uno professionale
Vediamo come si comporta uno sviluppatore che non conosce bene la materia rispetto a uno che sa dove mettere le mani.
Immaginiamo di dover connettere un'applicazione Laravel a un gateway di pagamento. Lo sviluppatore amatoriale vede l'errore e inizia a scaricare cacert.pem da internet. Lo mette nella cartella public (pessima idea per la sicurezza), poi va nel controller e aggiunge un'opzione al client HTTP per puntare a quel file. Funziona. Ma due mesi dopo, il gateway cambia l'autorità di certificazione. L'applicazione crolla. Lo sviluppatore è in vacanza, nessuno sa dove sia quel file e il business resta fermo per un intero weekend. Il costo? Migliaia di euro di transazioni perse e reputazione distrutta.
Lo sviluppatore professionale, invece, analizza il certificato del server remoto usando openssl s_client -connect host:443 -showcerts. Nota immediatamente che il server remoto non fornisce la catena completa. Invece di patchare la sua app, contatta il fornitore e segnala l'errore di configurazione sul loro server. Nel frattempo, configura il sistema operativo del proprio server (che sia Debian, RHEL o altro) per includere il certificato mancante nel keystore di sistema (ad esempio usando update-ca-certificates). In questo modo, ogni linguaggio o tool presente sul server — PHP, Python, curl, wget — beneficerà della correzione in modo centralizzato e sicuro. Al rinnovo del certificato, se il fornitore avrà sistemato la catena, tutto continuerà a funzionare senza un solo intervento sul codice dell'applicazione.
La differenza è tra mettere un cerotto su una ferita infetta e curare l'infezione alla radice. Il primo metodo è veloce, il secondo è definitivo.
Gestire i permessi del file system e le sandbox dei container
Spesso il problema non è nel certificato in sé, ma nel fatto che l'utente che esegue il processo web (come www-data o nginx) non ha i permessi di lettura sul file che hai appena aggiunto. Ho visto sistemisti caricare il certificato nella cartella /root e poi chiedersi perché l'applicazione PHP non riuscisse a vederlo. È un errore banale, ma succede molto più spesso di quanto si pensi, specialmente in ambienti Docker.
Nei container, la situazione si complica. Molti sviluppatori creano immagini Docker personalizzate ma dimenticano di aggiornare i certificati CA all'interno del container stesso durante la fase di build. Quando il container viene spostato in un ambiente con un proxy aziendale che esegue l'ispezione SSL, tutto si rompe. Invece di mappare il file dall'esterno come volume (che può creare problemi di portabilità), la soluzione corretta è iniettare i certificati necessari nel Dockerfile e l'esecuzione del comando di aggiornamento delle CA come parte del processo di creazione dell'immagine.
Non farlo significa avere un'infrastruttura "fragile" che funziona solo sulla macchina dello sviluppatore e fallisce miseramente in produzione o durante i test automatizzati della CI/CD. Ho visto interi team di QA bloccati per giorni perché le macchine di test non avevano i certificati corretti per parlare con l'ambiente di stage.
Verificare la catena dei certificati senza usare strumenti esterni insicuri
Molti sviluppatori usano siti web di terze parti per testare la validità dei certificati SSL. Sebbene siano utili, non dovresti mai affidarti esclusivamente a loro, specialmente se stai lavorando su reti interne o API private che non sono accessibili dal web pubblico. Devi imparare a usare i comandi nativi.
Il comando openssl è il tuo migliore amico, ma è anche lo strumento dove ho visto commettere gli errori più grossolani. Ad esempio, testare la connessione verso google.com per vedere se SSL funziona è inutile se il tuo problema è verso un'API specifica ospitata su un server legacy con protocolli TLS obsoleti. Molti server vecchi supportano solo TLS 1.0 o 1.1, che i client moderni rifiutano di default. Se provi a risolvere il problema cercando di aggiungere certificati CA quando il problema è il protocollo di cifratura, non ne uscirai mai.
Controlla sempre i dettagli della connessione. Se vedi errori relativi al "protocol version", il problema non è la CA mancante, ma l'incompatibilità dei protocolli. In un progetto per una pubblica amministrazione, abbiamo scoperto che il problema che tutti scambiavano per un errore di certificato era in realtà un firewall che troncava i pacchetti troppo grandi contenenti catene di certificati eccessivamente lunghe. Solo un'analisi dei pacchetti con tcpdump ha risolto quello che mesi di tentativi con i certificati non avevano scalfito.
Configurazione del sistema operativo vs configurazione dell'applicazione
C'è questa strana idea che ogni applicazione debba gestire i propri certificati. È un approccio che deriva dalla paura di toccare la configurazione del server, ma è profondamente sbagliato. Se hai dieci microservizi che girano sullo stesso server e ognuno ha la sua copia del bundle CA, stai creando un incubo di manutenzione.
Quando un'autorità di certificazione viene revocata (e succede, ricordate il caso di Symantec o di alcune CA cinesi?), dovrai andare ad aggiornare dieci posti diversi invece di uno solo. La strategia corretta, che ho implementato in infrastrutture che gestiscono milioni di richieste al giorno, è delegare la gestione dei trust al sistema operativo. Se usi Linux, metti i tuoi certificati in /usr/local/share/ca-certificates/ e lancia il comando di aggiornamento. PHP e le altre librerie che usano OpenSSL guarderanno lì per impostazione predefinita.
Questo approccio riduce il rischio di errori umani e garantisce che l'intero server sia allineato agli standard di sicurezza aziendali. È anche più facile da automatizzare con strumenti come Ansible, Terraform o Chef. Non c'è motivo di gestire i certificati a livello di codice nel 2026.
Controllo della realtà: quello che serve davvero per non sbagliare più
Smettiamola di girarci intorno: se continui a imbatterti nell'errore SSL Certificate Problem Unable To Get Local Issuer Certificate, significa che il tuo processo di gestione delle dipendenze e delle infrastrutture ha una falla. Non è un "glitch" del software e non è una colpa del server remoto. È un segnale che non hai il controllo totale sulla catena di fiducia delle tue comunicazioni digitali.
Per avere successo in questo campo ed evitare di perdere notti intere o causare danni economici, devi smettere di cercare la soluzione rapida su internet e iniziare a studiare come funziona TLS. Non ti serve una laurea in crittografia, ti basta capire la differenza tra un certificato Root, un Intermedio e un Leaf. Devi sapere dove il tuo linguaggio di programmazione cerca i certificati e come il tuo sistema operativo li valida.
La realtà è che la sicurezza non è un ostacolo al tuo lavoro, è una parte fondamentale del prodotto che stai costruendo. Ogni volta che provi a bypassare un errore SSL invece di risolverlo, stai scommettendo la tua carriera sulla speranza che nessuno se ne accorga. E nel mondo reale, la fortuna non è una strategia di ingegneria valida. La prossima volta che vedrai quell'errore, non cercare un modo per ignorarlo. Cerca il pezzo mancante della catena, installalo nel posto giusto e dormi sonni tranquilli sapendo che la tua connessione è davvero sicura. Non ci sono scorciatoie che valgano il rischio di una violazione dei dati o di un sistema instabile che crolla al minimo cambiamento del fornitore. Sii il professionista che risolve il problema, non quello che lo nasconde sotto il tappeto del codice.
