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

क्रिस पामर
क्रिस पामर
मैट गांट
Twitter होम पेज

इस लेख में बताए गए तरीके

  1. 2048-बिट आरएसए की सार्वजनिक/निजी कुंजी का जोड़ा बनाएं.
  2. एक सर्टिफ़िकेट हस्ताक्षर अनुरोध (सीएसआर) जनरेट करें, जो आपकी सार्वजनिक कुंजी को एम्बेड करता हो.
  3. फ़ाइनल सर्टिफ़िकेट या सर्टिफ़िकेट चेन पाने के लिए, अपने सीएसआर को अपनी सर्टिफ़िकेट देने वाली संस्था (सीए) के साथ शेयर करें.
  4. अपने फ़ाइनल सर्टिफ़िकेट को ऐसी जगह इंस्टॉल करें जहां वेब ऐक्सेस नहीं किया जा सकता. जैसे, /etc/ssl (Linux और Unix) या फिर जहां भी IIS को इसकी ज़रूरत हो (Windows).

कुंजियां और सर्टिफ़िकेट पर हस्ताक्षर के अनुरोध जनरेट किए जा रहे हैं

इस सेक्शन में Openएसएसएल कमांड-लाइन प्रोग्राम का इस्तेमाल किया जाता है, जो ज़्यादातर Linux, BSD, और Mac OS X सिस्टम के साथ आता है. इससे निजी/सार्वजनिक पासकोड और सीएसआर जनरेट किए जा सकते हैं.

सार्वजनिक/निजी कुंजी का जोड़ा जनरेट करें

चलिए, 2,048-बिट आरएसए कुंजी का जोड़ा जनरेट करके शुरुआत करते हैं. 1,024 बिट जैसी छोटी कुंजी में ब्रूट-फ़ोर्स अनुमान लगाने वाले हमलों से बचने की क्षमता कम होती है. 4,096 बिट जैसी बड़ी कुंजी ज़्यादा काम करती है. समय के साथ, जैसे-जैसे कंप्यूटर प्रोसेसिंग कम होती जाती है, कुंजी का साइज़ बढ़ता जाता है. इस समय 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:
         ...

अपना सीएसआर किसी सर्टिफ़िकेट देने वाली संस्था को सबमिट करना

अलग-अलग सर्टिफ़िकेट अथॉरिटी (सीए) को अपने सीएसआर भेजने के लिए, अलग-अलग तरीकों की ज़रूरत होती है. इन तरीकों में अपनी वेबसाइट पर फ़ॉर्म का इस्तेमाल करना, ईमेल से सीएसआर भेजना या कुछ और करना शामिल है. कुछ CA (या उनके रीसेलर) कुछ या पूरी प्रोसेस को ऑटोमेट भी कर सकते हैं. इनमें कुछ मामलों में, कुंजी की जोड़ी और सीएसआर जनरेट करना भी शामिल है.

अपने सीए को सीएसआर भेजें और अपना फ़ाइनल सर्टिफ़िकेट या सर्टिफ़िकेट चेन पाने के लिए उनके निर्देशों का पालन करें.

अलग-अलग सीए, आपकी सार्वजनिक कुंजी की गारंटी के लिए अलग-अलग शुल्क लेते हैं.

अपनी कुंजी को एक से ज़्यादा डीएनएस नामों से मैप करने के विकल्प भी हैं. इसमें कई अलग-अलग नाम (जैसे कि सभी example.com, www.example.com, example.net, और www.example.net) या "वाइल्डकार्ड" नाम जैसे *.example.com शामिल हैं.

उदाहरण के लिए, एक सीए फ़िलहाल इन कीमतों की पेशकश करता है:

  • मानक: 16 डॉलर/साल, example.com और www.example.com के लिए मान्य है.
  • वाइल्डकार्ड: 150 डॉलर/साल, example.com और *.example.com के लिए मान्य.

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

सर्टिफ़िकेट को अपने सभी फ़्रंट-एंड सर्वर पर ऐसी जगह कॉपी करें जिन्हें वेब ऐक्सेस नहीं किया जा सकता, जैसे कि /etc/ssl (Linux और Unix) या जहां भी IIS (Windows) को इनकी ज़रूरत होती है.

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

अपने वेब पेजों को सुरक्षित रखने के लिए, सर्वर पर एचटीटीपीएस को चालू करना ज़रूरी होता है.

  • Mozilla के सर्वर कॉन्फ़िगरेशन टूल का इस्तेमाल करके, अपने सर्वर को एचटीटीपीएस के लिए सेट अप करें.
  • Qualys के आसान एसएसएल सर्वर टेस्ट की मदद से, नियमित तौर पर अपनी साइट की जांच करें और पक्का करें कि आपको कम से कम A या A+ मिले.

