एसएसएल और टीएलएस प्रोटोकॉल कैसे सक्षम करें। टीएलएस और एसएसएल: आवश्यक न्यूनतम ज्ञान। क्लाइंट प्रमाणपत्रों का उपयोग करने के लिए अपाचे को कॉन्फ़िगर करना

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

1. एसएसएल/टीएलएस प्रमाणपत्र तैयार करना

प्रमाणपत्र स्व-हस्ताक्षरित या सीए द्वारा हस्ताक्षरित हो सकते हैं। स्व-हस्ताक्षरित प्रमाणपत्र आमतौर पर केवल विभिन्न सर्वरों और डिबगिंग सेटिंग्स में एसएसएल/टीएलएस समर्थन के परीक्षण के लिए उपयोग किए जाते हैं। सार्वजनिक सर्वर पर, आपको सीए द्वारा हस्ताक्षरित प्रमाणपत्रों का उपयोग करना चाहिए।

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

2. CA प्रमाणपत्र बनाएं (स्व-हस्ताक्षर करने के लिए)

एक सीए प्रमाणपत्र एक प्रमाणन प्राधिकरण प्रमाणपत्र है (जैसा कि यह ध्वनिमय हो सकता है)। यह प्रमाणपत्र विभिन्न सेवाओं द्वारा उपयोग किए जाने वाले अन्य सभी प्रमाणपत्रों पर हस्ताक्षर करता है।

आइए उस स्क्रिप्ट का उपयोग करें जो Opensl पैकेज के साथ आती है:
# /usr/lib/ssl/misc/CA.pl -newca सीए प्रमाणपत्र बनाने से पहले स्क्रिप्ट आपसे कुछ सवाल पूछेगी। निम्नलिखित जानकारी प्रदान करने के लिए तैयार रहें:

• देश
• राज्य या प्रांत
• शहर या अन्य नगरपालिका क्षेत्र
• संगठन
• उपखंड (संगठन इकाई)
• साधारण नाम
• ईमेल पता

प्रमाणपत्र निर्माण प्रक्रिया के दौरान, आपको एक पासफ़्रेज़ भी निर्दिष्ट करना होगा जिसका उपयोग हर बार आपके द्वारा प्रमाणित प्रमाणपत्रों पर हस्ताक्षर करने या रद्द करने पर किया जाएगा।

"सामान्य नाम" फ़ील्ड में ये मामलाआपको संगठन का नाम दर्ज करना होगा (या ट्रेडमार्क, जिसके तहत वह काम करती है) या मालिक का नाम। यदि आप एक सर्वर प्रमाणपत्र बनाते हैं, तो आपको उसका DNS नाम निर्दिष्ट करना होगा।

वर्तमान निर्देशिका में एक डेमोसीए उपनिर्देशिका बनाई जाएगी, जिसमें आवश्यक फाइलें बनाई जाएंगी।

उसके बाद, मैंने ओपनएसएसएल कॉन्फ़िगरेशन फ़ाइल /etc/ssl/openssl.conf को अतिरिक्त रूप से संपादित किया, प्रमाणीकरण प्राधिकारी के प्रमाणपत्रों के साथ निर्देशिका का पूरा पथ निर्दिष्ट किया (दो स्थानों पर) और नए बनाए गए प्रमाणपत्रों के लिए समाप्ति तिथि निर्धारित की:
dir = /etc/ssl/demoCA और
डिफ़ॉल्ट_दिन = 3650 3. सर्वर प्रमाणपत्र बनाएं

हालांकि सर्टिफिकेट अथॉरिटी सर्वर सर्टिफिकेट भी जेनरेट कर सकती है, आप इसे खुद जेनरेट कर सकते हैं:
# opensl req -new -nodes -keyout domain1.net.pem -out domain1.net.pem -days 3650 एक 2048 बिट RSA निजी कुंजी उत्पन्न करना ................... ……………………………………….. …………………………………………….. ……………………………………….. ……………………………………….. "domain1.net.pem" में नई निजी कुंजी लिखना -- आपसे ऐसी जानकारी दर्ज करने के लिए कहा जाने वाला है जिसे आपके प्रमाणपत्र अनुरोध में शामिल किया जाएगा। आप जो दर्ज करने जा रहे हैं उसे विशिष्ट नाम या डीएन कहा जाता है। काफी कुछ फ़ील्ड हैं लेकिन आप कुछ खाली छोड़ सकते हैं कुछ फ़ील्ड के लिए एक डिफ़ॉल्ट मान होगा, यदि आप "." दर्ज करते हैं, तो फ़ील्ड खाली छोड़ दी जाएगी। ----- देश का नाम (2 अक्षर कोड): RU राज्य या प्रांत का नाम (पूरा नाम): बश्कोर्तोस्तान गणराज्य इलाके का नाम (जैसे, शहर): ऊफ़ा संगठन का नाम (जैसे, कंपनी): व्लादिमीर स्टुपिन संगठनात्मक इकाई का नाम (जैसे, अनुभाग): सामान्य नाम (जैसे सर्वर FQDN या आपका नाम) :domain1.net ईमेल पता: [ईमेल संरक्षित]कृपया अपने प्रमाणपत्र अनुरोध के साथ भेजे जाने के लिए निम्नलिखित "अतिरिक्त" विशेषताएं दर्ज करें एक चुनौती पासवर्ड: एक वैकल्पिक कंपनी का नाम

फ़ाइल डोमेन1.net.pem प्रमाणपत्र के निजी भाग के साथ वर्तमान निर्देशिका में बनाई जाएगी।

4.1. सर्वर प्रमाणपत्र हस्ताक्षर (स्व-हस्ताक्षरित)

स्व-हस्ताक्षरित प्रमाणपत्र बनाने के लिए, आप निम्न आदेश का उपयोग कर सकते हैं:
# opensl ca -policy policy_anything -out domain1.net.pubilc.pem -infiles domain1.net.pem /usr/lib/ssl/openssl.cnf से कॉन्फ़िगरेशन का उपयोग करना /etc/ssl/ca/private/केकी के लिए पास वाक्यांश दर्ज करें। pem: जांचें कि अनुरोध हस्ताक्षर से मेल खाता है, ठीक है प्रमाणपत्र विवरण: क्रमांक: 14036232404122642274 (0xc2cab701208ea762) वैधता पहले नहीं: 5 फरवरी 15:31:10 2014 GMT बाद में नहीं: 3 फरवरी 15:31:10 2024 GMT विषय: देश का नाम = RU StateOrProvinceName = बश्कोर्तोस्तान रिपब्लिक लोकैलिटीनाम = ऊफ़ा ऑर्गनाइज़ेशननाम = व्लादिमीर स्टुपिन कॉमननेम = डोमेन1.नेट ईमेलएड्रेस = [ईमेल संरक्षित] X509v3 एक्सटेंशन: X509v3 बुनियादी बाधाएं: CA:FALSE नेटस्केप टिप्पणी: OpenSSL जेनरेटेड सर्टिफिकेट X509v3 विषय कुंजी पहचानकर्ता: 0B:DB:32:31:76:C8:F1:80:8E:2F:2E:70:8B:05:91 :2A:91:69:AF:31 X509v3 प्राधिकरण कुंजी पहचानकर्ता: keyid:B5:CB:D1:89:6A:E8:82:D2:D6:7C:A5:6C:13:88:EA:EE:D9 :5F:8F:6E सर्टिफिकेट को 3 फरवरी तक प्रमाणित किया जाना है 15:31:10 2024 GMT (3650 दिन) सर्टिफिकेट पर हस्ताक्षर करें? :y 1 में से 1 प्रमाणपत्र अनुरोध प्रमाणित है, प्रतिबद्ध है? y 1 नई प्रविष्टियों के साथ डेटाबेस लिखें डेटा बेस अपडेट किया गया # mv domain1.net.pem domain1.net.private.pem प्रमाणपत्र पर हस्ताक्षर करते समय, आपको CA प्रमाणपत्र से गुप्त वाक्यांश निर्दिष्ट करना होगा (ऊपर देखें)।

