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 पत्त्याने तपासणी करताना वापरकर्त्यांना मिळणाऱ्यापेक्षा वेगळे प्रमाणपत्र दिसू शकते. अयशस्वी नावाचा संच दुरुस्त करून तपासा आणि घटना बंद करण्यापूर्वी साइन-इन चाचणी पुन्हा करा.