PKI Certs का उपयोग कर वेब प्रमाणीकरण


14

मैं पीकेआई को एक वैचारिक दृष्टिकोण से बहुत अच्छी तरह से समझता हूं - अर्थात निजी कुंजी / सार्वजनिक कुंजी - उनके पीछे का गणित, एक प्रमाण पत्र पर हस्ताक्षर करने के लिए हैश और एन्क्रिप्शन का उपयोग, डिजिटल हस्ताक्षर लेनदेन या दस्तावेज़ आदि मैंने उन परियोजनाओं पर भी काम किया है जहां ओपनस्लैक सी पुस्तकालयों का उपयोग संचार और प्रमाणीकरण हासिल करने के लिए समारोहों के साथ किया गया था। मैं भी Opensl कमांड लाइन टूल से बेहद परिचित हूं।

हालाँकि, मेरे पास वेब आधारित PKI सक्षम परियोजनाओं के साथ बहुत कम अनुभव है और इसलिए मैं इसे बेहतर समझने के लिए एक व्यक्तिगत परियोजना को डिज़ाइन और कोड करने का प्रयास कर रहा हूं।

आवश्यकताएँ

यह एक बैंक के लिए वेबसाइट है। सभी इंटरनेट बैंकिंग उपयोगकर्ताओं को कुछ ज्ञात सीए द्वारा जारी किए गए किसी भी प्रमाण पत्र का उपयोग करने की अनुमति है (सत्यापन, Thawte, सौंपना आदि)। उपयोगकर्ता के लिए प्रमाण पत्र खरीदने के लिए बैंक जिम्मेदार नहीं है। ये प्रमाण पत्र बैंकों की वेबसाइट पर प्रमाणीकरण के लिए उपयोग किए जाएंगे। प्लेटफ़ॉर्म / ओएस आदि अभी भी तय नहीं हैं।

डिज़ाइन

मैं सोच रहा था कि प्रमाणीकरण करने का सबसे अच्छा तरीका क्या है।

  1. मैंने देखा कि अपाचे के पास 2 तरीके ssl को सक्षम करने का एक तरीका है - इस मामले में, मुझे लगता है कि वेबसाइट पर नेविगेट करने से उपयोगकर्ता से स्वचालित रूप से एक प्रमाण पत्र मांगा जाएगा। लेकिन मुझे यकीन नहीं है कि यह पर्याप्त है क्योंकि ऐसा लगता है कि यह सब सत्यापित करता है कि क्या कोई प्रमाण पत्र किसी विश्वसनीय सीए द्वारा हस्ताक्षरित है और यह भी हो सकता है कि क्या यह प्रमाण पत्र की विषय पंक्तियों की एक सफेद सूची में आता है आदि लेकिन यह पर्याप्त नहीं है एक बैंक मामले के लिए क्योंकि आपको एक प्रमाण पत्र के साथ एक बैंकुसराइड को जोड़ने में सक्षम होना चाहिए।

  2. IIS एक ऐसा तरीका है जिसके द्वारा मेरे पास सक्रिय निर्देशिका में प्रत्येक उपयोगकर्ता के लिए एक प्रमाणपत्र संग्रहीत किया जा सकता है। यह वही है जो मैंने कुछ MSDN लेखों को पढ़ने से समझा। आप IIS में 2 तरीके से SSL चालू करते हैं और फिर जब उपयोगकर्ता वेबसाइट पर नेविगेट करने का प्रयास करता है, तो IIS स्वीकृत CA की सूची के साथ ब्राउज़र को एक अनुरोध भेजेगा और ब्राउज़र उपयोगकर्ता को अपने सर्टिफिकेट से एक उपयुक्त प्रमाणपत्र लेने देगा और उसे भेज देगा to backend। मैं मान रहा हूँ कि IIS २ काम करेगा

    • सुनिश्चित करें कि उपयोगकर्ता के पास सर्टिफिकेशन के तहत (कवर वार्ताओं के तहत) निजी कुंजी है
    • AD उपयोगकर्ता-प्रमाणपत्र मैपिंग के आधार पर, IIS उपयोगकर्ता नाम को एप्लिकेशन को रिपोर्ट करेगा।
  3. यह करने के लिए वेबसर्वर के आधार पर क्रिप्टो कार्यों को कॉल करके प्रमाणीकरण की खोज करें।

    • एक उपयोगकर्ता स्क्रीन दिखाएं जहां वह एक प्रमाण पत्र अपलोड करता है और आवेदन सुनिश्चित करता है कि उपयोगकर्ता के पास सर्टिफिकेशन के लिए निजी कुंजी है (फ्रंट-एंड से पूछकर सर्टिफिकेट का उपयोग करके कुछ स्ट्रिंग पर हस्ताक्षर करने के लिए)।
    • एप्लिकेशन में एक डेटाबेस होता है, जिसमें कुछ डेटा संग्रहीत होता है, जो प्रत्येक उपयोगकर्ता को अपने उपयोगकर्ता के लिए मैप करने की अनुमति देता है। यह हो सकता है
    • प्रत्येक उपयोगकर्ता के लिए पूरे प्रमाण पत्र
    • प्रत्येक उपयोगकर्ता आईडी के अनुरूप सीए और प्रमाणित सीरियल नंबर।

