Lua-resty-auto-ssl: تدبيس OCSP: لا يمكن الوصول إلى الشبكة

هل حددت المحلل؟
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's OCSP. من هذا الخادم نفسه حيث تم تثبيت lua-resty-auto-ssl ، هل يمكنك إنشاء اتصال يدويًا بخادم Let's Encrypt OCSP الافتراضي؟ يمكنك اختبار ذلك باستخدام هذا الأمر:

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

من المفترض أن ترى ردًا بالحالة "200 موافق". إذا كنت لا ترى ذلك ، فهل يمكنك نشر الإخراج؟ أو هل هناك أي شيء على شبكتك يمكنك التفكير فيه يمنع هذا الطلب الصادر؟

تجدر الإشارة أيضًا إلى أنه في هذه الحالة ، لا يزال يجب أن يكون لديك شهادة SSL صالحة ، على الرغم من الخطأ في ملف السجل. هذا يعني ببساطة أن تدبيس 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 ، السجلات فارغة) كل aprox. 10 ساعات. هل هذا مرتبط؟ أي فكرة عن كيفية إصلاح ذلك؟ شكرا

ملاحظة: أنا لا أتعرف على عناوين IPv6 تلك.

GUI curl يعمل ، أي فكرة أخرى؟ تعمل الشهادات بشكل جيد ، ومع ذلك ، يحتوي السجل الخاص بي على هذا الخطأ عند تحميل كل صفحة. شكرا

