Certbot: स्टैंडअलोन को वैकल्पिक बंदरगाहों को बाध्य करने की अनुमति देनी चाहिए (लेकिन प्रमाणित नहीं)

मेरा मानना ​​​​है कि क्लाइंट के पास पहले से ही वह कार्यक्षमता है जो आप चाहते हैं, हालांकि, इसे बहुत उपयोगकर्ता के अनुकूल तरीके से प्रस्तुत नहीं किया गया है क्योंकि इसका मुख्य रूप से परीक्षण के लिए उपयोग किया जाता है। ग्राहक के पास निम्नलिखित झंडे हैं:

  --tls-sni-01-port TLS_SNI_01_PORT
                        Port number to perform tls-sni-01 challenge. Boulder
                        in testing mode defaults to 5001. (default: 443)
  --http-01-port HTTP01_PORT
                        Port used in the SimpleHttp challenge. (default: 80)

ये फ़्लैग आपको यह निर्दिष्ट करने की अनुमति देते हैं कि क्लाइंट किस पोर्ट के लिए डोमेन सत्यापन चुनौतियों को सेट करता है। सामान्य तौर पर, --tls-sni-01 वह पोर्ट होना चाहिए जिस पर आपने आने वाले पोर्ट 443 ट्रैफ़िक को रूट किया है और --http-01-port वह पोर्ट होना चाहिए जिस पर आपने आने वाले पोर्ट 80 ट्रैफ़िक को रूट किया है।

आपको दोनों झंडे का उपयोग करने की आवश्यकता नहीं होगी, हालांकि, स्टैंडअलोन डिफ़ॉल्ट रूप से 443 से अधिक चुनौतियों का प्रदर्शन करता है। आप निम्न ध्वज का उपयोग करके इस व्यवहार को नियंत्रित कर सकते हैं:

  --standalone-supported-challenges STANDALONE_SUPPORTED_CHALLENGES
                        Supported challenges. Preferred in the order they are
                        listed. (default: tls-sni-01,http-01)

आशा है यह मदद करेगा!

धन्यवाद, मैं कल यह कोशिश करूँगा।

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

22 मार्च 2016 को अपराह्न 3:16 बजे, बीएमडब्ल्यू नोटिफिकेशन @github.com ने लिखा:

मेरा मानना ​​​​है कि क्लाइंट के पास पहले से ही वह कार्यक्षमता है जो आप चाहते हैं, हालांकि, इसे बहुत उपयोगकर्ता के अनुकूल तरीके से प्रस्तुत नहीं किया गया है क्योंकि इसका मुख्य रूप से परीक्षण के लिए उपयोग किया जाता है। ग्राहक के पास निम्नलिखित झंडे हैं:

--tls-sni-01-पोर्ट TLS_SNI_01_PORT
tls-sni-01 चुनौती करने के लिए पोर्ट नंबर। बोल्डर
परीक्षण मोड में डिफ़ॉल्ट रूप से 5001. (डिफ़ॉल्ट: 443)
--http-01-पोर्ट HTTP01_PORT
SimpleHttp चुनौती में प्रयुक्त पोर्ट। (डिफ़ॉल्ट: 80)
ये फ़्लैग आपको यह निर्दिष्ट करने की अनुमति देते हैं कि क्लाइंट किस पोर्ट के लिए डोमेन सत्यापन चुनौतियों को सेट करता है। सामान्य तौर पर, --tls-sni-01 वह पोर्ट होना चाहिए जिस पर आपने आने वाले पोर्ट 443 ट्रैफ़िक को रूट किया है और --http-01-port वह पोर्ट होना चाहिए जिस पर आपने आने वाले पोर्ट 80 ट्रैफ़िक को रूट किया है।

आपको दोनों झंडे का उपयोग करने की आवश्यकता नहीं होगी, हालांकि, स्टैंडअलोन डिफ़ॉल्ट रूप से 443 से अधिक चुनौतियों का प्रदर्शन करता है। आप निम्न ध्वज का उपयोग करके इस व्यवहार को नियंत्रित कर सकते हैं:

--स्टैंडअलोन समर्थित-चुनौतियाँ STANDALONE_SUPPORTED_CHALLENGES
चुनौतियों का समर्थन किया। क्रम में पसंदीदा वे हैं
सूचीबद्ध। (डिफ़ॉल्ट: tls-sni-01,http-01)
आशा है यह मदद करेगा!

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने सूत्र को लिखा है।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें

@jvanasco अधिकांश लोग उस उपयोग के मामले के लिए वेबूट प्लगइन का उपयोग करते हैं लेकिन हां, प्रॉक्सी पास nginx उदाहरण अच्छा हो सकता है। एक पीआर बनाने के लिए स्वतंत्र महसूस करें जो दस्तावेज़ों में एक जोड़ता है; यह एक पर्याप्त रूप से विशिष्ट उपयोग मामला है कि इसे शायद इस फ़ाइल के निचले भाग में एक नया अनुभाग मिलना चाहिए:

https://github.com/letsencrypt/letsencrypt/blob/master/docs/using.rst

हालाँकि आप इसे मौजूदा स्टैंडअलोन सेक्शन से लिंक कर सकते हैं:

https://github.com/letsencrypt/letsencrypt/blob/master/docs/using.rst#standalone

हमने इस पर कभी वापस नहीं सुना, इसलिए मैं इस मुद्दे को बंद कर रहा हूं। अगर आप मुझे फिर से खोलना चाहते हैं तो कृपया मुझ पर चिल्लाते हुए टिप्पणी करें।

यह काम नहीं लग रहा है। @बीएमडब्ल्यू

/usr/local/bin/certbot-auto certonly --http-01-port 8484 --config-dir /etc/letsencrypt --work-dir /var/lib/letsencrypt --logs-dir /var/log/letsencrypt --standalone --standalone-supported-challenges http-01 --email [email protected] --domains example.com --agree-tos --non-interactive

tcp        0      0 0.0.0.0:8484                0.0.0.0:*                   LISTEN      7270/python2

मुझे लगता है कि प्रमाणीकरण पोर्ट 80 पर आता है, हालांकि पायथन 2 सर्वर 8484 पर शुरू हुआ था।

पोर्ट 80 . पर Nginx

66.133.109.36 - - [25/Aug/2016:12:41:15 +0100] "GET /.well-known/acme-challenge/xxxxxxxx HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"

संपादित करें:
मुझे लगता है कि --tls-sni-01-port 5001 --http-01-port 5002 दोनों आवश्यक हैं!

संपादित करें:
मैं अभी भी इस बारे में समझदार नहीं हूं कि स्टैंडअलोन सर्वर को कैसे स्पिन करता है और इसे प्रमाणित करता है

साथ ही --tls-sni-01-port को नज़रअंदाज़ किए जाने की समस्याएँ हैं:

# certbot certonly --noninteractive --email "matt.hanley@****" --domain **** --agree-tos --tls-sni-01-port 40443 --http-01-port 4080 --standalone  
Failed authorization procedure. ****** (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for TLS-SNI-01 challenge. Requested 2af2853170e5be7e86cdff79d0ca****.febd4f14bb130b15910f30587cf4****.acme.invalid from 185.***.***.***:443. Received certificate containing '*****'

ध्यान दें कि अनुरोध वास्तव में :443 पर गया था; मेरे पास पहले से ही :443 पर एक अलग प्रमाणपत्र परोसने वाली HTTPS सेवा चल रही है। हालांकि, यह renew के साथ काम करता है।

--tls-sni-01-port के साथ भी समस्या है:

certbot certonly -n -d example.com --agree-tos --email "[email protected]" --standalone --tls-sni-01-port 8443 --http-01-port 8080

Failed to connect to 1.2.3.4:443 for TLS-SNI-01

--http-01-port / --tls-sni-01-port आपको यह निर्दिष्ट करने की अनुमति नहीं देता है कि लेट्स एनक्रिप्ट किस पोर्ट पर आपके सर्वर से कनेक्ट होगा। यह हमेशा क्रमशः 80/443 का उपयोग करेगा। ये सभी झंडे आपको यह नियंत्रित करने की अनुमति देते हैं कि कौन से पोर्ट सर्टबॉट स्टैंडअलोन जैसे प्लगइन्स के लिए सुनता है। यह उपयोगी है यदि आप उदाहरण के लिए सभी पोर्ट 80 ट्रैफ़िक को पोर्ट 8080 पर रूट कर रहे हैं।

हाँ बस एक सिर ऊपर आपको मूल रूप से सार्वजनिक आईपी पते पर पोर्ट 80 पहुंच योग्य होना चाहिए।

कुछ ऐसा जो दस्तावेज़ीकरण में बहुत कमी है, इसका मतलब यह भी है कि लेट्स एनक्रिप्ट अल्पसंख्यक के उद्देश्य के लिए उपयुक्त नहीं है जो आने वाले यातायात को 80 पर नियंत्रित नहीं कर सकता (संभवतः चीन/कुछ आईएसपी, कॉर्प फायरवॉल)

मैंने इसके आस-पास कई पोस्ट पढ़े हैं, लगभग ऐसा लगता है कि 80 पर सुनने की क्षमता को सुरक्षा लाभ/भरोसेमंद उपाय माना जाता है क्योंकि यह निक्स बॉक्स पर एक विशेषाधिकार प्राप्त बंदरगाह है।

हालांकि ऐसा लगता है कि एन्क्रिप्ट वेब सर्वर के बाहर प्रमाण पत्र के लिए उपयोग को नहीं पहचानता है .. उदाहरण के लिए एक ईमेल सर्वर इत्यादि, मैं सिर्फ ऑथ को संभालने के लिए नोड ऐप के पोर्ट 7722 पर एक त्वरित बूट अप चाहता हूं, फिर शटडाउन के रूप में बंद करें ' एक वेब सर्वर नहीं चलाते .. लेकिन आंकड़ा जाओ।

इसका मतलब यह भी है कि यदि आप शेफ जैसे ऑटोमेशन का उपयोग करते हैं, उदाहरण के लिए आपको अपने nginx को बूट करने में सक्षम होने के लिए स्व-हस्ताक्षरित प्रमाणपत्रों को कॉन्फ़िगर करने की आवश्यकता है, तो कॉन्फ़िगरेशन में SSL होगा, उस पर कम से कम एक वैध प्रमाणपत्र होना चाहिए।

एक अन्य विकल्प हालांकि यदि आप केवल एसएसएल चलाते हैं तो एक अलग वेब सर्वर 80 परोसता है ताकि यह सुनिश्चित हो सके कि nginx के बूट होने से पहले प्रमाणपत्र डाउनलोड हो गया है। (कष्टप्रद सेटअप)

मेरे शेफ की तैनाती अब निम्नलिखित के माध्यम से चलती है:

1. एक स्व-हस्ताक्षरित प्रमाणपत्र स्थापित करें।
2. बूट nginx (स्व प्रमाणपत्र के साथ)
3. प्रमाण चलाएँ
4. मेरे स्थान के लिए सिमलिंक प्रमाणपत्र
5. पुनः लोड nginx

मेरे आईफोन से भेजा गया

15 सितंबर 2016 को 23:18 बजे, ब्रैड वारेन ने नोटिफिकेशन @github.com लिखा:

--http-01-port/--tls-sni-01-port आपको यह निर्दिष्ट करने की अनुमति नहीं देता है कि Let's Encrypt किस पोर्ट पर आपके सर्वर से कनेक्ट होगा। यह हमेशा क्रमशः 80/443 का उपयोग करेगा। ये सभी झंडे आपको यह नियंत्रित करने की अनुमति देते हैं कि कौन से पोर्ट सर्टबॉट स्टैंडअलोन जैसे प्लगइन्स के लिए सुनता है। यह उपयोगी है यदि आप उदाहरण के लिए सभी पोर्ट 80 ट्रैफ़िक को पोर्ट 8080 पर रूट कर रहे हैं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

मेरा वेब सर्वर एसएसएल कनेक्शन के लिए सिर्फ एक पोर्ट पर सुनता है और यह डिफ़ॉल्ट 443 नहीं है। ऐसा इसलिए है क्योंकि वेब सर्वर एक वीपीएन सेवा के पीछे है जो पोर्ट फ़ॉरवर्डिंग की अनुमति देता है, लेकिन पोर्ट फ़ॉरवर्डिंग को पोर्ट 80 या 443 की अनुमति नहीं देता है।

मैं इस सेवर पर लेट्स एनक्रिप्ट को कॉन्फ़िगर करने का प्रयास कर रहा हूं लेकिन लॉग में मैं देख सकता हूं कि एक्मे क्लाइंट पोर्ट 80 (जो पहुंच योग्य नहीं है) पर कनेक्ट करने का प्रयास करता है और विफल रहता है।

मुझे जो त्रुटि मिलती है वह "कनेक्ट नहीं हो सका" स्थिति 400 है।

"AddressesResolved" मान सही है, बस "पोर्ट" मान 80 है और सभी url गलत हैं, क्योंकि उनके पास मेरा कस्टम पोर्ट निर्दिष्ट होना चाहिए, जैसे subdomain.domain। tld:1234 जहां 1234 मेरा कस्टम पोर्ट है।

क्या इसे मेरे सेटअप के साथ काम करने का कोई तरीका है?

@gsdevme से मुझे यह आभास हुआ कि मेरे पास पोर्ट 80 सार्वजनिक रूप से सुलभ होना चाहिए ...

_आपके पास एक्मे सर्वर को सत्यापित करने के लिए पोर्ट 80 सार्वजनिक रूप से सुलभ होना चाहिए।_

_यह समाधान केवल सर्वर को किसी वैकल्पिक पोर्ट पर आंतरिक रूप से चलाने के लिए है, और PORT80 से वैकल्पिक पोर्ट पर प्रॉक्सी करने के लिए है।_

_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_
_यदि आपके पास PORT80 पहुंच योग्य नहीं है, तो आपको DNS सत्यापन का उपयोग करना होगा।_

उत्तर @jvanasco के लिए धन्यवाद। बहुत बुरा मैं कस्टम पोर्ट निर्दिष्ट नहीं कर सकता। DNS सत्यापन एक विकल्प नहीं है, क्योंकि मेरे डायनामिक DNS प्रदाता http://freedns.afraid.org/ में TXT रिकॉर्ड को स्वचालित रूप से बदलने के लिए इंटरफ़ेस नहीं है।

@jvanasco हालांकि मुझे पता है कि आप अपने उत्तर में पूरी तरह से सही हैं, यह अच्छा होगा यदि हम सभी उत्तर देने से पहले थोड़ा शांत हो जाएं: डी

क्या कोई समय अनुमान है कि यह कब कॉन्फ़िगर करने योग्य होगा? क्योंकि मुझे यकीन है कि बहुत से लोग कस्टम पोर्ट पर वेब सर्वर चला रहे हैं।

यह डिज़ाइन पसंद द्वारा कॉन्फ़िगर करने योग्य नहीं है

मेरे आईफोन से भेजा गया

14 फरवरी 2017 को 16:16 बजे, nvaert1986 [email protected] ने लिखा:

क्या कोई समय अनुमान है कि यह कब कॉन्फ़िगर करने योग्य होगा? क्योंकि मुझे यकीन है कि बहुत से लोग कस्टम पोर्ट पर वेब सर्वर चला रहे हैं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

यहां वही मुद्दा है, लेकिन डोकर उद्देश्य के लिए।

संकट :
मैं अपने वेबसर्वर स्टार्ट कमांड के साथ सर्टिफिकेट कमांड को पैकेज नहीं करना चाहता क्योंकि यह गैर-प्रोड वातावरण में हमेशा विफल रहेगा।
इसलिए मैं एक विशिष्ट छवि बनाना चाहता हूं जिसमें सर्टिफिकेट हो:

• प्रमाण पत्र के लिए पूछें
• प्रमाणपत्र को मेरे वेबसर्वर के साथ साझा किए गए वॉल्यूम के अंदर रखें

लेकिन यह समाधान तभी काम करेगा जब मैं अपने वेबसर्वर के कंटेनर को बंद कर दूं, जो पहले से ही पोर्ट 80 और 443 पर आबद्ध है।

समाधान :
सर्टिफिकेट पोर्ट को बदलने की क्षमता है। यह सर्टिफिकेट और वेबसर्वर कंटेनर दोनों को समानांतर में चलाने की अनुमति देगा।

DNS सत्यापन का उपयोग करने से उपयोग के मामले का समाधान हो सकता है।

मेरे आईफोन से भेजा गया

26 फरवरी 2017 को 23:32 बजे, NilsRenaud [email protected] ने लिखा:

यहां वही मुद्दा है, लेकिन डोकर उद्देश्य के लिए।

संकट :
मैं अपने वेबसर्वर स्टार्ट कमांड के साथ सर्टिफिकेट कमांड को पैकेज नहीं करना चाहता क्योंकि यह गैर-प्रोड वातावरण में हमेशा विफल रहेगा।
इसलिए मैं एक विशिष्ट छवि बनाना चाहता हूं जिसमें सर्टिफिकेट हो:

प्रमाण पत्र के लिए पूछें
प्रमाणपत्र को मेरे वेबसर्वर के साथ साझा किए गए वॉल्यूम के अंदर रखें
लेकिन यह समाधान तभी काम करेगा जब मैं अपने वेबसर्वर के कंटेनर को बंद कर दूं, जो पहले से ही पोर्ट 80 और 443 पर आबद्ध है।

समाधान :
सर्टिफिकेट पोर्ट को बदलने की क्षमता है। यह सर्टिफिकेट और वेबसर्वर कंटेनर दोनों को समानांतर में चलाने की अनुमति देगा।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

यह हो सकता है लेकिन स्टैंडअलोन मोड के साथ यह सत्यापन मोड संभव नहीं है: /
(से: https://certbot.eff.org/docs/using.html#plugins)

सुरक्षा से समझौता किए बिना एक समझदार मध्य मैदान की तरह लगता है कि डीएनएस एसआरवी रिकॉर्ड के माध्यम से बंदरगाह की खोज की अनुमति होगी। Letsencrypt एक रिकॉर्ड को क्वेरी कर सकता है जैसे

_letsencrypt._tcp IN SRV 0 0 8080 10.10.10.10

डोमेन पर और परिणामी पते/पोर्ट संयोजन के लिए सत्यापन अनुरोध अग्रेषित करें। इसका DNS सत्यापन के समान लाभ है लेकिन गतिशील अद्यतनों की आवश्यकता के दोष के बिना।

इसका अर्थ यह भी होगा कि यदि उपयोगकर्ता चाहें तो अपने प्रमाणपत्रों के प्रबंधन को केंद्रीय प्रमाणपत्र सर्वर के संदर्भ में आसानी से केंद्रीकृत कर सकते हैं।

वैकल्पिक बंदरगाहों की अनुमति सुरक्षा से कैसे समझौता करती है?

यह FOSS उपयोगिता उन होस्टों को ACME प्रमाणपत्रों की प्रत्यक्ष और अप्रत्यक्ष स्थापनाओं को स्वचालित करने में मदद कर सकती है जिनके पास TCP/443 पोर्ट व्यस्त है, या उन्हें TCP/443 पोर्ट अग्रेषित नहीं किया गया है:

https://www.actiu.net/sesele/

उपयोग करने की अनुमति देने के लिए SeSeLe कैसे काम करता है, इसके बारे में दस्तावेज़ीकरण कहाँ है
443 से अलग बंदरगाह?.

26 अक्टूबर, 2017 को दोपहर 1:21 बजे, "नार्सिस गार्सिया" नोटिफिकेशन @github.com ने लिखा:

यह FOSS उपयोगिता आपको की प्रत्यक्ष और अप्रत्यक्ष स्थापनाओं को स्वचालित करने में मदद कर सकती है
उन मेजबानों के लिए ACME प्रमाणपत्र जिनके पास TCP/443 पोर्ट व्यस्त है, या जिनके पास TCP/443 नहीं है
पोर्ट उन्हें अग्रेषित किया गया:

https://www.actiu.net/sesele/

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/certbot/certbot/issues/2697#issuecomment-339754606 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAOGHuxKLiYjM4-cME-0GBu9Ujoe0NB_ks5swM20gaJpZM4H1uae
.

कृपया, बेहतर प्रलेखन समन्वय की अनुमति देने के लिए SeSeLe फोरम के मुद्दे पर जाएं। (उत्तर अब SeSeLe प्रलेखन में लिखा गया है)

शायद इस मुद्दे पर दोबारा गौर किया जा सकता है? अंतर्निहित मुद्दे का अभी भी कोई समाधान नहीं है। हां, आप स्टैंडअलोन को अलग-अलग पोर्ट से बांध सकते हैं लेकिन यह बेकार है क्योंकि एथोरिटी अभी भी 80/443 से कनेक्ट होगी।

यदि आपके पास पहले से ही 80/443 पर उत्पादन में सर्वर चल रहा है, तो आप कभी-कभी उन बंदरगाहों को मुक्त करने का जोखिम नहीं उठा सकते हैं। चुनौती फ़ाइलों को मैन्युअल रूप से रखना भी समस्याग्रस्त हो सकता है (डॉकर में चलने वाले सर्वर)।

यहां वास्तविक समाधान बंदरगाहों के एक सेट को उच्चतर (10 000+) निर्दिष्ट करना होगा जहां प्राधिकरण फॉलबैक या ऐसा कुछ के रूप में कनेक्ट करने का प्रयास करेगा। शायद सुरक्षा निहितार्थ हैं, विशेषज्ञ नहीं।

LE को केवल पोर्ट 80/443 से जोड़ने की प्रेरणा क्या है? यह एक
औपचारिक रूप से प्रलेखित सीमा?

क्या कोई मुझे सही दस्तावेजों की ओर इशारा कर सकता है?

30 नवंबर, 2017 को सुबह 6:31 बजे, "सेन1" नोटिफिकेशन @github.com ने लिखा:

शायद इस मुद्दे पर दोबारा गौर किया जा सकता है? अभी भी कोई समाधान नहीं है
अंतर्निहित मुद्दा। हां, आप स्टैंडअलोन को अलग-अलग पोर्ट से बाइंड कर सकते हैं लेकिन वह
बेकार है क्योंकि अथोरिटी अभी भी 80/443 से जुड़ जाएगी।

यदि आपके पास एक सर्वर पहले से ही 80/443 पर चल रहा है, शायद उत्पादन में है, तो आप
कभी-कभी बस उन बंदरगाहों को मुक्त करने का जोखिम नहीं उठा सकते। मैन्युअल रूप से रखना
चुनौती फ़ाइलें भी समस्याग्रस्त हो सकती हैं (डॉकर में चलने वाले सर्वर)।

यहां वास्तविक समाधान बंदरगाहों के एक सेट को उच्चतर (10 .) निर्दिष्ट करना होगा
000+) जहां प्राधिकरण फ़ॉलबैक या कुछ के रूप में कनेक्ट करने का प्रयास करेगा
उसके जैसा। शायद सुरक्षा निहितार्थ हैं, विशेषज्ञ नहीं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/certbot/certbot/issues/2697#issuecomment-348162321 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAOGHqWG9XZyTVDdAbm3t5xQ-AD6Y_OQks5s7pIDgaJpZM4H1uae
.

LE को केवल पोर्ट 80/443 से जोड़ने की प्रेरणा क्या है?
क्या यह औपचारिक रूप से प्रलेखित सीमा है?

क्या कोई मुझे सही दस्तावेजों की ओर इशारा कर सकता है?

यह यहां वर्णित एक मौजूदा सीए/बी फोरम आवश्यकता है:
https://cabforum.org/2017/09/19/ballot-190-revised-validation-requirements/

और यहां अधिक विस्तार से समझाया गया है: https://community.letsencrypt.org/t/support-for-ports-other-than-80-and-443/3419/100

जैसा कि मैं अपनी खराब अंग्रेजी के साथ समझता हूं, सीए/ब्राउज़र फोरम में उन्होंने सितंबर 2017 को टीसीपी पोर्ट 25, 115, 22 के संभावित जोड़ के बारे में बहस की।
ऐसा लगता है कि प्रस्ताव को मंजूरी दे दी गई थी और इस नवंबर से प्रभावी होना चाहिए।

भविष्य से एक नोट अगर कोई Google से यहां आता है (मेरे जैसा):

2018-08-29 13:43:33,495: WARNING:certbot.plugins.standalone: 
The standalone specific supported challenges flag is deprecated. 
Please use the --preferred-challenges flag instead.

यदि आप nginx का उपयोग कर रहे हैं तो आप certbot certonly --nginx के साथ nginx मॉड्यूल का उपयोग कर सकते हैं, यह बिना किसी कॉन्फ़िगरेशन के मौजूदा nginx सर्वर में टैप करता है।

ध्वज --http-01-port वास्तव में सहज नहीं है, मैं इसे कमांड की मदद से नहीं ढूंढ सका और ध्वज के लिए Google को --http-01-port करना पड़ा। मदद में ध्वज का उल्लेख करना अच्छा होगा।