4.2. सर्वर प्रमाणपत्र हस्ताक्षर (बाहरी हस्ताक्षर)

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

उसके बाद, आप प्रमाणपत्र का सार्वजनिक हिस्सा बना सकते हैं:

# opensl x509 -in mail.stupin.su.pem -text > mail.stupin.su.public.pem # mv domain1.net.pem domain1.net.private.pem 5. उपयोग के लिए सर्वर प्रमाणपत्र तैयार करें

आइए प्रमाणपत्रों को व्यवस्थित करें ताकि वे स्वचालित रूप से डोवकोट द्वारा उठाए जा सकें और एक्सेस अधिकार स्थापित कर सकें।

सिस्टम के स्थानीय उपयोगकर्ताओं को प्रमाणपत्र के निजी हिस्से तक पढ़ने की पहुंच प्राप्त करने से रोकने के लिए और प्रमाणपत्र के सार्वजनिक हिस्से को बदलने में सक्षम नहीं होने के कारण, आपको तदनुसार फ़ाइल अनुमतियां सेट करने की आवश्यकता है:
# चाउन रूट: रूट /etc/ssl/domain1.net.public.pem # chmod u=rw,go=r /etc/ssl/domain1.net.public.pem # chown root:root /etc/ssl/domain1. net.private.pem # chmod u=rw,go= /etc/ssl/domain1.net.private.pem 6 पोस्टफिक्स

पोस्टफिक्स एक एसएमटीपी क्लाइंट के रूप में कार्य कर सकता है जब यह किसी अन्य मेल सर्वर पर मेल भेजता है, और जब यह किसी अन्य सर्वर से मेल प्राप्त करता है तो एसएमटीपी सर्वर के रूप में कार्य कर सकता है।

6.1. क्लाइंट पर TLS सेट करना

आइए प्राप्तकर्ता के मेल सर्वर का एन्क्रिप्शन और प्रमाणीकरण सेट करें जब हमारा सर्वर सुरक्षित एसएमटीपी प्रोटोकॉल का उपयोग करके एक पत्र भेजने का प्रयास करता है।

आइए हमारे प्रमाणन प्राधिकरण के pem-प्रमाणपत्र को crt प्रारूप में परिवर्तित करें और इसे प्रमाणपत्रों के लिए निर्देशिका में रखें विश्वसनीय केंद्रप्राधिकरण:
# apt-get install ca-certificates # mkdir /usr/share/ca-certificates/stupin.su # openssl x509 -in /etc/ssl/demoCA/cacert.pem -out /usr/share/ca-certificates/stupin. su/cacert.crt अब प्रमाणपत्रों की एक नई सूची तैयार करते हैं जिन पर हमारा सिस्टम भरोसा करेगा:
# dpkg-reconfigure ca-certificates खुलने वाली विंडो में, आपको "ask" का जवाब देना होगा और सूची में हमारे प्रमाणपत्र को चिह्नित करना होगा। उसके बाद, एक नई /etc/ca-certificates.conf फाइल जेनरेट होगी (आपको यह जांचना होगा कि हमारा प्रमाणपत्र सूची में है और लाइन की शुरुआत में कोई विस्मयादिबोधक चिह्न नहीं है)। pem प्रमाणपत्रों को /etc/ssl/certs निर्देशिका में रखा जाएगा।

निम्नलिखित सेटिंग्स को /etc/postfix/main.cf फ़ाइल में जोड़ें:
# मेल भेजने वाले SMTP क्लाइंट को कॉन्फ़िगर करना smtp_tls_loglevel = 2 smtp_tls_CApath = /etc/ssl/certs सेटिंग्स के प्रभावी होने के लिए सर्वर को पुनरारंभ करना बाकी है:
6.2. सर्वर पर TLS सेट करना

पहले से तैयार एसएसएल प्रमाणपत्रों का उपयोग करके एन्क्रिप्शन सेट करें। ऐसा करने के लिए, निम्नलिखित सेटिंग्स को /etc/postfix/main.cf फ़ाइल में जोड़ें:
# मेल स्वीकार करने वाले SMTP सर्वर को कॉन्फ़िगर करें smtpd_tls_received_header = हाँ सेटिंग्स के प्रभावी होने के लिए सर्वर को पुनरारंभ करना बाकी है:
# /etc/init.d/postfix पुनरारंभ करें 6.3. सर्वर पर एकाधिक TLS प्रमाणपत्र

पोस्टफ़िक्स में एसएनआई एक्सटेंशन के लिए समर्थन नहीं है, क्योंकि एसएमटीपी में क्लाइंट यह निर्दिष्ट नहीं कर सकता कि वह किस डोमेन नाम से कनेक्ट हो रहा था। तदनुसार, जब तक क्लाइंट इसे संप्रेषित नहीं कर सकता, एसएमटीपी सर्वर सही प्रमाणपत्र का चयन नहीं कर सकता है। अन्य डोमेन से मेल की सेवा करने के लिए, आपको एक एमएक्स रिकॉर्ड सेट करना होगा जो सर्वर के डोमेन नाम को इंगित करता है, जिसे वह हेलो / ईएचएलओ कमांड में रिपोर्ट करता है।

पोस्टफिक्स में अलग-अलग आईपी पते पर अलग-अलग प्रमाणपत्रों से निपटने के लिए स्पष्ट सेटिंग्स भी नहीं हैं। हालांकि, सुनने वाले आईपी पते, सर्वर नाम और उपयोग किए गए प्रमाणपत्रों के लिए अलग-अलग सेटिंग्स के साथ एसएमटीपीडी सर्वर के कई उदाहरण चलाना संभव है। ऐसा करने के लिए, आप निम्न सेटिंग्स को /etc/postfix/master.cf फ़ाइल में सेट करने का प्रयास कर सकते हैं:
192.168.0.1:smtp inet n - n - - smtpd -o smtpd_tls_key_file=/etc/ssl/domain1.net.private.pem -o smtpd_tls_cert_file=/etc/ssl/domain1.net.public.pem -o myhostname=domain1. net -o mydomain=domain1.net -o myorigin=domain1.net 172.16.0.1:smtp inet n - n - - smtpd -o smtpd_tls_key_file=/etc/ssl/domain2.ru.private.pem -o smtpd_tls_cert_file=/etc ssl/domain2.ru.public.pem -o myhostname=domain2.ru -o mydomain=domain2.ru -o myorigin=domain2.ru या आप कई सर्वर इंस्टेंस बनाने के लिए पोस्टफिक्स की नई सुविधा का उपयोग कर सकते हैं। आप इसके बारे में http://www.postfix.org/MULTI_INSTANCE_README.html पर अधिक पढ़ सकते हैं

6.4. प्रदर्शन अनुकूलन

टीएलएस सत्र प्रबंधक की स्थापना का वर्णन "6" खंड में पोस्टफिक्स, ओपनडीकेआईएम, क्लैमएवी-मिल्टर, मिल्टर-ग्रेलिस्ट को स्थापित और कॉन्फ़िगर करने वाले नोट में किया गया है। पोस्टफिक्स स्पीड ऑप्टिमाइज़ेशन।

7. कबूतर

