ओपनएसएसएल आधारित प्रमाणन प्राधिकरण

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



वे अंततः तैनात थे:

• प्रमाणपत्र जारी करने का केंद्र (CA - प्रमाणपत्र प्राधिकरण, उर्फ ​​CA - प्रमाणन प्राधिकरण, रूसी शब्दावली में एक संगठन जो प्रमाणपत्र जारी करने के लिए अधिकृत है),
• ग्राहक प्रमाणपत्र द्वारा पहुंच प्राधिकरण के साथ इंट्रानेट साइट,
• वीपीएन सर्वर, ग्राहकों और गतिशील मार्ग के पारस्परिक प्रमाणीकरण के साथ,
• एक ही प्रमाण पत्र का उपयोग कर एक कॉर्पोरेट आईएम सर्वर पर ग्राहकों का प्राधिकरण।

जाहिरा तौर पर, सिस्टम अब तक मर चुका है ... मुझे नहीं पता कि यह मेरी बर्खास्तगी के बाद कितने समय तक चला, सबसे अधिक संभावना है जब तक कि मूल प्रमाण पत्र की समाप्ति (लॉन्च की तारीख से 2 साल पहले)।



निम्नलिखित सामान्य उपयोगकर्ताओं के बजाय कॉर्पोरेट तकनीक के लिए दिलचस्प होगा। बशर्ते कि: संगठन राज्य के स्वामित्व में नहीं है, पैसा बचाने के लिए एक लक्ष्य है, आरएंडडी में छह शून्य के साथ राशि स्वैप किए बिना कुछ "चीजों" की कोशिश करने की इच्छा है।



यह माना जाता है कि पाठक वीपीएन (इस मामले में, वर्चुअल प्राइवेट नेटवर्क) और एसएसएल (सिक्योर सॉकेट्स लेयर) की अवधारणाओं और इस तथ्य से परिचित हैं कि वे x.509 प्रारूप में इलेक्ट्रॉनिक प्रमाण पत्र हैं।

सीए

परिणामी प्रणाली में, प्रमाणपत्रों को नवीनीकृत किया जा सकता है, निरस्त किया जा सकता है, प्रमाणीकरण के लिए उपयोग किया जाता है, कोड, फ़ाइलों, मेल के एन्क्रिप्शन और समझौता के मामले में, पूरे सीए को मारे बिना एक शाखा को निरस्त करें। ऐसा करने के लिए, मुझे OpenSSL कॉन्फ़िगरेशन फ़ाइलों पर ध्यान से विचार करना था, प्रमाणपत्र निरूपण सूची (CRL) और CA में सही पदानुक्रम बनाने के लिए प्रक्रिया का निर्माण करना था। तभी चुने गए कार्यान्वयन ने प्रमाण पत्र, झुकाव के उपयोग की अनुमति दी। और स्वचालित प्रक्रियाओं में जहां बटन पर क्लिक करने के लिए कोई नहीं था " हां, मैं अभी भी इस प्रमाण पत्र पर भरोसा करता हूं, हालांकि यह समाप्त हो गया है और गलत तरीके से जारी किया गया है और इसके लिए बिल्कुल भी इरादा नहीं है ।"



यह याद रखना महत्वपूर्ण है ( जैसा कि यह निकला ) कि इलेक्ट्रॉनिक डिजिटल हस्ताक्षर प्रमाणपत्र का मुद्दा और उपयोग न केवल एक तकनीकी है, बल्कि एक संगठनात्मक प्रक्रिया भी है, जिसके बिना इस तरह के संरक्षण का उपयोग करने के लाभ शून्य हो जाते हैं। सीए के साथ एक डिस्क, उदाहरण के लिए, सभी प्रमाण पत्र जारी करने के बाद, हटाने या डिस्कनेक्ट करने के लिए बेहतर है ( यदि यह यूएसबी है ) और इसे एक तिजोरी में रखें। और एक पत्रिका शुरू करें।

वेबसाइट

इंट्रानेट साइट के लिए ( पहला एक्सेल - अपाचे, इसके पीछे क्या था - यह कोई फर्क नहीं पड़ता ) बहु-कारक प्रमाणीकरण लागू किया गया था। आमतौर पर प्रमाणीकरण में पहला और एकमात्र कारक उपयोगकर्ता नाम और पासवर्ड या उपयोगकर्ता नाम और पिन कोड का ज्ञान होता है; सर्वर पर केवल क्लाइंट दिखाई देता है, और सर्वर को यह साबित करने की आवश्यकता नहीं है कि यह वह है, इसलिए सर्वर के लॉगिन / पासवर्ड और / या प्रतिस्थापन की चोरी की संभावना है। मेरे मामले में, यह अस्वीकार्य था, इसलिए लॉगिन / पासवर्ड के ज्ञान के लिए एक प्रमाण पत्र होने की आवश्यकता थी। CA से प्रमाणपत्र PKCS12 (PFX) प्रारूप में एक पासवर्ड के साथ अपलोड किए गए थे।



