dozens of feeds have this issue
I’m guessing that they’re using “Let’s Encrypt” for their SSL/TLS certificates. They’re transitioning to a different Certificate Authority right now, so you’re going to have to wait until those sites (and others that are using old Let’s Encrypt certificates) update their certificates, if that’s the case.
i’m not seeing any certificate problems with official docker image.
i’m also going to remind people that everything else is officially not supported.
tt-rss does not manage certificate stores of whatever obsolete systems affected people are using. any further offtopic posts about this outside this thread are going to result in probations, starting now.
i’m going to pin this thread as a containment zone.
If it started today, then it is probably this:
Let’s Encrypt DST Root CA X3 expiry Sept 30th 2021:
https://docs.certifytheweb.com/docs/kb/kb-202109-letsencrypt/
Also, some systems might not have yet picked up the newer LetsEncrypt root certificate. You’d think everyone would be sufficiently up to date, but I helped someone yesterday whose macOS brew had been installing things without updated certs.
So check you’re actually up to date on all system updates, and not using an unsupported version of your OS.
There only systems that should have been affected by this are Android phones on ancient versions due to the hardware being very old, and likewise iPhones earlier than the “5” series.
Hi, I’ve been affected by the “60 SSL certificate error”.
I’m running a non-official Bitnami one-click pacakge for Azure that I installed years ago and I never updated. I know this is far from ideal but I struggle with “devops stuff” and when I had it working, I was more than happy with it.
I don’t really understand the details of the problem, so I’m not sure what’s the best way to fix it. I have SSH access to the machine but (from what I understand) I think it would be better to deploy a new instance from the official Docker compose setup , right? Do you know any easier way?
I’m very lost and any help will be welcome. Thanks a lot!
Just for information, it appears some sites (using Let’s Encrypt) have SSL concerns with the provided chain. Whenever your certificate store is up-to-date*.
Example: Mascotte, le chaton des enfers (checked w/ Tiny Tiny RSS - Feed tester)
This feed is hosted on a vhost that return the old Let’s Encrypt root certificate in the certificate chain.
I am not sure of the surface of this problem. Because accessing the site with a modern-up-to-date browser is not a challenge, as it is with (my installation of ) tt-rss (the “stock” one: git version up-to-date, one my own web-server) or some other clients.
It could be a problem only for clients using openssl 1.0.x libs in the curl module for php. I can’t test on a different install right-now, but the problem is replicated with the @fox ’ tool to check feeds (Tiny Tiny RSS - Feed tester)
Am I wrong ?
So, eventually, if anyone have more info…?
(is it really usefull to have more info ; because …) The site owners HAVE TO update their certificate chain via their ACME clients / whatever they use.
If this remain to be a problem for you, check on the problematic website a contact address, form, etc. and ask politely to maintain the f. website.
Wish it helps.
.* : there is not such “up-to-date” concept about CA trust store, but some enterprises or fundations, as Mozilla do, develop and maintain a trust set of CA’s root certificates ; so, up-to-date is to ear as, e.g. “the same as the Mozilla one, today”
Yeah, this issue does affect the current version of Tiny Tiny RSS. The root issue is the incorrect intermediate certificate sent by the server, though. Chrome handles this by using the Authority Information Access part of the certificate to download the correct intermediate certificate instead.
I am not sure about Firefox, but I believe it at least caches any intermediate certificates. Therefore, if you have visited any site with a working Let’s Encrypt chain, any sites with the broken chain will work as long as the correct intermediate remains in Firefox’s cache.
curl does neither, though supporting AIA was put on their TODO list three years ago.
The solution is for the website admins to fix their broken servers and chain to the valid ISGR root. Something that seems to be inexplicably difficult despite Let’s Encrypt’s automated nature.
system certificate stores being broken would affect any application, tt-rss does nothing special in this regard.
stuff like this is precisely the reason i told everyone a year ago that host installs are no longer supported. 
it’s not, unless you try really hard to misconfigure everything by hand instead of using certbot.
I helped deal with an issue related to this yesterday relating to some python code.
Even after the server certificate was edited to no longer include the expired cross-signing the python code still errored.
Eventually we noticed the code in question (a third party plugin for the application) was using urllib directly, rather than the recommended requests module (which all of the actual application web code uses). Switching it to requests, which uses the certifi module, which has its own CA store, or adjusting the urllib call to specify the bundled certifi cacert.pem be used, fixed it.
This was on an up to date Windows 10 system with the latest stable release of Python 3.9.7, and latest urllib. We assume that it was something to do with the Windows CA store on that system. Possibly it caches certificate chains, maybe related to checking if the certificate has been revoked?
My point here is that it can be difficult to track down the exact cause of these issues. For ttrss, as fox has said, just use the official docker compose images and it will Just Work[TM].
On the server side LetsEncrypt was STILL using certificate renewals WITH the expired cross-signing in them yesterday (at least when using the slightly outdated certbot on the system I tested with). You can edit that out of fullchain.pem, or with new enough ACME clients specify which signing to include, thus not including the problematic one.
I assume LetsEncrypt still include it by default for some reason. Old Android which doesn’t have the newer root and doesn’t properly check the expiry on the old one?
Given the numerous outages that happened shortly after the intermediate and then the root certificate expired, I suppose the cross-signed Let’s Encrypt certificates have confused many people including developers. This is probably not helped by the fact that browsers are masking the issue by working around the broken chain. To anyone simply checking their site in Chrome or Firefox everything looks to be in order.
@fox I may have been a bit unclear, but when I said that this does affect current TT-RSS I meant the current stock docker version. The feed supplied by GregThib does show a “certificate has expired” warning in both my docker-compose setup and the official demo version of TT-RSS. This would happen on any system with an “up-to-date” certificate store, because the website is sending an expired intermediate signed by an expired root certificate. So, it is still the website owners responsibility to fix their server but, at least in this instance, not linked to incorrect host installs.
As GregThib said, contacting the website owner is the solution. Many will be completely unaware of the issue as the website will appear to be working just fine in any modern browser.
Indeed that Mascotte, le chaton des enfers server seems to only be supplying the expired CA, not the currently working one, so that’s a configuration error on their part. I actually wonder how they managed that, using an ACME client other than certbot ?
this would “affect” any networking client which validates SSL certificates, i’m not sure why is tt-rss somehow special here.
as you said already it’s an entirely third party problem, one we can’t do anything about, until dimwits wake up and fix their shit. why is this discussed here? i have no idea.
i mean i’m not trying to shutdown this discussion, let’s point fingers and laugh, as long as everyone understands that we aren’t to blame.
The documentation on custom certificates is slightly unclear on which container the certs should be mounted into: in my experience the lines have to be included for the app and updater containers in order to make it work. Maybe this could be updated. 