TLS त्रुटी फक्त कॉर्पोरेट VPN वर: योग्य ट्रस्ट स्टोअर दुरुस्त करा

Go बिल्ड, Composer इन्स्टॉल आणि Python क्लायंट हे सर्व घरी चालतात आणि सर्व कंपनीच्या VPN मध्ये अयशस्वी होतात। हा नमुना तुम्हाला मार्गाबद्दल सांगतो, अनुप्रयोगाबद्दल नाही। टनेलवरील काहीतरी तुमची प्रक्रिया जी प्रमाणपत्र साखळी पाहते ती बदलले, किंवा साखळी येण्यापूर्वीच हातमिळवणी रीसेट केली। दोन्ही बिघाड टर्मिनलमध्ये सारखे दिसतात आणि पूर्णपणे वेगळ्या प्रतिक्रिया मागतात।

तीन संदेश, तीन यंत्रणा

x509 certificate signed by unknown authority त्रुटीचा अर्थ असा की साखळी तयार झाली आणि तिचे रूट ती प्रक्रिया जे ट्रस्ट स्टोअर वापरते त्यात नाही। self-signed certificate in certificate chain त्रुटीचा अर्थ सहसा असा की तपासणी प्रॉक्सीने स्वतःच्या प्रमाणपत्राने उत्तर दिले, आणि ती अशी साखळी आहे जी तुमचे रनटाइम ओळखत नाही। हातमिळवणीदरम्यान SSL EOF म्हणजे कोणतेही उपयुक्त प्रमाणपत्र पाठवण्यापूर्वीच कनेक्शन बंद झाले, आणि ते ClientHello नाकारणारे मध्यस्थ उपकरण आहे, ट्रस्टची समस्या अजिबात नाही।

असुरक्षित फ्लॅग जोडल्यास तीनही संदेश गायब होतात पण इंटरसेप्शन जागेवरच राहते, आणि खऱ्या हल्लेखोराला पकडणारी तपासणीही ते काढून टाकते।

प्रक्रिया प्रत्यक्षात वाचते तो बंडल शोधा

Windows स्टोअरमध्ये इन्स्टॉल केलेले कॉर्पोरेट रूट सिस्टम स्टोअर पाहणारे ब्राउझर आणि .NET अनुप्रयोग दुरुस्त करते। कंटेनरमध्ये चालणाऱ्या बिल्डसाठी ते काहीही करत नाही, कारण तिचे स्वतःचे CA बंडल असते, आणि certifi वापरणाऱ्या Python प्रक्रियेसाठी किंवा स्वतःची समाविष्ट यादी वापरणाऱ्या Node प्रक्रियेसाठीही काहीही करत नाही। Go बायनरी ज्या वातावरणात चालते त्या वातावरणाचा सिस्टम पूल वाचते, म्हणजे कंटेनर, लॅपटॉप नाही। त्यामुळे एकच मशीन एकाच वेळी चालणारा ब्राउझर आणि अयशस्वी होणारे बिल्ड साधन देते।

गृहीत धरण्याऐवजी साधनालाच विचारा। python3 -c "import ssl; print(ssl.get_default_verify_paths())" Python ज्या फाइलींचा सल्ला घेईल त्या छापते, आणि node -e "console.log(process.env.NODE_EXTRA_CA_CERTS)" ओव्हरराइड आधीच सेट आहे का ते दाखवते। कंटेनरसाठी, तीच तपासणी इमेजच्या आत चालवा, कारण बिल्ड प्रत्यक्षात तेच वातावरण वापरते।

बिल्ड जिथे चालते तिथे एक रूट इन्स्टॉल करा

तपासणी रूट IT कडून PEM फाइल म्हणून घ्या आणि विश्वास ठेवण्यापूर्वी वेगळ्या चॅनेलने तिची बोटांची खूण तपासा। Debian आधारित इमेजवर, ती /usr/local/share/ca-certificates/ मध्ये कॉपी करा आणि update-ca-certificates चालवा; RHEL कुटुंबातील इमेज फाइल /etc/pki/ca-trust/source/anchors/ मध्ये ठेवल्यानंतर update-ca-trust वापरतात। कंटेनर बिल्डमध्ये, अयशस्वी होणाऱ्या आदेशापूर्वी ही पायरी जोडा जेणेकरून स्तर अवलंबित्व इन्स्टॉलच्या वर कॅशे होईल।

स्थानिक devcontainer साठी, PEM माउंट करा आणि सुरुवातीला तोच अद्ययावत आदेश चालवा, त्याऐवजी तो इतर कोणीही पुनरुत्पादित करू शकत नाही अशा वैयक्तिक इमेजमध्ये भाजू नका। स्वतःचे बंडल आणणाऱ्या साधनांना स्वतःचे दस्तऐवजीकृत ओव्हरराइड लागते: pip मध्ये प्रमाणपत्र सेटिंग आहे, npm मध्ये cafile सेटिंग आहे, आणि उर्वरित बहुतेक मानक वातावरण चल स्वीकारतात।

हे कोणतेही प्रमाणपत्र स्वीकारण्यासारखे नाही। तुम्ही तपासणी करणाऱ्या पक्षाकडून मिळालेले एक विशिष्ट रूट एका वातावरणात जोडता, आणि इतर प्रत्येक साखळीसाठी पडताळणी चालूच राहते। कोणती फाइल कधी जोडली आणि कधी संपेल ते नोंदवा, कारण तपासणी रूट इतर कोणत्याही CA प्रमाणे नूतनीकरण होते।

जेव्हा हातमिळवणी प्रमाणपत्रापूर्वी मरते

काहीही सादर न केल्यास, ट्रस्ट स्टोअरमधील कोणताही बदल मदत करणार नाही। तीच विनंती टनेल चालू आणि बंद असताना तुलना करा, नंतर openssl s_client -connect host:443 -servername host -showcerts ने साखळी थेट तपासा। जे कनेक्शन VPN बाहेर पूर्ण होते आणि आत रीसेट होते ते मध्यस्थ उपकरणाचा धोरण निर्णय आहे, आणि उपाय त्या होस्टसाठी अपवाद आहे, दुसरे प्रमाणपत्र नाही। पॅकेज रजिस्ट्री किंवा API एंडपॉइंट बदल न करता जाऊ देण्याची विनंती करा।

साधन VPN टाळावे म्हणून टनेल विभाजित करणे त्या रहदारीसाठी तपासणी टाळते, जे धोरणाचे उल्लंघन करू शकते आणि साधन विश्वासार्ह करत नाही।

प्रत्येक साधनासाठी निकाल लिहा

बायनरी, ती वाचते ती ट्रस्ट फाइल, खेळातील वातावरण चल आणि मंजूर अपवाद यांची यादी असलेली छोटी नोंद पुढील व्यक्तीची संपूर्ण निदान बचत करते। नोंद लॅपटॉपनुसार नाही तर साधनानुसार ठेवा, कारण जे बदलले ते लॅपटॉप असणे दुर्मिळ आहे।

आणि तिकिटात दोन वाक्ये वेगळी ठेवा: आम्ही एक विशिष्ट कॉर्पोरेट रूट इन्स्टॉल केले, आणि आम्ही पडताळणी बंद केली। त्यांपैकी फक्त एकच सहाय्य कृती आहे।