जब आप एसएसएल समर्थन सक्षम करते हैं, तो आपको डिफ़ॉल्ट रूप से उपयोग करने के लिए एक प्रमाणपत्र निर्दिष्ट करना होगा। /etc/dovecot/conf.d/10-ssl.conf फ़ाइल में SSL समर्थन सक्षम करें:
ssl=हाँ ssl_cert=# /etc/init.d/dovecot पुनरारंभ डोवकोट एक या अधिक प्रमाणपत्रों का उपयोग कर सकता है। यदि एकाधिक प्रमाणपत्रों का उपयोग किया जाता है, तो अलग-अलग आईपी पते दोनों को अलग-अलग प्रमाणपत्र सौंपे जा सकते हैं जहां डोवकोट कनेक्शन और व्यक्तिगत सेवाओं के लिए सुनेंगे। उदाहरण के लिए, आप POP3 और IMAP के लिए अलग-अलग प्रमाणपत्र सेट कर सकते हैं (हालांकि यह स्पष्ट नहीं है कि इसका क्या अर्थ होगा)। उदाहरण के लिए, इस तरह:
स्थानीय 192.168.0.1 (प्रोटोकॉल imap(ssl_cert= .)

अलग-अलग IP पतों और सेवाओं के लिए अलग प्रमाणपत्रों का उपयोग करने से डिफ़ॉल्ट प्रमाणपत्र निर्दिष्ट करने की आवश्यकता समाप्त नहीं होती है। ध्यान से!

डोवकोट एसएसएल प्रोटोकॉल के विस्तार का भी समर्थन करता है जिसे सर्वर नेम इंडिकेशन या संक्षेप में एसएनआई कहा जाता है। यदि क्लाइंट इस एक्सटेंशन का समर्थन करता है, तो विभिन्न डोमेन नामों के लिए विभिन्न प्रमाणपत्रों का उपयोग किया जा सकता है। सेटिंग्स जिन्हें एसएनआई का उपयोग करते समय पंजीकृत किया जा सकता है:
local_name domain1.net(ssl_cert=

8. लाइटटपडी

लाइटटैप वेब सर्वर में एसएसएल को कॉन्फ़िगर करने के लिए, बस एसएसएल मॉड्यूल को सक्षम करें:
# lighty-enable-mod ssl B /etc/lighthttpd/conf-enabled/05-ssl.conf फ़ाइल में उपयोग किए जाने वाले प्रमाणपत्र को जोड़ें:
$SERVER["socket"] == "0.0.0.0:443" ( ssl.engine = "enable" ssl.pemfile = "/etc/ssl/vladimir.stupin.su.pem" ssl.cipher-list = "ECDHE -RSA-AES256-SHA384:AES256-SHA256:RC4: High:!MD5:!aNULL:!EDH:!AESGCM" ssl.honor-cipher-order = "enable" ) और वेब सर्वर को इसकी नई सेटिंग्स लेने के लिए पुनरारंभ करें के आधार पर प्रभाव:
# /etc/init.d/lighthttpd पुनरारंभ जैसा कि आप देख सकते हैं, सेटिंग्स सुनने वाले आईपी पते और टीसीपी पोर्ट 443 के साथ एक मैच की जांच करती हैं। जाहिर है, इस तरह आप कई एसएसएल प्रमाणपत्र सेट कर सकते हैं, जिनमें से प्रत्येक का उपयोग तब किया जाएगा जब क्लाइंट एक विशिष्ट वेब सर्वर आईपी पते तक पहुंचता है। उदाहरण के लिए, इस तरह:
$SERVER["socket"] == "192.168.0.1:443" ( ssl.engine = "enable" ssl.pemfile = "/etc/ssl/domain1.net.pem" ssl.cipher-list = "ECDHE-RSA -AES256-SHA384:AES256-SHA256:RC4: High:!MD5:!aNULL:!EDH:!AESGCM" ssl.honor-cipher-order = "enable") $SERVER["socket"] == "172.16.0.1 :443" ( ssl.engine = "enable" ssl.pemfile = "/etc/ssl/domain2.ru.pem" ssl.cipher-list = "ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4: High: !MD5:!aNULL:!EDH:!AESGCM" ssl.honor-cipher-order = "enable" ) हालांकि, प्रति आईपी पते पर केवल एक प्रमाणपत्र इस तरह निर्दिष्ट किया जा सकता है। यदि एक आईपी पते पर कई डोमेन प्रस्तुत किए जाते हैं, तो आप या तो इस प्रमाणपत्र में सभी आवश्यक साइटों के डोमेन नाम पंजीकृत कर सकते हैं, या एसएनआई समर्थन का उपयोग कर सकते हैं।

लाइटटीपीडी वेब सर्वर संस्करण 1.4.24 से एसएनआई का समर्थन करता है यदि ओपनएसएसएल संस्करण 0.9.8f या उच्चतर स्थापित है। अलग-अलग डोमेन के लिए अलग-अलग प्रमाणपत्र सेट करने के लिए, आप सशर्त अनुभागों का उपयोग कर सकते हैं, उनके अंदर उपयोग किए गए प्रमाणपत्र को बदल सकते हैं:
$HTTP["host"] == "domain1.net" (ssl.pemfile = "/etc/ssl/domain1.net.pem") $HTTP["host"] == "domain2.ru" ( ssl.pemfile = "/etc/ssl/domain2.ru.pem" ) कुछ साइटों पर एसएसएल के उपयोग को बाध्य करने के लिए, आप /etc/lighthttpd/conf-enabled/05-ssl.conf फ़ाइल में निम्नलिखित सशर्त अनुभाग दर्ज कर सकते हैं :
$HTTP["host"] =~ "^domain(1\.net|2\.ru)$" ( url.redirect = (".*" => "https://%0$0")) ध्यान देने योग्य कि साइटों को ऐसे पुनर्निर्देशन के लिए तैयार किया जाना चाहिए। उदाहरण के लिए, साइट पर सभी आंतरिक लिंक में, आपको http प्रोटोकॉल विनिर्देश को हटा देना चाहिए। सभी आंतरिक साइट लिंक या तो सापेक्ष होने चाहिए या दो स्लैश से शुरू होने चाहिए।

जारी रहती है...

टीएलएस एसएसएल का उत्तराधिकारी है, एक प्रोटोकॉल जो इंटरनेट पर नोड्स के बीच एक विश्वसनीय और सुरक्षित कनेक्शन प्रदान करता है। इसका उपयोग विभिन्न क्लाइंट के विकास में किया जाता है, जिसमें ब्राउज़र और क्लाइंट-सर्वर एप्लिकेशन शामिल हैं। इंटरनेट एक्सप्लोरर में टीएलएस क्या है?

प्रौद्योगिकी के बारे में थोड़ा

वित्तीय लेनदेन में लगे सभी उद्यम और संगठन इस प्रोटोकॉल का उपयोग पैकेटों के वायरटैपिंग और घुसपैठियों द्वारा अनधिकृत पहुंच को बाहर करने के लिए करते हैं। यह तकनीक महत्वपूर्ण कनेक्शनों को दुर्भावनापूर्ण हमलों से बचाने के लिए डिज़ाइन की गई है।

मूल रूप से, अपने संगठन में वे अंतर्निहित ब्राउज़र का उपयोग करते हैं। कुछ मामलों में, मोज़िला फ़ायरफ़ॉक्स।

प्रोटोकॉल सक्षम या अक्षम करें

कुछ साइटों को कभी-कभी इस तथ्य के कारण एक्सेस नहीं किया जा सकता है कि एसएसएल और टीएलएस प्रौद्योगिकियों के लिए समर्थन अक्षम है। ब्राउज़र में एक सूचना पॉप अप होती है। तो, आप प्रोटोकॉल को सुरक्षित संचार का उपयोग जारी रखने के लिए कैसे सक्षम करते हैं?
1. प्रारंभ के माध्यम से नियंत्रण कक्ष खोलें। दूसरा तरीका: एक्सप्लोरर खोलें और ऊपरी दाएं कोने में गियर आइकन पर क्लिक करें।

2. "इंटरनेट विकल्प" अनुभाग पर जाएं और "उन्नत" ब्लॉक खोलें।

3. "टीएलएस 1.1 और टीएलएस 1.2 का उपयोग करें" के बगल में स्थित बॉक्स चेक करें।

4. अपने परिवर्तनों को सहेजने के लिए ठीक क्लिक करें। यदि आप प्रोटोकॉल को अक्षम करना चाहते हैं, जो अत्यधिक हतोत्साहित किया जाता है, खासकर यदि आप इंटरनेट बैंकिंग का उपयोग करते हैं, तो उसी आइटम को अनचेक करें।

1.0 और 1.1 और 1.2 में क्या अंतर है? 1.1 टीएलएस 1.0 का केवल थोड़ा उन्नत संस्करण है, जो आंशिक रूप से इसकी कमियों को विरासत में मिला है। 1.2 प्रोटोकॉल का सबसे सुरक्षित संस्करण है। दूसरी ओर, इस प्रोटोकॉल संस्करण के सक्षम होने पर सभी साइटें नहीं खुल सकती हैं।

जैसा कि आप जानते हैं, स्काइप मैसेंजर एक विंडोज़ घटक के रूप में सीधे इंटरनेट एक्सप्लोरर से संबंधित है। यदि आपके पास सेटिंग्स में TLS प्रोटोकॉल की जाँच नहीं है, तो Skype के साथ समस्याएँ हो सकती हैं। प्रोग्राम बस सर्वर से कनेक्ट नहीं हो पाएगा।

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

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

एसएसएल क्या है और टीएलएस क्या है?

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

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

एसएसएल 1.0 - कभी प्रकाशित नहीं हुआ
एसएसएल 2.0 - फरवरी 1995
एसएसएल 3.0 - 1996
टीएलएस 1.0 - जनवरी 1999
टीएलएस 1.1 - अप्रैल 2006
टीएलएस 1.2 - अगस्त 2008

एसएसएल और टीएलएस कैसे काम करते हैं

एसएसएल और टीएलएस के संचालन का सिद्धांत, जैसा कि मैंने कहा, वही है। टीसीपी / आईपी प्रोटोकॉल पर एक एन्क्रिप्टेड चैनल स्थापित किया जाता है, जिसके भीतर डेटा को एप्लिकेशन प्रोटोकॉल - एचटीटीपी, एफ़टीपी, और इसी तरह से प्रसारित किया जाता है। यहां बताया गया है कि इसे ग्राफिक रूप से कैसे दर्शाया जा सकता है:

एप्लिकेशन प्रोटोकॉल टीएलएस/एसएसएल में "लिपटे" है, जो बदले में, टीसीपी/आईपी में लपेटा गया है। वास्तव में, एप्लिकेशन प्रोटोकॉल डेटा टीसीपी / आईपी पर प्रेषित होता है, लेकिन यह एन्क्रिप्टेड होता है। और केवल मशीन जिसने कनेक्शन स्थापित किया है वह प्रेषित डेटा को डिक्रिप्ट कर सकता है। प्रेषित पैकेट प्राप्त करने वाले अन्य सभी लोगों के लिए, यह जानकारी अर्थहीन होगी यदि वे इसे डिक्रिप्ट नहीं कर सकते हैं।

कनेक्शन कई चरणों में स्थापित किया गया है:

1) क्लाइंट सर्वर से कनेक्शन स्थापित करता है और एक सुरक्षित कनेक्शन का अनुरोध करता है। यह या तो एक पोर्ट पर एक कनेक्शन स्थापित करके प्राप्त किया जा सकता है जिसे मूल रूप से एसएसएल / टीएलएस के साथ काम करने के लिए डिज़ाइन किया गया है, उदाहरण के लिए, 443, या अतिरिक्त रूप से क्लाइंट से एक सामान्य कनेक्शन स्थापित करने के बाद एक सुरक्षित कनेक्शन स्थापित करने का अनुरोध करके।

2) कनेक्शन स्थापित करते समय, क्लाइंट एन्क्रिप्शन एल्गोरिदम की एक सूची प्रदान करता है जिसे वह "जानता है"। सर्वर प्राप्त सूची की तुलना एल्गोरिदम की सूची से करता है जिसे सर्वर स्वयं "जानता है" और सबसे विश्वसनीय एल्गोरिदम का चयन करता है, जिसके बाद यह क्लाइंट को बताता है कि किस एल्गोरिदम का उपयोग करना है

