আপনার সার্ভারে HTTPS সক্ষম করুন

ক্রিস পামার
Chris Palmer

এই পৃষ্ঠাটি নিম্নলিখিত পদক্ষেপগুলি সহ আপনার সার্ভারে HTTPS সেট আপ করার জন্য নির্দেশিকা প্রদান করে:

  • একটি 2048-বিট RSA পাবলিক/প্রাইভেট কী জোড়া তৈরি করা হচ্ছে।
  • একটি সার্টিফিকেট সাইনিং রিকোয়েস্ট (CSR) তৈরি করা যা আপনার পাবলিক কী এম্বেড করে।
  • একটি চূড়ান্ত শংসাপত্র বা একটি শংসাপত্রের চেইন পেতে আপনার সার্টিফিকেট অথরিটির (CA) সাথে আপনার CSR শেয়ার করা।
  • আপনার চূড়ান্ত শংসাপত্রটি একটি নন-ওয়েব-অ্যাক্সেসযোগ্য জায়গায় ইনস্টল করা যেমন /etc/ssl (লিনাক্স এবং ইউনিক্স) বা যেখানে IIS এর প্রয়োজন হয় (উইন্ডোজ)।

কী এবং শংসাপত্র স্বাক্ষরের অনুরোধ তৈরি করুন

এই বিভাগটি ওপেনএসএল কমান্ড-লাইন প্রোগ্রাম ব্যবহার করে, যা বেশিরভাগ Linux, BSD, এবং Mac OS X সিস্টেমের সাথে আসে, ব্যক্তিগত এবং সর্বজনীন কী এবং একটি CSR তৈরি করতে।

একটি পাবলিক/প্রাইভেট কী জোড়া তৈরি করুন

শুরু করতে, একটি 2,048-বিট RSA কী জোড়া তৈরি করুন৷ একটি সংক্ষিপ্ত চাবি ব্রুট-ফোর্স অনুমান আক্রমণ দ্বারা ভাঙ্গা যেতে পারে, এবং দীর্ঘ কীগুলি অপ্রয়োজনীয় সংস্থান ব্যবহার করে।

একটি RSA কী জোড়া তৈরি করতে নিম্নলিখিত কমান্ডটি ব্যবহার করুন:

openssl genrsa -out www.example.com.key 2048

এটি নিম্নলিখিত আউটপুট দেয়:

Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)

একটি শংসাপত্র স্বাক্ষর অনুরোধ তৈরি করুন

এই ধাপে, আপনি একটি সার্টিফিকেট সাইনিং রিকোয়েস্ট বা CSR-এ আপনার সর্বজনীন কী এবং আপনার প্রতিষ্ঠান এবং আপনার ওয়েবসাইট সম্পর্কে তথ্য এম্বেড করুন। 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 []:

CSR এর বৈধতা নিশ্চিত করতে, এই কমান্ডটি চালান:

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:
         ...

একটি শংসাপত্র কর্তৃপক্ষের কাছে আপনার CSR জমা দিন

বিভিন্ন শংসাপত্র কর্তৃপক্ষ (CAs) আপনাকে তাদের কাছে বিভিন্ন উপায়ে আপনার CSR জমা দিতে চায়। এর মধ্যে তাদের ওয়েবসাইটে একটি ফর্ম ব্যবহার করা বা ইমেলের মাধ্যমে CSR পাঠানো অন্তর্ভুক্ত থাকতে পারে। কিছু CA, বা তাদের পুনঃবিক্রেতা, এমনকি কিছু বা সমস্ত প্রক্রিয়া স্বয়ংক্রিয় করতে পারে, কিছু ক্ষেত্রে, কী জোড়া এবং CSR জেনারেশন সহ।

আপনার CA-তে CSR পাঠান এবং আপনার চূড়ান্ত শংসাপত্র বা শংসাপত্রের চেইন পেতে তাদের নির্দেশাবলী অনুসরণ করুন।

