requests.packages.urllib3.exceptions.SSLError Debian 9

service-it · December 28, 2018, 12:51pm

I have a problem with a handshake

He should have the answer as in the link below
It’s the same for Apache

root@ftp:~# certbot --nginx -d sftp.domain.pl
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Enter email address (used for urgent renewal and security notices) (Enter ‘c’ to
cancel): service-it@domain.pl
An unexpected error occurred:
Traceback (most recent call last):
_ File “/usr/lib/python3/dist-packages/urllib3/contrib/pyopenssl.py”, line 417, in wrap_socket_
_ cnx.do_handshake()_
_ File “/usr/lib/python3/dist-packages/OpenSSL/SSL.py”, line 1426, in do_handshake_
_ self.raise_ssl_error(self.ssl, result)
_ File “/usr/lib/python3/dist-packages/OpenSSL/SSL.py”, line 1174, in raise_ssl_error
_ raise_current_error()
_ File "/usr/lib/python3/dist-packages/OpenSSL/util.py", line 48, in exception_from_error_queue
_ raise exception_type(errors)
OpenSSL.SSL.Error: [(‘SSL routines’, ‘tls_process_server_certificate’, ‘certificate verify failed’)]

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
_ File “/usr/lib/python3/dist-packages/urllib3/connectionpool.py”, line 594, in urlopen_
_ chunked=chunked)_
_ File “/usr/lib/python3/dist-packages/urllib3/connectionpool.py”, line 350, in make_request
_ self.validate_conn(conn)
_ File “/usr/lib/python3/dist-packages/urllib3/connectionpool.py”, line 837, in validate_conn
_ conn.connect()_
_ File “/usr/lib/python3/dist-packages/urllib3/connection.py”, line 323, in connect_
_ ssl_context=context)_
_ File “/usr/lib/python3/dist-packages/urllib3/util/ssl_.py”, line 324, in ssl_wrap_socket_
_ return context.wrap_socket(sock, server_hostname=server_hostname)_
_ File “/usr/lib/python3/dist-packages/urllib3/contrib/pyopenssl.py”, line 424, in wrap_socket_
_ raise ssl.SSLError(‘bad handshake: %r’ % e)_
ssl.SSLError: (“bad handshake: Error([(‘SSL routines’, ‘tls_process_server_certificate’, ‘certificate verify failed’)],)”,)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
_ File “/usr/lib/python3/dist-packages/requests/adapters.py”, line 423, in send_
_ timeout=timeout_
_ File “/usr/lib/python3/dist-packages/urllib3/connectionpool.py”, line 624, in urlopen_
_ raise SSLError(e)_
requests.packages.urllib3.exceptions.SSLError: (“bad handshake: Error([(‘SSL routines’, ‘tls_process_server_certificate’, ‘certificate verify failed’)],)”,)

During handling of the above exception, another exception occurred:

requests.exceptions.SSLError: (“bad handshake: Error([(‘SSL routines’, ‘tls_process_server_certificate’, ‘certificate verify failed’)],)”,)
Please see the logfiles in /var/log/letsencrypt for more details.

rg305 · December 28, 2018, 5:27pm

The site sftp.domain.pl is not accessible via http nor https.
You will need one of those to renew using --nginx
Mind you, https renewals will be ending soon; so you should focus on fixing http for a longer term support.
Otherwise, you can try using s DNS authentication plugin method.

rg305 · December 28, 2018, 5:32pm

I just realized that you probably did NOT use your real domain in the post - doh!

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know):

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):

service-it · January 2, 2019, 6:13am

noooo
I only changed the domain because I did not want to give the real one.
well
autosan.pl and sftp.autosan.pl

I manage the DNS, it seems to me that I entered everything I need

*** certbot --apache -d sftp.autosan.pl *** its the same

mnordhoff · January 2, 2019, 6:17am

It seems like Certbot can’t connect to Let’s Encrypt.

What does /var/log/letsencrypt/letsencrypt.log show?

What happens if you run “curl -v https://acme-v01.api.letsencrypt.org/directory” or “curl -v https://acme-v02.api.letsencrypt.org/directory”?

service-it · January 2, 2019, 6:19am

