किसी ज्ञात CA के विरुद्ध इसे सत्यापित करने की आवश्यकता के बिना मैं एक ग्राहक SSL प्रमाणपत्र के लिए अपाचे का अनुरोध कैसे कर सकता हूं?

Question

मैं apache2 (2.2.3) का उपयोग कर रहा हूं ताकि मैं उस साइट की सेवा कर सकूं जहां मैं ग्राहकों को प्रमाणपत्रों के साथ प्रमाणित करना चाहता हूं। चूंकि मुझे केवल यह सत्यापित करने की आवश्यकता है कि किसी विशेष प्रमाणपत्र को प्रस्तुत करने वाला उपयोगकर्ता वही उपयोगकर्ता है जिसने अतीत में उस प्रमाण पत्र को प्रस्तुत किया है, इसलिए प्रमाण पत्र पर हस्ताक्षर करने वाला CA अप्रासंगिक है। ऐसा लगता है, हालांकि, इसका उपयोग करने की SSLVerifyClient requireआवश्यकता है SSLCACertificateFile ...(या SSLCACertificatePath ...), और फिर अपाचे केवल उस फ़ाइल / पथ में सीए द्वारा हस्ताक्षरित प्रमाण पत्र स्वीकार करेगा। क्या किसी भी क्लाइंट प्रमाण पत्र को स्वीकार करने के लिए अपाचे प्राप्त करने का एक तरीका है, चाहे सीए जारी करने / गाने का कोई भी हो? (यानी सत्यापित करें कि ग्राहक के पास प्रस्तुत की गई सार्वजनिक कुंजी की संबंधित निजी कुंजी है, लेकिन जारी करने / हस्ताक्षर करने वाले सीए को सत्यापित करने से परेशान नहीं है)

Comments

आप ट्रैकिंग पर कैसे योजना बनाते हैं कि किस प्रमाण पत्र ने प्रमाणीकृत किया है?

— शेन मैडेन

@ShaneMadden: आंतरिक उपयोगकर्ता आईडी में तालिका मानचित्रण प्रमाणपत्र की तरह कुछ। सार्वजनिक कुंजी क्रिप्टोग्राफी के यांत्रिकी पासवर्ड एक्सचेंज की जगह ले लेंगे।

— इसहाक

सही - मुझे जो मिल रहा है वह यह है कि अपाचे आंतरिक उपयोगकर्ता आईडी के लिए एक टेबल मैपिंग प्रमाणपत्र नहीं करता है । यदि आप उपयोगकर्ताओं को ग्राहक प्रमाणपत्र के साथ प्रमाणित करने जा रहे हैं, तो उन उपयोगकर्ताओं को प्रमाण पत्र क्यों नहीं दें, जिन पर आप हस्ताक्षर करते हैं? जैसा कि आपने उल्लेख किया है, OpenID प्रदाता हैं जो वास्तव में ऐसा करते हैं। अपाचे का mod_sslसंबंध प्रमाणपत्र पर हस्ताक्षर करने के आधार पर उपयोगकर्ताओं को प्रमाणित करने के लिए बनाया गया था; यदि आप किसी कारणवश इसकी अवहेलना करना चाहते हैं तो आपको अपने स्वयं के कोड में प्रमाणपत्र प्रमाणीकरण को लागू करने की आवश्यकता होगी जो आपके प्रमाणपत्र-से-उपयोगकर्ता मैपिंग को भी संभाल रहा है।

— शेन मैडेन

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

— इसहाक

@ShaneMadden का एक फायदा optional_no_caयह है कि यह UI के लिए बेहतर हो सकता है, क्योंकि आप HTTP त्रुटि संदेश प्रदर्शित कर सकते हैं यदि प्रमाणपत्र के साथ कुछ गलत है (आप अन्यथा नहीं कर सकते, क्योंकि एक बुरा ग्राहक प्रमाणपत्र HTTP परत से पहले कनेक्शन बंद कर देगा। )। यदि आप किसी प्रमाणपत्र को प्रमाणित करने के वैकल्पिक तरीकों (जैसे WebID ) को आज़माना चाहते हैं तो यह उपयोगी है । आप सही हैं कि आप सत्यापन के लिए कुछ करना चाहते हैं, और यह केवल तभी काम करेगा जब अनुरोध कोड द्वारा संभाला जाएगा (जैसे PHP / CGI / जावा के भीतर), फाइलों के साथ इतना नहीं।

