Let's Encrypt Failing DVSNI Challenge

Question

Sto provando a configurare Let's Encrypt certificates su un server che è pubblicamente accessibile. Originariamente, il server si nascondeva dietro un router, ma da allora ho inoltrato le porte 80 e 443.

Il certificato sembra aver completato la maggior parte del processo di installazione, ma non riesce con il messaggio: Failed to connect to host for DVSNI challenge.

completa analisi dello stack:

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 

Qualsiasi supporto sarebbe molto apprezzato!

Ho cercato altrove una soluzione e non ho avuto molta fortuna. La maggior parte delle altre situazioni simili sono state risolte inoltrando la porta 443, ma sono certo che questa porta sia già stata inoltrata e aperta, anche se al momento non è in esecuzione alcun servizio.

Non dovrebbe fare la differenza, ma sto cercando di configurare questo certificato per l'uso con Node JS su un Raspberry Pi.

Answer 1

Finalmente ho capito cosa stava succedendo. Ho scoperto che il flag --manual attraversa il processo di autenticazione in modo interattivo.

Ogni fase del processo verrà visualizzato un prompt simile al seguente:

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 

Come ho scoperto, il processo, pur essendo eseguito come root per sé, non aveva i privilegi per avviare il server sfida in sé . Sicuramente, questo potrebbe essere un bug nell'API.

Esecuzione dello script nel prompt produce direttamente il seguente errore:

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

Ma eseguirlo come root (come la richiesta stessa ha dichiarato) ha iniziato il server in modo corretto e potrebbe essere monitorato come il server esterno interrogato a completare la sfida:

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 - 

Questo errore voluto un po 'da diagnosticare in quanto molte cose avrebbero potuto impedire le sfide di fallire ei server generato sono stati in mancanza silenziosamente in background.

Answer 2

Se stai utilizzando il servizio Cloudflare DNS davanti al tuo sito, ricorda che i record DNS A, AAAA puntano direttamente al tuo sito, temporaneamente fino al termine del rinnovo.

Answer 3

Suppongo che tutti voi abbiate già controllato questo. Lo stesso errore sollevato durante il processo di rinnovo. Avevo reindirizzato il traffico da 443 a 8443 (con iptables). La soluzione era rimuovere la voce da iptables, arrestare il tomcat, quindi eseguire il processo di rinnovo ha funzionato come un incantesimo. La sceneggiatura assomiglia a questo.

/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

ho ottenuto lo stesso errore quando provato:

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

ma ha funzionato con:

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

Dopo di che è necessario modificare i percorsi cert nel file di .conf apache (Predefinito- ssl.conf) e riavviare apache.

Answer 5

Ho risolto questo problema disabilitando IPv6 sulla mia macchina Ubuntu 14.04 per Apache 2.4 in quanto il mio server non ha un indirizzo IPv6 reale. (Original post sul 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)

Per fare questo, ho impostato in modo esplicito l'indirizzo IP in /etc/apache2/ports.conf:

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

e in tutti i vhost:

<VirtualHost <IP>:80> 

invece di:

<VirtualHost *:80> 

Dopo queste modifiche, netstat -lnp | egrep ":443|:80" mostra tcp nella prima colonna anziché tcp6.

Quindi, il cerbot renew ha funzionato come un fascino.

Answer 6

Ho combattuto per diverse ore, con lo stesso risultato nei miei registri. Ho persino seguito tutte le raccomandazioni su questa pagina. Mi sono imbattuto solo nella mia risposta. Ho incollato del codice da un altro webconfig e aveva già una sezione <virtual host _._._._:443>. Dopo aver eliminato quella sezione 443, sudo certbot-auto --apache -d example.com funzionava senza errori e avevo un sito funzionante.

Sto trarre conclusioni solo dalla mia esperienza: assicurati di avere solo host virtuali per la porta 80. Da nessuna parte nella documentazione che ho letto ha menzionato questo problema, ma sembra che certbot non giochi bene con il file di configurazione disponibile sul sito che contiene già una sezione di host virtuale 443.