Access Server में वेब प्रमाणपत्र त्रुटि: खाली CA बंडल ठीक करें

DNS सही ढंग से हल होने पर भी जो वेब लॉगिन पेज लोड नहीं होता, वह आमतौर पर DNS समस्या नहीं है। यदि सेवा लॉग खाली प्रमाणपत्र-बंडल पथ या वेब प्रमाणपत्र और निजी कुंजी के लिए PEM पार्स विफलता का उल्लेख करता है, तो HTTPS श्रोता के पास कोई उपयोगी सामग्री नहीं है और नाम-समाधान मदद नहीं करेगा। मरम्मत तीन कॉन्फ़िगरेशन कुंजियों में है और इसमें किसी VPN क्लाइंट प्रमाणपत्र को फिर से जारी करने की आवश्यकता नहीं है।

तीन कुंजियाँ वास्तव में किस ओर इशारा करती हैं

कस्टम वेब प्रमाणपत्र सेट cs.cert, cs.priv_key और cs.ca_bundle द्वारा वर्णित है। प्रत्येक फ़ाइल का पथ रखता है, और वेब सेवा तीनों को एक साथ उपयोग करती है। गलत कुंजी वाला प्रमाणपत्र, या ऐसी श्रृंखला फ़ाइल जो वास्तव में लीफ प्रमाणपत्र है, खाली मान की तरह विफल होती है: श्रोता ऐसी श्रृंखला नहीं बना सकता जिसे ब्राउज़र स्वीकार करे।

ये कुंजियाँ एडमिन और क्लाइंट वेब इंटरफ़ेस की हैं। ये उस PKI से अलग हैं जो VPN क्लाइंट को प्रमाणपत्र जारी करती है, इसलिए बदलने के लिए क्लाइंट प्रोफ़ाइल, सर्वर कुंजी या प्रमाणपत्र प्राधिकरण को छूने की आवश्यकता नहीं है। वेब TLS विफलता को पूरी PKI दोबारा बनाने का कारण मानना यहाँ सबसे महँगी गलती है।

एक अंतर समय बचाता है: स्पष्ट रूप से खाली कस्टम मान किसी ओवरराइड के न होने की स्थिति से भिन्न है। पहला पार्सर को खाली पथ देता है, लॉग पंक्ति यही कहती है। दूसरा Access Server को उसकी अपनी सामग्री पर छोड़ता है, इसीलिए कुछ होस्ट अपग्रेड के बाद ठीक चलते हैं और कुछ नहीं।

मौजूद फ़ाइल भी क्यों पार्स नहीं होती

पार्सर फ़ाइल के भीतर के लेबल वाले ब्लॉक पढ़ता है, फ़ाइल का नाम नहीं। निजी कुंजी वाला .crt, जहाँ एक प्रमाणपत्र की अपेक्षा थी वहाँ एक ही जुड़े ब्लॉक के रूप में लिखी श्रृंखला, या अंतिम पंक्ति कटी हुई फ़ाइल, सभी अस्वीकार होती हैं। RFC 7468 वे पठनीय लेबल इसलिए परिभाषित करता है क्योंकि वही पाठक को बताते हैं कि आगे किस प्रकार की वस्तु है।

वस्तुओं की जाँच करें, एक्सटेंशन की नहीं। Linux होस्ट पर openssl x509 -noout -subject -issuer -in server.pem और openssl pkey -noout -check -in key.pem दो महत्वपूर्ण प्रश्नों का उत्तर देते हैं, और दोनों का मापांक या सार्वजनिक कुंजी तुलना करने से सिद्ध होता है कि वे एक साथ हैं। निजी कुंजी का आउटपुट टिकट और चैट लॉग से दूर रखें; जाँच को फ़िंगरप्रिंट चाहिए, कुंजी नहीं।

