Давайте зашифруем ошибку DVSNI

Question

Я пытаюсь настроить Let's Encrypt certificates на общедоступном сервере. Первоначально сервер скрывался за маршрутизатором, но с тех пор я переправил порты 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.

Answer 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.

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

$(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 

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

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 - 

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

Answer 2

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

Answer 3

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

/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 

Answer 4

Я получил ту же ошибку, когда пытался:

./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 пути в апача файле .conf (default- ssl.conf) и перезапустите apache.

Answer 5

Я решил эту проблему, отключив 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 

и во всех виртуальный хост одновременно:

<VirtualHost <IP>:80> 

вместо:

<VirtualHost *:80> 

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

Затем cerbot renew работал как очарование.

Answer 6

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

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