讓我們加密失敗的DVSNI挑戰

我試圖在可公開訪問的服務器上配置Let's Encrypt certificates。最初，服務器隱藏在路由器後面，但我已經轉發了端口80和443.讓我們加密失敗的DVSNI挑戰

證書似乎已完成大部分安裝過程，但失敗並顯示消息：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一起使用。

來源

2016-01-08 James Taylor

我曾經遇到同樣的問題。我意識到經過多次檢查，服務器443端口只能通過我的IP訪問。所以，我建議再次檢查服務器的訪問端口443。祝你好運。 – efkan

我終於搞清楚發生了什麼事。我發現--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

正如我發現，這個過程中，儘管被以root身份運行本身沒有足夠的權限啓動質詢服務器本身。當然，這可能是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 -

這個錯誤了一段時間，因爲許多事情可以從失敗阻止了挑戰和服務器催生了在後臺靜默未能診斷。

來源

2016-01-09 08:27:31

哇 - 感謝' - 手動'提示！ – sage

如果您在您的網站前使用Cloudflare DNS，請記得暫時將DNS A，AAAA記錄直接指向您的站點，直到續訂完成。

來源

2016-03-18 20:11:13

** Cloudflare在我的情況下也**。在「DNS」設置下禁用「DNS和HTTP代理」（從「橙色」到「灰色」雲）解決了問題。 –

我想你們都已經檢查過了。更新過程中向我提出的同樣的錯誤。我將流量從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

來源

2016-05-05 19:18:09

我得到了同樣的錯誤嘗試時：

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

之後，你需要更改阿帕奇.conf文件證書路徑（默認 - ssl.conf）並重新啓動apache。

來源

2016-05-11 22:02:08 user570605

我解決了這個問題，在我的Ubuntu 14.04機器上爲Apache 2.4禁用了IPv6，因爲我的服務器沒有真正的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就像一個魅力。

來源

2016-05-18 09:21:52

我打了幾個小時，在我的日誌中完成了相同的輸出。我甚至跟進了本頁面上的所有建議。我只是偶然發現了我的答案。我從另一個webconfig粘貼了一些代碼，它已經有一個<virtual host _._._._:443>部分。刪除443部分後，sudo certbot-auto --apache -d example.com無誤地運行，我有一個工作站點。

我只根據我的經驗得出結論：確保您只有端口80的虛擬主機。我讀過的文檔中沒有提到這個問題，但似乎certbot不能很好地與網站可用的conf文件已包含443個虛擬主機部分。

來源

2017-01-05 19:26:01 wruckie

讓我們加密失敗的DVSNI挑戰

回答

相關問題