Let's Encrypt, IP address certificates जारी करने की तैयारी में

 (community.letsencrypt.org)
7 पॉइंट द्वारा GN⁺ 2025-06-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Let's Encrypt जल्द ही IP address SAN वाले certificates जारी करने का समर्थन करने वाला है, और शुरुआत में यह केवल 6-दिन expiry वाले shortlived profile तक सीमित होगा, साथ ही कुछ समय तक इसे whitelist-आधारित सीमित संचालन में रखा जाएगा
  • औपचारिक लॉन्च से पहले कोई ठोस timeline या आवेदन निर्देश नहीं हैं, और फिलहाल internal testing और तैयारी जारी है
  • staging environment में IPv6 address शामिल करने वाले sample certificates और उन्हें लागू करने वाली site सार्वजनिक की गई है, तथा community से anomalies या feedback साझा करने का अनुरोध किया गया है
  • Firefox में IP SAN display से जुड़ा bug (BZ #1973855) मिला है, इसलिए testing जारी है
  • DNS SAN और IP SAN को मिलाने वाले cases में भ्रम की संभावना वास्तविक test examples से पुष्टि हुई है, और यह दिखाया गया है कि TLD और IPv6 address notation एक जैसी लग सकती है

Let's Encrypt, Getting ready to issue IP address certificates

IP address SAN support की तैयारी की स्थिति

  • Let's Encrypt जल्द ही production environment में IP address SAN शामिल certificates जारी करने का समर्थन करने की योजना बना रहा है
  • ये certificates केवल 6-दिन validity वाले shortlived profile में जारी किए जाएंगे, और कुछ समय तक allowlist तरीके से सीमित रूप में चलाए जाएंगे
  • अभी औपचारिक रिलीज़ की तारीख और allowlist आवेदन का तरीका तय नहीं है, क्योंकि अतिरिक्त internal preparation की जरूरत है

Testing और sample certificates

  • staging environment में IP SAN शामिल sample certificate और उसके वास्तविक लागू site (IPv6 address) का उदाहरण सार्वजनिक किया गया है
  • community users से कोई anomaly, दिलचस्प व्यवहार, या समस्या मिले तो साझा करने का अनुरोध किया गया है

IP SAN और DNS SAN के मिश्रित cases

  • testing के दौरान DNS SAN और IP SAN दोनों शामिल certificates जारी होने की संभावना और display confusion के examples दिखाए गए
  • .cafe जैसे कुछ TLD और IPv6 address notation एक जैसे दिख सकते हैं, इसलिए भ्रम की संभावना है
  • Firefox में IP address SAN display से जुड़ा bug (BZ #1973855) भी देखा गया है

सारांश

  • Let's Encrypt का IP address certificate support शुरुआत में whitelist और short-lived certificates तक सीमित रहेगा
  • वास्तविक service deployment से पहले अलग-अलग cases की testing और community feedback के जरिए stability और compatibility की जांच की जाएगी
  • DNS names और IP addresses के SAN मिश्रण से जुड़े browser display issues पर भी साथ-साथ चर्चा हो रही है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-06-27
Hacker News टिप्पणियाँ

  • मुझे लगता है कि IP पते के लिए certificate भी उपयोगी हैं
    लेकिन अगर Let‘s Encrypt S/MIME certificate को support करे, तो उसका असर कहीं बड़ा हो सकता है
    ईमेल encryption को लेकर कई सालों से एक तरह की हास्यास्पद स्थिति बनी हुई है
    अब ज़्यादातर बड़े email client S/MIME encryption को सीधे support करते हैं, लेकिन web की तरह smooth user experience के लिए CA से certificate लेना पड़ता है
    विश्वसनीय, मुफ़्त, और 1 साल से ज़्यादा वैध S/MIME certificate देने वाले CA अब लगभग ख़त्म हो चुके हैं
    नतीजतन, व्यक्तिगत उपयोगकर्ता लगभग ईमेल encryption का इस्तेमाल ही नहीं करते
    PGP इतना असुविधाजनक है कि tech enthusiasts के अलावा शायद ही कोई इसका उपयोग करता हो
    मेरा मानना है कि अब हमारे email भी encrypt होने चाहिए
    वैसे, अगर CA private key खुद बनाकर दे, तो मैं ऐसे certificate को भरोसेमंद नहीं मानता
    और S/MIME में पुराने email decrypt करने के लिए पुराने certificate संभालकर रखने पड़ते हैं, इसलिए बार-बार बदलने वाले certificate व्यावहारिक नहीं लगते

    • जहाँ तक यह बात है कि S/MIME में पुराने email decrypt करने के लिए पुराने certificate चाहिए, decrypt करने वाली key तो नए certificate भी पुरानी key से ही बनाई जा सकती है (जैसे certbot का --reuse-key option), इसलिए ज़रूरी नहीं कि उन्हें बार-बार बदला जाए
      हाँ, यह अच्छा तरीका है या नहीं, यह अलग सवाल है
      असल ज़रूरत ACME-style automated certificate issuance automation की है
      अभी renewal process इतनी असुविधाजनक है कि लोग इसका उपयोग ही नहीं करते

    • PGP में अब WKD(Web Key Directory)लिंक जैसा तरीका है, जिससे email पर TLS की trust web लागू की जा सकती है
      TLS certificate, S/MIME certificate की तुलना में पाना काफ़ी आसान है
      identity management किसी third party से कराना मददगार हो सकता है, लेकिन ज़्यादातर लोग ऐसी कंपनियों में काम करते हैं जहाँ ऐसी identity management अच्छी तरह फ़िट नहीं बैठती
      अगर company का मामला हो, तो identity management अंदरूनी तौर पर करना ज़्यादा उपयुक्त लगता है
      हाल की Signalgate 1.0 घटनालिंक को end-to-end encryption में identity management failure के उदाहरण के रूप में काफ़ी कुछ सीखने लायक मानता हूँ
      इसी वजह से लगता है कि अगर S/MIME certificate या WKD को सचमुच उपयोगी system के रूप में अपनाया जाए, तो सरकारों के लिए भी यह उपयोगी हो सकता है

    • व्यक्तिगत रूप से मैं S/MIME-आधारित email encryption की संभावना को अच्छा मानता हूँ, लेकिन इसकी व्यवहारिकता कम लगती है
      आम उपयोगकर्ता अक्सर private key manage करना भी मुश्किल पाते हैं, email password तक ठीक से संभालना कठिन होता है
      आख़िरकार या तो हर domain पर centrally certificate issuance करनी पड़ेगी, या फिर उपयोगकर्ता certificate ले ही नहीं पाएँगे, जबकि cyber criminals S/MIME-signed mail भेजने लगेंगे
      शायद जब passkey का उपयोग आम हो जाएगा और पीढ़ीगत बदलाव आएगा, तब लोगों को key pair सीधे संभालने देना अधिक उचित होगा

    • राय यह है कि email encryption को बस ख़त्म हो जाना चाहिए
      संदर्भ: Stop using encrypted email

    • मुझे S/MIME encryption के बारे में ज़्यादा जानकारी नहीं है, इसलिए एक सवाल है
      पुराने email को उसी protocol से decrypt करने की ज़रूरत क्यों होती है?
      व्यक्तिगत रूप से मैं certificate को transport के लिए मानता था, और actual storage के लिए server या host पर अलग encryption होती होगी, तो transmission के लिए short-lived certificate और storage के लिए मनचाही encryption जैसी अलग व्यवस्था तार्किक लगती है; शायद मैं कुछ मिस कर रहा हूँ

  • सोच रहा हूँ कि क्या सभी address-managing संस्थाएँ (जैसे ISP, cloud provider) भी इस दिशा में साथ आएँगी
    ये लोग कभी-कभी IP बहुत तेज़ी से rotate करते हैं, कभी 6 दिनों से भी जल्दी
    अगर cloud provider IP analysis से पहले cooldown period रखें या उस IP से जुड़े certificate को lookup और revoke करें तो बात समझ आती है, वरना user की ज़िम्मेदारी होगी कि host header validate करे, अनचाहे IP-based connection reject करे, या legacy certificate पूरी तरह ख़त्म होने तक इंतज़ार करे — यानी काफ़ी complexity
    यह भी जिज्ञासा है कि अलग-अलग cloud provider कितने IP certificate देंगे और किस कीमत पर

    • सच कहूँ तो यह cloud provider के custom/vanity domain देने से बहुत अलग नहीं लगता
      उदाहरण के लिए Azure में myapp.westus.cloudapp.azure.com जैसा DNS किसी VM से जोड़ा जा सकता है, और किसी भी व्यक्ति को CA से उस domain के लिए certificate मिल सकता है संदर्भ
      ऐसे मामलों में भी बिना किसी cooldown के, VM हटते ही कोई दूसरा व्यक्ति तुरंत वही domain ले सकता है

    • HTTPS certificate domain expire होने से एक दिन पहले 90 दिनों के लिए renew किया जा सकता है, और CA को payment card limit का भी पता नहीं होता
      IP certificate इस्तेमाल करने वाले लोग शायद उन उपयोगकर्ताओं जैसे नहीं होंगे जो जल्दी से IP छोड़कर चले जाते हैं
      सबसे उपयोगी मामले बहुत ही खास legacy software होंगे, या फिर Cloudflare जैसी स्थिति जहाँ shared IP के बिना ECH(Encrypted Client Hello) या ESNI(Encrypted SNI) support चाहिए
      पहले मामले में IP आसानी से छोड़ा नहीं जाएगा, और दूसरे मामले में लगता है कि actual domain तक connection स्थापित करना ही कठिन होगा

    • इस सवाल पर कि क्या ISPs को साथ आना चाहिए, मुझे तो उल्टा लगता है
      ISPs का काम TLS standard के हिसाब से IP allocate करना नहीं है; बल्कि TLS certificate provider को ecosystem में identity (domain, IP आदि) के mapping तरीके के अनुसार "identity validation" की भूमिका निभानी चाहिए
      इस बार यह कैसे किया जाएगा, इसकी पूरी जानकारी नहीं दी गई, लेकिन मेरा अंदाज़ा है कि LetsEncrypt ASNs(Autonomous System Numbers) के आधार पर लंबे समय तक IP transfer होने वाली सूची बनाएगा (शायद Mozilla Public Suffix List जैसे किसी public DB की तरह संयुक्त रूप से), और केवल उसी सूची के IP के लिए certificate जारी करेगा; दूसरे ASN में जाने पर certificate invalidation management जैसी व्यवस्था भी होगी
      उम्मीद है कि यह अन्य ACME issuers के साथ भी साझा किया जाएगा

    • अगर जिज्ञासा यह है कि अलग-अलग cloud पर IP certificate कितने मिलेंगे और किस कीमत पर, तो आगे चलकर wildcard certificate support भी आएगा या नहीं, यह भी दिलचस्प होगा

    • मेरी स्थिति में तो सिर्फ़ एक दिन के लिए भी IP certificate मिल जाए, तो https URL test कर सकता हूँ, इसलिए यह बदलाव बहुत स्वागतयोग्य लगता है

  • तकनीकी रूप से यह कैसे काम करता है, समझ आता है, लेकिन इसका असली intended use case क्या है, यह जानना चाहता हूँ

    • सिर्फ़ ECH(Encrypted Client Hello) या ESNI(Encrypted SNI) support के लिए भी यह काफ़ी महत्वपूर्ण है
      ESNI के शुरुआती दिनों में Cloudflare जैसे बड़े https proxy ही इसे लागू कर सकते थे, इसलिए IP certificate की शुरुआत किसी सपने जैसी लगती थी, लेकिन अब हर server ESNI/ECH में भाग ले सकता है
      अगर client यह मानकर ESNI आज़माने लगें कि हर server के पास IP certificate है, तो इससे पूरे internet की privacy बेहतर हो सकती है

    • कई जवाबों में अच्छे use case आए हैं, लेकिन NTS(Network Time Security) का भी ज़िक्र होना चाहिए
      अगर IP certificate न मिल सके, तो NTS के लिए भी DNS चाहिए, और DNS down हो जाए तो authenticated time sync पूरी तरह असंभव हो जाती है
      DNSSEC सही समय के बिना validate नहीं होता, और DNS+NTS dependency होने पर recovery असंभव हो सकती है
      अगर IP शामिल certificate से DNS के बिना authenticated time distribution संभव हो, तो यह समस्या हल हो सकती है

    • अगर DNS में बड़े बदलावों के दौरान भी valid certificate बनाए रखना हो, जैसे dashboard access सुनिश्चित करना या पुरानी automation को DNS error की वजह से रुकने से बचाना, तो इसका उपयोग हो सकता है
      एक और use case यह है कि DNS के बिना अधिक सरल तरीके से test environment तुरंत खड़ा करना, या Cockpit जैसी चीज़ों को जल्दी बाहरी तौर पर expose करना
      असल में कल्पना जितनी अनुमति दे, उतने उपयोग सामने आ सकते हैं

    • authdns(authenticated DNS server) के लिए 'opportunistic' DoTLS(TLS-based DNS query) में भी यह रोचक हो सकता है
      public IP को SAN(Subject Alternative Name) में शामिल certificate के साथ authenticated DNS server DoTLS port पर service दे सकता है
      आज भी hostname के साथ यह संभव है, लेकिन एक public IP पर कई अलग-अलग name हो सकते हैं, इसलिए IP-based SAN ज़्यादा स्पष्ट binding देता है

    • मुझे लगता है कि यह उन लोगों के लिए अच्छा है जो hobby या one-off project के लिए hostname की जगह सीधे IP पर service बाँधना चाहते हैं, बिना domain के

  • समझ नहीं आता कि internet regional registry(RIR) या local registry(LIR) खुद certificate क्यों नहीं जारी करते
    क्यों किसी third party को RIR, LIR registrant verify करना चाहिए? क्या domain registrars के पास बहुत ज़्यादा काम है?
    सोच रहा हूँ कि वजह वही है या कुछ और

  • ऐसा लगता है कि TLS के दुरुपयोग का एक नया रास्ता बढ़ गया है
    पहले तक समस्या उन domain के लिए certificate issue करने की थी जो आपके नहीं थे, अब शायद उन IP के लिए भी certificate संभव हो जाएँ जो आपके नहीं हैं
    black-hat hackers शायद Telegram पर खूब उत्साहित होंगे

    • दरअसल IP certificate पहले से मौजूद थे; नई बात सिर्फ़ यह है कि अब Let's Encrypt भी इन्हें देगा

  • क्या इससे local router (जैसे 192.168.0.1) के admin page पर self-signed error के बिना https access संभव होगा?

    • अभी नहीं, लेकिन शायद आगे हो सके
      local address सार्वभौमिक रूप से allocate नहीं होते और globally routable भी नहीं होते, इसलिए मूल रूप से verify करने का तरीका नहीं है
      लेकिन अगर router manufacturer चाहे, और device CG-NAT के पीछे न हो तथा उसे public IPv4 address मिला हो, तो public address के लिए certificate माँगना संभव है
      IPv6 तो ज़्यादातर global routing में आता है, इसलिए और भी आसान होगा

    • नहीं, और ऐसा होना भी नहीं चाहिए
      व्यवहार में proxy, वास्तविक domain, असली certificate, और DNS rewrite का संयोजन करके यह पूरी तरह संभव है
      उदाहरण के लिए nginx manager UI और DNS के रूप में adguard
      router का DNS adguard तक सीमित रखें, अपने domain को proxy पर rewrite करें
      domain register करें और वास्तविक certificate जारी करवाएँ, समस्या हल हो जाएगी
      मैं भी अपनी सभी local services को https पर चलाता हूँ

    • private IP के लिए certificate जारी नहीं किए जाएँगे
      एक ही private IP अलग-अलग network में हर बार बिल्कुल अलग device का हो सकता है, इसलिए exclusive ownership सुनिश्चित नहीं की जा सकती

    • बात उलटी है
      अगर public IP नहीं है, तो valid certificate issue नहीं होगा
      पहले से domain certificate लेकर उस domain को 192.168.0.1 पर forward करने का तरीका मौजूद है

    • certificate पाने के लिए उस IP (public IP) का वास्तविक ownership होना चाहिए

  • क्या internal IPv4 (192.168.x.x, 172.16.x.x, 10.x.x.x) के लिए भी certificate संभव होंगे, या browser का ऐसे address को नज़रअंदाज़ करना सही है? और अगर नहीं, तो क्या internal network के लिए wildcard certificate मिल सकता है?

    • public CA द्वारा जारी certificate के संदर्भ में यह सवाल अर्थपूर्ण नहीं लगता
      10.10.10.10 जैसे private IP, domain के उलट, एक ही समय में अनगिनत लोग "own" करते हैं
      internal development के लिए mkcert जैसे tool हैं, और company के अंदर shared resource के लिए domain-based TLS certificate ज़्यादा आसान है

    • अगर आप साबित कर सकें कि device की private key कभी leak नहीं होगी, तो शायद मौजूदा CA के साथ भी कोशिश की जा सकती है
      लेकिन internal address certificate के मामले में, अगर कोई device खरीदकर private key निकाल ले, तो तुरंत certificate key revocation की समस्या खड़ी हो जाती है
      इसलिए अगर device विश्वसनीय हैं, तो manually certificate import करके बिना error access करना, या कई device हों तो अपना CA बनाकर certificate distribute करना अधिक व्यावहारिक है
      open source ACME server के साथ Let's Encrypt जैसी automated issuance अंदरूनी नेटवर्क में भी संभव है

    • DNS को पहले public server पर point करके certificate जारी करवाना, फिर DNS को internal 192.168… address पर वापस देना और certificate व key कॉपी करना भी एक तरीका है
      ध्यान रहे कि कुछ router internal address की ओर forward होने वाले DNS response को blackhole कर सकते हैं, इसलिए पहले test ज़रूर करें

    • मुझे नहीं लगता कि browser को private network को ignore करना चाहिए
      मेरे लिए private network का मतलब शायद सिर्फ़ local router है, लेकिन किसी और के लिए वह पूरी दुनिया में फैला network भी हो सकता है

  • उदाहरण certificate में subject field का न होना दिलचस्प है
    क्या यह इसलिए है क्योंकि request IP के लिए थी और SAN में DNS लिखा हुआ है?

    • Let's Encrypt team के अनुसार, आगे चलकर वे subject common name की जगह केवल subject alternative names का ही उपयोग करना चाहते हैं
      6-दिन वाले short-lived certificate profile में यह पहले से लागू हो चुका है, जबकि "classic" 90-दिन वाले profile में अभी नहीं

  • मज़ाक में कहा गया कि शायद CVE-2010-3170 vulnerability फिर चर्चा में आने का समय है

    • अगर कोई खुद X.509 validation logic implement करे, तो ऐसी vulnerability बची रह सकती है, लेकिन व्यवहार में इसका फायदा उठाने के लिए किसी ग़लत काम करने वाले CA को ऐसा certificate जारी करना होगा, इसलिए संभावना कम लगती है

  • दुर्भाग्य से IP address के लिए certificate, DNS challenge तरीके से issue नहीं किए जा सकते
    लेकिन क्यों नहीं किए जा सकते, यह समझ आता है