requests.packages.urllib3.exceptions.SSLError Debian 9


#1

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.


#2

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.


#3

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):


#4

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 :frowning:


#5

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”?


#6

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


#7

Does it still fail?

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


#8

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.


#9

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

#10

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:~#


#11

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.

#12

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.)


#13

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


#14

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.


#15

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


closed #16

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