ssl-certificate - solucion - el servidor no admite el tipo de cifrado de conexión especificado windows 7

Vamos a cifrar el desafío de DVSNI que falla (6)

Estoy intentando configurar los certificados de Let''s Encrypt en un servidor al que se puede acceder públicamente. Originalmente, el servidor se ocultaba detrás de un enrutador, pero desde entonces he reenviado los puertos 80 y 443.

El certificado parece haber completado la mayor parte del proceso de instalación, pero falla con el mensaje: Failed to connect to host for DVSNI challenge .

Rastreo de pila completa:

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

Cualquier ayuda sería muy apreciada!

Busqué una solución en otro lado y no he tenido mucha suerte. La mayoría de las demás situaciones similares se resolvieron reenviando el puerto 443, pero estoy seguro de que este puerto ya está reenviado y abierto, aunque no hay ningún servicio ejecutándose actualmente en él.

No debería hacer una diferencia, pero estoy tratando de configurar este certificado para usarlo con Node JS en una Raspberry Pi.

Finalmente me di cuenta de lo que estaba pasando. Descubrí que el indicador --manual través del proceso de autenticación de forma interactiva.

Cada fase del proceso mostrará un mensaje similar al siguiente:

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

Como descubrí, el proceso, a pesar de ejecutarse como root en sí mismo, no tenía los privilegios para iniciar el propio servidor de desafío. Seguramente, esto podría ser un error en la API.

La ejecución del script en la solicitud produce directamente el siguiente error:

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

Pero ejecutarlo como root (como lo indicó el mensaje de solicitud) inició el servidor correctamente y se pudo monitorear cuando el servidor externo lo consultó para completar el desafío:

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 -

Este error tomó un tiempo para diagnosticar, ya que muchas cosas podrían haber evitado que los desafíos fracasaran y los servidores generados fallaban silenciosamente en segundo plano.

Luché contra esto durante varias horas, completa con la misma salida en mis registros. Incluso seguí todas las recomendaciones en esta página. Solo tropecé con mi respuesta. Había pegado algo de código de otro webconfig y ya tenía una sección <virtual host _._._._:443> . Después de eliminar esa sección 443, el sudo certbot-auto --apache -d example.com ejecutó sin errores y tenía un sitio de trabajo.

Solo estoy sacando conclusiones de mi experiencia: asegúrese de que solo tenga hosts virtuales para el puerto 80. En ninguna parte de la documentación que leí mencioné este problema, pero parece que certbot no funciona bien con el archivo conf disponible en el sitio que ya contiene un 443 sección de host virtual.

Obtuve el mismo error cuando lo intenté:

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

pero funcionó con:

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

Después de eso, necesita cambiar las rutas de certificación en el archivo apconconc.conf (default-ssl.conf) y reiniciar apache.

Resolví este problema al deshabilitar IPv6 en mi máquina Ubuntu 14.04 para Apache 2.4, ya que mi servidor no tiene una dirección IPv6 real. (Publicación original en 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 )

Para lograr esto, establezco explícitamente la dirección IP en /etc/apache2/ports.conf :

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

y en todos los vhosts:

<VirtualHost <IP>:80>

en lugar de:

<VirtualHost *:80>

Después de estos cambios, netstat -lnp | egrep ":443|:80" netstat -lnp | egrep ":443|:80" muestra tcp en la primera columna en lugar de tcp6 .

Entonces, la cerbot renew funcionó a la cerbot renew .

Si está utilizando Cloudflare DNS delante de su sitio, recuerde que el DNS A, los registros AAAA apuntan directamente a su sitio, temporalmente hasta que finalice la renovación.

Supongo que todos ustedes ya han comprobado esto. El mismo error que me planteó durante el proceso de renovación. Había redirigido el tráfico de 443 a 8443 (con iptables). La solución fue eliminar la entrada de iptables, detener el tomcat y luego ejecutar el proceso de renovación funcionó a la perfección. El guión se ve así.

/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