Lua-resty-auto-ssl: प्रमाणपत्र जारी करते समय आईपी पते पर ध्यान न दें

मैंने अभी इसके लिए एक चेक लिखा है, केवल यह पता लगाने के लिए कि यह पहले से ही बहुत जल्दी विफल हो जाता है:

ssl_certificate (): ऑटो-एसएसएल: अनुरोध के लिए डोमेन निर्धारित नहीं कर सका (एसएनआई समर्थित नहीं है?) - फ़ॉलबैक का उपयोग कर -

जब कोई ब्राउज़र किसी आईपी-पते के लिए अनुरोध करता है, तो वह एसएनआई-हेडर नहीं भेजता है, इसलिए "डोमेन" भी सेट नहीं किया जाएगा।

मुझे यकीन नहीं है कि मेरा अनुरोध एन्क्रिप्ट करने के लिए अनुरोध क्यों भेज रहा था जो तब एक आईपी के साथ एक एसएसएल प्रमाणपत्र पंजीकृत करने के बारे में एक त्रुटि भेज रहा था: एस

@discobean : क्या आपके पास विशिष्ट त्रुटि संदेश है जो तब होता है जब आपने इसे देखा है?

@GUI मुझे कभी-कभी वही त्रुटि मिलती है। मेरा अनुमान है कि ऐसा इसलिए है क्योंकि क्लाइंट (जो शायद स्कैनर बॉट हैं) होस्ट हेडर भेज रहे हैं जो आईपी पते को लक्षित करने के बराबर है, उदाहरण के लिए:

2018/02/20 02:10:44 [warn] 490#490: *2723 [lua] init_by_lua:11: allow_domain(): auto-ssl: debug allow_domain domain XXX.XXX.XX.XX, context: ssl_certificate_by_lua*, client: 107.170.236.113, server: 0.0.0.0:8443
2018/02/20 02:10:49 [error] 490#490: *2723 [lua] lets_encrypt.lua:41: issue_cert(): auto-ssl: dehydrated failed: env HOOK_SECRET=XXXXX HOOK_SERVER_PORT=8999 /usr/local/bin/resty-auto-ssl/dehydrated --cron --accept-terms --no-lock --domain XXX.XXX.XX.XX --challenge http-01 --config /etc/resty-auto-ssl/letsencrypt/config --hook /usr/local/bin/resty-auto-ssl/letsencrypt_hooks status: 256 out: # INFO: Using main config file /etc/resty-auto-ssl/letsencrypt/config
Processing XXX.XXX.XX.XX
 + Signing domains...
 + Creating new directory /etc/resty-auto-ssl/letsencrypt/certs/XXX.XXX.XX.XX ...
 + Generating private key...
 + Generating signing request...
 + Requesting authorization for XXX.XXX.XX.XX...
 err:   + ERROR: An error occurred while sending post-request to https://acme-v01.api.letsencrypt.org/acme/new-authz (Status 400)

Details:
{
  "type": "urn:acme:error:malformed",
  "detail": "Error creating new authz :: Issuance for IP addresses not supported",
  "status": 400
}

, context: ssl_certificate_by_lua*, client: 107.170.236.113, server: 0.0.0.0:8443
2018/02/20 02:10:49 [error] 490#490: *2723 [lua] ssl_certificate.lua:97: issue_cert(): auto-ssl: issuing new certificate failed: dehydrated failure, context: ssl_certificate_by_lua*, client: 107.170.236.113, server: 0.0.0.0:8443
2018/02/20 02:10:49 [error] 490#490: *2723 [lua] ssl_certificate.lua:286: auto-ssl: could not get certificate for XXX.XXX.XX.XX - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: 107.170.236.113, server: 0.0.0.0:8443

जहां XXX.XXX.XX.XX हमारा वास्तविक सर्वर आईपी पता है

मैं कोड में इसे अवरुद्ध करने के लिए हूं, लेकिन, एह: आपका allow_domain() चाहिए _only_ FQDN की अनुमति दें कि आप "इनके लिए नहीं" (ब्लैकलिस्ट दृष्टिकोण) के विपरीत (श्वेतसूची दृष्टिकोण) के लिए एक प्रमाण पत्र उत्पन्न करना चाहते हैं।

आपको केवल allow_domain() में केवल "वापसी सही" नहीं करनी चाहिए। यह आपके सिस्टम पर दबाव डालता है और LE की ओर विफलताओं को जमा करता है।

हम हालांकि एक कदम आगे जा रहे हैं। हम अपने सभी वेबहोस्टिंग ग्राहकों की एक सूची को डिस्क पर लुआ टेबल फ़ाइल में निर्यात करते हैं, उसे पढ़ते हैं और इसे nginx के अंदर एक SHM कुंजी/मूल्य स्टोर में संग्रहीत करते हैं ताकि हम आसानी से जांच सकें कि हमें कौन से होस्ट के लिए प्रमाणपत्र बनाना चाहिए या नहीं।

हमारे प्रबंधन होस्टनामों के लिए हमारे पास कई वाइल्डकार्ड प्रमाणपत्र हैं, इसलिए हम संबंधित एसएसएल प्रमाणपत्र के साथ प्रतिस्थापित एसएसएल श्रृंखला के साथ जल्दी बाहर निकल जाते हैं। हम आईपी-एड्रेस और लोकलहोस्ट पर जल्दी बाहर निकलते हैं। और फिर अंत में हम डीएनएस की जांच करते हैं और क्या नाम वास्तव में हमारे सिस्टम पर कॉन्फ़िगर किए गए डोमेन की सूची में है या नहीं।

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

और कभी-कभी यह बेहतर होता है कि ओवर-इंजीनियरिंग न करें और विभिन्न जांचों को छोड़ दें जो कि विफलता का एक और बिंदु हो सकता है :) खासकर यदि आपके पास अत्यधिक गतिशील वातावरण है।

मैं यह नहीं कह रहा हूं कि इसे लुआ-रेस्टी-ऑटो-एसएसएल में अवरुद्ध किया जाना चाहिए, अगर कोई और इस मुद्दे पर ठोकर खाता है तो परीक्षण करते समय मुझे जो मिला है उसे साझा करना।

allow_domain में त्वरित हैक:

          local ip_chunks = {domain:match("(%d+)%.(%d+)%.(%d+)%.(%d+)")}
          if (#ip_chunks == 4) then
            return false
          end

श्वेतसूचीकरण अति-इंजीनियरिंग नहीं है, यह इसे सही कर रहा है। दुनिया में बहुत सारी सुरक्षा घटनाएं हैं क्योंकि डेवलपर्स श्वेतसूची के बजाय ब्लैकलिस्टिंग का उपयोग कर रहे हैं, यह दूर से भी अजीब नहीं है।

आपका चेक IPv6-पतों को भी छोड़ देता है, और वास्तव में अति-इंजीनियर्ड है:

if string.match(domain, "(%d+).(%d+).(%d+).(%d+)") or string.find(domain, ":", 1, true) then
    return false
end

आप हमारी स्थिति नहीं जानते हैं, लेकिन आप जल्दी से न्याय करते हैं। समझ गया।

आप शायद एक पीआर बना सकते हैं और allow_domain को README.md में बदल सकते हैं ताकि सभी को सुरक्षित बनाने के लिए true वापस करने से कहीं अधिक समझदार हो