3) सर्वर क्लाइंट को प्रमाणीकरण प्राधिकारी द्वारा हस्ताक्षरित अपना डिजिटल प्रमाणपत्र और सर्वर की सार्वजनिक कुंजी भेजता है।

4) क्लाइंट विश्वसनीय सीए के सर्वर से संपर्क कर सकता है जिसने सर्वर के प्रमाणपत्र पर हस्ताक्षर किए हैं और जांच सकते हैं कि सर्वर का प्रमाणपत्र मान्य है या नहीं। लेकिन यह कनेक्ट नहीं हो सकता है। ऑपरेटिंग सिस्टम में आमतौर पर पहले से ही प्रमाणन प्राधिकरणों के रूट प्रमाणपत्र स्थापित होते हैं, जिसके विरुद्ध सर्वर प्रमाणपत्रों के हस्ताक्षर, उदाहरण के लिए, ब्राउज़र, सत्यापित होते हैं।

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

6) इस प्रकार एक एन्क्रिप्टेड कनेक्शन स्थापित किया जाता है। कनेक्शन समाप्त होने तक इस पर प्रेषित डेटा एन्क्रिप्ट और डिक्रिप्ट किया जाता है।

रूट प्रमाणपत्र

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

हस्ताक्षर अनुरोध (सीएसआर, प्रमाणपत्र हस्ताक्षर अनुरोध)

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

ग्राहक प्रमाणपत्र

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

प्रमाण पत्र बनाने के लिए क्रियाओं की श्रृंखला

आइए व्यवहार में देखें कि प्रमाण पत्र की पीढ़ी से संबंधित क्रियाएं कैसे शुरू से ही काम करती हैं, और साथ ही व्यवहार में भी।

सबसे पहले रूट सर्टिफिकेट जेनरेट करना है। मूल प्रमाणपत्र पर स्वयं हस्ताक्षर किए जाते हैं। और फिर इस प्रमाण पत्र के साथ अन्य प्रमाणपत्रों पर हस्ताक्षर किए जाएंगे।

$openssl genrsa -out root.key 2048 RSA निजी कुंजी बनाना, 2048 बिट लंबा मापांक .........+++ ................... ........................+++ ई 65537 (0x10001) है $ openssl req -new -key root.key -out root.csr आप हैं आपके प्रमाणपत्र अनुरोध में शामिल की जाने वाली जानकारी दर्ज करने के लिए कहा जाएगा। आप जो दर्ज करने जा रहे हैं उसे विशिष्ट नाम या डीएन कहा जाता है। काफी कुछ फ़ील्ड हैं लेकिन आप कुछ खाली छोड़ सकते हैं कुछ फ़ील्ड के लिए एक डिफ़ॉल्ट मान होगा, यदि आप "." दर्ज करते हैं, तो फ़ील्ड खाली छोड़ दी जाएगी। ----- देश का नाम (2 अक्षर कोड): आरयू राज्य या प्रांत का नाम (पूरा नाम): एन / ए इलाके का नाम (जैसे, शहर): सेंट-पीटर्सबर्ग संगठन का नाम (जैसे, कंपनी): मेरी कंपनी संगठनात्मक इकाई का नाम (उदाहरण के लिए, अनुभाग): आईटी सेवा सामान्य नाम (जैसे सर्वर एफक्यूडीएन या आपका नाम): मेरी कंपनी रूट प्रमाणपत्र ईमेल पता: [ईमेल संरक्षित]कृपया अपने प्रमाणपत्र अनुरोध के साथ भेजे जाने के लिए निम्नलिखित "अतिरिक्त" विशेषताएं दर्ज करें एक चुनौती पासवर्ड: एक वैकल्पिक कंपनी का नाम: मेरी कंपनी $ ओपनएसएल x509 -req -days 3650 -in root.csr -signkey root.key -out root.pem हस्ताक्षर ठीक विषय = / सी = आरयू / एसटी = एन / ए / एल = सेंट-पीटर्सबर्ग / ओ = मेरी कंपनी / ओयू = आईटी सेवा / सीएन = मेरी कंपनी रूट प्रमाणपत्र / [ईमेल संरक्षित]निजी कुंजी प्राप्त करना