इस स्थिति में, आपको कार्रवाई से जुड़ा एक ज़रूरी फ़ैसला लेना होगा. इनमें से कोई एक चुनें:

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

अगर आपने हर होस्टनेम के लिए अलग-अलग आईपी पतों का इस्तेमाल किया है, तो सभी क्लाइंट के लिए एचटीटीपी और एचटीटीपीएस, दोनों पर आसानी से काम किया जा सकता है.

हालांकि, ज़्यादातर साइट ऑपरेटर आईपी पतों को सुरक्षित रखने के लिए, नाम पर आधारित वर्चुअल होस्टिंग का इस्तेमाल करते हैं. ऐसा इसलिए, क्योंकि आम तौर पर यह ज़्यादा सुविधाजनक होता है. Windows XP और Android 2.3 से पहले के वर्शन पर IE में समस्या यह है कि वे सर्वर नेम इंंडिकेशन (SNI) को नहीं समझते हैं, जो एचटीटीपीएस के नाम पर आधारित वर्चुअल होस्टिंग के लिए बहुत ज़रूरी है.

किसी दिन—उम्मीद है कि जल्द ही—एसएनआई का इस्तेमाल न करने वाले क्लाइंट को आधुनिक सॉफ़्टवेयर से बदल दिया जाएगा. अपने अनुरोध लॉग में उपयोगकर्ता एजेंट स्ट्रिंग पर नज़र रखें, ताकि यह पता चल सके कि आपके उपयोगकर्ताओं की बड़ी संख्या, मॉडर्न सॉफ़्टवेयर पर माइग्रेट हो गई है या नहीं. (यह तय किया जा सकता है कि पेमेंट थ्रेशोल्ड क्या होगा; शायद 5% से कम या फिर 1% से कम.)

अगर आपके सर्वर पर एचटीटीपीएस सेवा पहले से उपलब्ध नहीं है, तो इसे अभी चालू करें (एचटीटीपी को एचटीटीपीएस पर रीडायरेक्ट किए बिना; नीचे देखें). अपने वेब सर्वर को कॉन्फ़िगर करें, ताकि आप खरीदे और इंस्टॉल किए गए सर्टिफ़िकेट का इस्तेमाल कर सकें. आपको Mozilla का आसान कॉन्फ़िगरेशन जनरेटर काम का लग सकता है.

अगर आपके पास कई होस्टनेम या सबडोमेन हैं, तो सभी को सही सर्टिफ़िकेट का इस्तेमाल करना होगा.

अब और अपनी साइट के लाइफ़टाइम में, Qualys के आसान SSL सर्वर टेस्ट की मदद से अपने एचटीटीपीएस कॉन्फ़िगरेशन की जांच करें. आपकी साइट को A या A+ स्कोर करना चाहिए; हर उस चीज़ को बग मानें जिसके वजह से ग्रेड कम होता है. (आज का A कल का B है, क्योंकि एल्गोरिदम और प्रोटोकॉल के ख़िलाफ़ होने वाले हमले बेहतर होते जा रहे हैं!)

इंट्रासाइट यूआरएल को रिलेटिव बनाएं

अब जब आपकी साइट को एचटीटीपी और एचटीटीपीएस, दोनों पर दिखाया जा रहा है, तो प्रोटोकॉल का ध्यान रखते हुए चीज़ों को जितना हो सके, आसानी से काम करना होगा. एक अहम फ़ैक्टर है, इंट्रासाइट लिंक के लिए मिलते-जुलते यूआरएल का इस्तेमाल करना.

पक्का करें कि इंट्रासाइट यूआरएल और बाहरी यूआरएल, प्रोटोकॉल के लिए सहमत न हों. इसका मतलब है कि आपको रिलेटिव पाथ का इस्तेमाल करना चाहिए या //example.com/something.js जैसे प्रोटोकॉल का इस्तेमाल न करें.

एचटीटीपीएस के ज़रिए कोई ऐसा पेज दिखाने पर समस्या आती है जिसमें एचटीटीपी रिसॉर्स शामिल होते हैं, जिन्हें मिक्स कॉन्टेंट कहा जाता है. ब्राउज़र, उपयोगकर्ताओं को चेतावनी देते हैं कि एचटीटीपीएस की पूरी क्षमता खत्म हो गई है. अगर मिला-जुला कॉन्टेंट (स्क्रिप्ट, प्लग-इन, सीएसएस, iframe) चालू है, तो ब्राउज़र अक्सर उस कॉन्टेंट को लोड या एक्ज़ीक्यूट नहीं करेंगे और न ही कॉन्टेंट को लोड करेगा, जिससे पेज में गड़बड़ी होती है. याद रखें कि किसी एचटीटीपी पेज में एचटीटीपीएस रिसॉर्स शामिल करना ठीक है.

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

