अपने सर्वर पर एचटीटीपीएस चालू करना

Chris Palmer
Chris Palmer

इस पेज पर, अपने सर्वर पर एचटीटीपीएस सेट अप करने के लिए दिशा-निर्देश दिए गए हैं. इनमें ये चरण शामिल हैं:

  • 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://…"/> टैग का इस्तेमाल करके हर पेज के हेड में कैननिकल लिंक डालें.

Strict ट्रांसपोर्ट सिक्योरिटी और सुरक्षित कुकी की सुविधा चालू करें

अब आपके पास एचटीटीपीएस का इस्तेमाल "लॉक इन" करने का विकल्प है:

  • 301 रीडायरेक्ट की लागत से बचने के लिए, एचटीटीपी स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी (एचएसटीएस) का इस्तेमाल करें.
  • कुकी पर हमेशा 'सुरक्षित' फ़्लैग सेट करें.

सबसे पहले, स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी का इस्तेमाल करके क्लाइंट को बताएं कि उन्हें हमेशा एचटीटीपीएस का इस्तेमाल करके आपके सर्वर से कनेक्ट करना चाहिए. भले ही, वे किसी http:// रेफ़रंस का इस्तेमाल कर रहे हों. इससे एसएसएल हटाने जैसे हमलों से बचा जा सकता है. साथ ही, 301 redirect के राउंड-ट्रिप की लागत से भी बचा जा सकता है. हमने 301 redirect को एचटीटीपी को एचटीटीपीएस पर रीडायरेक्ट करें में चालू किया है.

एचएसटीएस चालू करने के लिए, Strict-Transport-Security हेडर सेट करें. OWASP के HSTS पेज पर, अलग-अलग तरह के सर्वर सॉफ़्टवेयर के लिए, निर्देशों के लिंक मौजूद हैं.

ज़्यादातर वेब सर्वर, कस्टम हेडर जोड़ने की सुविधा देते हैं.

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

इससे बचने के लिए, अपने वेब ऐप्लिकेशन को इस तरह सेट करें कि वह सेट की गई कुकी पर हमेशा 'सुरक्षित' फ़्लैग सेट करे. OWASP के इस पेज पर, कई ऐप्लिकेशन फ़्रेमवर्क में 'सुरक्षित' फ़्लैग सेट करने का तरीका बताया गया है. हर ऐप्लिकेशन फ़्रेमवर्क में, फ़्लैग सेट करने का एक तरीका होता है.

ज़्यादातर वेब सर्वर, आसानी से रीडायरेक्ट करने की सुविधा देते हैं. सर्च इंजन और ब्राउज़र को यह बताने के लिए कि एचटीटीपीएस वर्शन कैननिकल है, 301 (Moved Permanently) का इस्तेमाल करें. साथ ही, अपने उपयोगकर्ताओं को एचटीटीपी से अपनी साइट के एचटीटीपीएस वर्शन पर रीडायरेक्ट करें.

Search पर मिलने वाली रैंकिंग

Google, खोज के नतीजों की क्वालिटी के बारे में बताने वाले इंडिकेटर के तौर पर एचटीटीपीएस का इस्तेमाल करता है. Google, अपनी साइट को ट्रांसफ़र करने, दूसरी जगह ले जाने या माइग्रेट करने का तरीका बताने वाली गाइड भी पब्लिश करता है. ऐसा करने पर, साइट की खोज रैंक में कोई बदलाव नहीं होता. Bing, वेबमास्टर के लिए दिशा-निर्देश भी पब्लिश करता है.

परफ़ॉर्मेंस

जब कॉन्टेंट और ऐप्लिकेशन लेयर को सही तरीके से ट्यून किया जाता है, तो ऐप्लिकेशन की कुल लागत के मुकाबले, TLS की परफ़ॉर्मेंस से जुड़ी बाकी समस्याएं आम तौर पर कम होती हैं. सलाह के लिए, स्टीव साउडर की किताबें देखें. इन खर्चों को कम किया जा सकता है और इन पर अमॉर्टाइज़ेशन भी किया जा सकता है. TLS को ऑप्टिमाइज़ करने के बारे में सलाह पाने के लिए, इल्या ग्रिगोरिक की हाई परफ़ॉर्मेंस ब्राउज़र नेटवर्किंग देखें. साथ ही, इवान रिस्टिच की OpenSSL कुकबुक और Bulletproof SSL And TLS भी देखें.

कुछ मामलों में, TLS से परफ़ॉर्मेंस बेहतर हो सकती है. ऐसा, एचटीटीपी/2 का इस्तेमाल करने की वजह से होता है. ज़्यादा जानकारी के लिए, Chrome Dev Summit 2014 में एचटीटीपीएस और एचटीटीपी/2 की परफ़ॉर्मेंस के बारे में क्रिस पामर का टॉक देखें.

रेफ़रर हेडर

जब उपयोगकर्ता आपकी एचटीटीपीएस साइट से दूसरी एचटीटीपी साइटों पर जाने वाले लिंक पर क्लिक करते हैं, तो उपयोगकर्ता एजेंट, रेफ़रर हेडर नहीं भेजते. अगर आपको इस समस्या का सामना करना पड़ रहा है, तो इसे हल करने के कई तरीके हैं:

  • अन्य साइटों को एचटीटीपीएस पर माइग्रेट करना चाहिए. अगर रेफ़र की गई साइटें इस गाइड के अपने सर्वर पर एचटीटीपीएस चालू करें सेक्शन में पूरी जानकारी देती हैं, तो अपनी साइट के लिंक को http:// से https:// में बदला जा सकता है या प्रोटोकॉल-रिलेटिव लिंक का इस्तेमाल किया जा सकता है.
  • रेफ़रर हेडर से जुड़ी कई समस्याओं को हल करने के लिए, नए रेफ़रर नीति स्टैंडर्ड का इस्तेमाल करें.

विज्ञापन से मिलने वाला रेवेन्यू

विज्ञापन दिखाकर अपनी साइट से कमाई करने वाले साइट ऑपरेटर, यह पक्का करना चाहते हैं कि एचटीटीपीएस पर माइग्रेट करने से, विज्ञापन इंप्रेशन में कमी न आए. हालांकि, अलग-अलग तरह के कॉन्टेंट की सुरक्षा से जुड़ी समस्याओं की वजह से, एचटीटीपी <iframe>, एचटीटीपीएस पेज पर काम नहीं करता. जब तक विज्ञापन देने वाले लोग या कंपनियां एचटीटीपीएस पर पब्लिश नहीं करतीं, तब तक साइट ऑपरेटर, विज्ञापन से होने वाली आय में कमी के बिना एचटीटीपीएस पर माइग्रेट नहीं कर सकते. हालांकि, जब तक साइट ऑपरेटर एचटीटीपीएस पर माइग्रेट नहीं करते, तब तक विज्ञापन देने वाले लोगों या कंपनियों के पास एचटीटीपीएस पर पब्लिश करने की ज़्यादा दिलचस्पी नहीं होती.

इस समस्या को हल करने के लिए, एचटीटीपीएस पर विज्ञापन सेवाएं देने वाली कंपनियों का इस्तेमाल करें. साथ ही, उन कंपनियों से कहें जो एचटीटीपीएस पर विज्ञापन नहीं दिखातीं कि वे कम से कम इसे विकल्प के तौर पर उपलब्ध कराएं. आपको IntraSite यूआरएल को मिलते-जुलते यूआरएल बनाने की प्रोसेस को तब तक टालना पड़ सकता है, जब तक कि काफ़ी विज्ञापन देने वाले लोग ठीक से इंटरऑपरेट नहीं कर लेते.