इस प्रकार, हमने पहले एक निजी कुंजी, फिर एक हस्ताक्षर अनुरोध उत्पन्न किया, और फिर अपनी कुंजी के साथ अपने स्वयं के अनुरोध पर हस्ताक्षर किए और 10 वर्षों के लिए जारी अपना स्वयं का डिजिटल प्रमाणपत्र प्राप्त किया। प्रमाणपत्र बनाते समय पासवर्ड (चुनौती पासवर्ड) छोड़ा जा सकता है।

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

प्रमाणपत्र की जानकारी देखें

प्रमाण पत्र की सामग्री को इस तरह देखा जा सकता है:

$openssl x509 -noout -इश्यूअर -एंडडेट -in root.pem जारीकर्ता = /C=RU/ST=N/A/L=सेंट-पीटर्सबर्ग/O=मेरी कंपनी/OU=IT सेवा/CN=मेरी कंपनी रूट प्रमाणपत्र/ [ईमेल संरक्षित]बाद में नहीं = 22 जनवरी 11:49:41 2025 जीएमटी

हम देखते हैं कि यह प्रमाणपत्र किसने जारी किया और इसकी समय सीमा कब समाप्त हुई।

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

सर्वर के लिए प्रमाणपत्र पर हस्ताक्षर करने के लिए, हमें निम्नलिखित कार्य करने होंगे:

1) एक कुंजी उत्पन्न करें
2) एक हस्ताक्षर अनुरोध उत्पन्न करें
3) सीएसआर फ़ाइल को प्राधिकरण केंद्र को भेजें या स्वयं उस पर हस्ताक्षर करें

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

$openssl genrsa -out server.key 2048 RSA निजी कुंजी बनाना, 2048 बिट लंबा मापांक ................................... ……………………………………….. +++ ................. जानकारी दर्ज करने के लिए कहा गया है जिसे आपके प्रमाणपत्र अनुरोध में शामिल किया जाएगा। आप जो दर्ज करने जा रहे हैं उसे विशिष्ट नाम या डीएन कहा जाता है। काफी कुछ फ़ील्ड हैं लेकिन आप कुछ खाली छोड़ सकते हैं कुछ फ़ील्ड के लिए एक डिफ़ॉल्ट मान होगा, यदि आप "." दर्ज करते हैं, तो फ़ील्ड खाली छोड़ दी जाएगी। ----- देश का नाम (2 अक्षर कोड): आरयू राज्य या प्रांत का नाम (पूरा नाम): एन / ए इलाके का नाम (जैसे, शहर): सेंट-पीटर्सबर्ग संगठन का नाम (जैसे, कंपनी): मेरी कंपनी संगठनात्मक इकाई का नाम (उदाहरण के लिए, अनुभाग): आईटी सेवा सामान्य नाम (जैसे सर्वर एफक्यूडीएन या आपका नाम): www.mycompany.com ईमेल पता: [ईमेल संरक्षित]कृपया अपने प्रमाणपत्र अनुरोध के साथ भेजे जाने के लिए निम्नलिखित "अतिरिक्त" विशेषताएँ दर्ज करें एक चुनौती पासवर्ड: एक वैकल्पिक कंपनी का नाम: $ openssl x509 -req -in server.csr -CA root.pem -CAkey root.key -CAcreateserial -out सर्वर। pem -days 365 सिग्नेचर ओके सब्जेक्ट=/सी=आरयू/एसटी=एन/ए/एल=सेंट-पीटर्सबर्ग/ओ=मेरी कंपनी/ओयू=आईटी सर्विस/सीएन=www.mycompany.com/ [ईमेल संरक्षित] CA निजी कुंजी प्राप्त करना $openssl x509 -noout -जारीकर्ता -विषय-समाप्ति-समापन-सर्वर.pem जारीकर्ता = /C=RU/ST=N/A/L=सेंट-पीटर्सबर्ग/O=मेरी कंपनी/OU=IT सेवा/CN =मेरी कंपनी रूट प्रमाणपत्र/ [ईमेल संरक्षित]विषय = /सी=आरयू/एसटी=एन/ए/एल=सेंट-पीटर्सबर्ग/ओ=मेरी कंपनी/ओयू=आईटी सेवा/सीएन=www.mycompany.com/ [ईमेल संरक्षित] notafter=जनवरी 25 12:22:32 2016 जीएमटी

इस प्रकार, सर्वर प्रमाणपत्र पर हस्ताक्षर किए जाते हैं और हमें पता चल जाएगा कि यह प्रमाणपत्र किस संगठन ने जारी किया है। हस्ताक्षर करने के बाद, तैयार प्रमाणपत्र का उपयोग अपने इच्छित उद्देश्य के लिए किया जा सकता है, उदाहरण के लिए, वेब सर्वर पर स्थापित।

Nginx वाले सर्वर पर SSL/TLS प्रमाणपत्र स्थापित करना

Nginx वेब सर्वर पर SSL / TLS प्रमाणपत्र स्थापित करने के लिए, आपको कुछ सरल चरणों का पालन करना होगा:

1) सर्वर पर .key और .pem फाइलों को कॉपी करें। अलग-अलग ऑपरेटिंग सिस्टम पर सर्टिफिकेट और कीज़ को अलग-अलग डायरेक्टरी में स्टोर किया जा सकता है। डेबियन पर, उदाहरण के लिए, यह प्रमाणपत्रों के लिए /etc/ssl/certs और चाबियों के लिए /etc/ssl/private है। CentOS पर ये हैं /etc/pki/tls/certs और /etc/pki/tls/private

2) होस्ट के लिए कॉन्फ़िगरेशन फ़ाइल में आवश्यक सेटिंग्स लिखें। यहाँ यह कैसा दिखना चाहिए (यह सिर्फ एक उदाहरण है):

सर्वर (सुनो 443; server_name www.mycompany.com; रूट html; index.html index.htm; ssl on; ssl_certificate server.pem; ssl_certificate_key server.key; ssl_session_timeout 5m; # SSLv3 अनुशंसित नहीं है!!! # यह यहाँ है बस उदाहरण के लिए ssl_protocols SSLv3 TLSv1; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+high:+MEDIUM:+LOW:+SSLv3:+EXP; ssl_prefer_server_ciphers on; स्थान / (try_files $uri $uri/) )

3) nginx को पुनरारंभ करें

4) ब्राउज़र पोर्ट 443 सर्वर - https://www.mycompany.com पर जाएं और इसके प्रदर्शन की जांच करें।

अपाचे सर्वर पर एसएसएल/टीएलएस प्रमाणपत्र स्थापित करना

अपाचे पर एक एसएसएल/टीएलएस प्रमाणपत्र स्थापित करना उसी के बारे में दिखता है।

1) कुंजी और प्रमाणपत्र फ़ाइलों को उपयुक्त निर्देशिकाओं में सर्वर पर कॉपी करें

2) अपाचे के लिए "a2enmod ssl" कमांड के साथ ssl मॉड्यूल को सक्षम करें, अगर यह पहले से सक्षम नहीं है

3) एक वर्चुअल होस्ट बनाएं जो पोर्ट 443 पर सुनेगा। कॉन्फिग कुछ इस तरह दिखेगा:

सर्वर एडमिन [ईमेल संरक्षित] DocumentRoot /var/www विकल्प अनुसरण करेंSymLinks अनुमति दें कोई नहीं ओवरराइड करें विकल्प अनुक्रमित अनुसरण करेंSymLinks MultiViews AllowOverride कोई नहीं आदेश की अनुमति दें, सभी से अनुमति से इनकार करें ScriptAlias ​​​​/cgi-bin/ /usr/lib/cgi-bin/ अनुमति दें ओवरराइड कोई भी विकल्प नहीं + एक्ज़ेकसीजीआई -मल्टी व्यू + सिमलिंक्सअगर ओनरमैच ऑर्डर की अनुमति है, तो सभी से अनुमति से इनकार करें ErrorLog $(APACHE_LOG_DIR)/error.log LogLevel चेतावनी CustomLog $(APACHE_LOG_DIR)/ssl_access.log SSLCertificateFile /etc/ssl/certs/server.pem SSLCertificateKeyFile /etc/ssl/private/server पर संयुक्त SSLEngine # यह निर्देश a.key जोड़ता है। फ़ाइल , जिसमें सर्वर प्रमाणपत्र पर हस्ताक्षर करने वाले सभी प्रमाणपत्रों की सूची # शामिल है #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt SSLOptions+StdEnvVars SSLOptions+StdEnvVars BrowserMatch "MSIE" \ nokeepalive ssl-unclean-shutdown \ downgrad-1.0 force-response-1.0 BrowserMatch "MSIE" ssl-unclean-shutdown