বিভিন্ন CA আপনার পাবলিক কী-এর জন্য ভাউচিং পরিষেবার জন্য বিভিন্ন পরিমাণ অর্থ চার্জ করে।

এছাড়াও একাধিক DNS নামের সাথে আপনার কী ম্যাপ করার বিকল্প রয়েছে, যার মধ্যে রয়েছে বেশ কয়েকটি স্বতন্ত্র নাম (যেমন সমস্ত example.com, www.example.com, example.net, এবং www.example.net) বা "ওয়াইল্ডকার্ড" নাম যেমন যেমন *.example.com

/etc/ssl (লিনাক্স এবং ইউনিক্স) বা IIS (Windows) যেখানেই প্রয়োজন এমন একটি নন-ওয়েব-অ্যাক্সেসযোগ্য জায়গায় আপনার সমস্ত ফ্রন্ট-এন্ড সার্ভারে শংসাপত্রগুলি অনুলিপি করুন৷

আপনার সার্ভারে HTTPS সক্ষম করুন

আপনার সার্ভারে HTTPS সক্ষম করা আপনার ওয়েব পৃষ্ঠাগুলির নিরাপত্তা প্রদানের একটি গুরুত্বপূর্ণ পদক্ষেপ।

  • HTTPS সমর্থনের জন্য আপনার সার্ভার সেট আপ করতে Mozilla এর সার্ভার কনফিগারেশন টুল ব্যবহার করুন।
  • Qualys এর SSL সার্ভার টেস্টের মাধ্যমে নিয়মিতভাবে আপনার সাইট পরীক্ষা করুন এবং নিশ্চিত করুন যে আপনি অন্তত একটি A বা A+ পেয়েছেন।

এই মুহুর্তে, আপনাকে একটি গুরুত্বপূর্ণ অপারেশন সিদ্ধান্ত নিতে হবে। নিচের কোনো একটি পছন্দ কর:

  • আপনার ওয়েব সার্ভার থেকে সামগ্রী পরিবেশন করে প্রতিটি হোস্টনামের জন্য একটি স্বতন্ত্র IP ঠিকানা উৎসর্গ করুন৷
  • নাম-ভিত্তিক ভার্চুয়াল হোস্টিং ব্যবহার করুন।

আপনি যদি প্রতিটি হোস্টনামের জন্য স্বতন্ত্র IP ঠিকানা ব্যবহার করে থাকেন তবে আপনি সমস্ত ক্লায়েন্টের জন্য HTTP এবং HTTPS উভয় সমর্থন করতে পারেন। যাইহোক, বেশিরভাগ সাইট অপারেটর IP ঠিকানাগুলি সংরক্ষণ করতে নাম-ভিত্তিক ভার্চুয়াল হোস্টিং ব্যবহার করে এবং কারণ এটি সাধারণভাবে আরও সুবিধাজনক।

আপনার সার্ভারে যদি ইতিমধ্যেই HTTPS পরিষেবা উপলব্ধ না থাকে, তাহলে এখনই এটি সক্ষম করুন (HTTP-এ HTTPS-এ পুনঃনির্দেশ না করে। আরও তথ্যের জন্য HTTP-এ HTTPS-এ পুনঃনির্দেশ দেখুন)। আপনার কেনা এবং ইনস্টল করা শংসাপত্রগুলি ব্যবহার করতে আপনার ওয়েব সার্ভার কনফিগার করুন৷ আপনি Mozilla এর কনফিগারেশন জেনারেটর দরকারী খুঁজে পেতে পারেন.

আপনার যদি অনেক হোস্টনাম বা সাবডোমেন থাকে, তবে তাদের প্রত্যেকের সঠিক শংসাপত্র ব্যবহার করতে হবে।