खाली पथ उतनी ही शंका का पात्र है जितनी खराब फ़ाइल, क्योंकि दोनों अस्पष्ट आगे की त्रुटियाँ देते हैं। यदि लॉग कहता है कि बंडल पथ खाली है, तो फ़ाइल को डीबग करने से पहले संग्रहीत मान पढ़ें।

जानबूझकर फ़ॉलबैक पर लौटें

Access Server के CLI में सत्यापन जाँच है जो तीन पथों को तर्क के रूप में लेती है और बताती है कि सेट उपयोगी है या नहीं। नीचे के पथ उदाहरण हैं; इन्हें होस्ट के संरक्षित स्थानों से बदलें:

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

चालू सेवा को छूने से पहले परिणाम पढ़ें, और उसके बाद ही मान आयात करें तथा स्थापित संस्करण के लिए प्रलेखित संक्रिया से लागू करें। आधिकारिक CLI ट्यूटोरियल सत्यापन, कॉन्फ़िगरेशन डेटाबेस में आयात और लागू करने के चरण को कवर करता है, और उसका संस्करण किसी भी सारांश से अधिक महत्वपूर्ण है।

उपयोगकर्ता जो नाम टाइप करते हैं उसे सत्यापित करें

जब कस्टम सामग्री टूटी हो और मान्य अंतर्निहित फ़ॉलबैक अभी भी मौजूद हो, तो प्रलेखित पुनर्प्राप्ति तीन कस्टम ओवरराइड हटाकर Access Server को वह फ़ॉलबैक उपयोग करने देना है। पहले कंसोल पहुँच और वर्तमान कॉन्फ़िगरेशन का बैकअप व्यवस्थित करें, क्योंकि जिस सेवा को आप पुनः आरंभ करेंगे वही प्रशासनिक इंटरफ़ेस परोसती है।

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

पूरा कॉन्फ़िगरेशन डेटाबेस मिटाना प्रमाणपत्र की मरम्मत नहीं है। उन तीन कुंजियों को लक्षित करें, लागू करें और पुष्टि करें कि वेब इंटरफ़ेस उत्तर दे रहा है। web-ssl निर्देशिका की स्व-हस्ताक्षरित फ़ाइलें फ़ॉलबैक संसाधन हैं, कार्यक्षेत्र नहीं: उन्हें ओवरराइट या पुनः उत्पन्न करने से एकमात्र कार्यशील सामग्री हट सकती है।

फ़ॉलबैक लागू होने के बाद ब्राउज़र अलग प्रमाणपत्र दिखाएगा, इसकी अपेक्षा करें। यही सही परिणाम है, और उत्तर यह है कि इसे अपनी विश्वसनीय प्रशासनिक प्रक्रिया से सत्यापित करें, उपयोगकर्ताओं को हर चेतावनी छोड़ना न सिखाएँ।

पुनर्प्राप्ति सफल साइन-इन के बाद ही पूरी होती है

TCP श्रोता दिखते ही पुनर्प्राप्ति पूरी नहीं होती। DNS नाम, प्रमाणपत्र की पहचान और उस नाम की श्रृंखला सत्यापित करें, फिर एडमिन और क्लाइंट दोनों वेब इंटरफ़ेस लोड करें और साइन-इन पूरा करें। पोर्ट जाँच इनमें से कुछ भी सिद्ध नहीं करती।

Access Server 3.1 और बाद के संस्करण प्रत्येक SNI होस्टनाम के लिए अलग वेब प्रमाणपत्र भी परोस सकते हैं। यदि यह कॉन्फ़िगर है, तो डिफ़ॉल्ट कुंजियाँ और होस्टनाम-विशिष्ट प्रविष्टियाँ अलग सेट हैं, और IP पते से परीक्षण करने पर उपयोगकर्ताओं को मिलने वाले प्रमाणपत्र से भिन्न प्रमाणपत्र आसानी से दिख सकता है। विफल नाम का सेट ठीक करें और सत्यापित करें, फिर घटना बंद करने से पहले साइन-इन परीक्षण दोहराएँ।