HI वहाँ। चूंकि किसी और ने उत्तर नहीं दिया है, इसलिए मैं इस पर एक दरार लेगा - लेकिन उचित चेतावनी - मैं एक जावा/यूनिक्स डेवलपर हूं, और आप जो कुछ पूछ रहे हैं वह माइक्रोसॉफ्ट विशिष्ट है। लेकिन यहाँ कुछ जवाब है:
1 - सीएन = एप्लिकेशन-server-NLB-होस्ट नाम और 'सर्वर को प्रमाणीकरण की' डोमेन CA में उद्देश्य के साथ एक प्रमाण पत्र जारी करें
उद्देश्य कुछ हद तक माइक्रोसॉफ्ट विशिष्ट चीज है। यह सही लगता है, लेकिन यह भी - आपको कुछ खास होने के लिए नियमित "कुंजी उपयोग" की आवश्यकता हो सकती है - एसएसएल केर्ट्स के लिए मैं उपयोगात्मक रूप से कुंजी एन्क्रिप्शन या कुंजी एग्रीमेंट का उपयोग करता हूं। कभी-कभी साइट डिजिटल सिग्नेचर का उपयोग करती है। सभी तीन आरएफसी में मान्य हैं, लेकिन कभी-कभी माइक्रोसॉफ्ट वर्क के बारे में डरता है। यदि आप माइक्रोसॉफ्ट सीए का उपयोग कर रहे हैं, तो मैं देखता हूं कि इसमें एसएसएल केर्ट्स के लिए सर्टिफिकेट प्रोफाइल है या बस इसका इस्तेमाल करें।
2 - 'ग्राहक प्रमाणीकरण' उद्देश्य के साथ फ्रंट-एंड बॉक्स के लिए प्रमाणपत्र जारी करें।
# 1 के समान - प्रत्येक प्रमाणपत्र को कुछ प्रकार के मूल कुंजी उपयोग की आवश्यकता होती है। जिन फ़ील्ड का आप उल्लेख कर रहे हैं वे विस्तारित उपयोग हैं, जो शायद आवश्यक भी हैं, लेकिन अनिवार्य नहीं हैं।
3 - बैक-एंड सर्टिफिकेट के सार्वजनिक को फ्रंट-एंड नोड्स स्टोरेज (और इसके विपरीत) में कुंजी आयात करें।
केवल अगर यह एक माइक्रोसॉफ्ट विशिष्ट बात है। उचित पीकेआई में, आपको विश्वसनीय सीए प्रमाणपत्र का आयात करना चाहिए जो एसएसएल पर हस्ताक्षर करता है, लेकिन आपको फ्रंट एंड में प्रत्येक एंड पॉइंट (बैक एंड सर्टिफिकेट) आयात करना नहीं चाहिए।मैं इसे केवल अपनी भरोसेमंद सीए श्रृंखलाओं को कॉन्फ़िगर करने के साथ प्रयास करूंगा और देख सकता हूं कि आप इसे काम पर ला सकते हैं - यह आपके आर्किटेक्चर को लंबे समय तक कहीं अधिक एक्स्टेंसिबल बना देगा।
4 - WCF कॉन्फ़िगर परिवहन सुरक्षा
5 के साथ net.tpc उपयोग करने के लिए - कॉन्फ़िगर सेवा व्यवहार (serviceCredentials अनुभाग)
6 - ग्राहक endpoint व्यवहार कॉन्फ़िगर करें (clientCredentials अनुभाग)
मुझे अच्छा लगता है ...
वहां से, मुझे नहीं लगता कि आप कुछ और याद कर चुके हैं। कुंजी आमतौर पर अस्पष्ट त्रुटि संदेशों के माध्यम से काम कर रहा है। प्रत्येक सिस्टम में यह कहने का अपना स्वयं का अचूक तरीका है कि एसएसएल हैंडशेक विफल होने पर क्या गलत है, इसलिए ज्यादातर यह गलत हो रहा है कि क्या गलत हो रहा है।
आपके द्वारा वर्णित समस्या से, मैं सोचता हूं कि आपकी सुरक्षा आर्किटेक्चर कह रही है कि आपको प्रमाणपत्र स्थिति जांच करने की आवश्यकता है। यह माप पर एक जोड़ है जो आपके सिस्टम को जांच करेगा कि सीए द्वारा प्रमाण पत्र निरस्त कर दिया गया है या नहीं। इसे काम करने के लिए काफी कुछ बुनियादी ढांचा लगता है (सीआरएल या ओसीएसपी), इसलिए मैं नहीं कहूंगा कि आपको अपनी टीम में गंभीर चर्चा के बिना इसके लिए जाना चाहिए कि आप किस जोखिम को कम करने की कोशिश कर रहे हैं और वे कितने संभावित हैं पाए जाते हैं।
किस होस्टनाम फ्रंटेंड प्रमाणपत्र जारी किए जाने चाहिए?
उनके द्वारा प्रस्तुत सर्वर का होस्टनाम।
होस्ट नामों के बारे में एक बात - कुछ सिस्टम ठीक से काम नहीं करेंगे जबतक कि आप पूरी तरह योग्य डोमेन नाम का उपयोग नहीं करते। दूसरों को इतना पसंद नहीं है। किसी भी मामले में - प्रमाण पत्र के विषय डीएन को विशिष्ट रूप से सेवा, एप्लिकेशन या सर्वर का प्रतिनिधित्व करना चाहिए।
सामने वाले नोड्स डीएमजेड में हैं इसलिए डोमेन (सीए) तक पहुंच नहीं होगी। क्या इससे कोई समस्या होगी?
आपको कोई समस्या नहीं होगी।
UNLESS - आपको उपर्युक्त प्रमाण पत्र स्थिति जांच करने की आवश्यकता है। अगर आपको प्रमाणपत्र की स्थिति को प्रमाणित करना है, तो आपको प्रमाण पत्र की स्थिति (सीआरएल या ओसीएसपी सर्वर) के बारे में जानकारी के लिए अंत बिंदु (यानी, डीएमजेड) से प्राप्त करने की आवश्यकता है। जटिल आधारभूत संरचनाओं में, यह आमतौर पर ओसीएसपी सर्वर के लिए पथ खोलकर किया जाता है - यह एक निश्चित डोमेन नाम या आईपी पर HTTP प्राप्त होता है, इसलिए आमतौर पर फ़ायरवॉल पर पथ खोलने के लिए यह बहुत बुरा नहीं होता है।
जैसा कि मैंने कहा- यह अपस्केल, गंभीर जोखिम शमन प्रकार समाधान होगा। यह आपके सिस्टम के लिए अधिक हो सकता है - मुझे आपके सिस्टम के बारे में पर्याप्त जानकारी नहीं है कि यह आपको बताने के लिए कि क्या यह जरूरी है या नहीं।