Lua-resty-auto-ssl: ओसीएसपी स्टेपलिंग: नेटवर्क पहुंच योग्य नहीं है

क्या आपने रिज़ॉल्वर निर्दिष्ट किया था?
resolver 8.8.8.8;

हां

यह एक बुनियादी ढांचे के मुद्दे की तरह दिखता है, जैसे आप पोर्ट 80 पर नहीं सुन रहे हैं। क्या आप डॉकर का उपयोग कर रहे हैं?

हां

आप मेरी अपनी छवि आज़मा सकते हैं और देख सकते हैं कि क्या यह काम करती है: https://hub.docker.com/r/pushtospace/nginx/

अगर मेरे पास समय हो तो मैं कोशिश करूंगा।
मेरा:

FROM openresty/openresty:latest-xenial
RUN /usr/local/openresty/luajit/bin/luarocks install lua-resty-auto-ssl
RUN openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 \
      -subj '/CN=sni-support-required-for-valid-ssl' \
      -keyout /etc/ssl/resty-auto-ssl-fallback.key \
      -out /etc/ssl/resty-auto-ssl-fallback.crt
ADD nginx.conf /usr/local/openresty/nginx/conf/nginx.conf
RUN mkdir -p /etc/resty-auto-ssl/storage/file/
VOLUME ["/etc/resty-auto-ssl/storage/file/"]

@serathius : ऐसा लगता है कि यह विफल हो रहा है जब आपका सर्वर Let's Encrypt के OCSP सर्वर से एक आउटबाउंड अनुरोध करने का प्रयास कर रहा है। इसी सर्वर से जहां आपने lua-resty-auto-ssl स्थापित किया है, क्या आप मैन्युअल रूप से डिफ़ॉल्ट Let's Encrypt OCSP सर्वर से कनेक्शन स्थापित करने में सक्षम हैं? आप इस आदेश के साथ इसका परीक्षण कर सकते हैं:

curl -v "http://ocsp.int-x3.letsencrypt.org/"

आपको "200 OK" स्थिति के साथ एक प्रतिक्रिया दिखाई देनी चाहिए। यदि आप इसे नहीं देखते हैं, तो क्या आप आउटपुट पोस्ट कर सकते हैं? या आपके नेटवर्क पर ऐसा कुछ है जिसके बारे में आप सोच सकते हैं कि यह इस आउटबाउंड अनुरोध को रोक रहा होगा?

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

शायद इसका IPv6 से कुछ लेना-देना है? मैंने इसे प्राप्त किया

2016/08/31 04:58:27 [error] 31119#0: unexpected response for ocsp.int-x3.letsencrypt.org
2016/08/31 04:58:28 [error] 31119#0: connect() to [2001:428:4402:108::419e:2f9a]:80 failed (101: Network is unreachable), context: ssl_certificate_by_lua*, client: 50.4.134.47, server: 0.0.0.0:443
2016/08/31 04:58:28 [error] 31119#0: [lua] ssl_certificate.lua:203: set_cert(): auto-ssl: failed to set ocsp stapling for staging.example.com - continuing anyway - failed to get ocsp response: OCSP responder query failed (http://ocsp.int-x3.letsencrypt.org/): network is unreachable, context: ssl_certificate_by_lua*, client: snip, server: 0.0.0.0:443

एक बार काम करने वाले https पेज के साथ आने के बाद मैं पेज को रीफ्रेश करता हूं।

वही यहाँ, कोई विचार क्या गलत है?

2016/10/18 18:38:30 [error] 18084#18084: *24710 [lua] ssl_certificate.lua:203: set_cert(): auto-ssl: failed to set ocsp stapling for www.franklpharma.cz - continuing anyway - failed to get ocsp response: OCSP responder query failed (http://ocsp.int-x3.letsencrypt.org/): network is unreachable, context: ssl_certificate_by_lua*, client: 10.135.30.111, server: 0.0.0.0:443
2016/10/18 18:38:54 [error] 18084#18084: *24729 connect() to [2a02:26f0:122::215:f618]:80 failed (101: Network is unreachable), context: ssl_certificate_by_lua*, client: 10.135.30.111, server: 0.0.0.0:443

