web-dev-qa-db-ja.com

失敗したDVSNIチャレンジを暗号化しましょう

公にアクセス可能なサーバーで Let's Encrypt証明書 を構成しようとしています。元々、サーバーはルーターの後ろに隠れていましたが、その後ポート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を転送することで解決されましたが、現在このポートでサービスが実行されていないにもかかわらず、このポートはすでに転送されて開いているはずです。

違いはないはずですが、この証明書をRaspberry PiのNode JSで使用できるように構成しようとしています。

ssl-certificatelets-encrypt
19
James Taylor

私はついに何が起こっているのかを理解しました。 --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

しかし、（プロンプト自体が述べたように）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 -

多くのことでチャレンジの失敗を防ぐことができ、生成されたサーバーがバックグラウンドで静かに失敗していたため、このエラーの診断にはしばらく時間がかかりました。

12
James Taylor

サイトの前でCloudflare DNSを使用している場合は、更新が完了するまで一時的に、DNS A、AAAAレコードがサイトを直接指すようにしてください。

8
Jeff Tsay

私はこれを数時間戦ったが、私のログには同じ出力があった。このページのすべての推奨事項についてもフォローアップしました。私は私の答えを偶然見つけました。私は別のwebconfigからいくつかのコードを貼り付けており、すでに<virtual Host _._._._:443>セクション。その443セクションを削除した後、Sudo certbot-auto --Apache -d example.comエラーなしで実行され、作業サイトがありました。

私の経験からのみ結論を引き出しています：ポート80の仮想ホストのみがあることを確認してください。私が読んだドキュメントのどこにもこの問題が記載されていませんが、certbotは、すでに443仮想ホストセクション。

2
wruckie

サーバーに実際のIPv6アドレスがないため、Apache 2.4のUbuntu 14.04マシンで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/4 ）

これを実現するために、/etc/Apache2/ports.confにIPアドレスを明示的に設定します。

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

そして、すべての仮想ホストで：

<VirtualHost <IP>:80>

の代わりに：

<VirtualHost *:80>

これらの変更後、netstat -lnp | egrep ":443|:80"では、最初の列にtcp6ではなくtcpと表示されます。

その後、cerbot renewは魅​​力のように機能しました。

2
Frederick Thomssen

みなさんもチェックしていると思います。更新プロセス中に同じエラーが発生しました。トラフィックを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
1
Carlos Cavero

試したときに同じエラーが発生しました：

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

その後、Apache .confファイル（default-ssl.conf）の証明書パスを変更し、Apacheを再起動する必要があります。

0
user570605