Let's Encrypt ने 6-दिन वाले और IP address certificates की सामान्य उपलब्धता शुरू की

 (letsencrypt.org)
14 पॉइंट द्वारा GN⁺ 2026-01-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Let's Encrypt ने 6-दिन की वैधता वाले short-lived certificates और IP address-आधारित certificates की औपचारिक उपलब्धता शुरू की
  • short-lived certificates 160 घंटे (लगभग 6 दिन 16 घंटे) तक वैध रहते हैं, और ACME client में ‘shortlived’ profile चुनकर जारी किए जा सकते हैं
  • इन certificates का उद्देश्य ज़्यादा बार renew करने के लिए प्रोत्साहित करके security मज़बूत करना और कम विश्वसनीय revocation प्रक्रिया पर निर्भरता घटाना है
  • IP address certificates IPv4 और IPv6 दोनों को support करते हैं, और IP addresses की अधिक परिवर्तनशीलता के कारण केवल short-lived certificate रूप में ही जारी किए जाते हैं
  • इस कदम को स्वचालित certificate renewal प्रणाली के प्रसार और security सुदृढ़ीकरण के लिए चरणबद्ध बदलाव के रूप में देखा जा रहा है

short-lived (6-दिन) certificates की उपलब्धता

  • short-lived certificate 160 घंटे तक वैध रहता है, जो मौजूदा 90-दिन certificate की तुलना में बहुत कम अवधि है
    • ACME client में ‘shortlived’ certificate profile चुनने पर इसे जारी किया जा सकता है
  • यह certificate अधिक बार verification की मांग करके security बढ़ाता है, और revocation system की अस्थिरता की समस्या को कम करता है
    • पहले private key लीक होने पर certificate revocation की आवश्यकता होती थी, लेकिन revocation प्रक्रिया विश्वसनीय न होने से expiry तक कमजोरी बनी रह सकती थी
    • short-lived certificates के उपयोग से यह कमज़ोर अवधि काफ़ी घट जाती है
  • short-lived certificates वैकल्पिक (opt-in) हैं, और इन्हें default बनाने की कोई योजना नहीं है
    • जिन users ने automatic renewal process पूरी तरह स्थापित कर ली है, वे आसानी से इस पर स्विच कर सकते हैं
    • लेकिन यह ध्यान में रखते हुए कि सभी users इतनी छोटी validity के अभ्यस्त नहीं हैं, default यथावत रखा जाएगा
  • आने वाले कुछ वर्षों में default certificate validity को 90 दिन से घटाकर 45 दिन करने की योजना है

IP address certificates

  • IP address certificate से domain name के बजाय IP address के जरिए TLS connection को प्रमाणित किया जा सकता है
    • IPv4 और IPv6 दोनों supported हैं
  • IP address certificates को अनिवार्य रूप से केवल short-lived certificate रूप में जारी किया जाता है
    • कारण यह है कि IP address, domain की तुलना में अधिक बार बदलते हैं, इसलिए बार-बार verification आवश्यक है
  • संबंधित विस्तृत जानकारी और use cases जुलाई 2025 में प्रकाशित पहले IP certificate पोस्ट में देखे जा सकते हैं

समर्थन और प्रायोजन

  • यह विकास Open Technology Fund, Sovereign Tech Agency, तथा sponsors और donors के समर्थन से संभव हुआ
  • Let's Encrypt एक मुफ़्त, automated, open certificate authority (CA) है, जिसे गैर-लाभकारी संस्था Internet Security Research Group (ISRG) संचालित करती है
  • ISRG की 2025 annual report में उसकी व्यापक गैर-लाभकारी गतिविधियों को देखा जा सकता है

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

