Certificate verification error "bad handshake"
weinsteing opened this issue · comments
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/flask/app.py", line 1612, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/lib/python2.7/dist-packages/flask/app.py", line 1598, in dispatch_request
return self.view_functionsrule.endpoint
File "/root/photoframe/routes/baseroute.py", line 62, in call
return self.handle(self.app, **kwargs)
File "/root/photoframe/routes/oauthlink.py", line 44, in handle
return self.redirect(self.servicemgr.oauthStart(kwargs['service']))
File "/root/photoframe/modules/servicemanager.py", line 199, in oauthStart
return svc.startOAuth()
File "/root/photoframe/services/base.py", line 274, in startOAuth
return self._OAUTH.initiate()
File "/root/photoframe/modules/oauth.py", line 122, in initiate
self.rid = self.getRedirectId()
File "/root/photoframe/modules/oauth.py", line 118, in getRedirectId
r = requests.get('%s/?register' % self.ridURI)
File "/usr/lib/python2.7/dist-packages/requests/api.py", line 70, in get
return request('get', url, params=params, **kwargs)
File "/usr/lib/python2.7/dist-packages/requests/api.py", line 56, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 488, in request
resp = self.send(prep, **send_kwargs)
File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 609, in send
r = adapter.send(request, **kwargs)
File "/usr/lib/python2.7/dist-packages/requests/adapters.py", line 497, in send
raise SSLError(e, request=request)
SSLError: ("bad handshake: Error([('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')],)",)
This can happen when the local time of the device is off. Does your pi have the current time?
I am receiving the exact same error when trying to authorize GooglePhotos. I checked my Pi's time via SSH and it is local and correct.
Did you just install the device (ie, new SD card) ?
Yes, it was on a fresh install for me
Mine is not a fresh install.
I have the exact same error.
This is on a system that has been running for years
With 3 of us experiencing the same error, it sounds like the problem is being caused by something other than the timestamp. Would very much appreciate you looking for alternative reasons that this problem has occurred. Thanks and regards ... Gary
Would really appreciate you looking at this problem. There are no 4 of us experiencing it and its very frustrating not having a resolution to the problem. Thank you.
Hi all, first of all, I understand the frustration and I am looking into the issue, but since this issue isn't (yet) showing on my own frames, it making this harder to troubleshoot. On top of that, I also work full-time and have a family, and with the holidays around the corner, the amount of spare time is minimal.
I hope to find some time during my holiday break to dig into this and also be able to replicate this issue for easier troubleshoot.
While this probably is disappointing to hear, I'd rather be honest with my situation than make promises I cannot keep.
However, something which would help me out a lot would be if you guys can login to the frame using SSH and provide the output from the following commands (run as root) which will give me some data to look into and compare with.
First, run find /usr -name libssl.so* and copy the first .so filename and then feed that into the following command (if none are found, replace /usr with / but be warned, you'll get permission errors that clutters the output)
grep --text -o 'OpenSSL [[:digit:]][^ ]*' /file/to/check
So, in my case,
ha@WorkHorse:~$ find /usr -name libssl.so*
/usr/lib/x86_64-linux-gnu/libssl.so.1.1
ha@WorkHorse:~$ grep --text -o 'OpenSSL [[:digit:]][^ ]*' /usr/lib/x86_64-linux-gnu/libssl.so.1.1
OpenSSL 1.1.1f
Next, run the following command to grab a complete list of installed packages
apt list --installed > packages.txt
Finally, share the OpenSSL version string (in my case, OpenSSL 1.1.1f) and attach the packages.txt file from the pi (you can use the scp command to copy it from your pi)
Dear Henric, firstly I wish you to say "Thank You" for taking the time and effort to develop this Photoframe application, which when it is running, we are delighted to be using. That is why it is frustrating when something occurs and prevents us from being able to see our photos.
Secondly, I really do appreciate that you have made it available free-of-charge and give up your time to investigate issues when they arise.
I'm not technical myself, and have asked someone who is to help me undertake the instructions above, and will send you this data asap.
In the meantime, I wish you and your family well over the festive break and very happy new year.
Thanks and regards ... Gary
Thanks :) (and I hope my message didn't come across as whiny, that wasn't my intention). Me and my family and grandparents enjoy this as well, so I totally get you. I hope I'll have some positive information about this later this month.
Hi Henric,
I'm also experiencing the same issue. And, in complete transparency, I'm just beginning my journey into PI and non-GUI interfaces. So, I'm sure the issue is my own inexperience. That said, I'm adding this comment so that:
- I begin following this thread, and
- You know how much I really appreciate your efforts, both to provide this application and to look into the issue.
With great appreciation,
Jeremy
... amending with info I hope will be helpful:
-
Attached screenshot from the browser and local device
-
Google seems to have updated some of its API screens since you created your step-by-step directions. They're similar, but no longer exact. One thing that jums out at me is on the OAuth Consent Screen: should the user type be "Internal" or "External"? And, if External, will "Testing" suffice or "In production"? If I'm down the wrong Rabbit hole, I can leave it set to Internal. If External is needed, though, details about the specific settings may be helpful, too.
Again, I fear that I may be a victim of the limitations of my knowledge about both PI and Google's APIs. So, I apologize if this is unhelpful.
Sounds like I'll need to create a test setup and update my steps.
And yes, any testing you want to do and subsequent findings is appreciated. But I have a feeling that the SSL issue stems from outdated software or certificates on the PI.
Just let me know how I can help. I love to tinker and I've got some dev chops, but I'm new to these particular technologies, and I'm using an old PI and screen from a BYO computer kit I bought for my kids about 7 yrs ago (looks like this: https://www.adafruit.com/product/3256), and I thought a photo frame would be a great way to upcycle it. Anyway, I'm happy to be a tester and help in any way I can. Just LMK. Again, thank you!
Hopefully some of this info helps, followed your steps for additional information. Did this on a Pi Zero W that was flashed two weeks ago.
pi@photoframe:~ $ find /usr -name libssl.so*
/usr/lib/arm-linux-gnueabihf/libssl.so.1.0.2
/usr/lib/arm-linux-gnueabihf/libssl.so.1.1
pi@photoframe:~ $ grep --text -o 'OpenSSL [[:digit:]][^ ]*' /usr/lib/arm-linux-gnueabihf/libssl.so.1.1
OpenSSL 1.1.0j
And on the note of the Google authentication steps as mentioned by @ZapPappy , it has changed a bit since you made the guide but I was able to get the downloaded .json to verify on my photoframe about several weeks ago before this new issue cropped up. Looking back, I had selected "internal" and "testing," which were enough to get it to work, but I'm not sure if those settings are ideal.
Looks like I am having this problem as well. I can try to help troubleshoot after the holidays.
I've done some digging on what the issue could be and I need a volunteer with SSH access to their pi (and who feel comfortable running commands from shell).
note that what I'm about to propose hasn't been tested, but with SSL already broken, this should not make it worse
My thoughts are that the root certificates are out of date. Normally you'd run sudo apt-get install ca-certificates to fix this, BUT, stretch isn't supported anymore, so that won't work. So instead, here's what I suggest to try:
- Backup existing certs
sudo cp -r /etc/ssl/certs /etc/ssl/certs_backup
-
Download latest certificates (PLEASE HOLD, I'm extracting the ones I have from a fresh debian install and will update shortly)
-
Manually update them using debian's built-in functionality
sudo update-ca-certificates
If successful, please reboot and see if SSL issue is resolved. And in either case, please provide the output in this thread.
Sidenote, I have a working Python3 version now of photoframe and I intend to work on creating an updated SD card image based on latest RPi OS but it will mean you need to replace your installation, so to make this less painful, I'm also working on export/import of your configuration (including OAuth if possible) to minimize the effort (ie, install new SD image, import previous config and off you go).
certs.tar.gz
Here's the certificates needed for step 2 in the comment above.
AGAIN This will permanently change your debian installation and you may need to reinstall to return it to original state. This is purely for testing. IF you don't know what tar.gz files are, then you should probably let someone else try this first ;-)
Where did these come from? From my Kubuntu 23.x installation that I'm writing this on.
(and yes, I purposefully didn't give any specific details for step 2 since that's the step that can mess things up, if you're familiar with console/commandline, this should hopefully not pose a problem)
Well, don't I feel stupid now. The SSL issue "should" be resolved. Turns out that my certificate provider had updated their intermediate certificate but I didn't catch that when I renewed my SSL certificate, so I used the old one, which caused problems during SSL handshake. And depending on your client, it may or may not trigger on this.
With me running python3 version for testing, it seems the requests module was fine with this warning while python 2.7 (the official version) wasn't. I confirmed this with
openssl s_client -connect photoframe.sensenet.nu:443
Which would show this warning (while still connecting)
depth=0 CN = *.sensenet.nu
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = *.sensenet.nu
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = *.sensenet.nu
verify return:1
...
Verification error: unable to verify the first certificate
now the same command has no errors
CONNECTED(00000003)
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = AlphaSSL CA - SHA256 - G4
verify return:1
depth=0 CN = *.sensenet.nu
verify return:1
I'd appreciate it if you could confirm that this solves it.
Huge apologies to all who were affected by this issue and thanks for your patience.
It's fabulous, it works again. Thank you for the serious of your project and exceptional responsive. Sorry for my English I'm French ^^
congratulations again