मैं सोच रहा था कि आमतौर पर इस्तेमाल की जाने वाली विधि कौन सी है? सर्वोत्तम अभ्यास क्या हैं? अगर मुझे # 3 के साथ जाना चाहिए, तो ऐसा करने के सबसे अच्छे तरीके क्या हैं?

कुछ जो आसानी से स्मार्टफोन ऐप के साथ भी काम कर सकते हैं, एक अतिरिक्त बोनस होगा।

अपडेट करें

मुझे अपने कथन को स्पष्ट करें "प्रमाणीकरण भाग को स्वयं कोड करें" क्योंकि कुछ उत्तरों से लगता है कि यह गलत समझा गया है - स्पष्ट नहीं होने के लिए मेरा बुरा।

इसका मतलब यह नहीं है कि मैं क्रिप्टो सामान खुद लिखता हूं। इसका मतलब सिर्फ इतना है कि मैं वास्तव में आईआईएस या किसी अन्य वेबसर्वर के आधार पर इसके बजाय स्पष्ट रूप से क्रिप्टो दिनचर्या को कॉल करूंगा।



@adnan - मैंने पहले ही अपने प्रश्न में "आपसी SSL के साथ Apache" लिखा है और यह मेरे लिए काम क्यों नहीं करेगा।
user93353

1
क्यों घटता है? यदि व्यक्ति एक टिप्पणी छोड़ सकता है कि प्रश्न में क्या गलत है - मैं इसे सुधारने की कोशिश कर सकता हूं।
user93353

हाँ मैंने देखा है। मैं यह नहीं कह रहा हूं कि यह एक डुप्लिकेट है, मैं सिर्फ यह कह रहा हूं कि यह संबंधित है। अपने प्रश्न के पाठक के लिए अधिक जानकारी।
आदि

@ अदनान - ठीक है - मैं सिर्फ इस बात से चिंतित था कि लोग लिंक को देख सकते हैं और अपना प्रश्न डुप्लिकेट के रूप में बंद करने के लिए मतदान कर सकते हैं :-)
user93353

जवाबों:


9

जबकि मैं वास्तव में मुद्दे से जवाब देना चाहता था, मुझे लगता है कि मैं इस विषय को इस विषय से टकराऊंगा:

प्राधिकरण / प्रमाणीकरण

ठीक है, पहले चीजें पहले। अपने उदाहरण के लिए, आपको दोनों की आवश्यकता है:

  • प्रमाणीकरण - प्रमाण है कि उपयोगकर्ता वह है जो वह कहता है कि वह है। आपने PKI को चुना है, आपके प्रमाणीकरण के रूप में निजी कुंजी के निहित प्रमाण के साथ।
  • प्राधिकरण - उपयोगकर्ता का वह कनेक्शन जो उसे करने की अनुमति है। यह लॉगिन खातों और अनुमत खातों तक पहुंच प्राप्त करने के बीच का कनेक्शन बिंदु है। खाता और खाता क्षमताओं के प्रमाण पत्र की मैपिंग प्राधिकरण है।

