NGINX ने ACME प्रोटोकॉल के लिए नेटिव सपोर्ट जोड़ा

 (blog.nginx.org)
5 पॉइंट द्वारा GN⁺ 2025-08-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • NGINX ने SSL/TLS सर्टिफिकेट जारी करने और रिन्यूअल को ऑटोमेट करने वाले ACME प्रोटोकॉल के लिए नेटिव सपोर्ट वाली एक प्रीव्यू रिलीज़ पेश की है
  • Rust-आधारित नए मॉड्यूल ngx_http_acme_module के जरिए अब बाहरी टूल के बिना, सिर्फ NGINX कॉन्फ़िगरेशन से सर्टिफिकेट रिक्वेस्ट, इंस्टॉलेशन और रिन्यूअल किया जा सकता है
  • इससे Certbot जैसे बाहरी टूल पर निर्भरता घटती है और सुरक्षा व प्लेटफ़ॉर्म स्वतंत्रता बढ़ती है
  • शुरुआती वर्ज़न में HTTP-01 challenge का सपोर्ट है, जबकि TLS-ALPN और DNS-01 सपोर्ट बाद में जोड़े जाने की योजना है
  • उम्मीद है कि ACME सपोर्ट वेब के अलावा IoT और edge computing environments में भी security automation में महत्वपूर्ण भूमिका निभाएगा

अवलोकन और मुख्य बदलाव

  • NGINX ने ACME प्रोटोकॉल सपोर्ट फीचर का प्रीव्यू वर्ज़न जारी किया है
  • नए मॉड्यूल ngx_http_acme_module के जरिए NGINX कॉन्फ़िगरेशन के भीतर ही सर्टिफिकेट रिक्वेस्ट, इंस्टॉलेशन और रिन्यूअल को सीधे संभालने के लिए इसे डिज़ाइन किया गया है
  • यह ACME सपोर्ट अंदरूनी तौर पर NGINX-Rust SDK का उपयोग करता है और Rust-आधारित dynamic module के रूप में उपलब्ध कराया गया है
  • इस फीचर का उपयोग सिर्फ open source users ही नहीं बल्कि NGINX Plus enterprise customers भी कर सकते हैं
  • Certbot जैसे मौजूदा बाहरी टूल पर निर्भरता कम करके यह सर्टिफिकेट मैनेजमेंट की सुरक्षा और दक्षता बढ़ाता है

ACME प्रोटोकॉल परिचय

  • ACME(Automated Certificate Management Environment) प्रोटोकॉल एक communication protocol है जो SSL/TLS सर्टिफिकेट के issuance, validation, renewal और revocation को ऑटोमेट करता है
  • क्लाइंट CA(Certificate Authority) के साथ automated communication के जरिए बिना किसी मध्यस्थ के manual work के सीधे सर्टिफिकेट lifecycle को मैनेज कर सकता है
  • इसे Internet Security Research Group(ISRG) ने 2015 में Let’s Encrypt प्रोजेक्ट के रूप में विकसित और सार्वजनिक किया था
  • ACME के आने से पहले सर्टिफिकेट जारी करने की प्रक्रिया मैनुअल थी और इसमें लागत व त्रुटि की संभावना अधिक होती थी
  • नवीनतम ACMEv2 में authentication methods, wildcard support जैसी कई सुविधाएँ जोड़ी गई हैं, जिससे इसकी flexibility और security बढ़ी है