सर्वर कॉन्फ़िगरेशन में कुछ इस तरह जोड़ा गया था:



<Location /location1>

SSLOptions +FakeBasicAuth +StdEnvVars

SSLVerifyClient require

SSLVerifyDepth 2

SSLRequire %{SSL_CLIENT_I_DN_CN} in {"My LTD OpenSSL CA"}







यानी अनुमति दें जिसका प्रमाण पत्र माई लिमिटेड ओपनएसएसएल सीए द्वारा जारी किया गया है ( वास्तव में, नाम अलग है )



आप नाम से पहुंच को प्रतिबंधित भी कर सकते हैं:



<Location /location2>

SSLOptions +FakeBasicAuth +StdEnvVars

SSLVerifyClient require

SSLVerifyDepth 2

SSLRequire %{SSL_CLIENT_S_DN_CN} in {"Ivan A Ivanov", \

"Petr B Petrov"}







यह निम्न निर्माण का उपयोग करते हुए सर्वर लॉग में लिखा गया है:



CustomLog ../logs/ssl/ssl_request.log \

"\"%t\",\"%h\",\"%{SSL_CLIENT_S_DN_CN}x\",\"%r\",\"%s\"" env=!dontlogit

प्रमाणपत्र वितरण

चाबियाँ के साथ प्राप्त प्रमाण पत्र उपयोगकर्ता के कंप्यूटर पर स्थापित किया गया था ( रजिस्ट्री में, एक पिन कोड के साथ एन्क्रिप्टेड ), एक बहुत ही सामान्य मामला है, हालांकि, आप केवल इस कंप्यूटर पर प्रमाण पत्र का उपयोग कर सकते हैं और ऑपरेटिंग सिस्टम को फिर से स्थापित करने के मामले में, सबसे अधिक बार आपको प्रमाणपत्र प्राप्त करने की आवश्यकता होती है, जब तक कि निश्चित रूप से। निजी कुंजी को कंप्यूटर पर उत्पन्न किया गया था, और CA पर जाने पर आपको डिस्केट पर नहीं दिया गया था, जिसे विशेष निंदक के साथ अपवित्रता माना जा सकता है, क्योंकि वास्तव में यह आपकी कथित निजी कुंजी का मालिक बन जाता है ( साधारण की संभावना के साथ) आपको CA के लिए एक "इलेक्ट्रॉनिक हस्ताक्षर" ) भी देना है, और एक निश्चित स्तर पर नारेबाजी है - सभी प्रशासक CA में एक दूसरे को प्रतिस्थापित करते हैं। लेकिन सीए के पास प्रमाण पत्र के "बहाली" के लिए एक सेवा प्रदान करने का अवसर है।



क्योंकि मैं स्वयं एक सीए था, मुझे ऐसी "सेवा" और तकनीकी विशेषज्ञों द्वारा "स्मृति के लिए" प्रमाण पत्र की नकल करने से बख्शा गया था (और ऐसा नहीं)।



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

अलादीन eToken USB कीज़ केवल कार्ड के रूप में ऐसे कार्ड हैं।

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

बेशक, कोई भी स्मार्ट कार्ड का उपयोग करने की जहमत नहीं उठाता, जो सामान्य प्लास्टिक कार्ड की तरह दिखता है, लेकिन फिर हर कार्यस्थल पर जहां इस तरह के कार्ड का उपयोग करने की आवश्यकता होगी, वहां एक कार्ड रीडर होना चाहिए।



जब हम CA से एक प्रमाण पत्र प्राप्त करते हैं, तो इसे "टोकन" पर रखा जाता है, और एक पिन कोड के साथ टोकन को बंद कर दिया जाता है, हमें दो-कारक दो-तरफ़ा प्रमाणीकरण करने का अवसर मिलता है। पहला कारक - हमारे पास एक टोकन है, दूसरा कारक - हम इसे से पिन कोड जानते हैं। और एक प्रमाण पत्र होने पर, हम यह सत्यापित कर सकते हैं कि सर्वर वास्तव में वह है जो यह दावा करता है, इस मामले में bobik.ru और bobik.ru को भ्रमित नहीं किया जा सकता है, क्योंकि दूसरे संस्करण में रूसी "ओ" एक नाम बेमेल देगा ( यह सब एक कंप्यूटर के लिए है -साथ अलग-अलग अक्षर )।

प्रमाणपत्र निरस्तीकरण सूची

इस तथ्य के कारण कि सर्वर की सेटिंग्स में निरस्त प्रमाण पत्र (CRLs) की एक सूची पंजीकृत (और नियमित रूप से अपडेट) की गई थी, किसी भी उपयोगकर्ता की साइट पर जल्दी से पहुंच को निलंबित करना हमेशा संभव था, जिसमें शामिल है USB कुंजी के नुकसान (या नुकसान का संदेह) के मामले में, या किसी कर्मचारी की बर्खास्तगी पर।



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