वहीं, एक और काम करने की जरूरत है। फ़ाइल httpd.conf, या apache2.conf, या port.conf में, सिस्टम के आधार पर, कॉन्फ़िगरेशन के निम्न अनुभाग में खोजें:

सुनो 443

यदि ऐसी कोई शर्त नहीं है, तो इसे config. और एक और बात: आपको एक लाइन जोड़ने की जरूरत है

नामवर्चुअलहोस्ट *:443

यह लाइन httpd.conf, apache2.conf या port.conf में हो सकती है

4) अपाचे वेबसर्वर को पुनरारंभ करें

क्लाइंट प्रमाणपत्र बनाएं

क्लाइंट सर्टिफिकेट सर्वर सर्टिफिकेट की तरह ही बनाया जाता है।

$openssl genrsa -out client.key 2048 RSA निजी कुंजी बनाना, 2048 बिट लंबा मापांक ………………………+++ ..... ......................................................+++ ई is 65537 (0x10001) $ openssl req -new -key client.key -out client.csr आप जो दर्ज करने जा रहे हैं उसे विशिष्ट नाम या डीएन कहा जाता है। काफी कुछ फ़ील्ड हैं लेकिन आप कुछ खाली छोड़ सकते हैं कुछ फ़ील्ड के लिए एक डिफ़ॉल्ट मान होगा, यदि आप "." दर्ज करते हैं, तो फ़ील्ड खाली छोड़ दी जाएगी। ----- देश का नाम (2 अक्षर कोड): RU राज्य या प्रांत का नाम (पूरा नाम): सेंट-पीटर्सबर्ग इलाके का नाम (जैसे, शहर): ^ सी [ईमेल संरक्षित]:~/Temp/certs/CA$ openssl req -new -key client.key -out client.csr आपसे ऐसी जानकारी दर्ज करने के लिए कहा जाने वाला है जिसे आपके प्रमाणपत्र अनुरोध में शामिल किया जाएगा। आप जो दर्ज करने जा रहे हैं उसे विशिष्ट नाम या डीएन कहा जाता है। काफी कुछ फ़ील्ड हैं लेकिन आप कुछ खाली छोड़ सकते हैं कुछ फ़ील्ड के लिए एक डिफ़ॉल्ट मान होगा, यदि आप "." दर्ज करते हैं, तो फ़ील्ड खाली छोड़ दी जाएगी। ----- देश का नाम (2 अक्षर कोड): RU राज्य या प्रांत का नाम (पूरा नाम): N/A इलाके का नाम (जैसे, शहर): सेंट-पेटर्सबर्ग संगठन का नाम (जैसे, कंपनी): मेरी कंपनी संगठनात्मक इकाई का नाम (उदाहरण के लिए, अनुभाग): इंजीनियरिंग सामान्य नाम (जैसे सर्वर FQDN या आपका नाम): इवान इवानोव ईमेल पता: [ईमेल संरक्षित]कृपया अपने प्रमाणपत्र अनुरोध के साथ भेजे जाने के लिए निम्नलिखित "अतिरिक्त" विशेषताएं दर्ज करें एक चुनौती पासवर्ड: एक वैकल्पिक कंपनी का नाम: $ openssl x509 -req -in client.csr -CA root.pem -CAkey root.key -CAcreateserial -out क्लाइंट। pem -days 365 सिग्नेचर ओके सब्जेक्ट=/सी=आरयू/एसटी=एन/ए/एल=सेंट-पेटर्सबर्ग/ओ=मेरी कंपनी/ओयू=इंजीनियरिंग/सीएन=इवान इवानोव/ [ईमेल संरक्षित] CA निजी कुंजी प्राप्त करना $openssl x509 -noout -जारीकर्ता -विषय -समाप्ति-क्लाइंट.pem जारीकर्ता= /C=RU/ST=N/A/L=सेंट-पीटर्सबर्ग/O=मेरी कंपनी/OU=IT सेवा/CN =मेरी कंपनी रूट प्रमाणपत्र/ [ईमेल संरक्षित]विषय = /सी=आरयू/एसटी=एन/ए/एल=सेंट-पेटर्सबर्ग/ओ=मेरी कंपनी/ओयू=इंजीनियरिंग/सीएन=इवान इवानोव/ [ईमेल संरक्षित]बाद में नहीं=जनवरी 25 13:17:15 2016 जीएमटी

यदि आपको PKCS12 प्रारूप में क्लाइंट प्रमाणपत्र की आवश्यकता है, तो इसे बनाएं:

$openssl pkcs12 -export -in client.pem -inkey client.key -certfile root.pem -out iivanov.p12 निर्यात पासवर्ड दर्ज करें: सत्यापित करना - निर्यात पासवर्ड दर्ज करें:

अब हम अपने सर्वर के साथ काम करने के लिए क्लाइंट सर्टिफिकेट का उपयोग कर सकते हैं।

क्लाइंट प्रमाणपत्रों का उपयोग करने के लिए nginx को कॉन्फ़िगर करना

सबसे अधिक बार, जैसा कि मैंने कहा, एकतरफा प्रमाणीकरण का उपयोग किया जाता है, आमतौर पर केवल सर्वर प्रमाणपत्र की जाँच की जाती है। आइए देखें कि क्लाइंट प्रमाणपत्र को मान्य करने के लिए nginx वेब सर्वर कैसे प्राप्त करें। सर्वर अनुभाग में क्लाइंट प्रमाणपत्रों के साथ काम करने के लिए विकल्प जोड़ना आवश्यक है:

# क्लाइंट ssl_client_certificate /etc/nginx/certs/clientroot.pem द्वारा हस्ताक्षरित रूट प्रमाणपत्र; # संभावित विकल्प: पर | बंद | वैकल्पिक | वैकल्पिक_नो_का ssl_verify_client वैकल्पिक; # क्लाइंट ssl_verify_depth 2 द्वारा हस्ताक्षरित प्रमाणपत्रों की श्रृंखला की जाँच की गहराई;

उसके बाद, आपको सेटिंग्स या पूरे सर्वर को पुनरारंभ करने की आवश्यकता है और आप काम की जांच कर सकते हैं।

क्लाइंट प्रमाणपत्रों का उपयोग करने के लिए अपाचे को कॉन्फ़िगर करना

वर्चुअल होस्ट अनुभाग में अतिरिक्त विकल्प जोड़कर अपाचे को भी कॉन्फ़िगर किया गया है:

# SSLCARevocationPath क्लाइंट /etc/apache2/ssl.crl/ # या SSLCARevocationFile प्रमाणपत्र /etc/apache2/ssl.crl/ca-bundle.crl युक्त फ़ाइल की जाँच के लिए रूट प्रमाणपत्र वाली निर्देशिका # क्लाइंट सत्यापन विकल्प। विकल्प हैं: # कोई नहीं, वैकल्पिक, आवश्यकता और वैकल्पिक_नो_का SSLVerifyClient को # हस्ताक्षर श्रृंखला लुकअप की गहराई की आवश्यकता है। डिफ़ॉल्ट 1 SSLVerifyDepth 2

जैसा कि आप देख सकते हैं, विकल्प लगभग nginx के समान हैं, क्योंकि सत्यापन प्रक्रिया एक समान तरीके से आयोजित की जाती है।