root@ftp:~# cat /var/log/letsencrypt/letsencrypt.log
2018-12-30 09:29:26,191:DEBUG:certbot.main:certbot version: 0.28.0
2018-12-30 09:29:26,194:DEBUG:certbot.main:Arguments: [’-q’]
2018-12-30 09:29:26,194:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2018-12-30 09:29:26,206:DEBUG:certbot.log:Root logging level set at 30
2018-12-30 09:29:26,207:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2018-12-30 09:29:26,208:DEBUG:certbot.renewal:no renewal failures
2018-12-30 13:00:17,620:DEBUG:certbot.main:certbot version: 0.28.0
2018-12-30 13:00:17,622:DEBUG:certbot.main:Arguments: [’-q’]
2018-12-30 13:00:17,623:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2018-12-30 13:00:17,634:DEBUG:certbot.log:Root logging level set at 30
2018-12-30 13:00:17,635:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2018-12-30 13:00:17,636:DEBUG:certbot.renewal:no renewal failures
2018-12-31 06:57:14,966:DEBUG:certbot.main:certbot version: 0.28.0
2018-12-31 06:57:14,968:DEBUG:certbot.main:Arguments: [’-q’]
2018-12-31 06:57:14,969:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2018-12-31 06:57:14,980:DEBUG:certbot.log:Root logging level set at 30
2018-12-31 06:57:14,981:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2018-12-31 06:57:14,982:DEBUG:certbot.renewal:no renewal failures
2018-12-31 16:06:58,750:DEBUG:certbot.main:certbot version: 0.28.0
2018-12-31 16:06:58,752:DEBUG:certbot.main:Arguments: [’-q’]
2018-12-31 16:06:58,753:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2018-12-31 16:06:58,764:DEBUG:certbot.log:Root logging level set at 30
2018-12-31 16:06:58,765:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2018-12-31 16:06:58,766:DEBUG:certbot.renewal:no renewal failures
2019-01-01 11:11:26,574:DEBUG:certbot.main:certbot version: 0.28.0
2019-01-01 11:11:26,576:DEBUG:certbot.main:Arguments: [’-q’]
2019-01-01 11:11:26,576:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2019-01-01 11:11:26,587:DEBUG:certbot.log:Root logging level set at 30
2019-01-01 11:11:26,588:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2019-01-01 11:11:26,589:DEBUG:certbot.renewal:no renewal failures
2019-01-01 19:11:49,854:DEBUG:certbot.main:certbot version: 0.28.0
2019-01-01 19:11:49,856:DEBUG:certbot.main:Arguments: [’-q’]
2019-01-01 19:11:49,857:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2019-01-01 19:11:49,868:DEBUG:certbot.log:Root logging level set at 30
2019-01-01 19:11:49,869:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2019-01-01 19:11:49,870:DEBUG:certbot.renewal:no renewal failures

mnordhoff · January 2, 2019, 6:20am

Does it still fail?

Is there a file in /var/log/letsencrypt/ showing one of the failures?

service-it · January 2, 2019, 6:26am

root@ftp:~# echo “---------------------------” > /var/log/letsencrypt/letsencrypt.log
root@ftp:~#
root@ftp:~#
root@ftp:~# curl -v https://acme-v01.api.letsencrypt.org/directory” or “curl -v https://acme-v02.api.letsencrypt.org/directory”

