2016-01-08 19 views
19

Tôi đang cố định cấu hình Let's Encrypt certificates trên máy chủ có thể truy cập công khai. Ban đầu, máy chủ ẩn đằng sau bộ định tuyến nhưng tôi đã chuyển tiếp các cổng 80 và 443.Hãy mã hóa thách thức DVSNI thất bại

Chứng chỉ dường như đã hoàn thành phần lớn quy trình cài đặt nhưng không thành công với thông báo: Failed to connect to host for DVSNI challenge.

Full stack trace:

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 

Bất kỳ hỗ trợ sẽ được đánh giá rất nhiều!

Tôi đã tìm kiếm giải pháp khác và không có nhiều may mắn. Hầu hết các tình huống tương tự khác đã được giải quyết bằng cách chuyển tiếp cổng 443, nhưng tôi chắc chắn cổng này đã được chuyển tiếp và mở, mặc dù không có dịch vụ nào hiện đang chạy trên đó.

Nó không nên tạo sự khác biệt, nhưng tôi đang cố định cấu hình chứng chỉ này để sử dụng với nút JS trên Raspberry Pi.

+0

Tôi gặp phải vấn đề tương tự. Tôi nhận ra rằng sau nhiều lần kiểm tra, cổng máy chủ 443 chỉ có thể được truy cập bởi IP của tôi. Vì vậy, tôi khuyên bạn nên kiểm tra cổng truy cập 443 của máy chủ, một lần nữa. Chúc may mắn. – efkan

Trả lời

12

Cuối cùng tôi đã tìm ra những gì đang diễn ra. Tôi phát hiện ra rằng các bước cờ --manual thông qua quá trình xác thực tương tác.

Mỗi giai đoạn trong quá trình này sẽ hiển thị một tương tự nhắc những điều sau đây:

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 

Như tôi đã phát hiện ra, quá trình này, dù đã được chạy như là người chủ bản thân, không có đặc quyền để khởi động server thách thức bản thân . Chắc chắn, đây có thể là lỗi trong API.

Chạy kịch bản trong dấu nhắc trực tiếp sản xuất các lỗi sau:

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

Nhưng chạy nó như là người chủ (như dấu nhắc bản thân nêu) bắt đầu máy chủ một cách chính xác và có thể được theo dõi như là máy chủ bên ngoài truy vấn nó để hoàn thành thử thách:

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 - 

lỗi này mất một thời gian để chẩn đoán như nhiều điều có thể đã ngăn chặn những thách thức từ thất bại và các máy chủ sinh ra đã thất bại trong âm thầm sau nền hệ thống.

+2

Wow - cảm ơn gợi ý '--manual'! – sage

8

Nếu bạn đang sử dụng DNS Cloudflare ở phía trước trang web của mình, hãy nhớ có DNS A, bản ghi AAAA trỏ trực tiếp đến trang web của bạn, tạm thời cho đến khi gia hạn hoàn tất.

+3

** Cloudflare trong trường hợp của tôi quá **. Vô hiệu hóa 'DNS và HTTP proxy' (Từ' cam' sang 'grey' cloud) trong cài đặt' DNS' đã giải quyết được vấn đề. –

1

Tôi cho rằng tất cả các bạn đã kiểm tra điều này. Lỗi tương tự được đưa ra cho tôi trong quá trình gia hạn. Tôi đã chuyển hướng lưu lượng truy cập từ 443 đến 8443 (với iptables). Giải pháp là để loại bỏ các mục từ iptables, ngừng tomcat, sau đó thực hiện quá trình đổi mới làm việc như một say mê. Kịch bản trông như thế này.

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

Tôi đã nhận lỗi tương tự khi cố gắng:

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

nhưng nó làm việc với:

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

Sau đó bạn cần thay đổi đường dẫn cert trong file conf apache (default- ssl.conf) và khởi động lại apache.

2

Tôi đã giải quyết vấn đề này bằng cách tắt IPv6 trên máy tính Ubuntu 14.04 của tôi cho Apache 2.4 vì máy chủ của tôi không có địa chỉ IPv6 thực. (Bài gốc trên 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)

Để thực hiện điều này, tôi dứt khoát thiết lập địa chỉ IP trong /etc/apache2/ports.conf:

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

và trong tất cả vhosts:

<VirtualHost <IP>:80> 

thay vì:

<VirtualHost *:80> 

Sau những thay đổi này, netstat -lnp | egrep ":443|:80" hiển thị tcp trong cột đầu tiên thay vì tcp6.

Sau đó, cerbot renew hoạt động như một sự quyến rũ.

2

Tôi đã chiến đấu trong vài giờ, hoàn thành với cùng một đầu ra trong nhật ký của mình. Tôi thậm chí còn theo dõi tất cả các khuyến nghị trên trang này. Tôi chỉ vấp phải câu trả lời của tôi. Tôi đã dán một số mã từ một webconfig khác và nó đã có một phần <virtual host _._._._:443> trong đó. Sau khi xóa phần 443, sudo certbot-auto --apache -d example.com chạy mà không có lỗi và tôi đã có một trang web đang hoạt động.

Tôi chỉ rút ra kết luận từ kinh nghiệm của mình: đảm bảo bạn chỉ có máy chủ ảo cho cổng 80. Không có tài liệu nào tôi đọc đề cập đến vấn đề này, nhưng có vẻ như certbot không chơi tốt với tệp conf có sẵn trên trang web đã chứa phần máy chủ ảo 443.

Các vấn đề liên quan