केवल VPN से चलने वाली साइट के लिए प्रमाणपत्र: DNS-01 या निजी CA?

तीन शर्तें तय करती हैं कि केवल VPN से उपलब्ध साइट को अपना प्रमाणपत्र कैसे मिलना चाहिए: क्या आप एक सार्वजनिक DNS ज़ोन नियंत्रित करते हैं, क्या होस्टनाम सार्वजनिक लॉग में दिख सकता है, और क्या हर क्लायंट को एक निजी भरोसा एंकर दिया जा सकता है। सार्वजनिक और निजी, दोनों रास्ते काम करने वाला ताला बनाते हैं और वे अलग-अलग सवालों का जवाब देते हैं। इन शर्तों को तय किए बिना एक चुनना ही वह तरीका है जिससे कोई साइट ऐसे सार्वजनिक प्रमाणपत्र तक पहुँच जाती है जो उसे नहीं चाहिए था, या ऐसे आंतरिक प्रमाणपत्र तक जिसे आधे क्लायंट अस्वीकार कर देते हैं।

प्रमाणपत्र नाम सिद्ध करता है; VPN और आंतरिक DNS रास्ता देते हैं।

भरोसेमंद नाम तक दो रास्ते

DNS-01 सत्यापन के साथ एक सार्वजनिक जारीकर्ता आपके नियंत्रण वाले ज़ोन में TXT रिकॉर्ड के ज़रिए नाम पर नियंत्रण सिद्ध करता है, इसलिए वेब सेवा को कभी सार्वजनिक HTTP कनेक्शन स्वीकार नहीं करना पड़ता। एक निजी CA आंतरिक नामों के लिए लीफ़ प्रमाणपत्र जारी करता है और अपना भरोसा एंकर डिवाइस प्रबंधन के ज़रिए बाँटता है, इसलिए कोई सार्वजनिक लॉग नाम नहीं जान पाता। दोनों वैध हैं, और चुनाव सुविधा से नहीं, उन्हीं तीन शर्तों से निकलता है। कोई भी रास्ता वह मार्ग या रिज़ॉल्वर प्रविष्टि नहीं देता जिसकी क्लायंट को ज़रूरत है।

सार्वजनिक प्रमाणपत्र होस्टनाम को प्रमाणपत्र-पारदर्शिता लॉग में भी प्रकाशित करता है। अगर नाम ही संवेदनशील है, तो वह प्रकटीकरण एक डिज़ाइन निर्णय है, बाद में पता चलने वाला दुष्प्रभाव नहीं।

सेवा को उजागर किए बिना DNS-01

चैलेंज रिकॉर्ड ज़ोन में आरक्षित उपसर्ग के अंतर्गत एक TXT प्रविष्टि है, और जारीकर्ता उसे आधिकारिक DNS से पढ़ता है। ऐसा ACME क्लायंट और DNS एकीकरण चुनें जो वह रिकॉर्ड बना और हटा सके, और अपडेट को संकीर्ण रूप से अधिकृत करें: ज़ोन के लिए सीमित API क्रेडेंशियल, या केवल सत्यापन के लिए इस्तेमाल होने वाला नियंत्रित होस्ट। एक प्रमाणपत्र नवीनीकृत करने के लिए एप्लिकेशन सर्वर को अप्रतिबंधित रजिस्ट्रार क्रेडेंशियल देना काम की ज़रूरत से कहीं ज़्यादा अधिकार है। जब कई ऑर्डर एक नाम साझा करते हैं, तो उनके TXT मान अलग रखें ताकि एक की सफ़ाई किसी दूसरे के अभी ज़रूरी मान को न हटा दे।

स्थिर प्रतीक्षा के बजाय आधिकारिक सर्वरों के विरुद्ध जाँच के साथ प्रसार की प्रतीक्षा करें। प्रसार का व्यवहार प्रदाता पर निर्भर है, और आज काम करने वाली प्रतीक्षा कल के बारे में प्रमाण नहीं है।

प्रबंधित क्लायंट और जानबूझकर निजी नाम

प्रबंधित डिवाइस और जानबूझकर निजी नाम आंतरिक CA के साथ अच्छी तरह बैठते हैं। डिवाइस प्रबंधन के ज़रिए भरोसेमंद जारीकर्ता वितरित करें, फिर इच्छित नामों के लिए लीफ़ प्रमाणपत्र जारी करें। जाँचें कि हर क्लायंट वास्तव में कौन-सा स्टोर इस्तेमाल करता है, क्योंकि ऑपरेटिंग सिस्टम में एक आयात हर ब्राउज़र और एप्लिकेशन के बारे में सार्वभौमिक दावा नहीं है। लीफ़ पिनिंग एक और विकल्प है जहाँ उसे स्पष्ट रूप से समर्थन मिलता है, लेकिन लीफ़ बदलने पर हर बार एक और भरोसा अपडेट की कीमत पर।

वितरण चैनल कुंजी जितना ही मायने रखता है: जिस रूट को कोई इंस्टॉल नहीं करता, वह कुछ भी नहीं बचाता।

नवीनीकरण डिज़ाइन का हिस्सा है

आप जो भी रास्ता चुनें, नवीनीकरण के लिए एक मालिक और एक प्रक्रिया चाहिए। सत्यापन प्रमाण को ताज़ा करना, नई सामग्री इंस्टॉल करना और समर्थित तंत्र के ज़रिए श्रोता को फिर से लोड करना तीन अलग चरण हैं, और केवल पहले को ही अधिकांश ACME क्लायंट स्वचालित करते हैं। जो प्रमाणपत्र ठीक से नवीनीकृत होता है पर कभी लोड नहीं होता, वह उतनी ही रुकावट पैदा करता है जितनी समाप्त हो चुका प्रमाणपत्र।

प्रमाणपत्र VPN मार्ग इंस्टॉल नहीं करता और आंतरिक DNS रिकॉर्ड नहीं बनाता। क्लायंट को अब भी ऐसा रिज़ॉल्वर चाहिए जो नाम को निजी पते से जोड़े, और वहाँ पहुँचने का मार्ग। जिस क्लायंट के पास दोनों हों, उससे नाम से साइट जाँचें।

जारीकर्ता, सत्यापन विधि, भरोसा वितरण चैनल और पुनः लोड करने का तंत्र दर्ज करें। वही चार नवीनीकरण योजना हैं।