ये समस्याएं तब होती हैं, जब आपके पेजों में पूरी तरह क्वालिफ़ाइड, इंट्रासाइट यूआरएल शामिल होते हैं, जो http:// स्कीम का इस्तेमाल करते हैं.

यह न करें
<h1>Welcome To Example.com</h1>
<script src="http://example.com/jquery.js"></script>
<link rel="stylesheet" href="http://assets.example.com/style.css"/>
<img src="http://img.example.com/logo.png"/>;
<p>A <a href="http://example.com/2014/12/24/">new post on cats!</a></p>
पूरी तरह क्वालिफ़ाइड इंट्रासाइट यूआरएल का इस्तेमाल करने से बचें.

दूसरे शब्दों में, इंट्रासाइट यूआरएल को जितना हो सके उतना संबंधित बनाएं: प्रोटोकॉल-रिलेटिव (इसमें प्रोटोकॉल न होना, //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>
जहां मुमकिन हो, इंटरसाइट यूआरएल के लिए एचटीटीपीएस यूआरएल इस्तेमाल करें.

इसे स्क्रिप्ट की मदद से करें, हाथ से नहीं. अगर आपकी साइट का कॉन्टेंट किसी डेटाबेस में है, तो अपने डेटाबेस की डेवलपमेंट कॉपी पर अपनी स्क्रिप्ट की जांच करें. अगर आपकी साइट के कॉन्टेंट में सामान्य फ़ाइलें हैं, तो फ़ाइलों की डेवलपमेंट कॉपी पर अपनी स्क्रिप्ट की जांच करें. बदलावों को प्रोडक्शन में तब ही पुश करें, जब बदलावों को सामान्य रूप से QA पास कर लिया जाए. अपनी साइट में मिले-जुले कॉन्टेंट का पता लगाने के लिए, आप ब्रैम वैन डैम की स्क्रिप्ट या इससे मिलती-जुलती चीज़ों का इस्तेमाल कर सकते हैं.

अन्य साइटों से लिंक करते समय (उन साइटों से संसाधन शामिल करने के बजाय), प्रोटोकॉल को न बदलें, क्योंकि आपके पास उन साइटों के काम करने के तरीक़ों पर कंट्रोल नहीं होता.

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

अगर आपकी साइट किसी तीसरे पक्ष, जैसे कि सीडीएन या jquery.com से मिली स्क्रिप्ट, इमेज या दूसरे संसाधनों पर निर्भर है, तो आपके पास दो विकल्प हैं:

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

एचटीटीपी को एचटीटीपीएस पर रीडायरेक्ट करें

सर्च इंजन को यह बताने के लिए कि साइट पर जाने का सबसे अच्छा तरीका एचटीटीपीएस है, आपको अपने पेज पर सबसे ऊपर कैननिकल लिंक डालना होगा.

अपने पेजों में <link rel="canonical" href="https://…"/> टैग सेट करें. इससे सर्च इंजन को आपकी साइट पर आने का सबसे अच्छा तरीका तय करने में मदद मिलती है.

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

इस स्थिति में, आप एचटीटीपीएस का इस्तेमाल करने के लिए "लॉक इन" कर सकते हैं.

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

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

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

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

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

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

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

खोज के नतीजों में रैंकिंग

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

परफ़ॉर्मेंस

जब कॉन्टेंट और ऐप्लिकेशन लेयर को अच्छी तरह से ट्यून किया जाता है (बेहतर सलाह के लिए Steve Souders की किताबें देखें), तो TLS की परफ़ॉर्मेंस से जुड़ी बाकी समस्याएं आम तौर पर, ऐप्लिकेशन की कुल लागत के मुकाबले छोटी होती हैं. इसके अलावा, आपके पास उन कीमतों को कम करने और उसे घटाने या बढ़ाने का विकल्प भी है. (TLS ऑप्टिमाइज़ेशन के बारे में अच्छी सलाह और आम तौर पर, इलिया ग्रिगोरिक की हाई परफ़ॉर्मेंस ब्राउज़र नेटवर्किंग देखें.) इवान रिस्टिक की ओपनएसएसएल कुकबुक और बुलेटप्रूफ़ एसएसएल और TLS भी देखें.

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

रेफ़रर हेडर

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

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

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

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

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

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