Lua-resty-auto-ssl: Stapel OCSP: Jaringan tidak dapat dijangkau

Apakah Anda menentukan resolver?
resolver 8.8.8.8;

Ya

ini sepertinya masalah infrastruktur, seperti Anda tidak mendengarkan di port 80. apakah Anda menggunakan buruh pelabuhan?

Ya

Anda dapat mencoba gambar saya sendiri dan melihat apakah itu berfungsi: https://hub.docker.com/r/Pushtospace/nginx/

Saya akan mencoba jika saya punya waktu.
Milikku:

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 : Ini sepertinya gagal ketika server Anda mencoba membuat permintaan keluar ke server OCSP Let's Encrypt. Dari server yang sama di mana Anda telah menginstal lua-resty-auto-ssl, apakah Anda dapat membuat koneksi secara manual ke server Let's Encrypt OCSP default? Anda dapat mengujinya dengan perintah ini:

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

Anda akan melihat respons dengan status "200 OK". Jika Anda tidak melihatnya, dapatkah Anda memposting hasilnya? Atau adakah sesuatu di jaringan Anda yang menurut Anda dapat mencegah permintaan keluar ini?

Perlu juga dicatat bahwa dalam kasus ini, Anda harus tetap memiliki sertifikat SSL yang valid, meskipun ada kesalahan dalam file log. Ini berarti bahwa stapel OCSP telah gagal, jadi terserah klien untuk melakukan validasi OCSP apa pun.

Mungkin ada hubungannya dengan IPv6? saya mengerti ini

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

Setelah saya me-refresh halaman setelah muncul halaman https yang berfungsi.

Sama di sini, ada ide apa yang salah?

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

Kami mengalami Nginx/Openresty freeze (halaman nginx_status tidak dimuat, log kosong) setiap kira-kira. 10 jam. Apakah ini terhubung? Ada ide bagaimana cara memperbaikinya? Terima kasih

PS Saya tidak mengenali alamat IPv6 itu.

@GUI curl berfungsi, ada ide lain? Sertifikat berfungsi dengan baik, namun log saya memiliki kesalahan ini untuk setiap pemuatan halaman. Terima kasih

