It looks like there is a connectivity issue for some users today posting data to emoncms.org from I think mostly emonpi/emonbase systems starting 3pm onwards. It’s affecting about 10% of emoncms.org feeds.
If you have an affected system and can post any emonhub logs that may show associated errors that would be really useful. I will hopefully get a clearer idea of the solution shortly.
It may require running: sudo apt-get update && sudo apt-get upgrade to pull in latest certificates.
And that’s just as well, because the DST Root CA X3 certificate that started it all will expire shortly after 3pm UK time on Thursday 30 September 2021 [2021-09-30T14:01:15Z].
Please note: Disabling https does mean your data including apikey will be passed to emoncms.org in plain text without encryption and this could compromise your emoncms.org account. We do recommend upgrading to to the latest image as soon as possible to keep your system secure.
Im still looking into other options for updating the cert in place.
Thanks @bwduncan@glyn.hudson is going to try that now, I got the impression that this needed an OpenSSL update as well and the old image I tried to fix for someone just now had difficulty with package lists and was out of LTS anyway. Would be great though if that works.
I’ve just experienced a similar issue with one of the systems I maintain.
I found an alternative approach on the server side that’s given some breathing room, that was to change the ACME client to use a ZeroSSL certificate rather than Let’s Encrypt. ZeroSSL doesn’t rely on the same root certificates and so continues to work with older systems.
I realise that this is primarily a workaround for systems that should be updated, however it does give users time to get systems updated whilst everything continues to work. Also, I prefer Let’s Encrypt’s business model so will be returning to their certs as soon as possible.
Thanks, that’s very useful. I tried this on our emonSD-07Nov16 emonSD which is based on Debian 8 (Jessie). Unfortunately, it didn’t work. The image has got OpenSSL 1.0.1k 8 Jan 2015.
As @TrystanLea mentioned above, efforts to update packages are fraught with ‘unable to fetch packages’ error because the image is so old.
Give how old this image is, I think the sensible solution is to upgrade to the latest image.
Trystan - I didn’t look - and I’ve already swapped over the emonSD to a new image now. Having issues with my EmonTXs with the new image - I’ve posted a question on this.
Thanks for the prompt email Trystan. I’m in the strange position of having two systems running 2000km apart, both writing to emoncms.org. Unfortunately the remote one has been running low-write 9.8.0 2017.02.01 for over four years now with zero problems, but is now failing. It appears to have stopped about 10:00 UTC yesterday 30 Nov. A WeeWx weather station on the same site using the Emoncms add-on is working fine. With no physical access I may have to disable https as a workaround until I next get there!
We’re using Windows based servers and the Win-Acme client, it was just a case of running that with a different server URL. I’m guessing that won’t help you much as it looks like your site is Ubuntu/Apache based.
There is a list of Acme clients compatible with ZeroSSL here: ACME Automation - ZeroSSL. acme.sh is one of those clients and it looks like they’ve been defaulting to ZeroSSL’s server on versions released since August 2021. For other Acme clients, once you know the setting, just point it at the server: https://acme.zerossl.com/v2/DV90
Thanks @DelBert just tried that one and it’s just timing out unfortunately, they must be busy with everyone trying to switch certs!! Will try again soon, testing on another server first to be sure I have the process right!
I’d be surprised if their servers were overloaded but I guess it could have happened.
It might be worth forcing a re-issue of the Let’s Encrypt certificate with whatever tool you currently use to maintain the certificate. Since the root CA certificate expired, any new certs published aren’t including this path, which should mean the client will find the valid path instead, similar to @bwduncan solution, but from the server side instead.