Trying 23.59.120.38…
TCP_NODELAY set
Connected to acme-v01.api.letsencrypt.org (23.59.120.38) port 443 (#0)
ALPN, offering h2
ALPN, offering http/1.1
Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
successfully set certificate verify locations:
CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
TLSv1.2 (OUT), TLS header, Certificate Status (22):
TLSv1.2 (OUT), TLS handshake, Client hello (1):
TLSv1.2 (IN), TLS handshake, Server hello (2):
TLSv1.2 (IN), TLS handshake, Certificate (11):
TLSv1.2 (OUT), TLS alert, Server hello (2):
SSL certificate problem: unable to get local issuer certificate
Curl_http_done: called premature == 1
stopped the pause stream!
Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a “bundle”
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn’t adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you’d like to turn off curl’s verification of the certificate, use
the -k (or --insecure) option.

Rebuilt URL to: or/
Could not resolve host: or
Closing connection 1
curl: (6) Could not resolve host: or
Rebuilt URL to: “curl/
Failed to convert “curl to ACE; string contains a disallowed character
Could not resolve host: “curl
Closing connection 2
curl: (6) Could not resolve host: “curl
Trying 23.59.120.38…
TCP_NODELAY set
Connected to acme-v02.api.letsencrypt.org (23.59.120.38) port 443 (#3)
ALPN, offering h2
ALPN, offering http/1.1
Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
successfully set certificate verify locations:
CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
TLSv1.2 (OUT), TLS header, Certificate Status (22):
TLSv1.2 (OUT), TLS handshake, Client hello (1):
TLSv1.2 (IN), TLS handshake, Server hello (2):
TLSv1.2 (IN), TLS handshake, Certificate (11):
TLSv1.2 (OUT), TLS alert, Server hello (2):
SSL certificate problem: unable to get local issuer certificate
Curl_http_done: called premature == 1
stopped the pause stream!
Closing connection 3
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a “bundle”
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn’t adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you’d like to turn off curl’s verification of the certificate, use
the -k (or --insecure) option.
root@ftp:~#
root@ftp:~#
root@ftp:~#
root@ftp:~# cat /var/log/letsencrypt/letsencrypt.log

root@ftp:~# nslookup -type=TXT _acme-challenge.mydomain.com
Server: 82.177.196.221
Address: 82.177.196.221#53

Non-authoritative answer:
_acme-challenge.mydomain.com canonical name = mydomain.com.letsencrypt.vdeck.eigdyn.com.
mydomain.com.letsencrypt.vdeck.eigdyn.com text = “p8brDQy1XBdMqO1CbEeEDMOo2D7HD7bx1x1B95RpMcs”
mydomain.com.letsencrypt.vdeck.eigdyn.com text = “C_KYMSj2gUHQ6QwTQDrV2fRLJL7XcLTc5RvPBdfofp4”

Authoritative answers can be found from:
com nameserver = k.gtld-servers.net.
com nameserver = e.gtld-servers.net.
com nameserver = i.gtld-servers.net.
com nameserver = m.gtld-servers.net.
com nameserver = f.gtld-servers.net.
com nameserver = d.gtld-servers.net.
com nameserver = c.gtld-servers.net.
com nameserver = a.gtld-servers.net.
com nameserver = j.gtld-servers.net.
com nameserver = l.gtld-servers.net.
com nameserver = b.gtld-servers.net.
com nameserver = h.gtld-servers.net.
com nameserver = g.gtld-servers.net.

mnordhoff · January 2, 2019, 6:32am

curl and Python are probably using different trust stores, and I’m not sure what the correct path on Debian 9 is, but what does this show?

ls -l /etc/ssl/certs/ca-certificates.crt

service-it · January 2, 2019, 6:37am

root@ftp:~# ls -l /etc/ssl/certs/ca-certificates.crt
-rw-r–r-- 1 root root 237359 gru 28 13:35 /etc/ssl/certs/ca-certificates.crt
root@ftp:~#

service-it · January 2, 2019, 9:13am

it was a firewall, but I still have a problem

root@ftp:~# certbot -t --nginx -d sftp.autosan.pl
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for sftp.autosan.pl
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. sftp.autosan.pl (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://sftp.autosan.pl/.well-known/acme-challenge/-L8IX_qjgpKhAJnpkKqLnW11EbvVq3uY-97Z-vaMYMM: Timeout during connect (likely firewall problem)

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: sftp.autosan.pl
   Type:   connection
   Detail: Fetching
   http://sftp.autosan.pl/.well-known/acme-challenge/-L8IX_qjgpKhAJnpkKqLnW11EbvVq3uY-97Z-vaMYMM:
   Timeout during connect (likely firewall problem)

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

mnordhoff · January 2, 2019, 10:10am

It seems to be impossible to connect to http://sftp.autosan.pl/ from the Internet. Is a firewall blocking it?

(http://autosan.pl/ works, for what it’s worth.)

service-it · January 2, 2019, 10:37am

It turned out that GeoIP is still on the server
I am asking for a test because it is still not being validated

root@ftp:~# iptables -nvL
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
   25  3440 LOG        tcp  --  ens18  *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 LOG flags 0 level 4 prefix "http input: "
 1088  125K LOG        tcp  --  ens18  *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443 LOG flags 0 level 4 prefix "https input: "
   25  3440 ACCEPT     tcp  --  ens18  *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 /* http  -  GeoIP ON */
 1088  125K ACCEPT     tcp  --  ens18  *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443 /* ssl   -  GeoIP ON */

root@ftp:~# certbot -t --nginx -d sftp.autosan.pl
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for sftp.autosan.pl
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. sftp.autosan.pl (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://sftp.autosan.pl/.well-known/acme-challenge/ZCDtcWKA5GyqYOVownoRpdasiAL4xF3UGe70kef-OuU: Timeout during connect (likely firewall problem)

IMPORTANT NOTES:

The following errors were reported by the server:

Domain: sftp.autosan.pl
Type: connection
Detail: Fetching
http://sftp.autosan.pl/.well-known/acme-challenge/ZCDtcWKA5GyqYOVownoRpdasiAL4xF3UGe70kef-OuU:
Timeout during connect (likely firewall problem)

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you’re using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.

I have a question from which servers the test is being made

mnordhoff · January 2, 2019, 11:05am

Why do you ask? The IP addresses Let's Encrypt uses for validation are undocumented and will change in the future. To use HTTP validation, you have to allow all IPs to access http://sftp.autosan.pl/.well-known/acme-challenge/.

To quote the FAQ:

We don’t publish a list of IP addresses we use to validate, because they may change at any time. In the future we may validate from multiple IP addresses at once.

service-it · January 2, 2019, 11:44am

It works - problems were in the firewalls and router.

I am asking about IP or domain because I use GeoIP
and probably will be needed when renewing communication

system · February 1, 2019, 11:44am

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
Certificate Verify Failed Help	8	6809	July 20, 2018
An unexpected error occurred: requests.exceptions.SSLError: ("bad handshake: Error([('SSL routines Server	5	5411	February 6, 2019
Unable to issue a certificate Help	3	2252	July 5, 2020
Bad handshake error during renew Help	5	4625	December 12, 2021
Could not get a certificate using Certbоt, asks to install the root certificate of the Unified Internet Access Gateway on ubuntu lts 20.04 Help	15	593	March 13, 2024

requests.packages.urllib3.exceptions.SSLError Debian 9

Related topics