web-dev-qa-db-fra.com

Encryptons le challenge DVSNI qui a échoué

J'essaie de configurer Encryptons les certificats sur un serveur accessible publiquement. À l'origine, le serveur se cachait derrière un routeur, mais j'ai depuis transféré les ports 80 et 443.

Le certificat semble avoir achevé l'essentiel du processus d'installation, mais échoue avec le message: Failed to connect to Host for DVSNI challenge.

Trace complète de la pile:

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

Tout support serait grandement apprécié!

J'ai cherché ailleurs une solution et je n'ai pas eu beaucoup de chance. La plupart des autres situations similaires ont été résolues en transférant le port 443, mais je suis certain que ce port est déjà transféré et ouvert, bien qu'aucun service ne soit actuellement exécuté sur celui-ci.

Cela ne devrait pas faire de différence, mais j'essaie de configurer ce certificat pour l'utiliser avec Node JS sur un Raspberry Pi.

ssl-certificatelets-encrypt
19
James Taylor

J'ai finalement compris ce qui se passait. J'ai découvert que l'indicateur --manual suit le processus d'authentification de manière interactive.

Chaque phase du processus affichera une invite semblable à celle-ci:

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

Comme je l'ai découvert, le processus, bien qu'il soit exécuté en tant que root lui-même, ne disposait pas des privilèges nécessaires pour démarrer le serveur de challenge lui-même. C’est sûrement un bug de l’API.

L'exécution du script dans l'invite génère directement l'erreur suivante:

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

Mais son exécution en tant que root (comme l’invite elle-même l’a indiqué) démarrait le serveur correctement et pouvait être surveillée lorsque le serveur externe l’interrogeait pour compléter le défi:

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 -

Cette erreur a mis un certain temps à diagnostiquer, car beaucoup de choses auraient pu empêcher les défis d'échouer et les serveurs générés échouaient silencieusement en arrière-plan.

12
James Taylor

Si vous utilisez le DNS Cloudflare devant votre site, n'oubliez pas que les enregistrements DNS A, AAAA pointent directement sur votre site, temporairement jusqu'à la fin du renouvellement.

8
Jeff Tsay

Je me suis battu pendant plusieurs heures, avec la même sortie dans mes journaux. J'ai même suivi toutes les recommandations sur cette page. Je suis seulement tombé sur ma réponse. J'avais collé du code d'un autre webconfig et il contenait déjà une section <virtual Host _._._._:443>. Après avoir supprimé cette section 443, le Sudo certbot-auto --Apache -d example.com s'est exécuté sans erreur et j'avais un site de travail.

Je tire des conclusions uniquement de mon expérience: assurez-vous que vous n’avez que des hôtes virtuels pour le port 80. La documentation que j’ai lue n’a mentionné ce problème, mais il semble que certbot ne joue pas à Nice avec un fichier de configuration disponible sur le site 443 section hôte virtuel. 

2
wruckie

J'ai résolu ce problème en désactivant IPv6 sur ma machine Ubuntu 14.04 pour Apache 2.4 car mon serveur ne dispose pas d'une adresse IPv6 réelle. (Article original sur https://community.letsencrypt.org/t/how-to-resolve-the-correct-zname-not-found-for-tls-sni-challenge-error-when-i-try- renouveler-certificat/9405/43 )

Pour ce faire, j'ai explicitement défini l'adresse IP dans /etc/Apache2/ports.conf:

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

et dans tous les hôtes:

<VirtualHost <IP>:80>

au lieu de:

<VirtualHost *:80>

Après ces modifications, netstat -lnp | egrep ":443|:80" affiche tcp dans la première colonne au lieu de tcp6.

Ensuite, le cerbot renew a fonctionné comme un charme.

2
Frederick Thomssen

Je suppose que vous avez tous déjà vérifié cela. La même erreur m'a été signalée lors du processus de renouvellement. J'avais redirigé le trafic de 443 à 8443 (avec iptables). La solution consistait à supprimer l'entrée d'iptables, à arrêter le Tomcat, puis à exécuter le processus de renouvellement comme un charme. Le script ressemble à ceci.

/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

J'ai eu la même erreur quand j'ai essayé:

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

mais cela a fonctionné avec: 

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

Après cela, vous devez modifier les chemins de certificat dans le fichier .conf Apache (default-ssl.conf) et redémarrer Apache. 

0
user570605