प्राधिकरण-वार, आपको उस प्रक्रिया का पता लगाने की समस्या है जिसके द्वारा आप अपने उपयोगकर्ता के विषय DN को उनके बैंक खाते से जोड़ते हैं। लेन-देन की गंभीरता को देखते हुए, आप निश्चित रूप से इसके लिए एक मजबूत प्रक्रिया चाहते हैं, और यहां कोई एक सही तरीका नहीं है। आपको बैंक के साथ परामर्श करना होगा, और शायद यह वकील है, यह पता लगाने के लिए कि यह नीति के अनुसार कैसे किया जाए।

एसएसएल, क्लाइंट / सर्वर प्रमाणीकरण, निजी कुंजी का प्रमाण

SSL प्रोटोकॉल में हमेशा क्लाइंट प्रमाणीकरण के लिए अतिरिक्त वैकल्पिक सेटिंग के साथ सर्वर प्रमाणीकरण शामिल होता है। आप इसमें # 1 के साथ सही हैं। Apache एक सेटिंग प्रदान करता है जो PKI द्वारा क्लाइंट प्रमाणीकरण को जोड़ता है, और आप इसे विश्वसनीय CA की सूची के साथ प्रावधान कर सकते हैं। SSL सत्र की स्थापना के दौरान जिसे PKI के माध्यम से क्लाइंट प्रमाणीकरण की आवश्यकता होती है - आपको निजी कुंजी का प्रमाण मिलेगा।

या तो विकल्प # 1 या विकल्प # 2 यह प्रदान करेगा - Apache और IIS दोनों को इस तरह कॉन्फ़िगर किया जा सकता है। सबसे अच्छा अभ्यास, मैं या तो अपने खुद के समाधान रोलिंग पर एक ले जाएगा। # 3 खतरनाक ढंग से "अपना क्रिप्टो न लिखें" नियम के करीब आता है। यह मानते हुए कि आप अपने लेन-देन को एक प्रमाणित एसएसएल सत्र की उपस्थिति में बाँध सकते हैं, अपने स्वयं के रोल करने का कोई कारण नहीं है।

इसके अलावा - या तो विकल्प # 1 या विकल्प # 2 में, पूरे प्रमाण पत्र पर अपने हाथों को प्राप्त करने का एक तरीका है, और वहां से, प्रमाण पत्र के किसी भी हिस्से में। आमतौर पर विषय डीएन और / या प्रमाणपत्र क्रमांक का उपयोग प्राधिकरण उद्देश्यों के लिए उपयोगकर्ता की पहचान निर्धारित करने के लिए किया जाता है।

"सामान्य उपयोग" के संदर्भ में - सभी प्रमुख वेब सर्वर बहुत आम हैं। IIS, Apache, Tomcat, और कई अन्य क्लाइंट SSL SSL के साथ कॉन्फ़िगर किए जा सकते हैं। वहां से निर्णय काफी हद तक समग्र कार्यान्वयन पर आधारित है। प्रमुख वेब सर्वरों के पास एसएसएल सत्र में प्रदान किए गए प्रमाण पत्र तक पहुंचने के सभी तरीके हैं, जो कि आपको अधिक विस्तृत सत्यापन के लिए आवश्यक है।

प्रमाण पत्र सत्यापन

कम से कम, आपको इसकी आवश्यकता होगी:

  • SSL सत्र सेटअप करें
  • प्रमाणपत्र खींचें (अधिकांश वेब सर्वर प्रमाणपत्र की हस्ताक्षर और निजी कुंजी के प्रमाण की जांच करेंगे)
  • प्रमाणपत्र की वैधता तिथि सत्यापित करें (किसी वेबसर्वर के साथ नहीं दी गई)
  • वह प्रमाणपत्र देखें, जिसके लिए यह प्रमाणपत्र एक्सेस कर सकता है

बैंकिंग के उच्च दांव को देखते हुए, आप प्रमाणपत्र के निरस्तीकरण की स्थिति को भी सत्यापित करना चाह सकते हैं - यदि उपयोगकर्ता की निजी कुंजी खो गई है या चोरी हो गई है, तो उनके प्रमाणपत्र को निरस्त कर दिया जाना चाहिए।

