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

क्रिस पामर
क्रिस पामर
मैट गौंट

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

  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 से पहले के वर्शन पर आईई में समस्या यह है कि वे सर्वर नेम इंंडिकेशन (SNI) को नहीं समझते. एचटीटीपीएस नाम पर आधारित वर्चुअल होस्टिंग के लिए यह बेहद ज़रूरी है.

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

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

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

अब और अपनी साइट के जीवनकाल के दौरान, Qualys के आसान एसएसएल सर्वर टेस्ट की मदद से अपने एचटीटीपीएस कॉन्फ़िगरेशन की जांच करें. आपकी साइट को 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 में पास हो जाते हैं. अपनी साइट में मिले-जुले कॉन्टेंट का पता लगाने के लिए, Bram van Dame की स्क्रिप्ट या इसी तरह की किसी चीज़ का इस्तेमाल किया जा सकता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

खोज रैंकिंग

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

परफ़ॉर्मेंस

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

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

रेफ़रर हेडर

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

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

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

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

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

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