1 टिप्पणियां

 
GN⁺ 2026-01-17
Hacker News टिप्पणियाँ

  • आज की तारीख में certbot से IP address certificate नहीं मिल पाया
    इसकी जगह lego का इस्तेमाल किया, लेकिन सही command ढूँढने में काफ़ी समय लगा
    कल जो command सफल रही, वह यह थी
    lego --domains 206.189.27.68 --accept-tos --http --disable-cn run --profile shortlived

    • सोचा कि क्या Caddy में भी यह feature supported है
      लगता है अभी काम चल रहा है (GitHub issue)

  • IP address certificate खास तौर पर तब दिलचस्प है जब iOS users खुद अपना DoH server चलाते हैं
    iOS में इसे काम करने के लिए FQDN और IP दोनों के लिए सही certificate चाहिए था
    इसलिए dns4eu या nextdns जैसी बड़ी services के profiles तो ठीक चलते थे, लेकिन किसी व्यक्ति द्वारा बनाया गया DoH server fail हो जाता था

    • OpenSSL TLS connection के समय सख्ती से मांग करता है कि certificate के SAN field में IP address शामिल हो
      शायद यह iOS engineer ने जानबूझकर नहीं जोड़ा, बल्कि इस्तेमाल हो रही cryptography library का side effect हो सकता है
    • मैं खुद reverse proxy के पीछे अपने personal domain को DoH के लिए रोज़ाना इस्तेमाल करता हूँ और कोई समस्या नहीं है

  • जिज्ञासा थी कि certificate की अवधि 6 दिन ही क्यों रखी गई
    8 दिन होते तो weekly renewal के लिए बेहतर लगता, और 8 2 की power भी है और lucky number भी
    लेकिन 6 बस अच्छा नहीं लगता

    • 6 दिन का cycle रखने से लंबे समय में load हफ्ते के दिनों में बराबर distribute होता है
      8 दिन होने पर traffic किसी खास weekday पर जमा हो सकता है
    • असल में यह 6 दिन नहीं बल्कि लगभग 160 घंटे (6.6 दिन) है
      160 पहले 11 prime numbers का sum है, और पहले तीन prime numbers के cubes का sum भी है
    • 6 दिन का एक धार्मिक प्रतीक भी है कि ईश्वर ने 6 दिन काम किया और 7वें दिन विश्राम किया
    • 6 सबसे छोटा perfect number है, इसलिए पूर्णता का प्रतीक है

  • अगला फ़ोकस .onion addresses के लिए certificate जारी करने पर होना चाहिए
    .onion के पास पहले से key pair होता है, इसलिए ownership proof DNS से भी ज़्यादा भरोसेमंद हो सकता है

    • संबंधित standards और sites
    • लेकिन Tor खुद ही encryption और identity verification देता है, इसलिए HTTPS ज़रूरी ही हो, ऐसा नहीं लगता

  • अगर IP certificate चाहिए तो certbot अभी support नहीं करता
    इस पर PR खुला है (#10495)
    जबकि acme.sh शायद पहले से support करता है

    • इस समय IP address support करने वाले ACME clients में acme.sh, lego, traefik, acmez, caddy, cert-manager शामिल हैं
      उम्मीद है certbot भी जल्द support करेगा

  • मैं 2 हफ़्ते के renewal cycle पर test कर रहा था, लेकिन अब certificate 6 दिन का निकलने लगा, तो थोड़ा घबरा गया
    अगर pipeline fail हो जाए तो debugging के लिए बहुत कम समय बचता है
    यह मानना मुश्किल है कि IP domain से ज़्यादा volatile है
    VPS का static IP इतनी बार नहीं बदलता

    • लेकिन AWS जैसी जगहों पर Elastic IP तुरंत release किया जा सकता है
      अगर 45 दिन का certificate लेकर तुरंत IP छोड़ दिया जाए, तो वह IP किसी दूसरे user को मिल सकता है
      तब आपके पास किसी और के IP के लिए valid certificate रह जाएगा, जो जोखिम भरा है
    • cloud environments में IP जल्दी reassign हो जाते हैं, इसलिए 6 दिन भी लंबा माना जा सकता है
    • certificate की बहुत छोटी lifetime वास्तविक operations के तरीकों से मेल नहीं खाती
      ऐसी policy देखकर लगता है कि ground-level practical काम की समझ कम है
    • असली मुद्दा IP पर ownership control का है
      ज़्यादातर service operators खुद IP को सीधे control नहीं करते, इसलिए यह CA के risk को कम करने का उपाय है
    • अगर EC2 instance पर EIP attach न किया जाए, तो restart पर लगभग हमेशा अलग IP मिलता है
      इसका दुरुपयोग आसान नहीं है, लेकिन फिर भी security के लिहाज़ से सोचने वाली बात है

  • सोचा कि IP address certificate आने के बाद IPsec transport mode फिर से ध्यान खींच सकता है या नहीं
    मेरे द्वारा लिखा गया RFC 5660 भी इससे जुड़ा है

    • लेकिन व्यवहार में SDN या site-to-site VPN पहले से काफ़ी प्रचलित हैं
      IPsec tunnel में certificate इस्तेमाल कराना अब भी झंझट भरा है
      कुछ firewall devices में certificate chain लंबी होने पर authentication fail करने वाले अजीब bugs भी हैं
    • IPSec standard बहुत बड़ा और जटिल है, और इसे बनाने वाली कंपनियाँ भी दशकों तक CVE पाती रही हैं

  • IP certificates सिर्फ़ internet से पहुँचने योग्य addresses के लिए संभव हैं, इसलिए LAN devices के लिए TLS अभी भी मुश्किल है

    • IPv6 इस्तेमाल करें तो external exposure के बिना भी यह संभव है
      edge पर DNAT से traffic लेकर उसे certificate renewal VM तक पहुँचाया जा सकता है, फिर अंदरूनी devices में बाँटा जा सकता है
    • मैं अपने home network के लिए wildcard certificate(*.home.example.com) इस्तेमाल करता हूँ
      इसके लिए ऐसा public DNS चाहिए जिसमें TXT record को API से सेट किया जा सके, और lego के DNS plugins कई providers को support करते हैं
    • ऐसे मामलों में private CA का इस्तेमाल भी एक तरीका है
    • internal network addresses के लिए बाहर से ownership proof नहीं दिया जा सकता, इसलिए सिर्फ domain इस्तेमाल करना बेहतर लगता है

  • यह announcement सच में बहुत स्वागतयोग्य है
    IP certificate self-hosted software की शुरुआती bootstrap problem हल करने में मदद करता है
    उदाहरण के लिए, TakingNames का instant subdomains feature शायद अब ज़रूरी न रहे

  • IP address certificate ephemeral services के TLS communication में उपयोगी हैं
    अलग से DNS records बनाने की ज़रूरत नहीं होती, इसलिए सैकड़ों temporary instances चलाने में सुविधा होती है

    • यह Encrypted Client Hello(ECH) में भी काम आ सकता है
      plaintext में दिखने वाले SNI की जगह IP certificate इस्तेमाल करने पर बाहर से असली hostname दिखाई नहीं देगा
      इससे छोटी sites भी, बड़े cloud के बिना और proxy के बिना, ECH इस्तेमाल कर सकेंगी
    • Let's Encrypt की आधिकारिक घोषणा में कई use cases दिए गए हैं
    • registrar dependency न होना एक आकर्षक बात है
      इससे anonymity भी बढ़ती है
    • अगर service इंसानों के लिए नहीं है, तो nameserver dependency हटाना खास तौर पर उपयोगी है
    • इसे DNS over TLS या DNS over HTTPS जैसे protocols पर भी लागू किया जा सकता है