L'errore di certificato che compare dopo aver configurato un proxy può indicare due cose completamente diverse: o esiste un livello di ispezione intermedio, o manca una semplice impostazione. Distinguere i due casi è fondamentale per la tua sicurezza.
Cosa dovrebbe succedere in condizioni normali?
In un tunnel CONNECT configurato correttamente, il proxy non tocca affattoil certificato. L'handshake TLS avviene direttamente tra client e server di destinazione; il proxy trasporta soltanto i byte cifrati. Di conseguenza il certificato è quello reale del sito di destinazione.
In questo flusso non ci si aspetta alcun errore di certificato. Se compare un errore, o c'è qualcuno nel mezzo, o l'archivio certificati del client è incompleto.
Cause degli errori
La seconda riga è un campanello d'allarme: se nella catena compare un certificato autofirmato, il tuo traffico potrebbe essere letto.
Come riconoscere l'SSL inspection
Se i valori issuer nei due output sono diversi, significa che il proxy applica interception TLS e può leggere il tuo traffico.
Silenziare l'errore di certificato con -k oppure verify=False non risolve il problema — lo rende solo invisibile. Equivale a permettere a chiunque si trovi nel mezzo di leggere il tuo traffico. Non usarlo mai in produzione.
Soluzioni corrette
Aggiorna l'archivio delle CA radice
È la causa più frequente. Su Linux update-ca-certificates, in Python certifi aggiorna il pacchetto.
Aggiungi la CA radice aziendale dopo averla verificata
Se sei in una rete aziendale e la policy lo prevede, aggiungi all'archivio attendibile del client la CA radice ricevuta dal reparto IT. Non aggiungere mai un certificato scaricato da internet.
Controlla l'ora di sistema
Un orologio di sistema errato fa apparire "scaduti" certificati validi. È un caso frequente nelle macchine virtuali.
Usa un canale senza interception TLS
Le applicazioni che usano il certificate pinning non accettano l'intermediazione. In questi casi serve la rete dati mobile o una connessione diretta.
Archivio certificati per applicazione
Non tutte le applicazioni usano l'archivio attendibile di sistema. È questa la spiegazione del classico "funziona nel browser ma non nel mio script":
| Ambiente | Archivio certificati | Metodo di aggiunta |
|---|---|---|
| Strumenti di sistema Linux | /etc/ssl/certs | update-ca-certificates |
| Python (requests) | pacchetto certifi | REQUESTS_CA_BUNDLE variabile |
| Node.js | Archivio integrato | NODE_EXTRA_CA_CERTS variabile |
| Java | keystore cacerts | keytool -import |
| Firefox | Archivio proprio | Impostazioni → Certificati |
| Chrome | Archivio di sistema | Impostazione del sistema operativo |
Aggiungere un certificato a livello di sistema lo rende attendibile per tutte le applicazioni. Fallo solo con certificati di cui conosci con certezza l'origine.
Certificate pinning
Alcune app mobili e client bancari fissano il certificato del server all'interno dell'applicazione. Quando rilevano un certificato intermedio rifiutano la connessione — nessuna aggiunta di CA radice cambia questo comportamento.
È questo il motivo della lamentela "l'app non si apre sul Wi-Fi aziendale ma funziona con i dati mobili". L'unica soluzione è usare per quell'app un canale senza interception TLS.
Riepilogo
In un tunnel CONNECT sano il proxy non tocca il certificato; se vedi un errore, o l'archivio CA radice del tuo client è incompleto, o esiste un livello di ispezione intermedio. Per distinguere i due casi, confronta con la connessione diretta il valore issuer nella catena dei certificati. Disattivare la verifica non è una soluzione: rende solo invisibile il rischio. Per vedere cosa lascia realmente trapelare la tua connessione puoi usare test di anonimato il nostro strumento.