NGINX में ACME-आधारित सर्टिफिकेट automation flow

  • NGINX में ACME प्रोटोकॉल का उपयोग करके सर्टिफिकेट lifecycle automation नीचे दिए गए 4 चरणों में होता है

  • 1. ACME server configuration

    • ACME फीचर को सक्रिय करने के लिए acme_issuer के साथ ACME server की directory URL को अनिवार्य रूप से निर्दिष्ट करना होता है
    • सर्टिफिकेट issue होने के समय client contact information, state data storage path जैसी चीज़ें भी विकल्प के रूप में दी जा सकती हैं

  • 2. shared memory(zone) allocation

    • acme_shared_zone के जरिए सर्टिफिकेट, private key और challenge data को स्टोर करने के लिए shared memory zone अलग से कॉन्फ़िगर की जा सकती है
    • इसका डिफ़ॉल्ट आकार 256K है और आवश्यकता के अनुसार इसे बढ़ाया जा सकता है

  • 3. challenge configuration

    • मौजूदा प्रीव्यू वर्ज़न केवल HTTP-01 challenge को सपोर्ट करता है, जिसका उपयोग domain ownership verification के लिए होता है
    • इसके लिए NGINX कॉन्फ़िगरेशन में port 80 listener और default 404 response setting को परिभाषित करना होता है
    • आगे चलकर TLS-ALPN, DNS-01 challenge का सपोर्ट जोड़ा जाएगा

  • 4. सर्टिफिकेट जारी करना और रिन्यूअल

    • server block में acme_certificate directive जोड़ने पर संबंधित domain के लिए TLS सर्टिफिकेट issuance/renewal को ऑटोमेट किया जा सकता है
    • सर्टिफिकेट के target domain को आमतौर पर server_name से निर्दिष्ट किया जाता है
    • server_name में regular expression और wildcard का सपोर्ट प्रीव्यू वर्ज़न में नहीं है
    • मॉड्यूल के भीतर $acme_certificate, $acme_certificate_key variables के जरिए सर्टिफिकेट और key अपने-आप लिंक हो जाते हैं

मुख्य फायदे

  • दुनिया भर में HTTPS उपयोग में तेज़ बढ़ोतरी के केंद्र में ACME प्रोटोकॉल रहा है
  • ऑटोमेटेड सर्टिफिकेट मैनेजमेंट से सर्टिफिकेट lifecycle management की लागत और manual errors में उल्लेखनीय कमी आती है
  • बाहरी टूल हटने से attack surface कम होता है और portability बढ़ती है
  • विभिन्न environments में security standardization को बढ़ावा मिलता है

आगे की योजना

  • TLS-ALPN और DNS-01 challenge सपोर्ट जोड़ा जाएगा
  • user feedback के आधार पर फीचर का विस्तार किया जाएगा
  • IoT, API, edge computing को अपनाने का दायरा बढ़ने के साथ ACME के भविष्य में और व्यापक automated security infrastructure में मुख्य भूमिका निभाने की उम्मीद है
  • NGINX का नेटिव ACME सपोर्ट वेब security, automation और scalability को भविष्य के standard के रूप में स्थापित करने की दिशा में आधारभूत भूमिका निभाएगा

शुरुआत करें

  • open source users NGINX Linux पैकेज से prebuilt module का उपयोग कर सकते हैं
  • NGINX Plus enterprise customers को यह F5-supported dynamic module के रूप में उपलब्ध है
  • मॉड्यूल डॉक्यूमेंटेशन के लिए NGINX Docs देखें

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

