Let 's verschlüsseln fehlgeschlagene DVSNI-Herausforderung

Question

Ich versuche, Let's Encrypt certificates auf einem Server zu konfigurieren, der öffentlich zugänglich ist. Ursprünglich versteckte sich der Server hinter einem Router, aber ich habe seitdem Ports 80 und 443 weitergeleitet.

Das Zertifikat scheint einen Großteil des Installationsvorgangs abgeschlossen haben, schlägt aber mit der Nachricht fehl: Failed to connect to host for DVSNI challenge.

Voll 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 

Jede Unterstützung würde sehr geschätzt werden!

Ich suchte anderswo nach einer Lösung und hatte nicht viel Glück. Die meisten anderen ähnlichen Situationen wurden durch Weiterleiten von Port 443 gelöst, aber ich bin mir sicher, dass dieser Port bereits weitergeleitet und geöffnet ist, obwohl momentan kein Dienst darauf läuft.

Es sollte keinen Unterschied machen, aber ich versuche, dieses Zertifikat für mit Knoten JS auf einem Raspberry Pi zu konfigurieren.

Answer 1

Ich endlich herausgefunden, was los war. Ich entdeckte, dass das Flag --manual interaktiv durch den Authentifizierungsprozess schreitet.

Jede Phase in dem Prozess wird eine Eingabeaufforderung ähnlich der folgenden angezeigt:

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 

Als ich den Prozess entdeckt, trotz sich als Root ausgeführt wird, nicht über die Privilegien der Herausforderung Server selbst zu starten . Sicherlich könnte dies ein Fehler in der API sein.

das Skripts in der Eingabeaufforderung Ausführen erzeugt direkt die folgenden Fehler:

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

Aber es als root ausgeführt wird, wie der externe Server abgefragt (als Aufforderung selbst angegeben) gestartet überwacht werden, um den Server korrekt und konnte es Ergänzen Sie die Herausforderung:

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 - 

Dieser Fehler eine Weile nahm zu diagnostizieren, so viele Dinge, die Herausforderungen von Versagen und die Server gelaicht im Hintergrund versagten leise hätte verhindert werden können.

Answer 2

Wenn Sie mit Cloudflare DNS vor Ihrer Website, erinnere mich an den DNS-A haben, AAAA-Einträge direkt auf Ihre Website verweisen, vorübergehend bis zur Erneuerung beendet.

Answer 3

Ich vermute, Sie alle haben dies bereits überprüft. Derselbe Fehler ist mir während des Erneuerungsprozesses aufgefallen. Ich hatte den Traffic von 443 auf 8443 umgeleitet (mit iptables). Die Lösung bestand darin, den Eintrag von iptables zu entfernen, den Tomcat zu stoppen und dann den Erneuerungsprozess wie einen Zauberspruch auszuführen. Das Skript sieht so aus.

/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

ich den gleichen Fehler bekam, wenn versucht:

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

aber es funktionierte mit:

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

Danach Sie cert Pfade in Apache Conf-Datei ändern müssen (Default- ssl.conf) und Apache neu starten.

Answer 5

Ich habe dieses Problem gelöst, indem ich IPv6 auf meinem Ubuntu 14.04-Rechner für Apache 2.4 deaktiviert habe, da mein Server keine echte IPv6-Adresse hat. (Original-Beitrag auf 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)

Um dies zu erreichen, habe ich ausdrücklich die IP-Adresse in /etc/apache2/ports.conf:

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

und in allen vhosts:

<VirtualHost <IP>:80> 

statt:

<VirtualHost *:80> 

Nach diesen Änderungen zeigt netstat -lnp | egrep ":443|:80"tcp in der ersten Spalte statt tcp6.

Dann wirkte die cerbot renew wie ein Charme.

Answer 6

Ich kämpfte dies für mehrere Stunden, komplett mit der gleichen Ausgabe in meinen Protokollen. Ich habe sogar alle Empfehlungen auf dieser Seite befolgt. Ich bin nur über meine Antwort gestolpert. Ich hatte etwas Code von einer anderen Webconfig eingefügt und es hatte bereits einen <virtual host _._._._:443> Abschnitt darin. Nach dem Löschen dieses Abschnitts 443 lief die sudo certbot-auto --apache -d example.com ohne Fehler und ich hatte eine Arbeitswebsite.

Ich ziehe Schlussfolgerungen nur aus meiner Erfahrung: Stellen Sie sicher, dass Sie nur virtuelle Hosts für Port 80 haben. Nirgendwo in der Dokumentation, die ich gelesen habe, dieses Problem erwähnt, aber es scheint, dass certbot nicht gut mit Site-verfügbaren Conf-Datei Das enthält bereits einen virtuellen 443-Hostabschnitt.