এখন, এবং নিয়মিতভাবে আপনার সাইটের জীবদ্দশায়, Qualys-এর SSL সার্ভার টেস্টের সাথে আপনার HTTPS কনফিগারেশন পরীক্ষা করুন। আপনার সাইট একটি A বা A+ স্কোর করা উচিত. যেকোন কিছুকে একটি বাগ হিসাবে বিবেচনা করুন যা নিম্ন গ্রেডের কারণ হয় এবং পরিশ্রমী থাকুন, কারণ অ্যালগরিদম এবং প্রোটোকলের বিরুদ্ধে নতুন আক্রমণগুলি সর্বদা তৈরি করা হচ্ছে৷

ইন্ট্রাসাইট ইউআরএল আপেক্ষিক করুন

এখন আপনি HTTP এবং HTTPS উভয় ক্ষেত্রেই আপনার সাইট পরিবেশন করছেন, প্রোটোকল নির্বিশেষে জিনিসগুলি যতটা সম্ভব মসৃণভাবে কাজ করতে হবে। একটি গুরুত্বপূর্ণ বিষয় হল আন্তঃসাইট লিঙ্কগুলির জন্য আপেক্ষিক URL ব্যবহার করা।

নিশ্চিত করুন যে ইন্ট্রাসাইট ইউআরএল এবং বাহ্যিক ইউআরএল একটি নির্দিষ্ট প্রোটোকলের উপর নির্ভর করে না। আপেক্ষিক পাথ ব্যবহার করুন বা //example.com/something.js এর মতো প্রোটোকল ত্যাগ করুন।

HTTPS ব্যবহার করে HTTP রিসোর্স রয়েছে এমন একটি পৃষ্ঠা পরিবেশন করলে সমস্যা হতে পারে । যখন একটি ব্রাউজার অনিরাপদ সংস্থান ব্যবহার করে একটি অন্যথায় সুরক্ষিত পৃষ্ঠার মুখোমুখি হয়, তখন এটি ব্যবহারকারীদের সতর্ক করে যে পৃষ্ঠাটি সম্পূর্ণ সুরক্ষিত নয় এবং কিছু ব্রাউজার HTTP সংস্থানগুলি লোড করতে বা কার্যকর করতে অস্বীকার করে, যা পৃষ্ঠাটি ভেঙে দেয়। যাইহোক, আপনি নিরাপদে HTTP পৃষ্ঠায় HTTPS সংস্থান অন্তর্ভুক্ত করতে পারেন। এই সমস্যাগুলির সমাধানের বিষয়ে আরও নির্দেশিকা জন্য, মিশ্র বিষয়বস্তু সংশোধন করা দেখুন।