Opensl के साथ प्रमाणपत्र जानकारी सुनना

यह सत्यापित करने के लिए कि सर्वर क्लाइंट प्रमाणपत्रों के साथ इंटरैक्ट करता है, आप जांच सकते हैं कि क्या कनेक्शन TLS/SSL का उपयोग करके स्थापित किया गया है।

सर्वर साइड पर, हम Opensl का उपयोग करके पोर्ट को सुनना शुरू करते हैं:

Openssl s_server - 443 -cert server.pem -key server.key -state स्वीकार करें

क्लाइंट साइड पर, हम सर्वर तक पहुँचते हैं, उदाहरण के लिए, culr के साथ:

कर्ल-के https://127.0.0.1:443

सर्वर साइड से कंसोल में, आप सर्वर और क्लाइंट के बीच सूचना विनिमय की प्रक्रिया का निरीक्षण कर सकते हैं।

आप -verify [सत्यापन गहराई] और -verify [सत्यापन गहराई] विकल्पों का भी उपयोग कर सकते हैं। लोअरकेस विकल्प क्लाइंट से प्रमाणपत्र मांगता है, लेकिन उसे प्रदान करने की आवश्यकता नहीं है। बड़े अक्षरों में - यदि प्रमाणपत्र प्रदान नहीं किया गया है, तो एक त्रुटि होगी। आइए सर्वर साइड से इस तरह सुनना शुरू करें:

Openssl s_server - 443 -सर्टिफिकेट सर्वर.पेम -की सर्वर.की -स्टेट -वेरिफाई 3

सर्वर की ओर से, त्रुटि इस तरह दिखती है:

140203927217808: त्रुटि: 140890C7: SSL रूटीन: SSL3_GET_CLIENT_CERTIFICATE: सहकर्मी ने प्रमाणपत्र वापस नहीं किया: s3_srvr.c: 3287:

ग्राहक पक्ष से इस तरह:

कर्ल: (35) त्रुटि: 14094410: एसएसएल रूटीन: SSL3_READ_BYTES: sslv3 अलर्ट हैंडशेक विफलता

आइए क्लाइंट की ओर से एक प्रमाणपत्र और एक डोमेन नाम जोड़ें (सत्यापन के लिए, आप /etc/hosts फ़ाइल में 127.0.0.1 पते के लिए होस्ट नाम दर्ज कर सकते हैं):

कर्ल https://www.mycompany.com:443 --cacert root.pem --cert client.pem --key client.key

अब कनेक्शन सफल हो जाएगा और आप वेब सर्वर पर सर्वर सर्टिफिकेट इंस्टॉल कर सकते हैं, क्लाइंट को क्लाइंट सर्टिफिकेट दे सकते हैं और उनके साथ काम कर सकते हैं।

सुरक्षा

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

सामान्य तौर पर, इस प्रकार डिजिटल प्रमाणपत्र और टीएलएस और एसएसएल प्रोटोकॉल का उपयोग किया जाता है। यदि आपके कोई प्रश्न / जोड़ हैं, तो टिप्पणियों में लिखें।

यह प्रविष्टि लेखक द्वारा टैग की गई में पोस्ट की गई थी।

पोस्ट नेविगेशन

: 29 टिप्पणियाँ

1. cl-service.com

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

2. शुभचिंतक।

   स्तन के विषय का खुलासा नहीं किया गया है, क्योंकि वर्णित पीकेआई तकनीक का विषय शीर्षक से कोई लेना-देना नहीं है। यदि केवल किसी कारण से, मैं rfc को लिंक दूंगा।
   पी.एस. एक कुत्ते और एक पिस्सू के बारे में एक मजाक था।

3. शुभचिंतक।

   आपको ठेस पहुंचाने का मतलब कभी नहीं था। मैं व्यवहार में एसएसएल और टीएलएस के बीच अंतर के बारे में जानकारी ढूंढ रहा था और Google में आपका लिंक सबसे पहले था। विषय शीर्षक से उत्सुक था। सब कुछ बढ़िया है, लगे रहो!

4. डॉ ऐबोलिट

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

   1. मनोरिनपोस्ट लेखक

      इन उद्देश्यों के लिए मुझे अभी तक कोई विशिष्ट कार्यक्रम नहीं मिला है, लेकिन मैं इस मामले में कुछ सुझाव दे सकता हूं।
      उदाहरण के लिए, आप क्रोमियम या Google क्रोम का उपयोग कर सकते हैं। उदाहरण के लिए, साइट https://www.thawte.com/ को लें - एक कंपनी जो वास्तव में डिजिटल प्रमाणपत्रों से संबंधित है।
      एड्रेस बार में कंपनी का नाम और हरे रंग का पैडलॉक होगा। इसका मतलब है कि संगठन सत्यापित है, यह कम से कम एसएसएल ओवी है।
      यदि आप लॉक पर क्लिक करते हैं, और ड्रॉप-डाउन बॉक्स "विवरण", और फिर "प्रमाण पत्र देखें" में, आप प्रमाणपत्र के बारे में जानकारी देख सकते हैं। Thawte के लिए, प्रमाणपत्र पर निम्न प्रमाणपत्र के साथ हस्ताक्षर किए गए हैं: "thawte Extended Validation SHA256 SSL CA", और click.alfabank.ru के प्रमाणपत्र पर भी Thawte द्वारा हस्ताक्षर किए गए हैं, लेकिन एक अलग प्रमाणपत्र के साथ। ये "thawte EV SSL CA - G3" हैं, यानी ये एक्सटेंडेड वैलिडेशन भी पास कर चुके हैं।
      कुछ इस तरह।

5. रुस्लान

   खंड "एसएसएल और टीएलएस के संचालन का सिद्धांत", "क्लाइंट एक यादृच्छिक डिजिटल अनुक्रम उत्पन्न करता है"।

   मुझे यकीन था कि क्लाइंट एक सत्र निजी और तदनुसार, एक सार्वजनिक कुंजी (जिसे आप स्पष्ट रूप से "डिजिटल अनुक्रम" कहते हैं) उत्पन्न करता है। सार्वजनिक कुंजी सर्वर को पास की जाती है और सर्वर क्लाइंट के सत्र सार्वजनिक कुंजी के साथ पैकेट को क्लाइंट की ओर एन्क्रिप्ट करता है।

   कृपया स्पष्ट करें।

6. नौसिखिया

   लेख बहुत मददगार है! व्यावहारिक उदाहरण भी हैं =) केवल मुझे एक बात समझ में नहीं आई - रूट सर्टिफिकेट और सर्वर वन में क्या अंतर है? या यह वही बात है?

7. विटाली

   नमस्ते।
   होस्टर ने एक सेवा की पेशकश की - वर्चुअल सर्वर के लिए एसएसएल। फायदा उठाया है। यह पता चला कि तीसरे स्तर के लिए, अर्थात्। http://www.site.ru प्रमाणपत्र अमान्य है, केवल site.ru के लिए। इसके अलावा, आगंतुकों को हठपूर्वक https प्रोटोकॉल में फेंक दिया जाता है, इससे कोई फर्क नहीं पड़ता कि वे site.ru या http://www.site.ru पर जाते हैं। बेशक, दूसरे मामले में, ब्राउज़र दिल से शपथ लेना शुरू कर देता है, और आगंतुक साइट पर कभी नहीं जाता है।
   और जो लोग साइट पर पहुंचे, उनके लिए साइट टेढ़ी दिखने लगी, मेनू का हिस्सा गायब हो गया, खोज परिणामों में से कुछ चित्र अब कुछ घटकों द्वारा प्रदर्शित नहीं किए गए थे।

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

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

यदि, किसी साइट से कनेक्ट करते समय, ब्राउज़र यह निर्धारित करता है कि संसाधन गलत एसएसएल / टीएसएल सुरक्षा प्रोटोकॉल मापदंडों का उपयोग करता है, तो उपयोगकर्ता को उपरोक्त संदेश प्राप्त होता है, और साइट तक पहुंच अवरुद्ध हो सकती है।

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

