Подтвердить что ты не робот

Разрешить шифрование с ошибкой DVSNI Challenge

Я пытаюсь настроить Разрешить шифрование сертификатов на общедоступном сервере. Первоначально сервер скрывался за маршрутизатором, но с тех пор я переправил порты 80 и 443.

Сертификат, похоже, завершил большую часть процесса установки, но с сообщением об ошибке: Failed to connect to host for DVSNI challenge.

Полная трассировка стека:

Updating letsencrypt and virtual environment dependencies......
    Requesting root privileges to run with virtualenv: sudo /bin/letsencrypt certonly --standalone -d example.net -d www.example.net
    Failed authorization procedure. example.net (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to host for DVSNI challenge

IMPORTANT NOTES:
 - The following 'urn:acme:error:connection' errors were reported by
   the server:

   Domains: example.net
   Error: The server could not connect to the client to verify the
   domain

Любая поддержка будет принята с благодарностью!

Я огляделся где-то в другом месте для решения и не имел большой удачи. Большинство других подобных ситуаций были устранены переадресацией порта 443, но я уверен, что этот порт уже отправлен и открыт, хотя в настоящее время на нем не работает служба.

Это не должно меняться, но я пытаюсь настроить этот сертификат для использования с Node JS на малине Pi.

4b9b3361

ОТВЕТЫ

Ответ 1

Наконец я понял, что происходит. Я обнаружил, что флаг --manual выполняет интерактивный процесс аутентификации.

Каждая фаза процесса отображает приглашение, подобное следующему:

Make sure your web server displays the following content at
http://www.example.net/.well-known/acme-challenge/twJCKQm9SbPEapgHpyU5TdAR1ErRaiCyxEB5zhhw0w8 before continuing:

twJCKQm9SbPEapgHpyU5TdAR1ErRaiCyxEB5zhhw0w8.t7J7DDTbktMGCCu2KREoIHv1zwkvwGfJTAkJrnELb4U

If you don't have HTTP server configured, you can run the following
command on the target server (as root):

mkdir -p /tmp/letsencrypt/public_html/.well-known/acme-challenge
cd /tmp/letsencrypt/public_html
printf "%s" twJCKQm9SbPEapgHpyU5TdAR1ErRaiCyxEB5zhhw0w8.t7J7DDTbktMGCCu2KREoIHv1zwkvwGfJTAkJrnELb4U > .well-known/acme-challenge/twJCKQm9SbPEapgHpyU5TdAR1ErRaiCyxEB5zhhw0w8
# run only once per server:
$(command -v python2 || command -v python2.7 || command -v python2.6) -c \
"import BaseHTTPServer, SimpleHTTPServer; \
s = BaseHTTPServer.HTTPServer(('', 80), SimpleHTTPServer.SimpleHTTPRequestHandler); \
s.serve_forever()"

Press ENTER to continue

Как я обнаружил, процесс, несмотря на то, что он запускался как сам корень, не имел привилегий для запуска самого сервера запросов. Несомненно, это может быть ошибкой в ​​API.

Запуск script в строке запроса вызывает следующую ошибку:

$(command -v python2 || command -v python2.7 || command -v python2.6) -c \
> "import BaseHTTPServer, SimpleHTTPServer; \
> s = BaseHTTPServer.HTTPServer(('', 80), SimpleHTTPServer.SimpleHTTPRequestHandler); \
> s.serve_forever()"

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/SocketServer.py", line 419, in __init__
    self.server_bind()
  File "/usr/lib/python2.7/BaseHTTPServer.py", line 108, in server_bind
    SocketServer.TCPServer.server_bind(self)
  File "/usr/lib/python2.7/SocketServer.py", line 430, in server_bind
    self.socket.bind(self.server_address)
  File "/usr/lib/python2.7/socket.py", line 224, in meth
    return getattr(self._sock,name)(*args)
socket.error: [Errno 13] Permission denied

Но запустив его как root (как указано самим подсказкой), он начал правильно и мог отслеживаться, поскольку внешний сервер запросил его для завершения задачи:

sudo $(command -v python2 || command -v python2.7 || command -v python2.6) -c "import BaseHTTPServer, SimpleHTTPServer; \
s = BaseHTTPServer.HTTPServer(('', 80), SimpleHTTPServer.SimpleHTTPRequestHandler); \
s.serve_forever()"

66.133.109.36 - - [08/Jan/2016 21:25:10] "GET /.well-known/acme-challenge/SZ88SorxBGXBtSZCTn4FX2g7u5XjnPFOOV3f5S5DuXB HTTP/1.1" 200 -
66.133.109.36 - - [08/Jan/2016 21:25:10] "GET /.well-known/acme-challenge/twJCKQm9SbPEapgHpyU5TdAR1ErRaiCyxEB5zhhw0w8 HTTP/1.1" 200 -

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

Ответ 2

Если вы используете Cloudflare DNS перед своим сайтом, помните, что DNS A, AAAA записывается прямо на ваш сайт, временно, пока обновление не закончится.

Ответ 3

Я решил эту проблему, отключив IPv6 на моем компьютере Ubuntu 14.04 для Apache 2.4, так как у моего сервера нет реального IPv6-адреса. (Оригинальное сообщение на https://community.letsencrypt.org/t/how-to-resolve-the-correct-zname-not-found-for-tls-sni-challenge-error-when-i-try-renew-certificate/9405/43)

Для этого я явно устанавливаю IP-адрес в /etc/apache2/ports.conf:

Listen <IP>:80
Listen <IP>:443

и во всех vhosts:

<VirtualHost <IP>:80>

вместо:

<VirtualHost *:80>

После этих изменений netstat -lnp | egrep ":443|:80" показывает tcp в первом столбце вместо tcp6.

Затем cerbot renew работал как шарм.

Ответ 4

Я боролся с этим несколько часов, в том же выпуске в моих журналах. Я даже рассмотрел все рекомендации на этой странице. Я только наткнулся на свой ответ. Я вставил код из другого webconfig, и в нем уже был раздел <virtual host _._._._:443>. Удалив этот раздел 443, sudo certbot-auto --apache -d example.com работал без ошибок, и у меня был рабочий сайт.

Я делаю выводы только по своему опыту: убедитесь, что у вас есть только виртуальные хосты для порта 80. Нигде в документации, которую я читал, не упоминалось об этой проблеме, но похоже, что certbot не играет хорошенько с файлом conf, доступным на сайте, уже содержит раздел виртуального хоста 443.

Ответ 5

Полагаю, вы все уже проверили это. Такая же ошибка возникла во время процесса обновления. Я перенаправил трафик с 443 до 8443 (с iptables). Решение заключалось в том, чтобы удалить запись из iptables, остановить tomcat, а затем выполнить процесс обновления, работающий как шарм. script выглядит следующим образом.

/etc/init.d/tomcat7 stop
iptables -t nat -D PREROUTING -i eth0 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443

$letsencryptdir/letsencrypt-auto renew --standalone --standalone-supported-challenges tls-sni-01 --renew-by-default --email <my_email> --verbose --text  --agree-tos

iptables -t nat -I PREROUTING -i eth0 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443
/etc/init.d/tomcat7 start

Ответ 6

Я получил ту же ошибку при попытке:

./letsencrypt-auto --apache  -d example.com -d www.example.com

но он работал с:

./letsencrypt-auto certonly --webroot -w /var/www/html -d example.com -d www.example.com

После этого вам нужно изменить пути cert в файле apache.conf(default-ssl.conf) и перезапустить apache.