Webship ब्लॉग पर वापस

Webship इंजीनियरिंग

TLS प्रमाणपत्र Webship में: एम्बेडेड ACME CA

देखें कि Webship 1.4.0 अपने एम्बेडेड CA के साथ निजी प्रति-साइट TLS प्रमाणपत्र कैसे जारी करता है और घुमाता है, क्लाइंट ट्रस्ट कैसे काम करता है, और एम्बेडेड पहचानें सार्वजनिक ACME और मैनुअल प्रमाणपत्रों के साथ कैसे सहअस्तित्व करती हैं।

# Webship में TLS प्रमाणपत्र: एंबेडेड ACME CA

एक TLS प्रमाणपत्र दो काम करता है: यह कनेक्शन को एन्क्रिप्ट करने में मदद करता है और क्लाइंट को बताता है कि यह किस पहचान से बात कर रहा है। एन्क्रिप्शन मजबूत हो सकता है जबकि विश्वास निर्णय दर्शकों के लिए गलत हो सकता है। यही कारण है कि प्रमाणपत्र स्वचालन को एक प्रश्न से शुरू करना चाहिए: इस साइट पर किसे भरोसा करना चाहिए?

Webship 1.4.0 हर कॉन्फ़िगर किए गए साइट के लिए वह चुनाव स्वतंत्र रूप से करता है। एक सार्वजनिक वेबसाइट एक ब्राउज़र-विश्वसनीय ACME प्रमाणपत्र का उपयोग कर सकती है, एक आंतरिक सेवा Webship के एम्बेडेड निजी प्रमाणपत्र प्राधिकारी का उपयोग कर सकती है, और एक ऐसी साइट जिसके पास वर्तमान PKI मौजूद है, ऑपरेटर-प्रबंधित प्रमाणपत्र फ़ाइलें रख सकती है। वे सभी एक Webship प्रक्रिया साझा कर सकते हैं बिना किसी एक निजी कुंजी या एक ट्रस्ट बॉउंड्री साझा किए।

चार स्वचालित प्रमाणपत्र मोड, साइट के अनुसार चुने जाते हैं

certificate_mode फ़ील्ड प्रत्येक [[sites]] प्रविष्टि से संबंधित है। यह एक वैश्विक स्विच नहीं है।

| मोड | भरोसेमंद स्रोत | सर्वश्रेष्ठ फिट | सत्यापन पथ | | --- | --- | --- | --- | | प्रति_साइट | सार्वजनिक ब्राउज़र और ऑपरेटिंग सिस्टम ट्रस्ट स्टोर | एक सटीक होस्टनाम वाले सार्वजनिक साइट | सार्वजनिक ACME के साथ TLS-ALPN-01 | | फ्लीट | सार्वजनिक ब्राउज़र और ऑपरेटिंग-सिस्टम ट्रस्ट स्टोर | स्पष्ट रूप से पंजीकृत डोमेन के अंतर्गत तीसरे और चौथे स्तर के नामों के बड़े सेट | DNS-01 के साथ सार्वजनिक ACME और स्थिर प्रमाणपत्र शार्ड्स | | एम्बेडेड | ऑपरेटर द्वारा स्थापित एक निजी Webship रूट | आंतरिक सेवाएं, प्रबंधित डिवाइस, निजी फ्लीट, और परीक्षण वातावरण | इन-प्रोसेस जारीकरण; कोई बाहरी चुनौती नहीं | | साझा किया गया | सार्वजनिक ब्राउज़र और ऑपरेटिंग-सिस्टम ट्रस्ट स्टोर | पुराने परिनियोजन जो जानबूझकर एक सार्वजनिक मल्टी-एसएएन समूह का उपयोग करते हैं | सार्वजनिक ACME TLS-ALPN-01 के साथ |

डिफ़ॉल्ट per_site है। यह साइट के सही नाम के लिए एक सार्वजनिक प्रमाणपत्र प्राप्त करता है। फ़्लीट मोड कई गहरी उपडोमेन के लिए स्केलेबल सार्वजनिक विकल्प है। एम्बेडेड मोड Webship के निजी इन-प्रोसेस CA का उपयोग करता है। साझा मोड कंपैटिबिलिटी के लिए उपलब्ध रहता है, लेकिन यह डिफ़ॉल्ट नहीं है।