IIS में OCSP या CRL सत्यापन के लिए हुक हो सकते हैं - यह एक अधिक व्यापक (हाथ पकड़!) प्रणाली का प्रकार है, लेकिन मुझे अपने सिर के ऊपर से याद नहीं है। मुझे यह भी याद नहीं है कि क्या यह आपको इसके लिए Microsoft उत्पादों का उपयोग करने के लिए मजबूर करने वाला है। अपाचे के लिए, आपको लगभग OCSP / CRL चेक पर निश्चित रूप से कोड या जोड़ना होगा। मेरा मानना ​​है कि एसएसएल सत्र की स्थापना के दौरान इसमें हुक होते हैं - आमतौर पर एसएसटी सत्र की स्थापना के बाद यह चेक एक बार किया जाता है।

प्राधिकरण

# 1 बनाम # 2 पर - आप सही कह रहे हैं कि IIS ने कुछ कार्यक्षमता में बनाया है जो SSL सत्र में प्रदान किए गए प्रमाणपत्र को AD रिपॉजिटरी से जोड़ देगा। यह उन मामलों में से एक है जहां Microsoft अतिरिक्त मील जाता है ताकि इसे खरीदने और इसका अधिक उपयोग करने में आसानी हो। :) इस प्रश्न के दायरे से परे और मेरे तात्कालिक स्मरण से परे आईआईएस में ईआई के संबंध कैसे हैं, इसकी बारीकियां हैं। मैंने IIS और AD के साथ कुछ बहुत ही शानदार सामान किया है, और मेरा सामान्य विचार यह है कि जब आप AD रिपॉजिटरी से प्रमाण पत्र के आधार पर उपयोगकर्ता नाम को खींचने में अपेक्षाकृत सरल होते हैं - तो आप शायद ठीक हैं। जब आप डेटा संग्रहण, विषम AD लुकअप और विशेष रूप से पागल (लेकिन वैध) चीजों के अधिक जटिल मुद्दों में शामिल हो जाते हैं, तो आप '

IIS के साथ, यहां तक ​​कि अभी भी - आपको अपने AD संरचना में, या कहीं और कुछ जोड़ना होगा, उपयोगकर्ता नाम को बैंक खाते में बांधना होगा। आमतौर पर बैंकिंग में, एक उपयोगकर्ता के कई खाते होते हैं। और 2 उपयोगकर्ताओं का एक संयुक्त खाता हो सकता है, इसलिए यह कई से कई संबंध है।

# 1 - हां के लिए, आपको अपना लुकअप लिखना होगा। आपको कोड की आवश्यकता है: - एक डेटाबेस या LDAP पदानुक्रम उपयोगकर्ता को प्रमाण पत्र और उपयोगकर्ता को उपयोगकर्ता बैंक खातों से जोड़ता है। किसी प्रमाणपत्र का गारंटीकृत अनन्य भाग क्रम संख्या + जारीकर्ता DN है। अक्सर विषय DN काम करेगा, लेकिन सभी PKI सिस्टम में इसकी गारंटी नहीं है।

यह आमतौर पर है कि डेवलपर्स Apache के साथ उच्च अंत प्रमाणीकरण के लिए PKI का उपयोग कैसे करते हैं। इन प्रणालियों की एक संख्या में काम करने के बाद, मुझे अभी तक आसान प्राधिकरण के पुन: उपयोग के एक मामले का सामना करना पड़ा है, इसलिए मैं वास्तव में इसे कभी भी एक विशाल ऋण के रूप में नहीं देखता हूं - मुझे कुछ विशेष तरीके से भूमिकाएं / विशेषाधिकार प्राप्त होने हैं। कभी आसान नहीं।

यह # 1 और # 3 के मिश्रण की तरह लगता है - मेरी मजबूत सलाह होगी - एसएसएल सत्र उत्पन्न करने के लिए आप जो भी एप्लिकेशन / वेब सर्वर का उपयोग करते हैं उसकी मूल क्षमताओं का उपयोग करें। यही कारण है कि मानक, सर्वोत्तम अभ्यास, तरीके से प्रमाणपत्र क्वेरी के साथ ब्राउज़र को सर्वर सेटअप करने दिया जाएगा। वहां से, अपाचे के साथ, आपको स्वयं प्राधिकरण प्रणाली को रोल करने की आवश्यकता होगी। IIS Microsoft के विचार प्रदान करेगा कि यह आपके लिए कैसे काम करना चाहिए।

