Certbot: Nginx प्लगइन में HTTP2 समर्थन

#3640 . से

वर्तमान में nginx प्लगइन जोड़ता है:
listen 443 ssl; # managed by Certbot

HTTP 2 के लिए एक विकल्प अच्छा होगा, या तो --http2 ध्वज निर्दिष्ट करके या संगतता के लिए nginx की जांच करें।

listen 443 ssl http2;
listen [::]:443 ssl http2;

मुद्दे पर कोई प्रगति? यदि मैं हाथ से http2 जोड़ता हूं, तो क्या इसे नवीनीकरण पर मिटा दिया जाएगा?

नहीं. certbot renew के साथ अपने प्रमाणपत्र का नवीनीकरण करने से इन पंक्तियों में कोई परिवर्तन नहीं होगा.

इसके बारे में बस मेरी समस्या की जाँच की और देखा कि यह 22 घंटे पहले बंद हो गया था।

मुझे लगता है कि खबर है कि फीचर जोड़ा गया था, यहां प्रकाशित किया जाएगा, सबसे पहले और सबसे महत्वपूर्ण?

आश्चर्यजनक रूप से, rgrep -il http2 certbot-nginx कुछ भी नहीं लौटाता है। इसलिए इसे अभी तक लागू नहीं किया गया है।

@benqzq , हाँ। इस पर प्रगति की कोई भी खबर यहां जोड़ी जाएगी। Let's Encrypt के कम्युनिटी फोरम के विषय 30 दिनों तक बिना किसी गतिविधि के अपने आप बंद हो जाते हैं।

मेरा सुझाव है कि --lhttp ( l का अर्थ "नवीनतम") है, इसलिए हम इसे http के विशिष्ट संस्करण में लॉक नहीं करेंगे। हालांकि l भ्रमित करने वाला हो सकता है (शायद --LH ?)।

@benqzq साधारण चीजों को जटिल क्यों बना रहा है? --http2 स्वयं व्याख्यात्मक है

• डिफ़ॉल्ट व्यवहार http2 बंद है
• --http2 http2 को चालू करता है

कभी-कभी आपको इसकी आवश्यकता होती है, कम से कम थोड़ी, लेकिन वैसे भी, मैं एक सामान्य संकेतन के लिए तैयार हूं। या तो अच्छा आईएमएचओ है ( --http2 या सामान्य नोटेशन जैसा कि मैंने सुझाव दिया है)।

यह इतना महत्वपूर्ण टूल है, काश कोई इसे पहले ही जोड़ लेता...

बस यह देखते हुए कि मैं इसे कैसे स्वचालित करता हूं जब तक कि कोई तर्क उपलब्ध न हो:

sed -i "s/listen 443 ssl;/listen 443 ssl http2;/" /etc/nginx/sites-available/$domain.conf

क्या अभी भी http2 को सर्टिफिकेट के साथ सक्षम करने का कोई तरीका नहीं है? क्या किसी के पास कोई उपाय है?

@KyleTryon मैंने ऊपर अपना sed वर्कअराउंड दिया, लेकिन ऐसा लगता है कि अभी भी कोई आधिकारिक तरीका नहीं है। मैं ये समझ नहीं सकता।

@bendqh कि कोई आप हो सकता है!

हैरानी की बात यह है कि यह फीचर अभी तक जोड़ा नहीं गया है। :-)

@yw662 , क्या आप इसके लिए पुल अनुरोध सबमिट करने में रुचि रखते हैं?

इसे हल करना आसान है इसलिए …… आप जानते हैं, अगर केवल मेरे पास इसके लिए समय हो। मुझे लगता है कि यही समस्या है। चारों ओर काम आसान है, लेकिन स्क्रिप्ट को बदलना उतना आसान नहीं है :-)।

2019 के लिए टक्कर।

0 0,12 * * * certbot renew --quiet
1 0,12 * * * sed -i "s/listen 443 ssl;/listen 443 ssl http2;/" /etc/nginx/sites-available/default
2 0,12 * * * sed -i "s/443 ssl ipv6only=on;/443 ssl http2 ipv6only=on;/" /etc/nginx/sites-available/default
3 0,12 * * * systemctl nginx reload