[sites.tls] के तहत पूरी सर्टिफिकेट और कुंजी हमेशा उस साइट के लिए स्वचालित निर्गम पर प्राथमिकता लेती है।

‘एम्बेडेड ACME CA’ का क्या मतलब है

कॉन्फ़िगरेशन सेक्शन का नाम [acme_ca] है, लेकिन एम्बेडेड CA कोई सार्वजनिक या नेटवर्क-एक्सेसिबल ACME सेवा नहीं है। यह कोई निर्देशिका एंडपॉइंट नहीं प्रदान करता, कोई रिमोट एनरोलमेंट स्वीकार नहीं करता, कोई रजिस्टार API कॉल नहीं करता, और कोई प्रूफ-ऑफ-कंट्रोल चैलेंज नहीं करता।

इसके बजाय, Webship पूरे निजी इश्यूअन्स पथ को एक ही प्रक्रिया में रखता है:

  1. साइट certificate_mode = "embedded" चुनती है।
  2. Webship कॉन्फ़िगर किए गए स्थिति निर्देशिका में निजी मूल पहचान को लोड या बनाता है।
  3. Webship साइट के लिए एक नया निजी कुंजी उत्पन्न करता है।
  4. एंबेडेड रूट उसी सटीक नाम के लिए एक लीफ सर्टिफिकेट साइन करता है।
  5. Webship लाइव TLS रिज़ॉल्वर में स्थापित करने से पहले पूरी की गई पहचान को मान्य करता है।
  6. सर्टिफ़िकेट तब उस साइट के लिए सक्षम प्रत्येक प्रोटोकॉल के लिए उपलब्ध होता है।

एक ACME-शैली की नेटवर्क चुनौती केवल Webship को ही साबित करेगी, इसलिए एम्बेडेड पथ में जानबूझकर कोई नेटवर्क प्रोटोकॉल नहीं है। [acme_ca] सेक्शन निजी PKI स्थिति है: यह परिभाषित करता है कि रूट कहाँ मौजूद है और जारी किए गए लिफ़ सर्टिफिकेट कितने समय तक वैध रहते हैं।

एक साइट के लिए एम्बेडेड प्रमाणपत्र कॉन्फ़िगर करें

यह एक निजी साइट के लिए न्यूनतम आकार है:

~~~टॉमल सुनें = "0.0.0.0:443"

[टीएलएस] unknown_sni = "अस्वीकार"

[स्वचालित_tls] सक्षम = सच cache_dir = "/var/lib/webship/acme"

[एक्मे_ca] state_dir = "/var/lib/webship/acme-ca" leaf_validity_days = 90

[[साइट्स]] डोमेन = "service.internal.example" root = "/srv/service" certificate_mode = "संयुक्त"

[साइट्स.प्रोटोकॉल] h1 = सच h2 = सच h3 = सच ~~~

मूल पहचान तभी बनाई जाती है जब किसी एम्बेडेड साइट को पहली बार इसकी आवश्यकता होती है। Webship राज्य_डिर में प्रतिबंधित अनुमतियों के साथ मूल कुंजी को बनाए रखता है। मूल प्रमाणपत्र की उम्र दस वर्ष है; पत्ती की उम्र leaf_validity_days द्वारा नियंत्रित होती है।

दोनों भंडारण स्थानों को उत्पादन स्थिति के रूप में मानें:

  • ACME कैश स्वचालित रूप से प्रबंधित साइट पहचान को रखता है।
  • एंबेडेड-सीए स्टेट डायरेक्टरी निजी रूट पहचान रखती है।
  • सर्विस अकाउंट को एक्सेस की आवश्यकता है, लेकिन एप्लिकेशन उपयोगकर्ताओं को नहीं।
  • बैकअप को गोपनीयता और फ़ाइल अनुमतियों को संरक्षित करना चाहिए।
  • उत्पादन, विकास और परीक्षण के लिए अलग जड़ और अलग निर्देशिकाओं का उपयोग करना चाहिए।

रूट डायरेक्टरी को हटाने से “TLS रीसेट” नहीं होता। यह एक नया ट्रस्ट एंकर बनाता है। जो क्लाइंट पुराने रूट पर भरोसा करते हैं, वे उस प्रतिस्थापन द्वारा जारी किए गए प्रमाणपत्रों को तब तक अस्वीकार करेंगे जब तक उनके ट्रस्ट स्टोर अपडेट नहीं हो जाते।