— ब्रूनो

Answer 1

जैसा कि आपने पाया है, आप उपयोग करके Apache Httpd के भीतर SSL / TLS हैंडशेक स्तर पर प्रमाणपत्र सत्यापन को अक्षम कर सकते हैं SSLVerifyCLient optional_no_ca।

दूसरी समस्या जिसका सामना आप करने की कोशिश कर रहे हैं, वह है ग्राहक को प्रमाणपत्र भेजने के लिए प्राप्त करना। चूँकि आपके प्रमाणपत्र का PKI के भीतर होने का इरादा नहीं है, वे स्व-हस्ताक्षरित हो सकते हैं और विभिन्न जारीकर्ता हो सकते हैं।

क्लाइंट-सर्टिफिकेट का अनुरोध करते समय, सर्वर क्लाइंट को हैंडशेक के दौरान एक CertificateRequestटीएलएस संदेश भेजता है । इस संदेश में certificate_authoritiesसूची है:

स्वीकार्य प्रमाणपत्र अधिकारियों के विशिष्ट नामों की एक सूची। ये प्रतिष्ठित नाम रूट CA के लिए या अधीनस्थ CA के लिए वांछित प्रतिष्ठित नाम निर्दिष्ट कर सकते हैं; इस प्रकार, इस संदेश का उपयोग ज्ञात जड़ों और वांछित प्राधिकरण स्थान दोनों का वर्णन करने के लिए किया जा सकता है। यदि प्रमाण पत्र_अधिकारी सूची खाली है, तो ग्राहक MAY उचित ClientCertificateType का कोई भी प्रमाण पत्र भेज सकता है, जब तक कि इसके विपरीत कुछ बाहरी व्यवस्था न हो।

ब्राउजर इसका उपयोग यह चुनने के लिए करता है कि कौन सा क्लाइंट सर्टिफिकेट भेजना है (यदि कोई हो)।

(ध्यान दें कि खाली सूची के बारे में हिस्सा केवल टीएलएस 1.1 से विनिर्देश में है। एसएसएल 3.0 और टीएलएस 1.0 इस पर चुप हैं, और व्यवहार में, यह भी काम करेगा।)

इसके लिए आपको दो विकल्प मिलते हैं।

• यदि आपके द्वारा अपेक्षित ग्राहक प्रमाणपत्र स्व-हस्ताक्षरित होने वाले हैं, तो वे सभी अलग-अलग जारीकर्ता होंगे। क्योंकि आपको पता नहीं होगा कि क्या उम्मीद करनी है, सर्वर को एक खाली सूची भेजनी होगी। ऐसा करने के लिए, SSLCADNRequestFileनिर्देश का उपयोग करें और इसे एक फ़ाइल में इंगित करें जिसमें सिर्फ एक खाली लाइन है (यदि मुझे अच्छी तरह याद है, तो यह पूरी तरह से खाली फ़ाइल के साथ काम नहीं करता है)।