আপনার সাইটের অন্যান্য পৃষ্ঠাগুলিতে HTTP-ভিত্তিক লিঙ্কগুলি অনুসরণ করা ব্যবহারকারীর অভিজ্ঞতাকে HTTPS থেকে HTTP-তে ডাউনগ্রেড করতে পারে। এটি ঠিক করার জন্য, আপনার ইন্ট্রাসাইট ইউআরএলগুলিকে যতটা সম্ভব আপেক্ষিক করুন, সেগুলিকে হয় প্রোটোকল-রিলেটিভ (প্রোটোকলের অভাব, //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>
যেখানে সম্ভব অন্য সাইটের লিঙ্কের জন্য HTTPS URL ব্যবহার করুন।

ভুল এড়াতে হাত দিয়ে নয়, স্ক্রিপ্ট দিয়ে আপনার লিঙ্ক আপডেট করুন। আপনার সাইটের বিষয়বস্তু একটি ডাটাবেসে থাকলে, ডাটাবেসের একটি বিকাশ কপিতে আপনার স্ক্রিপ্ট পরীক্ষা করুন। আপনার সাইটের বিষয়বস্তুতে শুধুমাত্র সাধারণ ফাইল থাকলে, ফাইলগুলির একটি ডেভেলপমেন্ট কপিতে আপনার স্ক্রিপ্ট পরীক্ষা করুন। পরিবর্তনগুলি স্বাভাবিক হিসাবে QA পাস করার পরেই উত্পাদনে পরিবর্তনগুলিকে পুশ করুন৷ আপনি আপনার সাইটে মিশ্র বিষয়বস্তু সনাক্ত করতে Bram van Damme-এর স্ক্রিপ্ট বা অনুরূপ কিছু ব্যবহার করতে পারেন।

অন্যান্য সাইটের সাথে লিঙ্ক করার সময় (তাদের থেকে সংস্থানগুলি অন্তর্ভুক্ত করার বিপরীতে), প্রোটোকল পরিবর্তন করবেন না। সেই সাইটগুলি কীভাবে কাজ করে তার উপর আপনার নিয়ন্ত্রণ নেই৷

বড় সাইটগুলির জন্য মাইগ্রেশনকে সহজ করতে, আমরা প্রোটোকল-সম্পর্কিত URLগুলির সুপারিশ করি৷ আপনি এখনও সম্পূর্ণরূপে HTTPS স্থাপন করতে পারবেন কিনা তা নিশ্চিত না হলে, সমস্ত উপ-সম্পদগুলির জন্য আপনার সাইটটিকে HTTPS ব্যবহার করতে বাধ্য করলে তা ব্যাকফায়ার হতে পারে। এমন একটি সময় থাকতে পারে যেখানে HTTPS আপনার জন্য নতুন এবং অদ্ভুত, এবং HTTP সাইটটি অবশ্যই আগের মতোই কাজ করবে। সময়ের সাথে সাথে, আপনি স্থানান্তর সম্পূর্ণ করবেন এবং HTTPS এ লক করবেন (পরবর্তী দুটি বিভাগ দেখুন)।

যদি আপনার সাইট স্ক্রিপ্ট, ছবি বা তৃতীয় পক্ষ থেকে পরিবেশিত অন্যান্য সংস্থানগুলির উপর নির্ভর করে, যেমন একটি CDN বা jquery.com, আপনার কাছে দুটি বিকল্প রয়েছে:

  • এই সম্পদগুলির জন্য প্রোটোকল-সম্পর্কিত URL ব্যবহার করুন। যদি তৃতীয় পক্ষ HTTPS পরিবেশন না করে, তাহলে তাদের জিজ্ঞাসা করুন। jquery.com সহ বেশিরভাগই ইতিমধ্যে করে।
  • আপনার নিয়ন্ত্রণ করা একটি সার্ভার থেকে সংস্থানগুলি পরিবেশন করুন, যা HTTP এবং HTTPS উভয়ই অফার করে৷ যাইহোক এটি প্রায়শই একটি ভাল ধারণা, কারণ তারপরে আপনার সাইটের চেহারা, কার্যকারিতা এবং সুরক্ষার উপর আপনার আরও ভাল নিয়ন্ত্রণ থাকবে এবং আপনার সাইটকে সুরক্ষিত রাখতে কোনও তৃতীয় পক্ষকে বিশ্বাস করতে হবে না।

HTTPS-এ HTTP রিডাইরেক্ট করুন

সার্চ ইঞ্জিনকে আপনার সাইট অ্যাক্সেস করতে HTTPS ব্যবহার করতে বলতে, <link rel="canonical" href="https://…"/> ট্যাগ ব্যবহার করে প্রতিটি পৃষ্ঠার মাথায় একটি ক্যানোনিকাল লিঙ্ক রাখুন।

কঠোর পরিবহন নিরাপত্তা এবং নিরাপদ কুকি চালু করুন

এই মুহুর্তে, আপনি HTTPS ব্যবহার "লক ইন" করতে প্রস্তুত:

  • 301 রিডাইরেক্টের খরচ এড়াতে HTTP স্ট্রিক্ট ট্রান্সপোর্ট সিকিউরিটি (HSTS) ব্যবহার করুন।
  • সর্বদা কুকিতে সুরক্ষিত পতাকা সেট করুন।

প্রথমে, ক্লায়েন্টদের বলতে কঠোর পরিবহন নিরাপত্তা ব্যবহার করুন যে তারা সর্বদা HTTPS ব্যবহার করে আপনার সার্ভারের সাথে সংযুক্ত হওয়া উচিত, এমনকি একটি http:// রেফারেন্স অনুসরণ করার সময়ও। এটি SSL স্ট্রিপিং- এর মতো আক্রমণকে পরাস্ত করে এবং 301 redirect রাউন্ড-ট্রিপ খরচ এড়ায় যা আমরা HTTP-তে HTTPS-এ পুনঃনির্দেশে সক্ষম করেছি।

HSTS চালু করতে, Strict-Transport-Security শিরোনাম সেট করুন। OWASP-এর HSTS পৃষ্ঠায় বিভিন্ন ধরণের সার্ভার সফ্টওয়্যারের নির্দেশাবলীর লিঙ্ক রয়েছে

বেশিরভাগ ওয়েব সার্ভার কাস্টম শিরোনাম যোগ করার জন্য একই ধরনের ক্ষমতা প্রদান করে।

এটি নিশ্চিত করাও গুরুত্বপূর্ণ যে ক্লায়েন্টরা কখনই HTTP এর মাধ্যমে কুকিজ (যেমন প্রমাণীকরণ বা সাইটের পছন্দের জন্য) পাঠাবে না। উদাহরণস্বরূপ, যদি একজন ব্যবহারকারীর প্রমাণীকরণ কুকি প্লেইন টেক্সটে প্রকাশ করা হয়, তাহলে তাদের পুরো সেশনের জন্য আপনার নিরাপত্তা গ্যারান্টি নষ্ট হয়ে যাবে, এমনকি আপনি অন্য সবকিছু ঠিকঠাক করলেও!

এটি এড়ানোর জন্য, আপনার ওয়েব অ্যাপটি সর্বদা এটি সেট করা কুকিগুলিতে সুরক্ষিত পতাকা সেট করতে পরিবর্তন করুন৷ এই OWASP পৃষ্ঠাটি ব্যাখ্যা করে কিভাবে বিভিন্ন অ্যাপ ফ্রেমওয়ার্কে নিরাপদ পতাকা সেট করতে হয় । প্রতিটি অ্যাপল ফ্রেমওয়ার্ক পতাকা সেট করার একটি উপায় আছে।

বেশিরভাগ ওয়েব সার্ভার একটি সাধারণ পুনঃনির্দেশ বৈশিষ্ট্য অফার করে। সার্চ ইঞ্জিন এবং ব্রাউজারগুলিকে নির্দেশ করতে 301 (Moved Permanently) ব্যবহার করুন যে HTTPS সংস্করণটি আদর্শ, এবং আপনার ব্যবহারকারীদের HTTP থেকে আপনার সাইটের HTTPS সংস্করণে পুনঃনির্দেশ করুন৷

অনুসন্ধান র‌্যাঙ্কিং

Google একটি ইতিবাচক অনুসন্ধান গুণমান নির্দেশক হিসাবে HTTPS ব্যবহার করে৷ Google কীভাবে আপনার সাইটের সার্চ র‍্যাঙ্ক বজায় রেখে স্থানান্তর, স্থানান্তর বা স্থানান্তর করতে হয় তার একটি নির্দেশিকাও প্রকাশ করে৷ Bing ওয়েবমাস্টারদের জন্য নির্দেশিকাও প্রকাশ করে।

কর্মক্ষমতা

যখন বিষয়বস্তু এবং অ্যাপ্লিকেশন স্তরগুলি ভালভাবে সুরক্ষিত হয় (পরামর্শের জন্য স্টিভ সউডারের বই পড়ুন), অবশিষ্ট TLS কর্মক্ষমতা উদ্বেগ সাধারণত অ্যাপ্লিকেশনের সামগ্রিক খরচের তুলনায় ছোট হয়। আপনি সেই খরচগুলি কমাতে এবং বর্জন করতে পারেন। টিএলএস অপ্টিমাইজেশানের পরামর্শের জন্য, ইলিয়া গ্রিগোরিকের হাই পারফরম্যান্স ব্রাউজার নেটওয়ার্কিং , সেইসাথে ইভান রিস্টিকের ওপেনএসএসএল কুকবুক এবং বুলেটপ্রুফ এসএসএল এবং টিএলএস দেখুন।

কিছু ক্ষেত্রে, TLS কর্মক্ষমতা উন্নত করতে পারে, বেশিরভাগ HTTP/2 সম্ভব করার ফলে। আরও তথ্যের জন্য, ক্রোম ডেভ সামিট 2014-এ HTTPS এবং HTTP/2 পারফরম্যান্সের উপর ক্রিস পামারের আলোচনা পড়ুন।

রেফারার হেডার

যখন ব্যবহারকারীরা আপনার HTTPS সাইট থেকে অন্য HTTP সাইটের লিঙ্কগুলি অনুসরণ করে, তখন ব্যবহারকারী এজেন্টরা রেফারার হেডার পাঠায় না। যদি এটি একটি সমস্যা হয়, এটি সমাধান করার বিভিন্ন উপায় আছে:

  • অন্যান্য সাইটগুলিকে HTTPS-এ স্থানান্তর করা উচিত৷ যদি রেফারি সাইটগুলি এই গাইডের আপনার সার্ভারগুলিতে HTTPS সক্ষম করে, তাহলে আপনি আপনার সাইটের লিঙ্কগুলিকে http:// থেকে https:// তে পরিবর্তন করতে পারেন বা প্রোটোকল-রিলেটিভ লিঙ্কগুলি ব্যবহার করতে পারেন৷
  • রেফারার হেডারের সাথে বিভিন্ন সমস্যার সমাধান করতে, নতুন রেফারার নীতি মান ব্যবহার করুন।

বিজ্ঞাপন আয়

যে সাইট অপারেটররা বিজ্ঞাপন দেখিয়ে তাদের সাইট নগদীকরণ করে তারা নিশ্চিত করতে চায় যে HTTPS-এ স্থানান্তরিত করা বিজ্ঞাপনের ইম্প্রেশন কমবে না। যাইহোক, মিশ্র বিষয়বস্তুর নিরাপত্তা সংক্রান্ত উদ্বেগের কারণে, একটি HTTP <iframe> একটি HTTPS পৃষ্ঠায় কাজ করে না। যতক্ষণ না বিজ্ঞাপনদাতারা HTTPS-এর মাধ্যমে প্রকাশ করেন, সাইট অপারেটররা বিজ্ঞাপনের আয় না হারিয়ে HTTPS-এ স্থানান্তর করতে পারে না; কিন্তু যতক্ষণ না সাইট অপারেটররা HTTPS-এ স্থানান্তরিত হয়, বিজ্ঞাপনদাতাদের HTTPS প্রকাশ করার জন্য সামান্য অনুপ্রেরণা থাকে।

আপনি HTTPS-এর মাধ্যমে বিজ্ঞাপন পরিষেবাগুলি অফার করে এমন বিজ্ঞাপনদাতাদের ব্যবহার করে এবং যে বিজ্ঞাপনদাতারা একেবারেই HTTPS পরিবেশন করেন না তাদের অন্তত এটিকে একটি বিকল্প তৈরি করতে বলে এই অচলাবস্থা ভাঙার প্রক্রিয়া শুরু করতে পারেন৷ যতক্ষণ না পর্যাপ্ত বিজ্ঞাপনদাতারা সঠিকভাবে ইন্টারঅপারেটিং করে ততক্ষণ পর্যন্ত আপেক্ষিকভাবে মেক ইন্ট্রাসাইট ইউআরএল সম্পূর্ণ করা পিছিয়ে দিতে হতে পারে।