--http2 बहुत आसान लगेगा...

@rowan-OzRunways क्या यह https://github.com/certbot/certbot/issues/3646#issuecomment -323814774 आपके लिए मान्य नहीं है? बस एक बार हाथ से http2 संलग्न करें और इसे नवीनीकरण पर स्पर्श नहीं किया जाना चाहिए।

हम्म मुझे लगा कि यह साफ हो गया है। यह एक बार स्पष्ट हो गया लेकिन वह certbot-auto हो सकता है धन्यवाद मैं जांच करूंगा।

:+1: :+1: :+1: टक्कर
यह मेरा जन्मदिन है कृपया इसे जोड़ें धन्यवाद

यह आश्चर्यजनक है कि कितने डेवलपर्स प्रमाण पत्र का मैन्युअल रूप से अनुरोध करने और अपनी आवश्यकताओं के लिए एक Nginx सर्वर ब्लॉक को सिलाई करने के बजाय अस्पष्ट (स्वचालित) कॉन्फ़िगरेशन पर भरोसा करते हैं ...

डिफ़ॉल्ट व्यवहार http2 बंद है
--http2 http2 को चालू करता है

यह एक बुरा विचार है क्योंकि यह ऑनलाइन कॉपी-पेस्ट किए गए ट्यूटोरियल के वर्षों में बदल जाएगा, जो मानते हैं कि HTTP / 2 डिफ़ॉल्ट रूप से समर्थित नहीं है, जो अनिवार्य रूप से अंततः (और फिर HTTP / 3) होगा ... यदि कुछ भी हो, तो इसके विपरीत ध्वज द्वारा HTTP / 2 को अक्षम करने के लिए और अधिक समझ में आ सकता है, अगर आप "गूंगा" कॉन्फ़िगरेशन स्वचालन पर भरोसा कर रहे हैं तो क्षणभंगुर प्रासंगिक कमांड झंडे जोड़ने का कोई कारण नहीं है।

"समाधान" मैन्युअल रूप से प्रमाणपत्र का अनुरोध कर रहा है:

certbot certonly --noninteractive --agree-tos --expand -m ${SSL_EMAIL} -d ${SITE_DOMAIN_ONE} -d ${SITE_DOMAIN_TWO} --webroot -w /var/www/html/

संदर्भ: https://github.com/littlebizzy/slickstack/blob/master/ss-encrypt.txt

... और फिर एक कस्टम Nginx सर्वर ब्लॉक का उपयोग करना, जैसे:

server {
listen                 443 ssl http2;
listen                 [::]:443 ssl http2 ipv6only=on;
server_name            @DOMAIN;
    if ($http_host != "@DOMAIN") {
        return 301            $scheme://@DOMAIN$request_uri;
    }

संदर्भ: https://github.com/littlebizzy/slickstack/blob/master/nginx/default-single-site.txt
संदर्भ: https://github.com/littlebizzy/slickstack/blob/master/nginx/nginx-conf.txt

हमारा nginx प्लगइन वर्तमान में --http2 ध्वज के साथ भी HTTP/2 समर्थन को सक्षम करने का समर्थन नहीं करता है। इस मामले को ट्रैक किया जा रहा है।

जहां तक ​​हमारे डिफ़ॉल्ट व्यवहार का सवाल है, हमने अतीत में --redirect जैसे झंडों के साथ जो किया है, वह शुरू में ध्वज के पीछे छिपे समर्थन को लागू करना और अपने उपयोगकर्ताओं को इसे आज़माने के लिए प्रोत्साहित करना है। इसके अच्छी तरह से परीक्षण के बाद, हम यह सुनिश्चित करने के बाद सभी उपयोगकर्ताओं के लिए इसे डिफ़ॉल्ट व्यवहार बनाने पर विचार कर सकते हैं कि ऐसा करने से कोई कॉन्फ़िगरेशन नहीं टूटेगा (एम)।

@jessuppi

यह आश्चर्यजनक है कि कितने डेवलपर्स प्रमाण पत्र का मैन्युअल रूप से अनुरोध करने और अपनी आवश्यकताओं के लिए एक Nginx सर्वर ब्लॉक को सिलाई करने के बजाय अस्पष्ट (स्वचालित) कॉन्फ़िगरेशन पर भरोसा करते हैं ...

आप पूरी तरह से बिंदु को याद करते हैं। बेशक आप इसे स्वयं कर सकते हैं लेकिन एक कार्यक्षमता है जो सर्टिफिकेट क्लाइंट के साथ आती है जिसे बेहतर किया जाना चाहिए। आपको सर्टिफिकेट को अपने वेबसर्वर को कॉन्फ़िगर करने देना चाहिए या नहीं, इस मुद्दे के दायरे से पूरी तरह बाहर है।

यह मामला अब 4 साल पुराना है। मुझे नहीं लगता कि लोग इस बात की ज्यादा परवाह करते हैं कि उन्हें --http2 या --no-http2 ध्वज का उपयोग करना होगा, जब तक कि सर्टिफिकेट ने इसे हमारे लिए स्वचालित रूप से किया।

@bmw पिछले 4 वर्षों में पहले से लागू किए गए सभी बड़े बदलावों की तुलना में अपेक्षाकृत सरल होने वाली किसी चीज़ पर इतनी लंबी देरी क्यों है? निश्चित रूप से, सर्टिफिकेट टीम को इस बात से सहमत होना चाहिए कि HTTP2 के नए संस्करणों के लिए उचित समर्थन भी महत्वपूर्ण है ...

वास्तव में एक खुला पीआर है: https://github.com/certbot/certbot/pull/7113

@bmw किसी चीज़ पर इतनी लंबी देरी क्यों है जो अपेक्षाकृत सरल होनी चाहिए

क्योंकि कई Certbot मुद्दे हैं और हम एक छोटी टीम हैं इसलिए हमें चीजों को प्राथमिकता देनी होगी। मैं मानता हूं कि इसका मूल्य है, हम अभी तक इसे प्राप्त नहीं कर पाए हैं।

मैं इस मुद्दे में एक प्राथमिकता लेबल जोड़ूंगा ताकि भविष्य में नई परियोजनाओं की तलाश करते समय हम इसे और आसानी से देख सकें।

नमस्ते। मुझे लगता है कि भले ही http2 NGINX कॉन्फ़िगरेशन का समर्थन करने के लिए सर्टिफिकेट के लिए एक फिक्स प्रदान किया गया हो, यह इस तथ्य को ठीक नहीं करेगा कि बाउंडलर अभी भी HTTP / 2 कनेक्शन के खिलाफ वेबूट जांच करने में असमर्थ होगा, है ना? सीएफ इस लिंक

यह अनएन्क्रिप्टेड पोर्ट पर http2 के बारे में है। यह वास्तव में यहाँ कोई समस्या नहीं है। हम सिर्फ यह चाहते हैं कि एन्क्रिप्शन के साथ पोर्ट 443 पर listen निर्देशों में http2 विकल्प जोड़ा जाए।

@ cperrin88 ज़रूर, लेकिन ध्यान रखने वाली बात यह है कि NGINX HTTP/1.1 -> HTTP/2 h2c प्रोटोकॉल अपग्रेड करने में सक्षम नहीं है , इसलिए, वेबूट सत्यापन का उपयोग करते समय, बाउंडलर, लेट्स सेनक्रिप्ट द्वारा प्रदर्शन करने के लिए उपयोग किया जाने वाला सर्वर चुनौती विनिमय, केवल मान सकता है कि सर्वर HTTP/1.1 बोलता है और त्रुटि के साथ शिकायत करता है: "सर्वर HTTP पर HTTP/2 बोल रहा है" अन्यथा।

तो यह कुछ ध्यान में रखना है जब इस मुद्दे पर एक पैच जीवन में आ जाएगा IMHO :)

यह परिवर्तन किसी भी तरह से अनएन्क्रिप्टेड पोर्ट में http2 को नहीं जोड़ना चाहिए। लेकिन हमें इसे ध्यान में रखना चाहिए।