निजी ट्रस्ट जानबूझकर होता है

एमबेडेड सीए से प्रमाणपत्र स्वतः सार्वजनिक ब्राउज़र या ऑपरेटिंग सिस्टम द्वारा भरोसेमंद नहीं माने जाते हैं। वे केवल तब भरोसेमंद बनते हैं जब ऑपरेटर ने क्लाइंट के ट्रस्ट स्टोर में निर्यात किए गए Webship रूट प्रमाणपत्र को स्थापित कर दिया हो।

यह एम्बेडेड मोड को इसके लिए उपयुक्त बनाता है:

  • कंपनी-प्रबंधित लैपटॉप और फोन जो डिवाइस प्रबंधन के माध्यम से नामांकित हैं;
  • सुस्पष्ट CA बंडल के साथ आंतरिक सेवा-से-सेवा ट्रैफ़िक;
  • निजी उपकरण और नियंत्रित एज फ्लिट्स;
  • विकास और परीक्षण वातावरण जिन्हें वास्तविक TLS व्यवहार का अभ्यास करना चाहिए;
  • विभाजित नेटवर्क जो किसी सार्वजनिक CA पर निर्भर नहीं कर सकते।

यह एक सामान्य सार्वजनिक वेबसाइट के लिए सही मोड नहीं है जिसके आगंतुक अपंजीकृत ब्राउज़र का उपयोग करते हैं। सटीक सार्वजनिक नाम के लिए सार्वजनिक प्रति_साइट जारी करना, बड़े सार्वजनिक उपडोमेन सेट के लिए फ़्लीट जारी करना, जानबूझकर पुराने मल्टी-SAN तैनाती के लिए केवल साझा करना, या पहले से विश्वसनीय PKI से मैन्युअल फ़ाइलों का उपयोग करें।

केवल रूट प्रमाणपत्र को क्लाइंट्स में वितरित करें। रूट निजी कुंजी को कभी वितरित न करें। उस कुंजी का स्वामित्व रखने वाला व्यक्ति हर पंजीकृत क्लाइंट द्वारा विश्वसनीय पहचानों को जारी करने का अधिकार रखता है।

सार्वजनिक और निजी प्रमाणपत्र सह-अस्तित्व में रह सकते हैं

Webship 1.4.0 एक ही लिस्नर पर सर्टिफिकेट रणनीतियों को मिल सकता है:

~~~टॉमल सुनें = "0.0.0.0:443"

[टीएलएस] unknown_sni = "अस्वीकार"

[स्वचालित_tls] सक्षम = सच directory_url = "https://acme-v02.api.letsencrypt.org/directory" cache_dir = "/var/lib/webship/acme" संपर्क = ["mailto:ops@example.com"] सेवा की शर्तें स्वीकार करें = सही

[एक्मे_ca] state_dir = "/var/lib/webship/acme-ca" leaf_validity_days = 90

[[साइट्स]] डोमेन = "www.example.com" root = "/srv/public" certificate_mode = "प्रति_साइट"

[[साइट्स]] डोमेन = "control.internal.example" root = "/srv/control" certificate_mode = "संग्रहीत"

[[साइट्स]] डोमेन = "payments.example.com" root = "/srv/payments"

[साइट्स.tls] cert = "/etc/webship/payments-fullchain.pem" कुंजी = "/etc/webship/payments-private-key.pem" ~~~

यहाँ, www.example.com अपना स्वयं का सार्वजनिक ACME प्रमाणपत्र प्राप्त करता है। control.internal.example एम्बेडेड CA से निजी प्रमाणपत्र प्राप्त करता है। payments.example.com ऑपरेटर के बाहरी PKI के तहत रहता है क्योंकि इसके स्पष्ट फ़ाइलों को प्राथमिकता मिली हुई है।

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

H1, H2, H3, और WebTransport के लिए एक प्रमाणपत्र समाधानकर्ता