[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 : Ah, menarik. Sepertinya curl sedang menyelesaikan domain menggunakan IPv4, tetapi koneksi di dalam nginx mencoba menggunakan IPv6 (dan gagal). Pengaturan resolver apa yang telah Anda konfigurasikan di nginx? Apakah Anda menggunakan DNS Google dengan resolver 8.8.8.8 ? Dan juga, server DNS apa yang digunakan sistem Anda secara default? Pada sistem linux, Anda seharusnya dapat menemukannya dengan cat /etc/resolv.conf (cari entri nameserver ).

Saya menduga apa yang terjadi adalah Anda menggunakan server DNS yang berbeda antara nginx dan sistem default. Sayangnya, nginx tidak mengambil server DNS sistem default, jadi itulah mengapa README kami menggunakan entri DNS Google sebagai contoh. Biasanya ini baik-baik saja, tetapi saya pikir apa yang mungkin terjadi adalah DNS Google mengembalikan alamat IPv6 ke nginx, tetapi Anda mungkin berada di jaringan yang tidak sepenuhnya kompatibel dengan IPv6. Jadi setelah nginx menerima alamat IPv6 dan mencoba menghubungkannya, koneksi gagal.

Jika itu yang terjadi, maka saya pikir ini mungkin harus diselesaikan jika Anda membuat pengaturan nginx resolver cocok dengan server apa pun yang digunakan sistem Anda secara default (yang mungkin tidak akan mengembalikan alamat IPv6 apa pun).

Seperti yang Anda catat, sertifikat SSL akan tetap berfungsi saat aspek ini gagal, hanya saja sertifikat tidak akan dikembalikan dengan penstaplesan OCSP (dan nginx akan terus mencoba meminta permintaan penjepretan, alih-alih menyimpan keberhasilan dalam cache).

Saya menemukan resolusi untuk hanya menyelesaikan alamat IPv4 dengan mengonfigurasi Nginx dengan flag ipv6=off :

resolver 8.8.8.8 ipv6=off;

dapat membantu menyelesaikan ini. Saya menjalankan ini di AWS dan IP resolver yang harus digunakan berbeda:

resolver 172.16.0.23 ipv6=off;

(IP ini dapat ditemukan dengan menjalankan cat /etc/resolv.conf dan mencari nilai nameserver )

@GUI @berzniz Terima kasih atas solusinya! Kami telah mengaktifkan IPv6 di VPS Digital Ocean kami dan kesalahannya hilang.

Terima kasih untuk semua penyelidikan dan debugging, semuanya!

Karena masalah ini tampaknya berasal dari lingkungan jaringan server Anda (apakah itu kompatibel dengan IPv6) dan pilihan server DNS (apakah mereka mengembalikan hasil IPv6), sepertinya tidak banyak yang dapat kami lakukan dari perspektif pengkodean untuk menangani ini. Tetapi saya telah menambahkan beberapa komentar ke contoh README untuk semoga memperjelas dan menjelaskan ini: https://github.com/GUI/lua-resty-auto-ssl/commit/856f52fb096c29f950dda83b3201faa5557a239b Jadi saya akan melanjutkan dan menutup ini masalah, tetapi beri tahu jika ada yang masih mengalami masalah atau memiliki saran lain.

Saya melihat "Respons OCSP tidak berhasil (6: tidak sah)", saya menduga itu mungkin terkait dengan masalah ini dan saya ingin memeriksa ulang sebelum membuat yang baru.

127.0.0.1 - - [03/Jan/2017:19:18:19 +0000] "POST /deploy-challenge HTTP/1.1" 200 5 "-" "curl/7.47.0"
10.255.0.3 - - [03/Jan/2017:19:18:20 +0000] "GET /.well-known/acme-challenge/i64vxEpJN-wUE-OvK7tKh0M3o842VcXSSEoyxtCd7Wk HTTP/1.1" 200 99 "-" "Mozilla/5.0 (kompatibel; Let's Encrypt validasi server; +https://www.letsencrypt.org)"
127.0.0.1 - - [03/Jan/2017:19:18:22 +0000] "POST /clean-challenge HTTP/1.1" 200 5 "-" "curl/7.47.0"
127.0.0.1 - - [03/Jan/2017:19:18:25 +0000] "POST /deploy-cert HTTP/1.1" 200 30 "-" "curl/7.47.0"
2017/01/03 19:18:26 [kesalahan] 16#16: 3 [lua] ssl_certificate.

mengapa saya mendapatkan tanggapan yang tidak sah?

Terima kasih

@faguirre1 : Kesalahan "tidak sah" ini terlihat seperti masalah yang sedikit berbeda dari kesalahan "jaringan tidak dapat dijangkau" sebelumnya di utas ini. Tetapi bagaimanapun juga, jika Anda membuat permintaan lain ke domain Anda, apakah Anda mendapatkan kesalahan OCSP yang sama di log nginx Anda? Dalam beberapa kasus lain di mana Let's Encrypt OCSP mengembalikan "tidak sah" ( #1 , #2 ), sepertinya ini adalah masalah server sementara di akhir Let's Encrypt.

Jika Anda masih melihat kesalahan yang sama di log Anda, output apa yang Anda dapatkan saat menjalankan curl -v "http://ocsp.int-x3.letsencrypt.org/" dari server?

(Dan untuk memperjelas, terlepas dari kesalahan ini, sertifikat SSL Anda harus benar-benar valid apa adanya, hanya saja OCSP stapel tidak berfungsi, yang merupakan pengoptimalan sehingga klien dapat melewati pencarian OCSP sendiri.)

Hai,

terima kasih atas jawabannya, saya mendapat kesalahan yang sama di semua permintaan. tetapi setelah memeriksa hari ini masalahnya hilang. sepertinya Anda benar tentang itu adalah masalah mari mengenkripsi akhir.

Terima kasih lagi

Menambahkan ipv6=off memecahkan masalah ini untuk saya juga. Saya pertama kali mencoba menggunakan server DNS seperti yang tercantum dalam resolv.conf tetapi itu tidak berpengaruh.

BTW @GUI , saya suka betapa mudahnya lua-resty-auto-ssl membuat proses SSL! Sudah selesai dilakukan dengan baik! Apakah Anda memiliki fasilitas untuk menerima sumbangan?

Baru saja mengalami masalah yang sama. Sepertinya ipv6=off menyelesaikannya juga.

Saya tidak yakin seberapa dekat hubungannya, jadi saya akan memposting di sini sebelum membuat masalah baru.

Saya memutakhirkan ke versi terbaru kemarin, sebelum sertifikat kami kedaluwarsa, karena tidak dapat menerbitkan kembali (masalah yang sama dengan # 192), dan hari ini, masih belum berhasil mengeluarkan sertifikat baru.

Melihat ke dalam log saya menemukan:

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

Ini menarik karena tampaknya mencoba mencapai alamat IPv6, meskipun instruksi resolver menyertakan ipv6=off , dan karena ini berjalan dalam conatiner buruh pelabuhan tanpa jaringan ipv6, ia gagal (menghasilkan 99: Address not available ).

Saya telah mencoba semua hal yang dapat segera saya pikirkan, tetapi saya mungkin melewatkan beberapa opsi yang jelas karena sekarang masih pagi di sini di Australia.

Adakah yang punya saran tentang apa yang mungkin menyebabkannya menyelesaikan alamat IPv6 dalam kasus ini? dan konfigurasi apa yang mungkin perlu saya ubah, baik di konfigurasi nginx, atau di gambar buruh pelabuhan dan tumpukan terkait untuk mencegah masalah ini?

Terima kasih atas bantuan apa pun yang dapat Anda berikan.

Oke, pagi baru, otak benar-benar berfungsi, melakukan hal pertama yang seharusnya saya coba dan menghapus sertifikat yang menyinggung di direktori penyimpanan. Tidak ada masalah dalam menerbitkan sertifikat baru. jadi pada sisi baiknya, semuanya sudah diperbaiki untuk saat ini.

Saya masih penasaran apa yang menyebabkan masalah ini? baik untuk pemahaman saya sendiri dan jika ini muncul lagi nanti, jadi masukan akan tetap dihargai.