त्रुटि के कारण "साइट टीएलएस प्रोटोकॉल के लिए पुरानी या अविश्वसनीय सुरक्षा सेटिंग्स का उपयोग कर सकती है" निम्नलिखित हो सकते हैं:

शिथिलता को कैसे ठीक करें: अविश्वसनीय TLS सुरक्षा सेटिंग्स का उपयोग किया जाता है

जो समस्या उत्पन्न हुई है उसका समाधान नीचे वर्णित विधियों में हो सकता है। लेकिन उनका वर्णन करने से पहले, मैं आपके पीसी को फिर से शुरू करने की सलाह देता हूं - सभी तुच्छता के लिए, यह विधि अक्सर काफी प्रभावी साबित होती है।

यदि यह मदद नहीं करता है, तो निम्न कार्य करें:

• अपने एंटीवायरस को अस्थायी रूप से अक्षम करें। कुछ मामलों में, एंटीवायरस ने अविश्वसनीय (इसके अनुमानों के अनुसार) साइटों तक पहुंच को अवरुद्ध कर दिया। एंटी-वायरस प्रोग्राम को अस्थायी रूप से अक्षम करें, या एंटी-वायरस सेटिंग्स में प्रमाणपत्र जाँच अक्षम करें (उदाहरण के लिए, Kaspersky Anti-Virus पर "सुरक्षित कनेक्शन स्कैन न करें");
• अपने कंप्यूटर पर क्रिप्टोप्रो प्रोग्राम का नवीनतम संस्करण स्थापित करें (इस प्रोग्राम के साथ पिछले काम के मामले में)। उत्पाद के पुराने संस्करण के कारण यह त्रुटि हो सकती है कि पृष्ठ से कोई सुरक्षित कनेक्शन नहीं है;
• अपनी आईई सेटिंग्स बदलें। "इंटरनेट विकल्प" पर जाएं, "सुरक्षा" टैब चुनें, फिर "विश्वसनीय साइट" पर क्लिक करें (आपके पोर्टल का पता पहले से ही दर्ज होना चाहिए, यदि नहीं, तो इसे दर्ज करें)। सबसे नीचे, "सुरक्षित मोड सक्षम करें" विकल्प को अनचेक करें।

  

  फिर ऊपर "साइट" बटन पर क्लिक करें, और "इस क्षेत्र में सभी साइटों के लिए..." विकल्प को अनचेक करें। "ओके" पर क्लिक करें और समस्या स्थल पर जाने का प्रयास करें।

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

  

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

  

  BIOS में "सिक्योर बूट" विकल्प को निष्क्रिय करें

निष्कर्ष

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

संपर्क में

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

इसलिए, हम टीएलएस प्रोटोकॉल के वर्तमान संस्करणों का उपयोग करने के लिए ब्राउज़रों को कॉन्फ़िगर करते हैं और इसके पुराने संस्करणों और एसएसएल का बिल्कुल भी उपयोग नहीं करते हैं। किसी भी मामले में, सिद्धांत रूप में जहां तक ​​संभव हो।

और सिद्धांत हमें बताता है कि हालांकि इंटरनेट एक्सप्लोरर ने संस्करण 8 के बाद से टीएलएस 1.1 और 1.2 का समर्थन किया है, विंडोज एक्सपी और विस्टा के तहत हम इसे ऐसा करने के लिए मजबूर नहीं करेंगे। क्लिक करें: उपकरण / इंटरनेट विकल्प / उन्नत और "सुरक्षा" खंड में हम पाते हैं: एसएसएल 2.0, एसएसएल 3.0, टीएलएस 1.0 ... कुछ और मिला? बधाई हो, आपके पास TLS 1.1/1.2 होगा! नहीं मिला - आपके पास विंडोज एक्सपी या विस्टा है, और रेडमंड में आपको पिछड़ा माना जाता है।

इसलिए, हम सभी एसएसएल से चेकमार्क हटाते हैं, हम उन्हें सभी उपलब्ध टीएलएस पर डालते हैं। यदि केवल टीएलएस 1.0 उपलब्ध है, तो ऐसा ही हो, यदि अधिक अप-टू-डेट संस्करण हैं, तो केवल उन्हें चुनना बेहतर है, और टीएलएस 1.0 को अनचेक करें (और बाद में आश्चर्यचकित न हों कि कुछ साइटें HTTPS के माध्यम से नहीं खुलती हैं) . फिर "लागू करें", "ओके" बटन पर क्लिक करें।

ओपेरा के साथ, यह आसान है - यह हमारे लिए विभिन्न प्रोटोकॉल संस्करणों के वास्तविक भोज की व्यवस्था करता है: उपकरण / सामान्य सेटिंग्स / उन्नत / सुरक्षा / सुरक्षा प्रोटोकॉल। हम क्या देखते हैं? पूरा सेट, जिसमें से हम केवल टीएलएस 1.1 और टीएलएस 1.2 के लिए चेकबॉक्स छोड़ते हैं, जिसके बाद हम "विवरण" बटन पर क्लिक करते हैं और वहां हम "256 बिट एईएस" से शुरू होने वाली लाइनों को छोड़कर सभी लाइनों को अनचेक करते हैं - वे बहुत ही हैं समाप्त। सूची की शुरुआत में "256 बिट एईएस ( अनाम DH/SHA-256), इसे भी अनचेक करें। "ओके" पर क्लिक करें और सुरक्षा का आनंद लें।

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

लेकिन गोलाकार ओगनेलिस फ़ायरफ़ॉक्स हमें बिल्कुल भी खुश नहीं करेगा: उपकरण / सेटिंग्स / उन्नत / एन्क्रिप्शन: हम केवल एसएसएल को अक्षम कर सकते हैं, टीएलएस केवल संस्करण 1.0 में उपलब्ध है, ऐसा करने के लिए कुछ नहीं है - हम इसे एक चेकमार्क के साथ छोड़ देते हैं।

हालांकि, तुलना में बुरा सीखा जाता है: क्रोम और सफारी में कोई भी सेटिंग नहीं होती है, जो एन्क्रिप्शन प्रोटोकॉल का उपयोग करना है। जहां तक ​​​​हम जानते हैं, सफारी विंडोज के तहत संस्करणों में 1.0 से अधिक हाल के टीएलएस संस्करणों का समर्थन नहीं करती है, और चूंकि इस ओएस के लिए नए संस्करणों को जारी करना बंद कर दिया गया है, इसलिए यह नहीं होगा।

क्रोम, जहाँ तक हम जानते हैं, टीएलएस 1.1 का समर्थन करता है, लेकिन, सफारी के मामले में, हम एसएसएल का उपयोग करने से इनकार नहीं कर सकते। क्रोम में टीएलएस 1.0 को अक्षम करना भी कोई रास्ता नहीं है। लेकिन टीएलएस 1.1 के वास्तविक उपयोग के साथ - एक बड़ा सवाल: इसे पहले चालू किया गया था, फिर संचालन में समस्याओं के कारण बंद कर दिया गया था, और जहां तक ​​कोई बता सकता है, इसे अभी तक वापस चालू नहीं किया गया है। यही है, समर्थन लगता है, लेकिन यह बंद है, और इसे उपयोगकर्ता को वापस चालू करने का कोई तरीका नहीं है। फ़ायरफ़ॉक्स के साथ एक ही कहानी - टीएलएस 1.1 इसमें समर्थन, वास्तव में है, लेकिन यह अभी तक उपयोगकर्ता के लिए उपलब्ध नहीं है।

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

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

अन्यथा, कोई विकल्प नहीं है: केवल ओपेरा और केवल टीएलएस 1.2 (टीएलएस 1.1 केवल टीएलएस 1.0 का सुधार है, आंशिक रूप से इसकी सुरक्षा समस्याओं को विरासत में मिला है)। हालांकि, हमारी पसंदीदा साइटें टीएलएस 1.2 का समर्थन नहीं कर सकती हैं :(