ज्ञात गोत्र

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

विशेष रूप से, पिछली बार मैंने ऐसा किया था, बल कोडिंग और सत्र के समय से बाहर होने का प्रश्न बहुत बड़ी बात थी।

स्मार्टफोन्स

अच्छा। भाग्य। मैं कह सकता हूं। मैं बिल्कुल भी मोबाइल ऐप डेवलपर नहीं हूं, लेकिन इस तरह से मेरी धारणा यह है कि औसत स्मार्ट फोन में, पीकेआई सर्टिफिकेट हैंडलिंग सब बराबर या न के बराबर है।

मैं गलत साबित होना पसंद करूंगा।


2

व्यक्तिगत प्रमाण पत्र समय-समय पर प्रमाणपत्र के नवीकरण के लिए अच्छी तरह से काम करते हैं (जिसके पीछे काफी मजबूत प्रक्रिया है) और इसे "पासवर्ड-कम" प्रमाणीकरण के रूप में लागू किया जा सकता है जो ग्राहकों को पसंद आता है

लेकिन जहां यह विफल है

  • प्रति प्रमाणपत्र लागत
  • आधुनिक ब्राउज़रों के साथ संगतता
  • अंत उपयोगकर्ताओं को प्रमाण पत्र निकालने और निजी कुंजी असुरक्षित रूप से संग्रहीत करना

ज्ञात हो कि sha-2 पर हस्ताक्षर करने वाले आधुनिक व्यक्तिगत प्रमाण पत्र iPad पर सफारी और बहुत सारे आधुनिक ब्राउज़रों के साथ काम नहीं करते हैं। ऐसा इसलिए है क्योंकि व्यक्तिगत प्रमाण पत्र वास्तव में कभी नहीं हटाए गए जैसे प्रमाणीकरण प्राधिकरण संगठनों ने सोचा था कि यह हो सकता है। 30,000 प्रमाण पत्र जारी करना (हम क्या करते हैं) प्रति प्रमाणपत्र के बारे में कुछ हार्डवेयर टोकन प्रकारों के रूप में खर्च होते हैं।

ग्राहकों को अपने स्वयं के प्रमाण पत्र खोजने की अनुमति देने की आपकी रणनीति वास्तव में मान्य नहीं है। आजकल व्यक्तिगत प्रमाणपत्रों के आपूर्तिकर्ताओं को खोजना मुश्किल है और वे काफी महंगे हैं - आपको यह सुनिश्चित करने की आवश्यकता है कि व्यवसाय का मामला काम करता है अन्यथा ग्राहक बस इस पर खरीद नहीं करेंगे।


'आजकल मेरे देश में निजी प्रमाणपत्रों के आपूर्तिकर्ताओं को खोजना मुश्किल है -' नहीं। लोग बैंकिंग के लिए और इलेक्ट्रॉनिक रूप से टैक्स रिटर्न दाखिल करने के लिए भी सेर का उपयोग करते हैं। इसलिए इसे प्राप्त करना बहुत आसान है। मैंने सिर्फ थावे, वेरिसाइन जैसे सीए का उदाहरण दिया ताकि लोगों को पता चले कि मैं बाहरी सीए के बारे में बात कर रहा हूं।
user93353

1

ठीक है, यहाँ बहुत कुछ चल रहा है। पहले चीजें पहले, क्लाइंट सर्टिफिकेशन ऑथेंटिकेशन बेकार है अगर यह एंडपॉइंट पर सपोर्ट नहीं है। इसलिए, हमारे पास स्मार्ट एप्स के लिए क्लाइंट प्रमाणीकरण की मूल बातें शामिल करने वाले इंट्रेपिडस का एक शानदार पोस्ट है ।

अगला, मुझे अत्यधिक सुझाव दें कि आप अपनी खुद की प्रमाणीकरण दिनचर्या को कोड न करें। बहुत सारे महान, वीटो लाइब्रेरी हैं जो इसे संभालती हैं। आप अपने आप को कार्यक्षमता और सुरक्षा बगों को सहेजेंगे, जिसमें एक परिपक्व पुस्तकालय के लिए भाग लिया जाएगा। इसके लिए एक वेटेड, परिपक्व पुस्तकालय का उपयोग करना निश्चित रूप से सबसे अच्छा अभ्यास होगा।

