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 : Похоже, что происходит сбой, когда ваш сервер пытается сделать исходящий запрос на сервер OCSP Let's Encrypt. С того же сервера, на котором у вас установлен lua-resty-auto-ssl, можете ли вы вручную установить соединение с OCSP-сервером Let’s Encrypt по умолчанию? Вы можете проверить это с помощью этой команды:

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

Вы должны увидеть ответ со статусом «200 OK». Если вы этого не видите, можете ли вы опубликовать вывод? Или вы можете придумать что-нибудь в вашей сети, что могло бы предотвратить этот исходящий запрос?

Также стоит отметить, что в этом случае у вас все равно должен быть действующий 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 не загружается, журналы пусты) каждый прибл. 10 часов. Это связано? Есть идеи, как это исправить? Спасибо

PS Я не узнаю эти 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 )

@GUI @berzniz Спасибо за решения! Мы включили IPv6 на наших VPS Digital Ocean, и ошибка исчезла.

Всем спасибо за поиск и отладку!

Поскольку эта проблема, похоже, связана с сетевой средой вашего сервера (независимо от того, совместим ли он с 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 /deploy-challenge 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 (совместимо; сервер проверки Let's Encrypt; +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 /deploy-cert HTTP/1.1" 200 30 "-" "curl/7.47.0"
03.01.2017, 19:18:26 [ошибка] 16#16: 3 [lua] ssl_certificate.

почему я получаю неавторизованный ответ?

Спасибо

@faguirre1 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=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-адреса, несмотря на инструкцию преобразователя, включающую ipv6=off , и, поскольку он работает в контейнере докеров без сети ipv6, он терпит неудачу (в результате 99: Address not available ).

Я перепробовал все, что мог сразу придумать, но, вероятно, пропустил некоторые очевидные варианты, так как сейчас раннее утро здесь, в Австралии.

Есть ли у кого-нибудь какие-либо предложения относительно того, что может привести к разрешению адреса IPv6 в этом случае? и какую конфигурацию мне может потребоваться изменить либо в конфигурации nginx, либо в образе докера и связанном с ним стеке, чтобы предотвратить эту проблему?

Спасибо за любую помощь, которую вы можете предоставить.

Хорошо, новое утро, мозг на самом деле работает, я сделал первое, что я должен был попробовать, и удалил оскорбительные сертификаты в каталоге хранилища. Проблем с выдачей новых сертификатов не было. так что с другой стороны, на данный момент все исправлено.

Мне все еще любопытно, что могло вызвать эту проблему? как для моего собственного понимания, так и в случае, если это снова всплывет позже, поэтому вклад все равно будет оценен.