1 टिप्पणियां

 
GN⁺ 2025-08-14
Hacker News राय
  • मौजूदा preview version में क्लाइंट domain ownership verify करने के लिए सिर्फ HTTP-01 challenge का support है
    DNS-01 तरीका उन nginx users के लिए कहीं ज़्यादा मायने रखता है जिनका setup publicly open नहीं है (जैसे Nginx Proxy Manager इस्तेमाल करते समय)। DNS-01 में सिर्फ record update करना होता है, इसलिए मुझे हमेशा लगा है कि यह सबसे साफ-सुथरा तरीका है। मैं सच में इस feature के आने का इंतज़ार कर रहा हूँ
    • लेकिन इसके लिए dns api key होना ज़रूरी है, और बहुत से dns providers zone-by-zone अलग api key नहीं देते। मुझे व्यक्तिगत रूप से DNS-01 पसंद है, लेकिन practically शायद थोड़ा निराशाजनक compromise करना पड़ सकता है
    • इंतज़ार करने की ज़रूरत नहीं है: angie में भी support है (angie, f5 छोड़ने वाले मूल nginx developers द्वारा बनाया गया nginx fork है)
    • Traefik के ACME support की एक कमी यह है कि हर DNS provider के लिए सिर्फ एक api key इस्तेमाल की जा सकती है। इस वजह से domain के हिसाब से api key सीमित करना, या कई accounts के domains इस्तेमाल करना, काफी restrictive हो जाता है। उम्मीद है Nginx में यह limitation नहीं होगी
    • मैं व्यक्तिगत रूप से homelab में step-ca और caddy का combo लेकर dns01 इस्तेमाल कर रहा हूँ। अनुभव बहुत संतोषजनक है
    • DNS-01 का support बहुत अच्छा है, इसलिए Angie पर switch करना भी recommend करूँगा
  • यह काफ़ी बड़ा बदलाव है। Caddy में यह पहले से था, लेकिन हर कोई caddy को पसंद नहीं करता। यह upgrade Traefik जैसे software का market share खींच सकता है
    • मुझे Caddy की साफ़-सुथरी syntax खास तौर पर पसंद है। अभी मैं nginx (nginx proxy manager के ज़रिए) और Traefik इस्तेमाल करता हूँ, लेकिन हाल में Caddy के साथ एक project किया और अनुभव बहुत smooth था। आगे समय मिला तो अपने selfhosted environment को Caddy पर migrate करना चाहूँगा। या शायद pangolin जैसा कुछ इस्तेमाल करूँ। pangolin, cloudflare tunnels का alternative भी देता है
    • मैं हाल ही में पूरी तरह caddy पर आ गया। nginx के http 1 desync issue पर उसके passive response ने निर्णायक भूमिका निभाई। मुझे यह पसंद नहीं कि issue होने तक इंतज़ार करना पड़े, या auditor पूछे तब भी nginx की ओर से साफ़ जवाब न मिले।
      Caddy, nginx से साफ़ तौर पर आसान है। यह कई services, testing, और educational institutions के लिए special services तक cover करने वाले templates, बेहतर logging, मेरे लिए perfect certificate handling, और बेहतर metrics features देता है।
      हालांकि plugin side अभी भी सीख रहा हूँ, और caddy में rate limiting नहीं है, इसलिए powerbi के bug की वजह से एक खास user द्वारा images को दिन में 3 लाख बार request किए जाने जैसी situation में दिक्कत होती है
    • मुझे भी बिल्कुल ऐसा ही लगता है। घर में traefik कुछ जगह इस्तेमाल कर रहा हूँ, लेकिन अब शायद इसे तुरंत replace कर दूँगा
  • यह स्वागतयोग्य बदलाव है। Dokku (जिसका मैं maintainer हूँ) अभी letsencrypt plugin के साथ एक workaround इस्तेमाल करता है, और users को अक्सर random issues झेलने पड़ते हैं। nginx का reload के दौरान कभी-कभी "रुक जाना" और endpoints न मिलना भी होता है। ऐसे moving parts जितने कम हों, उतना बेहतर है
    लेकिन Ubuntu या Debian के stable repository में यह feature आने में अभी काफ़ी समय लगेगा।
    और अभी DNS challenge (wildcard certificates) का support नहीं है, इसलिए short term में शायद Dokku के लिए बहुत मददगार नहीं होगा
    • नमस्ते! आपको यहाँ देखकर अच्छा लगा
      मैं dokku को आज़मा रहा हूँ (और अभी भी आज़मा रहा हूँ), लेकिन इसका entry barrier काफ़ी ऊँचा लगा
      उदाहरण के लिए, Coolify में github app बनाते ही deployment link हो जाता था, और GH actions के साथ container build/deploy करने का अनुभव भी है।
      dokku की official docs ज़्यादा reference material जैसी लगती हैं, जैसे encyclopedia पढ़ रहे हों: dokku git initialization official docs
      Coolify की तरह सीधे deploy कराने वाली immediate guidance ज़्यादा उपयोगी लगती है: coolify github integration help
      अच्छा होता अगर Dokku के लिए popular OSS apps install करना, step-by-step goal/completion style की beginner guide, और baremetal environment में reverse proxy व कई popular apps को एक साथ कवर करने वाला tutorial होता
      आखिर Dokku इस्तेमाल करने का मकसद Dokku खुद नहीं है, बल्कि Dokku के ज़रिए जल्दी और आसानी से "मैं जो state चाहता हूँ" वहाँ पहुँचना है
      अंततः मैं ऐसा painless process चाहता हूँ जहाँ "पसंद की repo पर क्लिक करो और वह सीधे मेरी machine पर deploy हो जाए"। उसके बाद backend details में जाना चाहूँगा
  • यह अच्छी खबर है। जिन्हें पता न हो, उनके लिए dehydrated नाम का एक आसान solution पहले से था। बस vhost config में कुछ lines जोड़नी होती हैं: 
      location ^~ /.well-known/acme-challenge/ {  
    alias ;  
  }
    dehydrated लंबे समय से HTTP-01 renewal automation के लिए इस्तेमाल होने वाला हल्का tool है
    • feature अपने आप में वाकई शानदार है, लेकिन यह अफ़सोस की बात है कि हज़ारों लोगों द्वारा निर्भर किए जाने वाला project लगातार Stable release नहीं देता
      v1.0.0 official release के बिना software का interface कभी भी बिना सूचना बदल सकता है। major version 0 कभी न कभी जाल साबित होता है।
      maintainers से stable version release की माँग करनी चाहिए।
      dehydrated पिछले 7 साल से major version 0 पर है
      0ver.org भी देखने लायक है:
      इसकी versioning philosophy कुछ ऐसी है कि "अगर आप इसे production में इस्तेमाल कर रहे हैं, तो इसे पहले ही 1.0.0 होना चाहिए"
      ज़्यादा जानकारी के लिए यहाँ देखें
  • इस release में एक छोटी चूक हुई: ngx_http_acme_module कई Linux distribution packages में शामिल हुआ, लेकिन Debian stable इसमें नहीं है
    nginx official package list के अनुसार oldstable/oldoldstable तो हैं, लेकिन 4 दिन पहले रिलीज़ हुआ Debian 13 Trixie नहीं है
    • अभी Trixie package upload का काम चल रहा है। इस हफ़्ते के भीतर आ जाएगा। Debian 13 को रिलीज़ हुए सिर्फ 4 दिन हुए हैं, इसलिए नए OS के लिए infrastructure setup में समय लगा। (मैं F5 में काम करता हूँ)
    • शायद वह Debian की तरफ़ की गलती होगी
  • Caddy के बारे में जानने के बाद से मैं nginx इस्तेमाल नहीं करता। developer experience बहुत बेहतर है
  • बड़े open source संगठनों की समस्या यह है कि वे हमेशा ‘basic innovation’ को समझने और लागू करने में देर कर देते हैं
    Caddy और Traefik जो 5 साल पहले कर चुके थे, nginx अब जाकर support कर रहा है।
    फिर भी, मुझे यह अच्छा बदलाव लगता है। अब certbot को खुद चलाने की ज़रूरत नहीं रहेगी, तो सुविधा होगी
    • दरअसल Caddy ने लगभग 10 साल पहले, 2016 में ही Let’s Encrypt के automatic HTTPS का कुछ हद तक support दे दिया था।
      इस हिसाब से Nginx यह feature लगभग 9~10 साल देर से ला रहा है
  • व्यक्तिगत रूप से मुझे कभी ऐसा नहीं लगा कि nginx सिर्फ web content serve करे और certbot renewal संभाले, इसमें कोई दिक्कत है
    मुझे अब भी लगता है कि Unix philosophy, यानी एक काम अच्छे से करो और tools को जोड़कर इस्तेमाल करो, बेहतर है
    हर feature को एक ही ‘tool’ में ठूँस देने से कहीं न कहीं कमी रह ही जाती है
    • certbot के साथ setup करना काफ़ी झंझट भरा अनुभव है
      certbot auto-configure की कोशिश करता है, लेकिन ज़्यादातर non-default environments में ठीक से काम नहीं करता
      nginx के अंदर ही सब कुछ handle हो जाए, यह उल्टा बेहतर solution लगता है
  • यानी मैं इसे ऐसे समझ रहा हूँ कि इस feature के आने से nginx config file में बस कुछ lines जोड़कर certbot को install/run करने की ज़रूरत नहीं रहेगी
    साथ ही, क्या इससे Let's Encrypt के अलावा दूसरे alternatives इस्तेमाल करना भी आसान हो जाएगा?
  • यह बदलाव उत्साहजनक है
    Caddy में out-of-the-box convenience features बहुत हैं, इसलिए वह वाकई उपयोगी है
    व्यक्तिगत रूप से मैं Caddy पर पूरी तरह switch नहीं कर पाया हूँ क्योंकि मुझे nginx के rate limiting और geo modules की ज़रूरत है