होस्टनेम, निर्भरताओं और स्वामित्व की सूची बनाएं
उन सभी होस्टनेम की सूची बनाएं जिनका उपयोग विज़िटर या इंटीग्रेशन करते हैं: apex, www, सबडोमेन, APIs, एसेट होस्ट, पोर्टल और रीजनल नाम। प्रत्येक के लिए रिकॉर्ड करें कि TLS कहाँ समाप्त होता है, कौन इसे बदल सकता है, प्रमाणपत्र का कवरेज और समाप्ति तिथि, नवीनीकरण विधि, और URL उत्पन्न करने वाली निर्भरताएँ। अनुरोधित होस्टनेम को प्रमाणपत्र की Subject Alternative Name सूची में कवर होना चाहिए। CMS, CDN, टैग मैनेजर, ऑब्जेक्ट स्टोरेज, पेमेंट प्रोवाइडर, ईमेल टेम्पलेट और तृतीय-पक्ष एम्बेड्स शामिल करें; ये अक्सर पहली HTTPS रिलीज़ के बाद HTTP URL लाते हैं।
कैनोनिकल www या apex होस्टनेम चुनें और वैकल्पिक नाम को उसी के HTTPS URL पर सीधे रीडायरेक्ट करें।
प्रमाणपत्र और वर्तमान TLS संस्करण तैनात करें
सार्वजनिक अनुरोध का उत्तर देने वाले वेब सर्वर, रिवर्स प्रॉक्सी, CDN या लोड बैलेंसर को कॉन्फ़िगर करें। प्रमाणपत्र और आवश्यक चेन इंस्टॉल करें, उन्हें इच्छित नामों से बाँधें और होस्टिंग नेटवर्क के बाहर से सत्यापित करें। ब्राउज़र चेन, होस्टनेम और तिथियों की जाँच करता है; सार्वजनिक चेतावनी रिलीज़ ब्लॉकर होती है। डिफ़ॉल्ट रूप से TLS 1.3 इस्तेमाल करें और संगतता आवश्यक होने पर ही TLS 1.2 रखें। SSL तथा TLS 1.0 और 1.1 अक्षम करें। कॉपी की गई पुरानी सिफर सूची के बजाय मेंटेन किए गए प्लेटफ़ॉर्म दिशानिर्देशों का पालन करें और सर्वर व TLS लाइब्रेरी को पैच रखें।
प्राइवेट कीज़ तक पहुँच सीमित करें और उन सभी सिस्टमों का रिकॉर्ड रखें जो एक ही की साझा करते हैं, ताकि की बदलते समय सभी सिस्टमों को अपडेट किया जा सके।
HTTP को एक बार रीडायरेक्ट करें और HTTPS को कैनोनिकल बनाएं
प्रत्येक HTTP URL से समकक्ष HTTPS URL पर सर्वर-साइड परमानेन्ट रीडायरेक्ट लौटाएँ, सामान्यतः 301 या 308। चेन से बचें: वे देरी और विफलता के और बिंदु जोड़ते हैं। आंतरिक लिंक, कैनोनिकल टैग, साइटमैप, संरचित डेटा, सोशल टैग, ईमेल और ऐप-जनित एब्सोल्यूट लिंक्स में HTTPS कैनोनिकल URL प्रकाशित करें। होम पेज, एक गहरा पेज, एक क्वेरी URL, एरर रूट और होस्टनेम वेरिएंट्स का परीक्षण करें। जब TLS प्रॉक्सी पर समाप्त होता है, तो विश्वसनीय forwarded-protocol हैंडलिंग कॉन्फ़िगर करें ताकि एप्लिकेशन HTTP और HTTPS के बीच लूप न करे।
यह केवल रीडायरेक्ट करने या प्रमाणपत्र चुनौती पूरी करने के लिए उपलब्ध रह सकता है — सार्वजनिक साइट सर्व करने के लिये नहीं।
मिश्रित सामग्री (mixed content) का स्रोत पर पता लगाएँ और ठीक करें
मिश्रित सामग्री वह होती है जब HTTPS पृष्ठ किसी संसाधन को HTTP या किसी अन्य असुरक्षित प्रोटोकॉल पर अनुरोध करता है। ब्राउज़र कुछ मीडिया को अपग्रेड कर सकते हैं, पर वे कई जोखिमभरे अनुरोधों को ब्लॉक करते हैं, जिनमें स्क्रिप्ट, स्टाइलशीट, फ्रेम, fetch कॉल और फ़ॉन्ट शामिल हैं। हर संदर्भ को परीक्षण की हुई HTTPS URL, अपने कंटेंट के लिए सापेक्ष (relative) URL, या अनुमोदित वैकल्पिक के साथ बदलें। प्रतिनिधि टेम्पलेट्स को क्रॉल करें और प्रमुख यात्राओं को पूरा करते समय डेवलपर टूल्स की जाँच करें। CSS, JavaScript, CMS ब्लॉक्स, एसेट मैनिफेस्ट, टैग-मैनेजर एंट्री, डाउनलोड और वेंडर एम्बेड्स जांचें। एक सुरक्षित पृष्ठ HTTP डाउनलोड ऑफ़र नहीं करना चाहिए।
ऑटोमेटिक ब्राउज़र अपग्रेडिंग से भी एक अनुपलब्ध या असमर्थित तृतीय-पक्ष निर्भरता रह सकती है; संग्रहीत URL को ठीक करें।
नवीनीकरण स्वचालित करें और प्रमाणपत्र रिकवरी का अभ्यास करें
नवीनीकरण को कैलेंडर रिमाइंडर नहीं, बल्कि स्वचालित परिनियोजन के रूप में लें। स्वचालन को प्रमाणपत्र नवीनीकृत करना, उसे हर सर्विंग टीयर पर तैनात करना और सेवा को सुरक्षित रूप से पुनः लोड करना चाहिए। उत्पादन में समाप्ति से पहले उसी सत्यापन रूट का परीक्षण करें। उदाहरण के लिए, Let’s Encrypt 90-दिन के प्रमाणपत्रों को हर 60 दिन में नवीनीकृत करने की सलाह देता है; अपने जारीकर्ता और प्लेटफ़ॉर्म के जीवनचक्र का पालन करें। प्रमाणपत्र के नाम, जारीकर्ता खाता, चुनौती विधि, ऑटोमेशन, कुंजी का स्थान, लक्ष्य और आपातकालीन संपर्क इन्वेंटरी में रखें। तैनाती के बाद सार्वजनिक एंडपॉइंट से तिथियों की पुष्टि करें।
नाकाम नवीनीकरण के लिए DNS, चुनौती रूटिंग, अनुमतियाँ, जारीकर्ता पहुँच, रेट लिमिट और CDN-से-ओरिजिन परिनियोजन जांचें।
समूचा 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 पर सर्व न करें।
होस्टनेम, समय, क्लाइंट, त्रुटि, परिवर्तन और परिणाम कैप्चर करें ताकि अगले नवीनीकरण या माइग्रेशन को आसानी से डायग्नोज़ किया जा सके।