Errori TLS solo sulla VPN aziendale: correggete il giusto archivio di fiducia
Stesso strumento, stesso portatile, solo la VPN rompe TLS. Leggete il messaggio, trovate il pacchetto CA che legge il binario e aggiungete una radice invece di disattivare i controlli.
La build Go, l’installazione di Composer e il client Python funzionano tutti a casa e falliscono tutti dentro la VPN aziendale. Questo schema vi parla del percorso, non dell’applicazione. Qualcosa sul tunnel ha cambiato la catena di certificati che vede il vostro processo, oppure ha azzerato l’handshake prima che arrivasse qualsiasi catena. I due guasti sembrano uguali in un terminale e richiedono risposte del tutto diverse.
Tre messaggi, tre meccanismi
L’errore x509 certificate signed by unknown authority significa che è stata costruita una catena e che la sua radice manca in l’archivio di fiducia usato da quel processo. L’errore self-signed certificate in certificate chain di solito significa che un proxy di ispezione ha risposto con il proprio certificato, che è una catena che il vostro runtime non riconosce. Un SSL EOF durante l’handshake significa che la connessione è stata chiusa prima che fosse inviato un certificato utilizzabile, e questo è un dispositivo intermedio che rifiuta il ClientHello, non un problema di fiducia.
Aggiungere un’opzione di insicurezza fa sparire tutti e tre i messaggi lasciando l’intercettazione al suo posto, e rimuove il controllo che catturerebbe un vero attaccante.
Trovate il pacchetto che il processo legge davvero
La radice aziendale installata nell’archivio di Windows corregge i browser e le applicazioni .NET che consultano l’archivio di sistema. Non fa nulla per una build eseguita dentro un container, che porta il proprio pacchetto CA, né per un processo Python che usa certifi o un processo Node che usa il suo elenco integrato. Go legge il pool di sistema dell’ambiente in cui gira il binario, cioè il container e non il portatile. Una sola macchina produce quindi insieme un browser che funziona e uno strumento di build che fallisce.
Chiedete allo strumento invece di supporre. python3 -c "import ssl; print(ssl.get_default_verify_paths())" stampa i file che Python consulterà, e node -e "console.log(process.env.NODE_EXTRA_CA_CERTS)" mostra se una sostituzione è già impostata. Per un container, eseguite lo stesso controllo dentro l’immagine, perché è l’ambiente che la build usa davvero.
Installate una radice dove gira la build
Ottenete la radice di ispezione dall’IT come file PEM e verificate la sua impronta tramite un canale separato prima di fidarvi. Sulle immagini derivate da Debian, copiatela in /usr/local/share/ca-certificates/ ed eseguite update-ca-certificates; le immagini della famiglia RHEL usano update-ca-trust dopo aver messo il file in /etc/pki/ca-trust/source/anchors/. In una build di container, aggiungete quei passaggi prima del comando che fallisce, così lo strato viene messo in cache sopra l’installazione delle dipendenze.
Per un devcontainer locale, montate il PEM ed eseguite lo stesso comando di aggiornamento all’avvio invece di cuocerlo in un’immagine personale che nessun altro può riprodurre. Gli strumenti che portano il proprio pacchetto hanno bisogno della propria sostituzione documentata: pip ha un’impostazione del certificato, npm ha un’impostazione cafile, e la maggior parte degli altri accetta le variabili d’ambiente standard.
Questo non è lo stesso che accettare qualsiasi certificato. Aggiungete una radice precisa, ottenuta dalla parte che esegue l’ispezione, a un ambiente, e la verifica resta attiva per ogni altra catena. Annotate quale file è stato aggiunto e quando scade, perché una radice di ispezione si rinnova come qualsiasi altra CA.
Quando l’handshake muore prima di un certificato
Se non viene presentato nulla, nessuna modifica all’archivio di fiducia aiuterà. Confrontate la stessa richiesta con il tunnel attivo e spento, poi ispezionate la catena direttamente con openssl s_client -connect host:443 -servername host -showcerts. Una connessione che si completa fuori dalla VPN e si azzera dentro è una decisione di politica del dispositivo intermedio, e il rimedio è un’eccezione per quell’host, non un altro certificato. Chiedete che il registro dei pacchetti o l’endpoint API passino senza modifiche.
Dividere il tunnel perché lo strumento aggiri la VPN evita l’ispezione di quel traffico, il che può violare la politica e non rende lo strumento affidabile.
Annotate il risultato per ogni strumento
Una nota breve che elenca il binario, il file di fiducia che legge, la variabile d’ambiente in gioco e l’eccezione approvata risparmia alla persona successiva tutta la diagnosi. Tenete la nota per strumento e non per portatile, perché il portatile è raramente la cosa che è cambiata.
E tenete due frasi separate nel ticket: abbiamo installato una radice aziendale precisa, e abbiamo disattivato la verifica. Solo una delle due è un’azione di supporto.