सर्टिफिकेट का चयन TLS हैंडशेक के दौरान होता है, इससे पहले कि कोई HTTP अनुरोध मौजूद हो। Webship साइट पहचान चुनने के लिए ClientHello सर्वर नाम का उपयोग करता है और फिर एप्लिकेशन प्रोटोकॉल पर बातचीत करता है।

  • HTTP/1.1 और HTTP/2 TCP पर TLS का उपयोग करते हैं।
  • HTTP/3 और WebTransport UDP पर QUIC के अंदर TLS का उपयोग करते हैं।
  • एक मान्य साइट पहचान हर सक्षम प्रोटोकॉल के लिए सेवा दे सकती है।
  • HTTP/3 को UDP पहुँच भी चाहिए; H1 और H2 TCP मार्ग का उपयोग करते हैं।
  • Alt-Svc H3 का प्रचार कर सकता है जबकि TCP फॉलबैक को बनाए रखता है।

TCP, TLS और QUIC एक ही साइट-सूचित पहचान मॉडल का उपयोग करते हैं। सटीक नामों को प्राथमिकता दी जाती है, सबसे लंबा वैध वाइल्डकार्ड तब जीतता है जब वाइल्डकार्ड प्रमाणपत्र कॉन्फ़िगर किए गए हों, और अज्ञात नामित SNI को अस्वीकार किया जा सकता है बजाय कि किसी असंबंधित डिफ़ॉल्ट प्रमाणपत्र को प्राप्त करने के।

जब एक अज्ञात होस्टनेम को फेल क्लोज़ होना आवश्यक हो, तब मल्टी-साइट लिसनर पर unknown_sni = "reject" का उपयोग करें। उत्पादन रोलआउट से पहले मान्यता प्राप्त नामों, अज्ञात नामों और आपकी अपेक्षित no-SNI व्यवहार का परीक्षण करें।

सर्विंग गैप के बिना एम्बेडेड पहचान को घुमाएँ

Webship प्रमाणपत्र की स्थिति और नियंत्रित परिवर्तन को इसके प्रमाणीकरण किए गए, लूपबैक-बाउंड MCP सर्वर के माध्यम से उजागर करता है:

  • webship.tls.get_status सक्रिय प्रमाणपत्र रेज़ोल्वर और नवीनीकरण स्थिति की रिपोर्ट करता है।
  • webship.tls.reissue_certificate केवल तभी तुरंत स्वतः प्रबंधित साइट को पुनः जारी करता है जब वह साइट एम्बेडेड मोड का उपयोग करती है।
  • webship.tls.reload सामान्य सुरक्षित TLS पथ के माध्यम से प्रमाणपत्र की स्थिति को पुनः लोड करता है।
  • webship.acme_ca.status यह रिपोर्ट करता है कि निजी CA चुना गया है या नहीं, इसका स्टेट डायरेक्टरी, लीफ लाइफटाइम, जारी करने की संख्या, रिवोकेशन संख्या, और हाल का डोमेन नमूना।
  • webship.sites.apply पिन की गई कॉन्फ़िगरेशन संस्करण के खिलाफ साइटों को जोड़ता या हटाता है।

एक एम्बेडेड रीइशू के लिए, Webship सेवा में बदलने से पहले प्रतिस्थापन बनाता है और मान्य करता है। वर्तमान वैध पहचान तब तक सेवा देती रहती है जब तक नई पहचान तैयार न हो जाए। प्रतिस्थापित पहचान केवल तब दर्ज की जाती है जब प्रतिस्थापन स्थापित हो जाता है।

तत्काल पुनः जारी करने का संचालन जानबूझकर सार्वजनिक per_site प्रमाणपत्रों को अस्वीकार करता है। सार्वजनिक नवीनीकरण को निजी प्रक्रिया में हस्ताक्षर के साथ भ्रमित किए बिना सार्वजनिक ACME जीवनचक्र के भीतर रहना चाहिए। साझा-रूप सदस्यता भी पुनः आरंभ-फ्रीज है क्योंकि एक बहु-SAN समूह को बदलने से पहचान सीमा पुनर्निर्मित होती है।

MCP एक विशेष नियंत्रण सतह है। इसे लूपबैक पर रखें, TLS और एक मजबूत बेयरर टोकन की आवश्यकता रखें, दूरस्थ प्रशासन के लिए प्रमाणीकृत टनेल का उपयोग करें, और हर परिवर्तन का ऑडिट करें।

विफलता की सीमाएँ जो मायने रखती हैं

