आंतरिक सेवाओं के लिए TLS प्रमाणपत्र सही तरीके से

मूल लेख ↗ Hacker News चर्चा ↗

स्प्लिट-होराइजन DNS बनाम विकल्प

  • कई लोग स्प्लिट-होराइजन DNS की आलोचना करते हैं कि यह नाज़ुक और अधिक रखरखाव वाला है, खासकर बड़े पैमाने पर (डुप्लिकेट रिकॉर्ड, कैशिंग की अजीबताएँ, VPN रूटिंग समस्याएँ)।
  • अन्य लोग कहते हैं कि यह छोटे/होम लैब्स के लिए ठीक है और hairpin NAT के साथ मिलाया जा सकता है; असली परेशानी बड़े कॉर्पोरेट सेटअप में होती है जहाँ आंतरिक और सार्वजनिक ज़ोन का नाम एक ही होता है।
  • कुछ लोग स्पष्ट रूप से स्प्लिट DNS का उपयोग करने से इनकार करते हैं, और इसकी जगह एकल सार्वजनिक ज़ोन में आंतरिक IPs या overlay networks को प्राथमिकता देते हैं।

ACME, DNS-01, और ऑटोमेशन पैटर्न

  • आंतरिक सेवाओं के लिए HTTP-01 की तुलना में DNS-01 validation को लेकर मजबूत प्राथमिकता है।
  • सामान्य पैटर्न:
    • प्रमाणपत्र प्राप्त करने के लिए DNS APIs वाला सार्वजनिक डोमेन उपयोग करें (अक्सर wildcard), फिर नामों को आंतरिक IPs की ओर इंगित करें।
    • DNS-01 को किसी अलग zone/provider या acme-dns जैसे टूल्स को delegate करने के लिए CNAME “_acme-challenge” aliasing का उपयोग करें।
    • केंद्रीय ACME helper services या GitHub Actions जो DNS credentials का स्वामित्व रखते हैं और आंतरिक hosts के लिए प्रमाणपत्र जारी करते हैं।
  • DNS-PERSIST-01 challenge में रुचि है, जो dynamic DNS updates की आवश्यकता को कम कर सकता है, हालांकि समर्थन अभी भी सीमित है।

सार्वजनिक CAs बनाम आंतरिक CAs

  • एक पक्ष: “बस एक आंतरिक CA चलाओ, आंतरिक certs पर sign करो, और उस CA पर अपने devices में trust करो।” इसे स्वच्छ cryptographic समाधान माना जाता है।
  • प्रतिवाद:
    • विविध OSes, languages, containers, और browsers में trust anchors को वितरित और प्रबंधित करना कठिन है।
    • कुछ लोग तर्क देते हैं कि सार्वजनिक CAs (जैसे DNS-01 के माध्यम से Let’s Encrypt) परिचालन रूप से सरल हैं, खासकर जब आप client devices को पूरी तरह नियंत्रित नहीं करते।
    • rate limits और trust semantics को लेकर चिंताएँ (सार्वजनिक cert केवल domain control साबित करता है, organizational identity नहीं)।

Wildcard certs, CT logs, और hostname/privacy संबंधी चिंताएँ

  • कुछ लोगों को चिंता है कि non-wildcard सार्वजनिक certs Certificate Transparency logs के माध्यम से आंतरिक hostnames उजागर कर देते हैं; wildcard certs इससे बचाते हैं लेकिन key risk को केंद्रीकृत कर देते हैं।
  • अन्य लोग सामान्य होम hostnames के लीक होने को लेकर चिंतित नहीं हैं, या कहते हैं कि obscurity से अधिक attack surface मायने रखता है।
  • इस बात पर बहस है कि आंतरिक IPs और hostnames को सार्वजनिक DNS में डालना स्वीकार्य है या नहीं; कुछ इसे हानिरहित मानते हैं, अन्य इसे पूरी तरह अस्वीकार करते हैं।

Client trust stores और tooling fragmentation

  • कई टिप्पणियाँ इस बात पर अफसोस जताती हैं कि clients को internal CAs पर trust कराने के लिए configure करना जितना होना चाहिए उससे कहीं अधिक कठिन है।
  • अलग-अलग ecosystems अलग trust stores का उपयोग करते हैं (OS, Java, browsers, Node, Python/certifi, containers, snaps), जिससे CA installation बार-बार करनी पड़ती है।
  • यह जटिलता एक बड़ा कारण है कि कुछ लोग पूरी तरह internal services के लिए भी public ACME certs को प्राथमिकता देते हैं।

Security models और access patterns

  • कुछ लोग “BeyondCorp/zero trust” शैली की वकालत करते हैं: VPN और split DNS की जगह mTLS, device certs, और authenticated reverse proxies।
  • अन्य लोग VPNs (WireGuard, Tailscale) के साथ internal DNS, या केंद्रीय reverse proxies/load balancers पर भरोसा करते हैं जो TLS terminate करते हैं और internal services तक route करते हैं।
  • इस पर राय बंटी हुई है कि internal-only high-value services के लिए public certs का उपयोग उचित है या नहीं; कुछ इसे “bogus” कहते हैं, जबकि अन्य पूछते हैं कि यह हानिकारक क्यों होगा।