अगला सबसे अच्छा अभ्यास अपने क्लाइंट को संभालने के लिए एक निर्देशिका का उपयोग कर रहा है: प्रमाणपत्र मानचित्रण। तो आप AD या LDAP देख रहे होंगे। जैसा कि आपने उल्लेख किया है, विंडोज और आईआईएस आपके लिए यह बहुत सहज बनाता है। IIS.net के तहत प्रमाणपत्र मैपिंग को कॉन्फ़िगर करने पर IIS.net का एक अच्छा हिस्सा है ।

यदि आप अपाचे के साथ रोल करते हैं, तो यह बॉक्स से उतना आसान नहीं है। ऐसा लगता है कि mod_authz_ldap क्लाइंट सर्टिफिकेट मैपिंग करता है, लेकिन मैंने व्यक्तिगत रूप से इसके साथ काम नहीं किया है।

इस तरह यह वास्तव में कुछ इस तरह से लागू करने के लिए हमें रसद के लिए लाता है। आप उपयोगकर्ताओं के प्रमाणपत्र पर हस्ताक्षर नहीं कर रहे हैं, इसलिए आपको एक उपयोगकर्ता द्वारा अपना प्रमाणपत्र जमा करने और अपने ऐप को निर्देशिका में प्रकाशित करने के लिए एक आयरनक्लाड प्रक्रिया की आवश्यकता है। मैं इसके लिए दो-कारक देखना चाहूंगा, एक पासवर्ड के साथ और एक पाठ संदेश या किसी विश्वसनीय नंबर पर कॉल करना। मैं उपयोगकर्ता को यह बताने के लिए ईमेल करूंगा कि उनके खाते में एक प्रमाणपत्र जोड़ा गया है। मैं उपयोगकर्ता को ऐप में उनके खाता प्रबंधन पृष्ठ के माध्यम से उपयोगकर्ता-प्रमाणित मानचित्रण को हटाने देता हूं।

मैं यह देखूंगा कि दो-कारक से बचने के लिए विश्वसनीय उपकरणों के लिए कुकीज़ स्थापित करने के लिए Google और फेसबुक क्या करते हैं। मेरे पास प्रमाण-पत्र की अनुमति देने से पहले दो-कारक के साथ नए उपकरण होंगे।

मैं यह भी सोचता हूं कि उपयोगकर्ता सेरेक्ट को कैसे रद्द किया जाए। इसका मतलब है कि एक बाहरी प्रमाणपत्र निरस्तीकरण सूची (CRL) की जाँच करना। यदि ग्राहक प्रमाणपत्र में CRL वितरण बिंदु परिभाषित नहीं है तो आप क्या करते हैं? जब भी उपयोगकर्ता लॉग इन करता है या नौकरी के हिस्से के रूप में एक निर्धारित आधार पर सीआरएल की जांच करता है, तो संभवत: केवल कुछ मुट्ठी भर सीआरएल उपयोग में होंगे?

वास्तव में, यह नीचे उबलता है: मुझे कैसे पता चलेगा कि मैं विश्वास कर सकता हूं कि उपयोगकर्ताओं के सीरट्स से समझौता नहीं किया गया है, और मुझे कैसे भरोसा है कि मैं प्रमाण पत्र एक्स को उपयोगकर्ता वाई पर मैप कर सकता हूं।


`पहली चीजें पहले, क्लाइंट सर्टिफिकेशन ऑथेंटिकेशन बेकार है अगर यह एंडपॉइंट पर सपोर्ट नहीं है।` - इसका क्या मतलब है?
user93353

इस उत्तर में से अधिकांश मेरे प्रश्न को संबोधित करते हैं। मैं साइड मुद्दों को संबोधित करने के लिए किए गए प्रयास की सराहना करता हूं - लेकिन मैं वास्तव में अपने वास्तविक प्रश्न के अधिक विस्तृत उत्तर में रुचि रखता हूं। मुझे पता है कि OCSP / CRL करना होगा - लेकिन यह मेरे प्रश्न के लिए प्रासंगिक नहीं है। नामांकन कैसे करें यह सवाल का हिस्सा नहीं है।
user93353
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.