स्वयं हस्ताक्षरित प्रमाणपत्र के साथ एसएसएल पर ओपनआईडी

Question

मैंने अपने व्यक्तिगत सर्वर पर अपना स्वयं का ओपन आईडी प्रदाता सेटअप किया, और मेरी अपाचे कॉन्फ़िगरेशन फ़ाइल में https पर रीडायरेक्ट जोड़ा। सुरक्षित कनेक्शन का उपयोग नहीं करते समय (जब मैं रीडायरेक्ट को अक्षम करता हूं) मैं ठीक से लॉग इन कर सकता हूं, लेकिन रीडायरेक्ट के साथ मैं इस त्रुटि संदेश से लॉग इन नहीं कर सकता:

अंतर्निहित कनेक्शन बंद था: ट्रस्ट रिलेशनशिप स्थापित नहीं कर सका एसएसएल/टीएलएस सुरक्षित चैनल।

मुझे लगता है कि ऐसा इसलिए है क्योंकि मैं स्वयं हस्ताक्षरित प्रमाणपत्र का उपयोग कर रहा हूं।

क्या कोई यह पुष्टि कर सकता है कि स्वयं हस्ताक्षरित प्रमाणपत्र मुद्दा है या नहीं? यदि नहीं, तो क्या किसी के पास कोई विचार है कि समस्या क्या है?

Answer 1

आपके ओपनआईडी यूआरएल के लिए एसएसएल का उपयोग करने का प्राथमिक लाभ यह है कि यह निर्भर पार्टी को यह पता लगाने के लिए एक तंत्र देता है कि क्या DNS को छेड़छाड़ की गई है। भरोसेमंद पार्टी को यह बताने के लिए असंभव है कि एक स्व-हस्ताक्षरित प्रमाणपत्र वाले ओपनआईडी यूआरएल से समझौता किया गया है या नहीं।

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

Answer 2

ऐसा लगता है। आपके ओपनआईडी सर्वर का क्लाइंट रूट प्रमाणन प्राधिकरण पर भरोसा नहीं करता है।

Answer 3

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

Answer 4

ओपनआईडी एक रीडायरेक्ट-पारदर्शी तरीके से डिज़ाइन किया गया है। जब तक प्रत्येक कुंजीपटल पर आवश्यक कुंजी/मूल्य जोड़े संरक्षित होते हैं, या तो जीईटी या पोस्ट द्वारा, सबकुछ ठीक से काम करेगा।

उपभोक्ताओं है कि स्व-हस्ताक्षरित प्रमाणपत्र के साथ काम नहीं करते के साथ संगतता प्राप्त करने के लिए सबसे आसान समाधान एक गैर एन्क्रिप्टेड अंत बिंदु जो एक एन्क्रिप्टेड एक के लिए checkid_immediate और checkid_setup संदेशों रीडायरेक्ट का उपयोग करने के लिए है।

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

// Redirect OpenID authentication requests to https:// of same URL 
// Assuming valid OpenID operation over GET 
if (!isset($_SERVER['HTTPS']) && 
     ($_GET['openid_mode'] == 'checkid_immediate' || 
     $_GET['openid_mode'] == 'checkid_setup')) 
    http_redirect("https://{$_SERVER['HTTP_HOST']}{$_SERVER['REQUEST_URI']}"); 

रूप openid.return_to मूल्य एक सादे HTTP अंत बिंदु के खिलाफ जनरेट किया गया था, जहाँ तक उपभोक्ता का संबंध है, यह केवल है:

उदाहरण के लिए, PHP में, रीडायरेक्ट के रूप में सरल रूप में हो सकता है एक गैर-एन्क्रिप्टेड सर्वर से निपटना। सत्र और nonces के साथ उचित ओपनआईडी 2.0 ऑपरेशन मानते हुए, उपभोक्ता और आपके सेवर के बीच जो भी जानकारी पारित की गई है, वह शोषक जानकारी प्रकट नहीं करनी चाहिए। आपके ब्राउज़र और ओपनआईडी सर्वर के बीच संचालन, जो शोषक हैं (पासवर्ड स्नूपिंग या सत्र कुकी अपहरण) एन्क्रिप्टेड चैनल पर किए जाते हैं।

ईवर्सड्रॉपर्स को रखने के अलावा, एसएसएल पर प्रमाणीकरण संचालन करने के लिए आपको secure HTTP कुकी ध्वज का उपयोग करने की अनुमति मिलती है। यह checkid_immediate संचालन के लिए सुरक्षा की एक और परत जोड़ता है, क्या आप इसे अनुमति देना चाहते हैं।