• दूसरा (कम साफ) विकल्प। क्या आप जारी करने वाले सभी ग्राहक प्रमाणपत्रों के लिए एक जारीकर्ता डीएन आम से सहमत होना चाहते हैं, चाहे वे वास्तव में उस सीए प्रमाण पत्र द्वारा जारी किए गए हों या नहीं (या फिर वह सीए मौजूद भी हो या नहीं)। ऐसा करने से, आप PKI मॉडल को (और अधिक) तोड़ देंगे।

  यदि आप किसी जारीकर्ता डीएन पर सहमत हैं जैसे CN=Dummy CA(उदाहरण के लिए)। कोई भी व्यक्ति CN=Dummy CAसंभवतः अलग-अलग कुंजी के साथ सब्जेक्ट डीएन (और जारीकर्ता डीएन) का उपयोग करके एक स्व-हस्ताक्षरित प्रमाण पत्र बना सकता है। हालाँकि SSLCADNRequestFile, सूची के निर्माण के लिए निर्देश प्रमाणपत्र के साथ कॉन्फ़िगर किए जाने की उम्मीद करता है, इनका उपयोग क्लाइंट-प्रमाणपत्र को सत्यापित करने के लिए बिल्कुल भी नहीं किया जाता है, यह certificate_authoritiesसूची को कॉन्फ़िगर करने के तरीके के लिए एक जटिल (लेकिन अन्य निर्देशों के संदर्भ में स्वाभाविक) है । यदि आप एक सेवा के रूप में SSLCADNRequestFile, इन नामों के साथ एक स्व-हस्ताक्षरित प्रमाण-पत्र लगाते हैं , तो यह सूची में CertificateRequestTLS संदेश का उपयोग करेगा (ये सिर्फ नाम हैं, इस स्तर पर नहीं)। क्लाइंट तब जारीकर्ता डीएन के साथ अपना प्रमाण पत्र लेने में सक्षम होगाCN=Dummy CAcertificate_authoritiesCN=Dummy CA, या नहीं, इसके प्रमाण पत्र को उस प्रमाण पत्र (उसी कुंजी) द्वारा सत्यापित किया जा सकता है या नहीं, क्योंकि कोई हस्ताक्षर सत्यापन वैसे भी इन चरणों में शामिल नहीं है।

यह कहा जा रहा है, याद रखें कि SSLVerifyCLient optional_no_caकोई भी वास्तविक प्रमाणपत्र सत्यापन नहीं किया गया है (मुझे लगता है कि आप SSL_CLIENT_VERIFYचर की जांच कर सकते हैं यदि आपका मैनुअल सत्यापन आपके द्वारा किसी भी कॉन्फ़िगर किए गए PKI के लिए केवल एक वापसी समाधान है)। आप सभी को उस स्तर पर पता चल जाएगा कि ग्राहक के पास सार्वजनिक कुंजी प्रमाणपत्र के लिए निजी कुंजी है जो उसने प्रस्तुत किया है (टीएलएस CertificateVerifyसंदेश द्वारा गारंटी ): आपको सत्यापन का कुछ रूप प्रदर्शन करने की आवश्यकता होगी यदि आप चाहते हैं कि कुछ का प्रमाणीकरण हो छांटते हैं। (आप प्रमाण पत्र की किसी भी सामग्री पर भरोसा नहीं कर सकते, जो कि इसकी सार्वजनिक कुंजी और इसमें शामिल नामों / विशेषताओं के बीच का कोई भी बंधन है।)

यह फ़ाइलों के लिए अच्छी तरह से काम नहीं करेगा, लेकिन आप इसे एक आवेदन के लिए कर सकते हैं (उदाहरण के लिए PHP / CGI / ... यहां तक ​​कि जावा अगर आप प्रमाणीकृत जावा सर्वर को प्रमाण पत्र पास करते हैं)। एक मूल तरीका सार्वजनिक कुंजी की पूर्व-ज्ञात सूची होगी, या आप एफओएएफ + एसएसएल / वेबिड में विचारों को देख सकते हैं ।

Answer 2

उपयोग SSLVerifyCLient optional_no_caकरने के बजाय ( require) के कारण जारी करने वाले सीए की जांच न करने के लिए अपाचे का कारण बनता है (और इस तरह सीए प्रमाणपत्र फ़ाइल या पथ की आवश्यकता नहीं है)। यह क्लाइंट / उपयोगकर्ता को प्रमाण पत्र प्रस्तुत नहीं करने की अनुमति देता है, इसलिए यह जांचना कि सभी में एक प्रमाण पत्र का उपयोग किया गया था अलग से किया जाना है।

(जाहिर है, मैं सिर्फ mod_sslप्रलेखन को अच्छी तरह से पढ़ने में विफल रहा ।)