यदि आवश्यक हो, तो प्रमाणपत्र को उसी निजी कुंजी के साथ फिर से जारी किया गया था, जिसने पहले एन्क्रिप्ट किए गए डेटा तक पहुंच नहीं खोने की अनुमति दी थी।

ओपनएसएसएल डिबगिंग

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



चीजों को थोड़ा अधिक गंभीर बनाने के लिए, आपको थोड़ा सीधा करने की आवश्यकता है:

• यदि आप चाहते हैं कि आपका सिस्टम एक साल से अधिक जीवित रहे, तो रूट CA प्रमाणपत्र जारी करने से पहले, दिनों की संख्या को 3650 तक बढ़ाएं, फिर इसे वापस कर दें, उपयोगकर्ता प्रमाणपत्रों के लिए एक वर्ष या छह महीने छोड़ना बेहतर है
• [CA_default] अनुभाग में
  
  "हां" के लिए unique_subject पैरामीटर सेट करें - यह आपको 2 समान प्रमाणपत्र जारी करने की अनुमति नहीं देगा
• [user_cert] अनुभाग में
  
  जोड़ना
  
  ExtendedKeyUsage = clientAuth
  
  
  
  
• सर्वर अनुभाग इस तरह दिख सकता है
  
  [ server_cert ]

basicConstraints = CA:FALSE

nsCertType = server

keyUsage = digitalSignature, keyEncipherment

extendedKeyUsage = nsSGC, serverAuth
  
  
  
  
• अनुभाग में [v3_ca]
  
  संशोधन करना
  
  basicConstraints = CA:TRUE, pathlen:5
  
  
  
  
• अधूरा nsCertType और keyUsage
• जोड़ना
  
  extendedKeyUsage = serverAuth, clientAuth
  
  
  
  

हमेशा की तरह - एक तैयार विन्यास ।

सर्टिफिकेट इश्यू ऑटोमेशन

स्वचालन में अगला कदम प्रमाण पत्र की सूची देखने के लिए एक इंटरफ़ेस लिख सकता है। सूची में नाम index.txt, एक स्पष्ट प्रारूप है, और मैंने इसके लिए HTA पर एक इंटरफ़ेस लिखा है। डिबगिंग को सरल बनाने के लिए, एचटीए ने व्यक्तिगत प्रक्रियाओं के लिए बैच फ़ाइलों को बुलाया। आवश्यक सेट इस प्रकार है:

1. पर्यावरण चर सेट करने के लिए अलग फाइल
2. एक मनमाना प्रमाण पत्र जारी करना - सेटिंग्स का एक न्यूनतम, प्रश्नों का एक गुच्छा पूछता है, आपको एक प्रमाणपत्र जारी करने की अनुमति देता है, कहते हैं, भागीदारों के लिए, फिर हमारे सीए में साइन इन करें।
3. सीए रूट प्रमाणपत्र जारी करना - एक बार या कई बार कॉल किया जाता है, अगर एक पेड़ बनाया जा रहा है, हैंडल के साथ
4. सर्वर सर्टिफिकेट जारी करना समझ में आता है, ओपनस्ले को -डेंटेंशन सर्वर_सर्ट पैरामीटर के साथ कहा जाता है, और [सर्वर_क्रर्ट] अनुभाग में सेटिंग्स में आवश्यक पैरामीटर होना चाहिए, एक और अंतर यह है कि यह पीएफएक्स में पैक नहीं किया गया है और कुंजी के अनपैक्ड संस्करण बनाता है, कुछ सर्वर को इसकी आवश्यकता हो सकती है
5. उपयोगकर्ता प्रमाणपत्र समस्या
6. प्रमाणपत्र निरस्तीकरण एक दिलचस्प प्रक्रिया है: जारी किए गए प्रमाणपत्रों के संग्रह से (आपको इसे स्वयं करने की आवश्यकता है), आवश्यक एक को निकाला गया था (नाम से, लेकिन क्रम संख्या द्वारा भी), फिर इसे पहले ही निरस्त कर दिया गया था
7. उपयोगकर्ता प्रमाणपत्र का नवीकरण - पहले, पुराने प्रमाणपत्र को रद्द कर दिया गया था (बैच फ़ाइल संख्या 6), फिर पुरानी कुंजी के लिए एक नया प्रमाणपत्र (बैच फ़ाइल नंबर 5) का निर्माण।
8. निरस्त किए गए प्रमाणपत्रों की सूची को अपडेट करना एक सरल आदेश है, लेकिन मेरे मामले में यह पर्ल में एक स्क्रिप्ट चलाने के साथ था, जिसने सूची तैयार की और इसे लोटस डोमिनोज़ डायरेक्टरी ( एड्रेस बुक, जैसा कि कभी-कभी कहा जाता है ) में रखा गया, वहां से प्राप्त करना आसान था (एलडीएपी के माध्यम से, जो CRL वितरित करने का लगभग एक मानक तरीका है)

वह सब उपकरण है, शायद। अच्छा परिचय है।