इस पेज पर, अपने सर्वर पर एचटीटीपीएस सेट अप करने के लिए दिशा-निर्देश दिए गए हैं. इनमें ये चरण शामिल हैं:
- 2048-बिट आरएसए सार्वजनिक/निजी कुंजी का जोड़ा बनाना.
- सर्टिफ़िकेट के लिए अनुरोध (सीएसआर) जनरेट करना, जिसमें आपकी सार्वजनिक कुंजी एम्बेड की गई हो.
- फ़ाइनल सर्टिफ़िकेट या सर्टिफ़िकेट चेन पाने के लिए, अपना सीएसआर, सर्टिफ़िकेट अथॉरिटी (सीए) के साथ शेयर करना.
- अपना फ़ाइनल सर्टिफ़िकेट ऐसी जगह पर इंस्टॉल करना जहां वेब से ऐक्सेस न किया जा सके. जैसे,
/etc/ssl(Linux और Unix) या जहां IIS को इसकी ज़रूरत हो (Windows).
कुंजियां और सर्टिफ़िकेट पर हस्ताक्षर करने के अनुरोध जनरेट करना
इस सेक्शन में, openssl कमांड-लाइन प्रोग्राम का इस्तेमाल किया जाता है. यह प्रोग्राम, ज़्यादातर Linux, BSD, और Mac OS X सिस्टम के साथ आता है. इसका इस्तेमाल, निजी और सार्वजनिक कुंजियों और सीएसआर जनरेट करने के लिए किया जाता है.
सार्वजनिक/निजी पासकोड का जोड़ा जनरेट करना
शुरू करने के लिए, 2,048-बिट आरएसए कुंजी का जोड़ा जनरेट करें. छोटी कुंजी को ब्रूट-फ़ोर्स (अनुमान लगाकर) हमले से तोड़ा जा सकता है. वहीं, लंबी कुंजियों में ज़रूरत से ज़्यादा संसाधनों का इस्तेमाल होता है.
आरएसए कुंजी का जोड़ा जनरेट करने के लिए, नीचे दिए गए निर्देश का इस्तेमाल करें:
openssl genrsa -out www.example.com.key 2048
इससे यह आउटपुट मिलता है:
Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)
सर्टिफ़िकेट पर हस्ताक्षर करने का अनुरोध जनरेट करना
इस चरण में, सर्टिफ़िकेट साइन करने के अनुरोध या सीएसआर में अपनी सार्वजनिक कुंजी और अपने संगठन और वेबसाइट की जानकारी जोड़ी जाती है. openssl कमांड, आपसे ज़रूरी मेटाडेटा मांगता है.
यह कमांड चलाएं:
openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr
यह इन चीज़ों को दिखाता है:
You are about to be asked to enter information that will be incorporated
into your certificate request
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:webmaster@example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
सीएसआर की पुष्टि करने के लिए, यह निर्देश चलाएं:
openssl req -text -in www.example.com.csr -noout
रिस्पॉन्स कुछ ऐसा दिखेगा:
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/emailAddress=webmaster@example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
...
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha256WithRSAEncryption
5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
...
सर्टिफ़िकेट देने वाली संस्था या निकाय को अपना सीएसआर सबमिट करना
अलग-अलग सर्टिफ़िकेट अथॉरिटी (सीए), आपसे अपने सीएसआर को अलग-अलग तरीकों से सबमिट करने के लिए कहती हैं. इनमें उनकी वेबसाइट पर मौजूद फ़ॉर्म का इस्तेमाल करना या ईमेल से सीएसआर भेजना शामिल हो सकता है. कुछ सीए या उनके रीसेलर, इस प्रोसेस के कुछ या सभी हिस्सों को अपने-आप भी कर सकते हैं. इनमें, कुछ मामलों में, पासकोड और सीएसआर जनरेट करना भी शामिल है.
सीएसआर को अपने सीए को भेजें और अपना आखिरी सर्टिफ़िकेट या सर्टिफ़िकेट चेन पाने के लिए, उनके निर्देशों का पालन करें.
अलग-अलग सीए, आपकी सार्वजनिक कुंजी की पुष्टि करने की सेवा के लिए अलग-अलग शुल्क लेते हैं.
अपनी पासकोड को एक से ज़्यादा डीएनएस नेम से मैप करने के विकल्प भी हैं. इनमें कई अलग-अलग नेम (उदाहरण के लिए, सभी example.com, www.example.com, example.net, और www.example.net) या *.example.com जैसे "वाइल्डकार्ड" नेम शामिल हैं.
सर्टिफ़िकेट को अपने सभी फ़्रंट-एंड सर्वर पर, वेब से ऐक्सेस न की जा सकने वाली जगह पर कॉपी करें. जैसे, /etc/ssl (Linux और Unix) या जहां IIS (Windows) के लिए ज़रूरी हो.
अपने सर्वर पर एचटीटीपीएस चालू करना
अपने वेब पेजों को सुरक्षित रखने के लिए, अपने सर्वर पर एचटीटीपीएस चालू करना ज़रूरी है.
- एचटीटीपीएस की सुविधा के लिए अपने सर्वर को सेट अप करने के लिए, Mozilla के सर्वर कॉन्फ़िगरेशन टूल का इस्तेमाल करें.
- अपनी साइट की नियमित तौर पर जांच करें. इसके लिए, Qualys के एसएसएल सर्वर टेस्ट का इस्तेमाल करें और पक्का करें कि आपको कम से कम A या A+ ग्रेड मिले.
इस समय, आपको ऑपरेशंस से जुड़ा अहम फ़ैसला लेना होगा. इनमें से कोई एक चुनें:
- अपने वेब सर्वर से कॉन्टेंट दिखाने वाले हर होस्टनेम के लिए, एक अलग आईपी पता तय करें.
- नेम-आधारित वर्चुअल होस्टिंग का इस्तेमाल करें.
अगर हर होस्टनेम के लिए अलग-अलग आईपी पतों का इस्तेमाल किया जा रहा है, तो सभी क्लाइंट के लिए एचटीटीपी और एचटीटीपीएस, दोनों का इस्तेमाल किया जा सकता है. हालांकि, ज़्यादातर साइट ऑपरेटर, आईपी पतों को बचाने के लिए, नाम पर आधारित वर्चुअल होस्टिंग का इस्तेमाल करते हैं. ऐसा इसलिए किया जाता है, क्योंकि आम तौर पर यह ज़्यादा सुविधाजनक होता है.
अगर आपके सर्वर पर एचटीटीपीएस सेवा पहले से उपलब्ध नहीं है, तो एचटीटीपी को एचटीटीपीएस पर रीडायरेक्ट किए बिना, इसे अभी चालू करें. ज़्यादा जानकारी के लिए, एचटीटीपी को एचटीटीपीएस पर रीडायरेक्ट करना देखें. खरीदे और इंस्टॉल किए गए सर्टिफ़िकेट का इस्तेमाल करने के लिए, अपने वेब सर्वर को कॉन्फ़िगर करें. आपको Mozilla का कॉन्फ़िगरेशन जनरेटर काम का लग सकता है.
अगर आपके पास कई होस्टनेम या सबडोमेन हैं, तो हर एक के लिए सही सर्टिफ़िकेट का इस्तेमाल करना होगा.
अब और अपनी साइट के पूरे जीवनकाल के दौरान, Qualys के एसएसएल सर्वर टेस्ट की मदद से, अपने एचटीटीपीएस कॉन्फ़िगरेशन की जांच करें. आपकी साइट को A या A+ ग्रेड मिलना चाहिए. कम ग्रेड मिलने पर, उस समस्या को गड़बड़ी मानें और सतर्क रहें, क्योंकि एल्गोरिदम और प्रोटोकॉल के ख़िलाफ़ हमेशा नए हमले किए जा रहे हैं.
इंटर्नैट साइट के यूआरएल को मिलते-जुलते बनाना
अब आपकी साइट, एचटीटीपी और एचटीटीपीएस, दोनों पर दिख रही है. इसलिए, प्रोटोकॉल के बावजूद, साइट को जितना हो सके उतना आसानी से काम करना चाहिए. एक अहम बात यह है कि इंटर्नैट साइट के लिंक के लिए, रिलेटिव यूआरएल का इस्तेमाल किया जाए.
पक्का करें कि इंटरनैट साइट यूआरएल और बाहरी यूआरएल, किसी खास प्रोटोकॉल पर निर्भर न हों.
रिलेटिव पाथ का इस्तेमाल करें या //example.com/something.js की तरह प्रोटोकॉल को हटाएं.
एचटीटीपीएस का इस्तेमाल करके, एचटीटीपी रिसॉर्स वाले पेज को दिखाने से समस्याएं हो सकती हैं. जब किसी ब्राउज़र को असुरक्षित रिसॉर्स का इस्तेमाल करने वाला ऐसा पेज मिलता है जो अन्यथा सुरक्षित है, तो वह उपयोगकर्ताओं को चेतावनी देता है कि पेज पूरी तरह से सुरक्षित नहीं है. साथ ही, कुछ ब्राउज़र एचटीटीपी रिसॉर्स को लोड या लागू करने से इनकार कर देते हैं. इससे पेज काम नहीं करता. हालांकि, एचटीटीपी पेज में एचटीटीपीएस रिसॉर्स को सुरक्षित तरीके से शामिल किया जा सकता है. इन समस्याओं को ठीक करने के बारे में ज़्यादा जानने के लिए, मिले-जुले कॉन्टेंट की समस्या को ठीक करना लेख पढ़ें.
आपकी साइट पर मौजूद अन्य पेजों के एचटीटीपी लिंक पर जाने से भी, उपयोगकर्ता अनुभव को एचटीटीपीएस से एचटीटीपी पर डाउनग्रेड किया जा सकता है. इसे ठीक करने के लिए, अपने इंटरसाइट यूआरएल को जितना हो सके उतना रिलेटिव बनाएं. इसके लिए, उन्हें प्रोटोकॉल-रिलेटिव (//example.com से शुरू होने वाले प्रोटोकॉल का इस्तेमाल न करें) या होस्ट-रिलेटिव (/jquery.js जैसे सिर्फ़ पाथ से शुरू करें) बनाएं.
<h1>Welcome To Example.com</h1> <script src="/jquery.js"></script> <link rel="stylesheet" href="/assets/style.css"/> <img src="/images/logo.png"/>; <p>A <a href="/2014/12/24">new post on cats!</a></p>
<h1>Welcome To Example.com</h1> <script src="//example.com/jquery.js"></script> <link rel="stylesheet" href="//assets.example.com/style.css"/> <img src="//img.example.com/logo.png"/>; <p>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>
<h1>Welcome To Example.com</h1> <script src="/jquery.js"></script> <link rel="stylesheet" href="/assets/style.css"/> <img src="/images/logo.png"/>; <p>A <a href="/2014/12/24">new post on cats!</a></p> <p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>
गड़बड़ियों से बचने के लिए, अपने लिंक को मैन्युअल तरीके से न अपडेट करें, बल्कि स्क्रिप्ट का इस्तेमाल करें. अगर आपकी साइट का कॉन्टेंट किसी डेटाबेस में है, तो डेटाबेस की डेवलपमेंट कॉपी पर अपनी स्क्रिप्ट की जांच करें. अगर आपकी साइट के कॉन्टेंट में सिर्फ़ सामान्य फ़ाइलें शामिल हैं, तो फ़ाइलों की डेवलपमेंट कॉपी पर अपनी स्क्रिप्ट की जांच करें. बदलावों को प्रोडक्शन में तब ही डालें, जब वे सामान्य तौर पर क्वालिटी जांच (क्यूए) से पास हो जाएं. अपनी साइट पर मिले-जुले कॉन्टेंट का पता लगाने के लिए, Bram van Damme की स्क्रिप्ट या मिलती-जुलती किसी स्क्रिप्ट का इस्तेमाल किया जा सकता है.
दूसरी साइटों से लिंक करते समय, प्रोटोकॉल में बदलाव न करें. आपके पास उन साइटों के काम करने के तरीके पर कंट्रोल नहीं होता.
बड़ी साइटों को आसानी से माइग्रेट करने के लिए, हमारा सुझाव है कि आप प्रोटोकॉल-रिलेटिव यूआरएल का इस्तेमाल करें. अगर आपको यह पक्का नहीं है कि एचटीटीपीएस को पूरी तरह से डिप्लॉय किया जा सकता है या नहीं, तो अपनी साइट के सभी सब-रिसॉर्स के लिए एचटीटीपीएस का इस्तेमाल करने पर, आपको नुकसान हो सकता है. ऐसा हो सकता है कि एचटीटीपीएस आपके लिए नया और अजीब लगे. हालांकि, एचटीटीपी साइट पहले की तरह ही काम करती रहेगी. समय के साथ, माइग्रेशन पूरा हो जाएगा और आपका ऐप्लिकेशन एचटीटीपीएस पर काम करेगा. इसके बारे में जानने के लिए, अगले दो सेक्शन देखें.
अगर आपकी साइट, तीसरे पक्ष से मिलने वाली स्क्रिप्ट, इमेज या अन्य रिसॉर्स पर निर्भर करती है, जैसे कि सीडीएन या jquery.com, तो आपके पास दो विकल्प हैं:
- इन रिसॉर्स के लिए, प्रोटोकॉल-रिलेटिव यूआरएल का इस्तेमाल करें. अगर तीसरा पक्ष एचटीटीपीएस का इस्तेमाल नहीं करता है, तो उससे कहें कि वह एचटीटीपीएस का इस्तेमाल करे. jquery.com के साथ-साथ, ज़्यादातर वेबसाइटों पर यह सुविधा पहले से ही मौजूद है.
- अपने कंट्रोल वाले ऐसे सर्वर से रिसॉर्स दिखाएं जो एचटीटीपी और एचटीटीपीएस, दोनों का इस्तेमाल करता हो. आम तौर पर, यह एक अच्छा विचार है, क्योंकि इससे आपको अपनी साइट के दिखने के तरीके, परफ़ॉर्मेंस, और सुरक्षा पर बेहतर कंट्रोल मिलता है. साथ ही, अपनी साइट को सुरक्षित रखने के लिए, तीसरे पक्ष पर भरोसा करने की ज़रूरत नहीं पड़ती.
एचटीटीपी को एचटीटीपीएस पर रीडायरेक्ट करना
सर्च इंजन को अपनी साइट को ऐक्सेस करने के लिए एचटीटीपीएस का इस्तेमाल करने के लिए कहने के लिए, <link rel="canonical" href="https://…"/> टैग का इस्तेमाल करके हर पेज के हेड में कैननिकल लिंक डालें.
स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी और सुरक्षित कुकी चालू करना
अब आपके पास एचटीटीपीएस का इस्तेमाल "लॉक इन" करने का विकल्प है:
- 301 रीडायरेक्ट की लागत से बचने के लिए, एचटीटीपी स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी (एचएसटीएस) का इस्तेमाल करें.
- कुकी पर हमेशा 'सुरक्षित' फ़्लैग सेट करें.
सबसे पहले, स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी का इस्तेमाल करके क्लाइंट को बताएं कि उन्हें हमेशा एचटीटीपीएस का इस्तेमाल करके आपके सर्वर से कनेक्ट करना चाहिए. भले ही, वे http:// रेफ़रंस का इस्तेमाल कर रहे हों. इससे एसएसएल हटाने जैसे हमलों से बचा जा सकता है. साथ ही, 301 redirect के राउंड-ट्रिप की लागत से भी बचा जा सकता है. हमने 301 redirect को एचटीटीपी को एचटीटीपीएस पर रीडायरेक्ट करें में चालू किया है.
एचएसटीएस चालू करने के लिए, Strict-Transport-Security हेडर सेट करें. OWASP के HSTS पेज पर,
अलग-अलग तरह के सर्वर सॉफ़्टवेयर के लिए, निर्देशों के लिंक मौजूद हैं.
ज़्यादातर वेब सर्वर, कस्टम हेडर जोड़ने की सुविधा देते हैं.
यह पक्का करना भी ज़रूरी है कि क्लाइंट कभी भी एचटीटीपी पर कुकी न भेजें. जैसे, पुष्टि करने या साइट की प्राथमिकताओं के लिए. उदाहरण के लिए, अगर किसी उपयोगकर्ता की पुष्टि करने वाली कुकी को सादे टेक्स्ट में दिखाया जाता है, तो उसके पूरे सेशन के लिए सुरक्षा की गारंटी खत्म हो जाती है. भले ही, आपने बाकी सभी काम सही तरीके से किए हों!
इससे बचने के लिए, अपने वेब ऐप्लिकेशन को इस तरह सेट करें कि वह सेट की गई कुकी पर हमेशा 'सुरक्षित' फ़्लैग सेट करे. OWASP के इस पेज पर, कई ऐप्लिकेशन फ़्रेमवर्क में 'सुरक्षित' फ़्लैग सेट करने का तरीका बताया गया है. हर ऐप्लिकेशन फ़्रेमवर्क में, फ़्लैग सेट करने का एक तरीका होता है.
ज़्यादातर वेब सर्वर, रीडायरेक्ट करने की आसान सुविधा देते हैं. सर्च इंजन और ब्राउज़र को यह बताने के लिए कि एचटीटीपीएस वर्शन कैननिकल है, 301 (Moved Permanently) का इस्तेमाल करें. साथ ही, अपने उपयोगकर्ताओं को एचटीटीपी से अपनी साइट के एचटीटीपीएस वर्शन पर रीडायरेक्ट करें.
Search पर मिलने वाली रैंकिंग
Google, खोज के नतीजों की क्वालिटी के बारे में बताने वाले इंडिकेटर के तौर पर एचटीटीपीएस का इस्तेमाल करता है. Google, अपनी साइट को ट्रांसफ़र, माइग्रेट या दूसरी जगह ले जाने का तरीका बताने वाली गाइड भी पब्लिश करता है. ऐसा करने पर, साइट की खोज रैंक में कोई बदलाव नहीं होता. Bing, वेबमास्टर के लिए दिशा-निर्देश भी पब्लिश करता है.
परफ़ॉर्मेंस
जब कॉन्टेंट और ऐप्लिकेशन लेयर को सही तरीके से ट्यून किया जाता है (सलाह के लिए, स्टीव साउडर की किताबें देखें), तो ऐप्लिकेशन की कुल लागत के मुकाबले, TLS की परफ़ॉर्मेंस से जुड़ी बाकी समस्याएं आम तौर पर कम होती हैं. इन खर्चों को कम किया जा सकता है और इन पर होने वाले ब्याज को कम किया जा सकता है. टीएलएस को ऑप्टिमाइज़ करने के बारे में सलाह पाने के लिए, इल्या ग्रिगोरिक की हाई परफ़ॉर्मेंस ब्राउज़र नेटवर्किंग देखें. साथ ही, इवान रिस्टिच की OpenSSL कुकबुक और बुलप्रूफ़ एसएसएल और टीएलएस भी देखें.
कुछ मामलों में, TLS से परफ़ॉर्मेंस बेहतर हो सकती है. ऐसा, एचटीटीपी/2 का इस्तेमाल करने की वजह से होता है. ज़्यादा जानकारी के लिए, Chrome Dev Summit 2014 में एचटीटीपीएस और एचटीटीपी/2 की परफ़ॉर्मेंस के बारे में क्रिस पामर का टॉक देखें.
रेफ़रर हेडर
जब उपयोगकर्ता आपकी एचटीटीपीएस साइट से दूसरी एचटीटीपी साइटों पर जाने वाले लिंक पर क्लिक करते हैं, तो उपयोगकर्ता एजेंट, रेफ़रर हेडर नहीं भेजते. अगर आपको इस समस्या का सामना करना पड़ रहा है, तो इसे हल करने के कई तरीके हैं:
- अन्य साइटों को एचटीटीपीएस पर माइग्रेट करना चाहिए. अगर रेफ़र करने वाली साइटें, इस गाइड के अपने सर्वर पर एचटीटीपीएस चालू करें सेक्शन को पूरा कर लेती हैं, तो अपनी साइट के लिंक को
http://सेhttps://पर बदला जा सकता है या प्रोटोकॉल के हिसाब से लिंक का इस्तेमाल किया जा सकता है. - रेफ़रर हेडर से जुड़ी कई समस्याओं को हल करने के लिए, नए रेफ़रर नीति स्टैंडर्ड का इस्तेमाल करें.
विज्ञापन से मिलने वाला रेवेन्यू
विज्ञापन दिखाकर अपनी साइट से कमाई करने वाले साइट ऑपरेटर, यह पक्का करना चाहते हैं कि एचटीटीपीएस पर माइग्रेट करने से, विज्ञापन इंप्रेशन में कमी न आए. हालांकि, अलग-अलग तरह के कॉन्टेंट की सुरक्षा से जुड़ी समस्याओं की वजह से, एचटीटीपी <iframe>, एचटीटीपीएस पेज पर काम नहीं करता.
जब तक विज्ञापन देने वाले लोग या कंपनियां एचटीटीपीएस पर पब्लिश नहीं करतीं, तब तक साइट ऑपरेटर, विज्ञापन से होने वाली आय में कमी के बिना एचटीटीपीएस पर माइग्रेट नहीं कर सकते. हालांकि, जब तक साइट ऑपरेटर एचटीटीपीएस पर माइग्रेट नहीं करते, तब तक विज्ञापन देने वाले लोगों या कंपनियों के पास एचटीटीपीएस पर पब्लिश करने की ज़्यादा दिलचस्पी नहीं होती.
इस समस्या को हल करने के लिए, एचटीटीपीएस पर विज्ञापन सेवाएं देने वाली कंपनियों का इस्तेमाल करें. साथ ही, उन कंपनियों से कहें जो एचटीटीपीएस पर विज्ञापन नहीं दिखाती हैं कि वे कम से कम इसे विकल्प के तौर पर उपलब्ध कराएं. जब तक विज्ञापन देने वाले ज़रूरत के मुताबिक सही तरीके से इंटरऑपरेट नहीं करते, तब तक आपको इंटरनैशनल साइट के यूआरएल को रिलेटिव बनाएं को पूरा करने से रोकना पड़ सकता है.