turtl/tracker

Certificate problem

kkarpieszuk opened this issue ยท 23 comments

Hello,

Today as everyday I tried to open Turl and I have been invited by log in screen. But I couldn't log in.

The error message says the SSL certificate has expired. I am using your servers.

Could you help me to resolve this?

Below screenshots of error message and server configuration

Screenshot_20210930-175227__01

Screenshot_20210930-175924

I'm seeing this as well. The odd thing is that the certificate is not expired at all.

I'm guessing one of the higher-up certificates that signs the Let's Encrypt certificates expired, and the new top-level CA they use (I think I read about them switching over at some point) is not bundled with the Android system or the app.

I think what I have to do is just buy one of those shitty $9 SSL certs until I can get a new version of the app out. Will do this as soon as possible. Sorry for the inconvenience, everyone. This kind of happened out from under us.

Yep, here's what happened: https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/

This confirms my suspicion.

So, for anyone who hosts their own Turtl server with self-signed certificates, would renewing them solve the problem?

Hi everyone. I got new certs pushed to the server (well, a new server, I had a ton of trouble getting them provisioned on the old server, which is why it took me a while to set up).

Can everyone try their desktop/android apps? The server should be the same (apiv3.turtlapp.com). Would love to know if it's working any better.

Working for me now, thanks!

Back up and running on Linux and Android. Thank you!

Excellent! Thanks for the report and the patience.

@benoit-smith I don't think this would affect self-signed certificates. However, if you're using Let's Encrypt like we are, then this was the fix I used:

certbot --preferred-chain="ISRG Root X1"

Regenerating the certificates with a different chain was what fixed things. Hopefully this helps.

Thank you for the quick solve! And thanks for the great product!

@benoit-smith I don't think this would affect self-signed certificates. However, if you're using Let's Encrypt like we are, then this was the fix I used:

certbot --preferred-chain="ISRG Root X1"

Regenerating the certificates with a different chain was what fixed things. Hopefully this helps.

It did! Thank you for the fix, and for the software!

Hello,

Sorry for the inconvenience, but the certificate issue always occurs on my Android 7.0.0/Turtl 0.7.2.5 (Server : https://apiv3.turtlapp.com).
I can't connect anymore from my smartphone.
The connection works fine on my Linux and Windows systems.

Before your server side Let's Encrypt renew, I have the @kkarpieszuk issue: #400 (certificate has expired).
But after your server side Let's Encrypt renew, I have the @benoit-smith issue: #375 (unable to get local issue certificate)

Could you help me to resolve this ?

@borntobeolive My issue was about trying to connect to a home-hosted Turtl server, not a turtlapp.com server. If that's your case, have you by chance tried the fix mentioned above?

certbot --preferred-chain="ISRG Root X1"

i have the same problem but certbot --preferred-chain="ISRG Root X1"
gives option unrecognized arguments. i drag the certificate from yunohost system

@benoit-smith Thanks for reply.
I have been understand your home-hosted Turtl server context.
This is not my case. I use the turtlapp.com server.

I have supposed your fix is on your server side.
So, perhaps this kind of fix can resolv this issue on the turtlapp.com server.

I have supposed your fix is on your server side. So, perhaps this kind of fix can resolv this issue on the turtlapp.com server.

As @orthecreedence stated earlier, the --preferred-chain option has already been applied to the turtlapp.com server. So I guess the explanation for your problem has yet to be found.

@benoit-smith Thanks for your help!

I am looking for a workaround (client side) to continue using Turtlapp on my Android version.
I hope I can use this application without changing my smartphone :-/

If someone has an idea, keep me informed :-)

@borntobeolive I don't there's a perfect solution here. If you're committed to that Android version/phone, you could install one of the latest unreleased mobile updates as an apk and check the "Skip SSL verification" box in the advanced settings in login.

I cannot officially recommend this, but I think it would get you going again. Another more pain-in-the-ass option would be to set up a server/VPS with some kind of older SSL certificate that just proxies incoming connections back to https://apiv3.turtlapp.com. If you have an extra server laying around that has a domain and nginx/apache already, this would be an easy-ish option. Otherwise, I'd go the "apk+skip verification" route.

@orthecreedence Thanks a lot for these workaround.

I understand that is not recommanded to skip SSL verfication.

I will try the proxy option.
But I probably buy a new smartphone soon.

Except my Android version issue, Turtlapp is a very good software. Long life for him and for you :-)

I think this is not really a server issue, but more a client issue.
So i don't understand why implementing workarounds on the server is the goto route here.

See electron/electron#31212 Which is causing this.

I think this is not really a server issue, but more a client issue.

It's both. The server and the clients don't have a matching set of certificates.

So i don't understand why implementing workarounds on the server is the goto route here.

The issue is/was caused by a root CA certificate expiring. Let's Encrypt switched over to a new chain or something (more detail in the link I posted above) but it seemed like my older versions of getssl were still using the old chain with expired root cert. By installing certbot and using an option to select a new chain (found by scouring forums for an hour or so) it started working on most android/desktop apps again.

Note that in that thread you posted, someone made the same fix I did: electron/electron#31212 (comment)

yes. but its just a workaround on the server-side.

And the same comment if you continue reading it says:
Hope this solution helps others to obtain a valid shortened certificate chain until the long term issue is resolved at the Electron level.

The issue is basicly this:
Nearly all clients follow the certificate chain and if the first one fails, check the second one etc.

Some Option in Electron was different though and resulted in Electron throwing the error right when the first certificate in the chain was invalid.

That can also easily be tested in just accessing the turtl server using a regular Browser. = no cert error.

Thats why i say its still mostly a Client issue and not a server issue and should be fixed in the Client.

Good to know, I'll try to get a new set of client releases out soon.

To me it seems like this issue was never actually fixed wasn't it?
Just set up my self-hosted Turtl server and I cannot connect to it with any client whatsover because of this very issue.
It works with the "official" server but this one uses a RapidSSL/Digicert certificate.