[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 : آه ، مثير للاهتمام. يبدو أن curl يحل المجال باستخدام IPv4 ، لكن الاتصال داخل nginx يحاول استخدام IPv6 (ويفشل). ما هو إعداد resolver الذي قمت بتكوينه في nginx؟ هل تستخدم DNS الخاص بـ Google مع resolver 8.8.8.8 ؟ وبالمثل ، ما هي خوادم DNS التي يستخدمها نظامك بشكل افتراضي؟ في نظام Linux ، يجب أن تكون قادرًا على العثور عليها بواسطة cat /etc/resolv.conf (ابحث عن مدخلات nameserver ).

أظن أن ما يحدث هو أنك تستخدم خوادم DNS مختلفة بين nginx وخوادم النظام الافتراضية. لسوء الحظ ، لا يلتقط nginx خوادم DNS الافتراضية للنظام ، ولهذا السبب يستخدم README إدخالات Google DNS كمثال. عادةً ما يكون هذا على ما يرام ، لكنني أعتقد أن ما قد يحدث هو أن DNS الخاص بـ Google يعيد عناوين IPv6 إلى nginx ، ولكن قد تكون على شبكة غير متوافقة تمامًا مع IPv6. لذلك بعد أن يستقبل nginx عناوين IPv6 ويحاول الاتصال بها ، يفشل الاتصال.

إذا كان هذا ما يحدث ، فأعتقد أنه من المحتمل أن يكون هذا قابلاً للحل إذا جعلت إعداد nginx resolver يطابق أي خوادم يستخدمها نظامك افتراضيًا (والتي من المفترض أنها لن تُرجع أي عناوين IPv6).

كما أشرت ، ستستمر شهادات SSL في العمل عندما يفشل هذا الجانب ، فالأمر يتعلق فقط بعدم إرجاع الشهادات مع تدبيس OCSP (وسيستمر nginx في طلب طلبات التدبيس ، بدلاً من تخزين النجاح مؤقتًا).

لقد وجدت حلًا لحل عنوان IPv4 فقط من خلال تكوين Nginx باستخدام علامة ipv6=off :

resolver 8.8.8.8 ipv6=off;

يمكن أن تساعد في حل هذا. أقوم بتشغيل هذا على AWS ويكون عنوان IP للمحلل الذي يجب استخدامه مختلفًا:

resolver 172.16.0.23 ipv6=off;

(يمكن العثور على عنوان IP هذا بتشغيل cat /etc/resolv.conf والبحث عن قيمة nameserver )

GUIberzniz شكرا لك على الحلول! لقد قمنا بتمكين IPv6 على خوادمنا الافتراضية الخاصة للمحيطات الرقمية وذهب الخطأ.

شكرًا على جميع عمليات التجسس والتصحيح ، جميعًا!

نظرًا لأن هذه المشكلة يبدو أنها تنبع من بيئة شبكة الخادم (سواء كانت متوافقة مع IPv6) وخيارات خادم DNS (سواء كانت تعرض أي نتائج IPv6) ، فلا يبدو أن هناك الكثير الذي يمكننا القيام به من منظور الترميز للتعامل مع هذا. لكني أضفت بعض التعليقات إلى مثال README لأتمنى توضيح هذا الأمر وتوضيحه: https://github.com/GUI/lua-resty-auto-ssl/commit/856f52fb096c29f950dda83b3201faa5557a239b لذا سأذهب وأغلق هذا المشكلة ، ولكن صرخ إذا كان أي شخص لا يزال يواجه مشاكل أو لديه اقتراحات أخرى.

أرى "استجابة OCSP غير ناجحة (6: غير مصرح به)" ، أظن أنه قد يكون مرتبطًا بهذه المشكلة وأريد التحقق مرة أخرى قبل إنشاء واحدة جديدة.

127.0.0.1 - - [03 / يناير / 2017: 19:18: 19 +0000] "POST / publish-تحدي HTTP / 1.1" 200 5 "-" "curl / 7.47.0"
10.255.0.3 - - [03 / يناير / 2017: 19: 18: 20 +0000] "GET /.well-known/acme-challenge/i64vxEpJN-wUE-OvK7tKh0M3o842VcXSSEoyxtCd7Wk HTTP / 1.1" 200 99 "-" "Mozilla / 5.0 (متوافق ؛ دعنا نشفر خادم التحقق ؛ + https: //www.letsencrypt.org) "
127.0.0.1 - - [03 / يناير / 2017: 19: 18: 22 +0000] "POST / clean-Challenge HTTP / 1.1" 200 5 "-" "curl / 7.47.0"
127.0.0.1 - [03 / يناير / 2017: 19:18: 25 +0000] "POST / publish-cert HTTP / 1.1" 200 30 "-" "curl / 7.47.0"
2017/01/03 19:18:26 [خطأ] 16 # 16: 3 [lua] ssl_certificate.

لماذا أحصل على الرد غير المصرح به؟

شكرا

@ faguirre1 : يبدو هذا الخطأ "غير المصرح به" مشكلة مختلفة قليلاً عن الخطأ السابق "الشبكة غير قابلة للوصول" في هذا الموضوع. ولكن على أي حال ، إذا قمت بتقديم طلب آخر إلى المجال الخاص بك ، فهل تحصل على نفس خطأ OCSP في سجلات nginx الخاصة بك؟ في حالتين أخريين حيث كان Let's Encrypt OCSP يعيد "غير مصرح به" ( # 1 ، # 2 ) ، يبدو أن هذه كانت مشكلة خادم مؤقتة في نهاية Let's Encrypt.

إذا كنت لا تزال ترى نفس الخطأ في سجلاتك ، فما الناتج الذي تحصل عليه عند تشغيل curl -v "http://ocsp.int-x3.letsencrypt.org/" من الخادم؟

(وللتوضيح فقط ، على الرغم من هذا الخطأ ، يجب أن تكون شهادة SSL الخاصة بك صالحة تمامًا كما هي ، فقط أن تدبيس OCSP لا يعمل ، وهو تحسين حتى يتمكن العملاء من تخطي عمليات بحث OCSP بأنفسهم.)

أهلا،

شكرًا على الإجابة ، لقد تلقيت نفس الخطأ في جميع الطلبات. ولكن بعد التحقق اليوم اختفت المشكلة. يبدو أنك كنت محقًا بشأن ذلك ، فقد كانت مشكلة تتعلق بنهاية التشفير.

شكرا لك مرة أخرى

أدت إضافة ipv6=off حل هذه المشكلة بالنسبة لي أيضًا. حاولت أولاً استخدام خوادم DNS كما هو مدرج في resolv.conf لكن ذلك لم يكن له أي تأثير.

راجع للشغل GUI ، أحب مدى سهولة lua-resty-auto-ssl في إجراء عملية SSL! أتقنه! هل لديك مرفق لقبول التبرعات؟

فقط واجهت نفس المشكلة. يبدو أن ipv6 = إيقاف حلها أيضًا.

لست متأكدًا من مدى الارتباط الوثيق بين هذا الأمر ، لذلك سأقوم بالنشر هنا قبل إنشاء عدد جديد.

لقد قمت بالترقية إلى أحدث إصدار أمس ، قبل انتهاء صلاحية شهاداتنا ، حيث لم نتمكن من إعادة الإصدار (نفس المشكلة مثل # 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 ، على الرغم من تعليمات المحلل بما في ذلك ipv6=off ، وبما أن هذا يعمل داخل عامل ميناء مع عدم وجود شبكة ipv6 ، فإنه يفشل (مما أدى إلى 99: Address not available ).

لقد جربت كل الأشياء التي كان بإمكاني التفكير فيها على الفور ، لكنني على الأرجح فاتني بعض الخيارات الواضحة حيث إنها الآن في وقت مبكر من الصباح هنا في أستراليا.

هل لدى أي شخص أي اقتراحات بشأن سبب حل عنوان IPv6 في هذه الحالة؟ وما هو التكوين الذي قد أحتاج إلى تغييره ، سواء في تكوين nginx أو في صورة عامل الإرساء والمكدس المرتبط به لمنع حدوث هذه المشكلة؟

شكرا لأية مساعدة يمكنك تقديمها.

حسنًا ، صباحًا جديدًا ، عمل الدماغ بالفعل ، فعل أول شيء كان يجب أن أجربه وأزلت الشهادات المخالفة في دليل التخزين. لم يكن هناك مشكلة في إصدار شهادات جديدة. لذلك على الجانب الإيجابي ، تم إصلاح كل شيء في الوقت الحالي.

ما زلت أشعر بالفضول لمعرفة سبب هذه المشكلة؟ من أجل فهمي الشخصي وفي حالة ظهور هذا الأمر مرة أخرى لاحقًا ، لذلك فإن المدخلات ستظل موضع تقدير.