एक सुरक्षित प्रमाणपत्र प्रणाली को सही दिशा में विफल होना चाहिए।

  • एक नव-संरचित एम्बेडेड साइट तब तक अन्य साइट की पहचान नहीं प्राप्त करती जब तक कि जारी किया जाना लंबित न हो।
  • एक अमान्य प्रतिस्थापन कार्यरत प्रमाणपत्र पर स्थापित नहीं है।
  • स्पष्ट मैनुअल फ़ाइलें उस साइट के स्वचालित स्वामित्व को रोकती हैं।
  • अज्ञात नामित SNI को HTTP रूटिंग से पहले अस्वीकार किया जा सकता है।
  • एंबेडेड सीए निजी बनी रहती है और इसका कोई रिमोट एनरोलमेंट एंडपॉइंट नहीं है।
  • सार्वजनिक और एम्बेडेड पहचानें ऑटोमैटिक-TLS स्थिति के अंदर अलग कैश पथ का उपयोग करती हैं।

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

उत्पादन चेकलिस्ट

एम्बेडेड मोड सक्षम करने से पहले:

  1. हर उस ग्राहक समूह की पहचान करें जिसे साइट पर भरोसा करना चाहिए।
  2. रूट सर्टिफिकेट निर्यात और इंस्टॉल करने के लिए एक नियंत्रित प्रक्रिया बनाएं।
  3. उत्पादन, विकास और परीक्षण के लिए अलग मूल स्थिति का उपयोग करें।
  4. एम्बेडेड-सीए स्थिति निर्देशिका और ऑटोमैटिक-टीएलएस कैश को बनाए रखें और सुरक्षित रखें।
  5. Webship को केवल आवश्यक कुंजी सामग्री तक पहुँच वाली एक समर्पित सेवा खाते के तहत चलाएँ।
  6. हर उस साइट पर certificate_mode चुनें जिसकी ट्रस्ट सीमा स्पष्ट होनी चाहिए।
  7. अज्ञात-SNI नीति सेट करें और परीक्षण करें।
  8. H1, H2, और H3 को जानबूझकर सक्षम करें और TCP और UDP दोनों रास्तों की जांच करें।
  9. उत्पादन के बाहर रिइश्यू, पुनःप्रारंभ, बैकअप, पुनर्स्थापना, और क्लाइंट-ट्रस्ट सत्यापन का अभ्यास करें।
  10. रोलआउट से पहले webship --check-config चलाएँ, फिर किसी वास्तविक क्लाइंट से जारीकर्ता, नाम, वैधता, श्रृंखला, और नेगोशिएट किए गए प्रोटोकॉल की पुष्टि करें।

पहले विश्वास चुनें, फिर स्वचालन

एम्बेडेड CA निजी इंफ्रास्ट्रक्चर के लिए बाहरी प्रमाणपत्र-सेवा निर्भरता को हटाता है। यह किसी निजी रूट को वैश्विक रूप से विश्वसनीय नहीं बनाता, और यह ऑपरेटर की PKI जिम्मेदारियों को हटाता नहीं है।

Webship कुंजी उत्पादन, हस्ताक्षर, सत्यापन, स्थापना, घुमाव, और प्रोटोकॉल-व्यापी प्रमाणपत्र चयन को स्वचालित करता है। ऑपरेटर अभी भी रूट कस्टडी, क्लाइंट नामांकन, पर्यावरण पृथक्करण, बैकअप, पुनर्प्राप्ति, और सार्वजनिक या निजी ट्रस्ट पथ का उपयोग करने का निर्णय रखता है।

वह अलगाव ही विशेषता है। एक स्वयं-संपूर्ण सर्वर निजी TLS को स्वचालित कर सकता है बिना यह दिखावे के कि यह एक सार्वजनिक CA है—और सार्वजनिक साइटें अभी भी उसी प्रक्रिया में ब्राउज़र-विश्वसनीय प्रति-साइट या फ्लीट जारीकरण का उपयोग कर सकती हैं।

रोलआउट से पहले संस्करणित Webship 1.4.0 प्रलेखन पढ़ें। RFC 5280 प्रमाणपत्र प्रोफाइल और सत्यापन को परिभाषित करता है, RFC 6066 TLS सर्वर-नाम संकेत को परिभाषित करता है, RFC 8446 TLS 1.3 को परिभाषित करता है, RFC 8555 सार्वजनिक ACME को परिभाषित करता है, और RFC 9525 सेवा पहचान सत्यापन को परिभाषित करता है।