Mga error sa TLS sa corporate VPN lang: ayusin ang tamang trust store

Gumagana ang Go build, ang pag-install ng Composer at ang Python client sa bahay at lahat sila ay nabigo sa loob ng VPN ng kumpanya. Ang pattern na iyon ay nagsasabi sa iyo tungkol sa landas, hindi tungkol sa aplikasyon. May nagbago sa tunnel ng certificate chain na nakikita ng iyong proseso, o ni-reset ang handshake bago pa man dumating ang anumang chain. Magkahawig ang dalawang failure sa terminal at nangangailangan ng ganap na magkaibang tugon.

Tatlong mensahe, tatlong mekanismo

Ang error na x509 certificate signed by unknown authority ay nangangahulugan na may nabuong chain at nawawala ang root nito sa trust store na ginagamit ng prosesong iyon. Ang error na self-signed certificate in certificate chain ay kadalasang nangangahulugan na sumagot ang isang inspection proxy gamit ang sarili nitong certificate, at iyon ay isang chain na hindi kinikilala ng iyong runtime. Ang SSL EOF sa panahon ng handshake ay nangangahulugan na nagsara ang koneksyon bago maipadala ang anumang magagamit na certificate, at iyon ay isang middlebox na tumatanggi sa ClientHello, hindi talaga problema sa pagtitiwala.

Ang pagdaragdag ng flag na hindi secure ay nagpapawala sa lahat ng tatlong mensahe habang nananatili ang interception, at inaalis nito ang pagsusuring makakahuli sa isang tunay na attacker.

Hanapin ang bundle na aktwal na binabasa ng proseso

Ang corporate root na naka-install sa Windows store ay nag-aayos ng mga browser at .NET application na kumukunsulta sa system store. Wala itong ginagawa para sa isang build na tumatakbo sa loob ng container, na may sariling CA bundle, at wala rin para sa prosesong Python na gumagamit ng certifi o prosesong Node na gumagamit ng sarili nitong kasamang listahan. Binabasa ng Go ang system pool ng environment kung saan tumatakbo ang binary, ibig sabihin ang container at hindi ang laptop. Kaya ang isang makina ay gumagawa ng gumaganang browser at nabigong build tool nang sabay.

Tanungin ang tool sa halip na magpalagay. Ang python3 -c "import ssl; print(ssl.get_default_verify_paths())" ay nagpi-print ng mga file na kokonsultahin ng Python, at ang node -e "console.log(process.env.NODE_EXTRA_CA_CERTS)" ay nagpapakita kung may nakatakda nang override. Para sa container, patakbuhin ang parehong pagsusuri sa loob ng image, dahil iyon ang environment na aktwal na ginagamit ng build.

Mag-install ng isang root kung saan tumatakbo ang build

Kunin ang inspection root mula sa IT bilang PEM file at i-verify ang fingerprint nito sa hiwalay na channel bago ito pagkatiwalaan. Sa mga image na nakabase sa Debian, kopyahin ito sa /usr/local/share/ca-certificates/ at patakbuhin ang update-ca-certificates; ginagamit ng mga image ng pamilyang RHEL ang update-ca-trust pagkatapos ilagay ang file sa /etc/pki/ca-trust/source/anchors/. Sa build ng container, idagdag ang mga hakbang na iyon bago ang command na nabigo upang ma-cache ang layer sa itaas ng pag-install ng mga dependency.

Para sa lokal na devcontainer, i-mount ang PEM at patakbuhin ang parehong update command sa simula sa halip na i-bake ito sa personal na image na walang ibang makakagawa muli. Ang mga tool na may sariling bundle ay nangangailangan ng sarili nilang dokumentadong override: may setting ng certificate ang pip, may setting na cafile ang npm, at tinatanggap ng karamihan ng iba ang karaniwang environment variables.

Hindi ito katulad ng pagtanggap ng anumang certificate. Nagdaragdag ka ng isang partikular na root, na nakuha mula sa partidong gumagawa ng inspection, sa isang environment, at nananatiling naka-on ang verification para sa bawat ibang chain. Itala kung aling file ang idinagdag at kailan ito mag-eexpire, dahil ang inspection root ay nire-renew tulad ng anumang ibang CA.

Kapag namatay ang handshake bago ang isang certificate

Kung walang ipinakita, walang pagbabago sa trust store ang makakatulong. Ihambing ang parehong request habang bukas at sarado ang tunnel, pagkatapos suriin ang chain nang direkta gamit ang openssl s_client -connect host:443 -servername host -showcerts. Ang koneksyong natatapos sa labas ng VPN at na-reset sa loob nito ay desisyon sa patakaran ng middlebox, at ang lunas ay eksepsyon para sa host na iyon, hindi isa pang certificate. Hilingin na ang registry ng package o ang endpoint ng API ay makapasok nang hindi binabago.

Ang paghahati ng tunnel upang laktawan ng tool ang VPN ay umiiwas sa inspection para sa trapik na iyon, na maaaring lumabag sa patakaran at hindi ginagawang mapagkakatiwalaan ang tool.

Itala ang resulta bawat tool

Ang maikling tala na naglilista ng binary, ang trust file na binabasa nito, ang environment variable na nasa laro at ang aprubadong eksepsyon ay nagtitipid sa susunod na tao ng buong diagnosis. Panatilihin ang tala bawat tool at hindi bawat laptop, dahil ang laptop ay bihirang ang bagay na nagbago.

At panatilihing hiwalay ang dalawang pangungusap sa ticket: nag-install kami ng partikular na corporate root, at pinatay namin ang verification. Isa lang sa dalawa ang aksyong pang-suporta.