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

DNS सही रूपमा समाधान हुँदै गर्दा लोड नहुने वेब लगइन पृष्ठ सामान्यतया DNS समस्या होइन। यदि सेवा लगले खाली प्रमाणपत्र-बन्डल मार्ग वा वेब प्रमाणपत्र र निजी कुञ्जीका लागि PEM पार्सिङ असफलता उल्लेख गर्छ भने, HTTPS श्रोतासँग प्रयोगयोग्य सामग्री हुँदैन र नाम समाधानले सहयोग गर्दैन। सुधार तीन कन्फिगरेसन कुञ्जीमा छ र कुनै पनि VPN ग्राहक प्रमाणपत्र पुनः जारी गर्न आवश्यक पर्दैन।

तीन कुञ्जीले वास्तवमा के संकेत गर्छन्

अनुकूलित वेब प्रमाणपत्र सेट cs.cert, cs.priv_key र cs.ca_bundle द्वारा वर्णन गरिन्छ। प्रत्येकले फाइलको मार्ग भण्डारण गर्छ र वेब सेवाले तीनवटै सँगै प्रयोग गर्छ। गलत कुञ्जी भएको प्रमाणपत्र, वा वास्तवमा पात प्रमाणपत्र भएको शृङ्खला फाइल, खाली मानजस्तै असफल हुन्छ।

यी कुञ्जी Admin र Client वेब इन्टरफेसका हुन्। ती VPN ग्राहकलाई प्रमाणपत्र जारी गर्ने PKI भन्दा छुट्टै छन्, त्यसैले बदल्नका लागि प्रोफाइल, सर्भर कुञ्जी वा प्रमाणपत्र अधिकारलाई छुन आवश्यक पर्दैन। सम्पूर्ण 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 नाम, प्रमाणपत्रको पहिचान र त्यो नामको शृङ्खला जाँच्नुहोस्, त्यसपछि Admin र Client दुवै वेब इन्टरफेस लोड गरी साइन-इन पूरा गर्नुहोस्। पोर्ट जाँचले यीमध्ये केही पनि प्रमाणित गर्दैन।

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