हम हर लगभग Nginx/Openresty फ्रीज (nginx_status पेज लोड नहीं हो रहा है, लॉग खाली हैं) का अनुभव कर रहे हैं। 10 घंटे। क्या यह जुड़ा हुआ है? इसे कैसे ठीक किया जाये, कोई विचार? धन्यवाद

PS मैं उन IPv6 पतों को नहीं पहचानता।

@GUI कर्ल काम कर रहा है, कोई अन्य विचार? Certs ठीक काम कर रहे हैं, हालांकि मेरे लॉग में हर पेज लोड के लिए यह त्रुटि है। धन्यवाद

[root@realm0-ssl1 logs]# curl -v "http://ocsp.int-x3.letsencrypt.org/"
*   Trying 2.22.8.114...
* Connected to ocsp.int-x3.letsencrypt.org (2.22.8.114) port 80 (#0)
> GET / HTTP/1.1
> Host: ocsp.int-x3.letsencrypt.org
> User-Agent: curl/7.47.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: nginx
< Content-Type: text/plain; charset=utf-8
< Content-Length: 0
< Cache-Control: max-age=33645
< Expires: Fri, 28 Oct 2016 23:29:12 GMT
< Date: Fri, 28 Oct 2016 14:08:27 GMT
< Connection: keep-alive
< 
* Connection #0 to host ocsp.int-x3.letsencrypt.org left intact

@fibigerg : आह, दिलचस्प। ऐसा लगता है कि कर्ल IPv4 का उपयोग करके डोमेन को हल कर रहा है, लेकिन nginx के अंदर कनेक्शन IPv6 (और विफल) का उपयोग करने का प्रयास कर रहा है। आपने nginx में कौन सी resolver सेटिंग कॉन्फ़िगर की है? क्या आप resolver 8.8.8.8 के साथ Google के DNS का उपयोग कर रहे हैं? और इसी तरह, आपका सिस्टम डिफ़ॉल्ट रूप से किस DNS सर्वर का उपयोग कर रहा है? एक linux सिस्टम पर, आपको इन्हें cat /etc/resolv.conf ( nameserver प्रविष्टियों के लिए देखें) द्वारा खोजने में सक्षम होना चाहिए।

मुझे संदेह है कि क्या हो रहा है कि आप nginx और डिफ़ॉल्ट सिस्टम वाले के बीच विभिन्न DNS सर्वर का उपयोग कर रहे हैं। दुर्भाग्य से, nginx डिफ़ॉल्ट सिस्टम DNS सर्वरों को नहीं उठाता है, इसलिए हमारा README एक उदाहरण के रूप में Google DNS प्रविष्टियों का उपयोग करता है। आमतौर पर यह ठीक है, लेकिन मुझे लगता है कि जो हो रहा है वह यह है कि Google का DNS IPv6 पतों को nginx पर लौटा रहा है, लेकिन आप ऐसे नेटवर्क पर हो सकते हैं जो पूरी तरह से IPv6 संगत नहीं है। इसलिए जब nginx IPv6 पते प्राप्त करता है और उससे कनेक्ट करने का प्रयास करता है, तो कनेक्शन विफल हो जाता है।

यदि ऐसा हो रहा है, तो मुझे लगता है कि यह शायद हल करने योग्य होना चाहिए यदि आप nginx resolver सेटिंग को डिफ़ॉल्ट रूप से आपके सिस्टम द्वारा उपयोग किए जाने वाले सर्वर से मेल खाते हैं (जो संभावित रूप से किसी भी आईपीवी 6 पते को वापस नहीं करेगा)।

जैसा कि आपने उल्लेख किया है, एसएसएल प्रमाणपत्र तब भी काम करेगा जब यह पहलू विफल हो जाएगा, यह सिर्फ इतना है कि प्रमाण पत्र ओसीएसपी स्टेपलिंग के साथ वापस नहीं किए जाएंगे (और nginx सफलता को कैशिंग करने के बजाय स्टेपलिंग अनुरोधों का अनुरोध करने का प्रयास करता रहेगा)।

मुझे Nginx को ipv6=off ध्वज के साथ कॉन्फ़िगर करके केवल IPv4 पते को हल करने का एक संकल्प मिला:

resolver 8.8.8.8 ipv6=off;

इसे हल करने में मदद कर सकते हैं। मैं इसे एडब्ल्यूएस पर चलाता हूं और जिस रिज़ॉल्वर आईपी का उपयोग किया जाना चाहिए वह अलग है:

resolver 172.16.0.23 ipv6=off;

(यह आईपी cat /etc/resolv.conf चलाकर और nameserver मूल्य की तलाश में पाया जा सकता है)

@GUI @berzniz समाधान के लिए धन्यवाद! हमने अपने डिजिटल महासागर VPS पर IPv6 को सक्षम किया है और त्रुटि दूर हो गई है।

सभी खोजी और डिबगिंग के लिए धन्यवाद, हर कोई!

चूंकि यह समस्या आपके सर्वर के नेटवर्क वातावरण (चाहे वह IPv6 संगत हो) और DNS सर्वर विकल्प (चाहे वे कोई IPv6 परिणाम लौटाएं) से उपजी प्रतीत होती है, ऐसा नहीं लगता कि इसे संभालने के लिए हम कोडिंग के दृष्टिकोण से बहुत कुछ कर सकते हैं। लेकिन मैंने उम्मीद के मुताबिक इसे स्पष्ट करने और समझाने के लिए रीडमे के उदाहरण में कुछ टिप्पणियां जोड़ी हैं: मुद्दा, लेकिन अगर किसी को अभी भी समस्या हो रही है या अन्य सुझाव हैं तो चिल्लाएं।

मैं देख रहा हूं "ओसीएसपी प्रतिक्रिया सफल नहीं है (6: अनधिकृत)", मुझे संदेह है कि यह इस मुद्दे से संबंधित हो सकता है और मैं एक नया बनाने से पहले दोबारा जांच करना चाहता हूं।

127.0.0.1 - - [03/जनवरी/2017:19:18:19 +0000] "पोस्ट/तैनाती-चुनौती HTTP/1.1" 200 5 "-" "कर्ल/7.47.0"
10.255.0.3 - - [03/जनवरी/2017:19:18:20 +0000] "प्राप्त करें/. (संगत; आइए सत्यापन सर्वर को एन्क्रिप्ट करें; +https://www.letsencrypt.org)"
127.0.0.1 - - [03/जनवरी/2017:19:18:22 +0000] "पोस्ट/क्लीन-चैलेंज HTTP/1.1" 200 5 "-" "कर्ल/7.47.0"
127.0.0.1 - - [03/जनवरी/2017:19:18:25 +0000] "पोस्ट/तैनाती-प्रमाणित HTTP/1.1" 200 30 "-" "कर्ल/7.47.0"
2017/01/03 19:18:26 [त्रुटि] 16#16: 3 [लुआ] ssl_certificate.

मुझे अनधिकृत प्रतिक्रिया क्यों मिलती है?

धन्यवाद

@ faguirre1 : यह "अनधिकृत" त्रुटि इस थ्रेड में पहले "नेटवर्क पहुंच योग्य" त्रुटि की तुलना में थोड़ी अलग समस्या की तरह दिखती है। लेकिन किसी भी मामले में, यदि आप अपने डोमेन के लिए एक और अनुरोध करते हैं, तो क्या आपको अपने nginx लॉग में वही OCSP त्रुटि मिलती है? कुछ अन्य मामलों में जहां Let's Encrypt OCSP "अनधिकृत" ( #1 , #2 ) लौटा रहा था, ऐसा लगता है कि Let's Encrypt के अंत में यह एक अस्थायी सर्वर समस्या थी।

यदि आप अभी भी अपने लॉग में वही त्रुटि देख रहे हैं, तो सर्वर से curl -v "http://ocsp.int-x3.letsencrypt.org/" चलाने पर आपको क्या आउटपुट मिलता है?

(और केवल स्पष्ट करने के लिए, इस त्रुटि के बावजूद, आपका एसएसएल प्रमाणपत्र पूरी तरह से मान्य होना चाहिए, यह सिर्फ इतना है कि ओसीएसपी स्टेपलिंग काम नहीं कर रहा है, जो एक अनुकूलन है ताकि ग्राहक ओसीएसपी लुकअप को स्वयं छोड़ सकें।)

नमस्ते,

उत्तर के लिए धन्यवाद, मुझे सभी अनुरोधों में एक ही त्रुटि मिली। लेकिन आज जाँच के बाद समस्या दूर हो गई है। ऐसा लगता है कि आप इसके बारे में सही थे, चलो एन्क्रिप्ट अंत पर एक मुद्दा था।

एक बार फिर धन्यवाद

ipv6=off जोड़ने से मेरे लिए भी यह समस्या हल हो गई। मैंने पहले resolv.conf में सूचीबद्ध DNS सर्वरों का उपयोग करने का प्रयास किया लेकिन इसका कोई प्रभाव नहीं पड़ा।

BTW @GUI , मुझे पसंद है कि lua-resty-auto-ssl SSL प्रक्रिया को कितना आसान बना रहा है! बहुत बढ़िया! क्या आपके पास दान स्वीकार करने की सुविधा है?

बस एक ही मुद्दे में भाग गया। ऐसा लगता है कि ipv6=off ने इसे भी हल कर दिया।

मुझे यकीन नहीं है कि यह कितना निकट से संबंधित हो सकता है, इसलिए मैं एक नया मुद्दा बनाने से पहले यहां पोस्ट करूंगा।

हमारे प्रमाणपत्रों की समय सीमा समाप्त होने से पहले, मैंने कल नवीनतम संस्करण में अपग्रेड किया, क्योंकि यह फिर से जारी करने में सक्षम नहीं था (#192 के समान मुद्दा), और आज भी, यह अभी भी नए प्रमाणपत्र जारी करने में कामयाब नहीं हुआ है।

लॉग में देखकर मुझे लगता है:

2019/11/24 12:50:45 [crit] 17#17: *3 connect() to [2600:1415:2000::17ce:f212]:80 failed (99: Address not available), context: ssl_certificate_by_lua*, client: 1.158.52.47, server: 0.0.0.0:443
2019/11/24 12:50:45 [error] 17#17: *3 [lua] ssl_certificate.lua:260: set_response_cert(): auto-ssl: failed to set ocsp stapling for <domain> - continuing anyway - failed to get ocsp response: OCSP responder query failed (http://ocsp.int-x3.letsencrypt.org): address not available, context: ssl_certificate_by_lua*, client: 1.158.52.47, server: 0.0.0.0:443

यह दिलचस्प है क्योंकि यह ipv6=off सहित रिज़ॉल्वर निर्देश के बावजूद IPv6 पते तक पहुंचने का प्रयास करता प्रतीत होता है, और चूंकि यह एक docker conatiner के भीतर चल रहा है जिसमें कोई ipv6 नेटवर्क नहीं है, यह विफल हो जाता है (परिणामस्वरूप 99: Address not available )।

मैंने उन सभी चीजों की कोशिश की है जिनके बारे में मैं तुरंत सोच सकता था, लेकिन मैंने कुछ स्पष्ट विकल्पों को याद किया है क्योंकि यह अब ऑस्ट्रेलिया में सुबह जल्दी है।

क्या किसी के पास कोई सुझाव है कि इस मामले में IPv6 पते को हल करने का क्या कारण हो सकता है? और इस समस्या को रोकने के लिए मुझे किस कॉन्फ़िगरेशन को बदलने की आवश्यकता हो सकती है, या तो nginx config में, या docker छवि और इसके संबंधित स्टैक में?

आप जो भी सहायता प्रदान कर सकते हैं उसके लिए धन्यवाद।

ठीक है, नई सुबह, मस्तिष्क वास्तव में काम कर रहा है, सबसे पहले मुझे कोशिश करनी चाहिए थी और भंडारण निर्देशिका में आपत्तिजनक प्रमाणपत्रों को हटा दिया। नए प्रमाण पत्र जारी करने में कोई समस्या नहीं थी। तो उल्टा, अभी के लिए सब कुछ तय है।

मैं अभी भी उत्सुक हूं कि इस मुद्दे का क्या कारण रहा होगा? दोनों मेरी अपनी समझ के लिए और इस घटना में यह बाद में फिर से अपना सिर उठाता है, इसलिए इनपुट की अभी भी सराहना की जाएगी।