হোস্টনেম, নির্ভরশীলতা, এবং মালিকানা ইনভেন্টরি করুন
ভিজিটর বা ইন্টিগ্রেশন যে প্রতিটি হোস্টনেম ব্যবহার করে সেগুলো তালিকাভুক্ত করুন: apex, www, সাবডোমেইন, API, অ্যাসেট হোস্ট, পোর্টাল এবং রিজিওনাল নাম। প্রতিটির জন্য রেকর্ড করুন কোথায় TLS টারমিনেট হয়, কে এটি পরিবর্তন করতে পারে, সার্টিফিকেটের কভারেজ ও মেয়াদ, নবায়ন পদ্ধতি, এবং URL উৎপাদনকারী নির্ভরশীলতাগুলো। একটি সার্টিফিকেটকে অবশ্যই অনুরোধকৃত হোস্টনেমটি তার Subject Alternative Name তালিকায় রাখতে হবে। CMS, CDN, ট্যাগ ম্যানেজার, অবজেক্ট স্টোরেজ, পেমেন্ট প্রদানকারী, ইমেইল টেমপ্লেট এবং তৃতীয়-পক্ষের এমবেডগুলো অন্তর্ভুক্ত করুন; এগুলো প্রথম HTTPS রিলিজের পরে সাধারণত HTTP URL প্রবর্তন করে।
ক্যানোনিকাল www অথবা apex হোস্টনেম নির্বাচন করুন এবং বিকল্প হোস্টনেমটিকে HTTPS-এর মাধ্যমে সরাসরি নির্বাচিত ক্যানোনিকাল হোস্টনেমে রি-ডাইরেক্ট করুন।
সার্টিফিকেট এবং বর্তমান TLS সংস্করণ ডিপ্লয় করুন
পাবলিক অনুরোধের জবাব দেয় এমন ওয়েব সার্ভার, রিভার্স প্রোক্সি, CDN, অথবা লোড ব্যালান্সার কনফিগার করুন। সার্টিফিকেট এবং প্রয়োজনীয় চেইন ইনস্টল করুন, সেগুলো উদ্দেশ্যভিত্তিক নামগুলোর সাথে বাইনড করুন, এবং হোস্টিং নেটওয়ার্কের বাইরে থেকে যাচাই করুন। ব্রাউজার চেইন, হোস্টনেম এবং তারিখ পরীক্ষা করে; পাবলিক সতর্কতা একটি রিলিজ ব্লকার। ডিফল্টভাবে TLS 1.3 ব্যবহার করুন এবং শুধুমাত্র কম্প্যাটিবিলিটির কারণে TLS 1.2 রাখুন। SSL এবং TLS 1.0/1.1 অবরুদ্ধ করুন। কপি করা লেগেসি সাইফার লিস্টের পরিবর্তে রক্ষণাবেক্ষণকৃত প্ল্যাটফর্ম গাইডলাইন অনুসরণ করুন এবং সার্ভার ও TLS লাইব্রেরি প্যাচ বজায় রাখুন।
প্রাইভেট কীতে প্রবেশাধিকার সীমিত করুন এবং যেসব সিস্টেমে একটি কী শেয়ার করা হয়েছে সেগুলোর সবকটি নথিভুক্ত করুন, যাতে কী বদলালে সব সিস্টেমে নতুন কীটি পৌঁছে।
HTTP-কে একবার রি-ডাইরেক্ট করুন এবং HTTPS কে ক্যোনিকাল করুন
প্রতিটি HTTP URL থেকে সমতুল্য HTTPS URL-এ সার্ভার-সাইড পার্মানেন্ট রি-ডাইরেক্ট (সাধারণত 301 বা 308) দিন। চেইন এড়িয়ে চলুন: এগুলো বিলম্ব ও ব্যর্থতার বিন্দু বাড়ায়। অভ্যন্তরীণ লিঙ্ক, canonical ট্যাগ, সাইটম্যাপ, স্ট্রাকচার্ড ডেটা, সোশ্যাল ট্যাগ, ইমেইল এবং অ্যাপ্লিকেশন-তৈরি অ্যাবসলিউট লিঙ্কে ক্যানোনিকাল HTTPS URL প্রকাশ করুন। হোম পেজ, ডিপ পেজ, কোয়েরি URL, এরর রুট ও হোস্টনেমের ভ্যারিয়েন্ট পরীক্ষা করুন। TLS কোনো প্রোক্সিতে শেষ হলে, ট্রাস্টেড ফরওয়ার্ডেড-প্রোটোকল হ্যান্ডলিং কনফিগার করুন, যাতে অ্যাপ্লিকেশন HTTP ও HTTPS-এর মধ্যে লুপ না করে।
HTTP শুধুই রি-ডাইরেক্ট বা সার্টিফিকেট চ্যালেঞ্জ সম্পন্ন করার জন্যই উপলব্ধ থাকতে পারে—পাবলিক সাইট আলাদা করে সার্ভ করতে নয়।
মিশ্র কনটেন্ট উৎসে খুঁজে বের করুন এবং ঠিক করুন
মিশ্র কনটেন্ট হলো একটি HTTPS পেজ যা HTTP বা অন্য কোনো অনিরাপদ প্রোটোকলের মাধ্যমে একটি রিসোর্স অনুরোধ করে। ব্রাউজার কিছু মিডিয়া আপগ্রেড করতে পারে, কিন্তু তারা স্ক্রিপ্ট, স্টাইলশিট, ফ্রেম, fetch কল ও ফন্টের মতো অনেক ঝুঁকিপূর্ণ অনুরোধ ব্লক করে। প্রতিটি রেফারেন্সকে একটি পরীক্ষিত HTTPS URL, আপনার নিজস্ব কনটেন্টের জন্য একটি রিলেটিভ URL, অথবা অনুমোদিত বিকল্প দিয়ে প্রতিস্থাপন করুন। প্রতিনিধিত্বমূলক টেমপ্লেট ক্রল করুন এবং গুরুত্বপূর্ণ ব্যবহারকারী-যাত্রা সম্পন্ন করার সময় ডেভেলপার টুলস দিয়ে পরীক্ষা করুন। CSS, JavaScript, CMS ব্লক, অ্যাসেট ম্যানিফেস্ট, ট্যাগ-ম্যানেজার এন্ট্রি, ডাউনলোড, এবং ভেন্ডর এমবেডগুলো চেক করুন। একটি নিরাপদ পেজ HTTP ডাউনলোড অফার করা উচিত নয়।
স্বয়ংক্রিয় ব্রাউজার আপগ্রেডিং থাকলেও একটি অনুপলব্ধ বা সমর্থনহীন তৃতীয়-পক্ষ নির্ভরশীলতা থাকতে পারে; সংরক্ষিত URLটি ঠিক করুন।
নবায়ন স্বয়ংক্রিয় করুন এবং সার্টিফিকেট পুনরুদ্ধার অনুশীলন করুন
নবায়নকে একটি ক্যালেন্ডার রিমাইন্ডার হিসেবে নয় বরং একটি স্বয়ংক্রিয় ডিপ্লয়মেন্ট হিসেবে বিবেচনা করুন। এটি নবায়ন করবে, প্রতিটি সার্ভিং টিয়ারে ডিপ্লয় করবে এবং সেবাটি নিরাপদভাবে রিলোড করবে। প্রোডাকশনের মেয়াদ শেষ হওয়ার আগে একই ভ্যালিডেশন রুট পরীক্ষা করুন। উদাহরণস্বরূপ Let’s Encrypt 90‑দিনের সার্টিফিকেটের জন্য 60 দিনে নবায়ন করার পরামর্শ দেয়; আপনার ইস্যুকারী ও প্ল্যাটফর্ম অনুযায়ী লাইফসাইকেল অনুসরণ করুন। সার্টিফিকেট নাম, ইস্যুকারী অ্যাকাউন্ট, চ্যালেঞ্জ পদ্ধতি, অটোমেশন, কী অবস্থান, টার্গেট এবং জরুরি যোগাযোগ ইনভেন্টরিতে রাখুন। ডিপ্লয়মেন্টের পরে পাবলিক এন্ডপয়েন্ট থেকে তারিখগুলি যাচাই করুন।
নবায়ন ব্যর্থ হলে DNS, চ্যালেঞ্জ রাউটিং, পারমিশন, ইস্যুকারীর অ্যাক্সেস, রেট লিমিট এবং CDN‑to‑origin ডিপ্লয়মেন্ট চেক করুন।
HTTPS স্থিতিশীল হলে মাত্র HSTS ব্যবহার করুন
HTTP Strict Transport Security (HSTS) হলো একটি HTTPS রেসপন্স হেডার যা ব্রাউজারকে ভবিষ্যত ভিজিটে ওই হোস্টে HTTPS ব্যবহার করতে বলে। ব্রাউজার এরপর সার্টিফিকেট ত্রুটির জন্য ভিজিটরকে বাইপাস অপশন দেয় না। এটি কেবল HTTPS-এ পাঠান এবং HTTP রি-ডাইরেক্ট রাখুন কারণ HSTS একটি নিরাপদ রেসপন্সের পরে শিখা হয়, যদি না কোনো preload তালিকা প্রযোজ্য হয়। সীমিত একটি max-age দিয়ে শুরু করুন এবং নবায়ন ও প্রয়োজনীয় রুট প্রমাণিত হওয়ার পরে এটি দীর্ঘ করুন। includeSubDomains যোগ করবেন না যতক্ষণ না প্রতিটি বর্তমান এবং ভবিষ্যৎ সাবডোমেইন বৈধ HTTPS দিতে পারে। Preload HSTS স্পেসিফিকেশনের অংশ নয় এবং আলাদা, দীর্ঘমেয়াদী প্রতিশ্রুতির পুনরালোচনা দাবি করে।
max-age=0 কেবল তখনই কার্যকর যখন ব্রাউজার একটি বৈধ HTTPS রেসপন্স পৌঁছে; এটি একটি অনুপলব্ধ নিরাপদ হোস্টকে ঠিক করতে পারে না।
ট্রান্সপোর্ট দুর্বল না করে রিলিজ, পরীক্ষা ও রোলব্যাক করুন
পরিবর্তনের আগে পরিচিত-ভালো সার্টিফিকেট, এজ এবং রি-ডাইরেক্ট কনফিগারেশন সংরক্ষণ করুন। কে রোলব্যাক অনুমোদন করেন তা নির্ধারণ করুন, সম্ভব হলে স্টেজিং পরিবেশ ব্যবহার করুন এবং একবারে এক ধরনের নিয়ন্ত্রণ পরিবর্তন করুন। একাধিক নেটওয়ার্ক থেকে দ্রুত পাবলিক এন্ডপয়েন্ট পরীক্ষা করুন, রি-ডাইরেক্ট অনুসরণ করুন, সার্টিফিকেট পরিদর্শন করুন এবং গুরুত্বপূর্ণ ভিজিটর-অ্যাকশন সম্পন্ন করুন। আপনার দর্শকের জন্য গুরুত্বপূর্ণ ব্রাউজার ও ক্লায়েন্ট-গ্রুপ পরীক্ষা করুন। পেমেন্ট বা নিয়ন্ত্রিত ফ্লো থাকলে, প্রযোজ্য প্রয়োজনীয়তা পর্যালোচনার জন্য পেমেন্ট প্রদানকারী ও যোগ্য নিরাপত্তা বিশেষজ্ঞকে বলুন। কোনো পরিবর্তনে HTTPS ভেঙে গেলে যাচাইকৃত নিরাপদ কনফিগারেশন পুনরুদ্ধার করুন; বিকল্প ব্যবস্থা হিসেবে গ্রাহকের পেজ HTTP-তে পরিবেশন করবেন না।
হোস্টনেম, সময়, ক্লায়েন্ট, ত্রুটি, পরিবর্তন এবং ফলাফল ক্যাপচার করুন যাতে পরবর্তী নবায়ন বা মাইগ্রেশন সহজে নির্ণয়যোগ্য থাকে।