I just flashed a new card and can’t get a certificate. Is this project still alive?
Hi Chris,
Welcome back, and thank you very much for reporting this issue.
It looks like LetsEncrypt stopped supporting the certificate signing algorithm that WebThings Gateway is using for the free webthings.io subdomains, so we’re going to need to issue an urgent update.
I have filed an issue on GitHub and you can monitor progress there.
Apologies for the inconvenience. In the meantime I can only suggest that you use WebThings Gateway on your local network, or with your own custom domain.
Ben
1 Like
If anyone desperately wants a running commentary on me fumbling my way through creating a 1.0.1 release in order to resolve this issue (because who wouldn’t?), see the WebThings channel on Mozilla’s Matrix https://chat.mozilla.org/#/room/#iot:mozilla.org
Explains my problem - same issue - flashed a clean install to to a new SD card. Is there a way to “move” the old certificate from the old SD - and would this even work?
Otherwise - working locally for now and completing my config … will come back here from time to time to see progress. Good luck on completing 1.0.1
Thanks Ben - I have just read that 1.0.1 is ready for testing - just wondering if there is a way to manually update acme-client to ver 4.2.5 pending the release of 1.0.1?
You could manually copy over the certificate files:
~/.webthings/ssl/privatekey.pem
~/.webthings/ssl/certificate.pem
But you would also need to configure the correct domain, which isn’t as straightforward since I think that’s stored as a setting in the SQLite database.
Currently only if you build from source. There is not yet a built image, package or OTA update available to test.
It is possible to take a Raspberry Pi running WebThings Gateway 1.0, manually check out and build the the 1.0.X (or master) branch of the source code and then switch out the new “gateway” folder for the old one. I have done this successfully to create a demo gateway.
However, I would not recommend this for a production gateway because you may get the gateway into an unusual state where it can’t be automatically upgraded in the future.
Thanks for the suggestion Ben - I was away from my home setup for several days so only able to test this this evening. Unfortunately - without success.
I was able to recover the PEM files from the old (i.e. now broken config) and copy them over to the new (i.e. working locally config), and also updated the “tunneltoken” in the db.sqlite3 - and restarted by WebThings gateway - but it seems this is not enough to make the old certificate active. Maybe, I’ll just wait until 1.0.1 is ready for testing/released …
You also need to delete “notunnel” from the settings table.
sqlite3 ~/.webthings/config/db.sqlite3 ‘delete from settings where key = “notunnel”’
Note the " ’ at the end there. Then restart. That is probably your last issue. If you look in the daily developer log for “certificate” you should see logging about it. If it fails to update your old certificate already expired.
Thanks Ben - some success! The OTA update worked and my Raspberry Pi rebooted with 1.1.0-alpha.2 loaded - good news - and was immediately available via the Internet (automatic certificate renewal?). However, none of my Zigbee devices were active. Next I tried booting from a clean (new install) of the 1.1.0-alpha.2 ZIP, and that also booted up correctly - and I was able to reclaim my certificate/token. While I could pair some of the existing Zigbee devices, none worked - it’s as if none have any attributes (on-off, temperature, etc.). I will do some more tests and post logs and screen shots to Github. As an aside, the SquareTheme add-on does not work with 1.1.0-alpha.2 (won’t insall) - there is a message in the log about something being depreciated - will log that separately
WHAT: working folder changes from /home/node/.mozilla-iot to:
/home/node/.webthings
This change could have occured previous to the alpha release, but it’s the first time I’ve encountered the change.
For addon developers, the full path of the working folder for (log, addon, etc) changed path. In my addon, I had hard-coded the path to a custom addon program/executable as: /home/node/.mozilla-iot.
The new path is: /home/node/.webthings
In my addon I updated the path to the executable to it’s standard location, and since I use Docker, created a new volume in my startup script to include the script in the Docker container. Not ideal but works for me.
Note: When I tested my addon changes the DateTime addon still had the same error condition where I had to disable it, update, add the addon again, for it to recover. The blocking (core dumping) Datetime addon version is 1.2.1
I think an env var exist to the .webthings folder
Thanks for reporting.
That would be great, thank you. Which zigbee add-on are you using? The WebThingsIO Zigbee adapter or the Zigbee2MQTT adapter? There’s a known issue with the latter which affects all versions of WebThings Gateway.
Thank you, I commented on the issue you filed.
This changed two years ago in 1.0 when Mozilla branding was removed.
Why do you need an absolute path? Which add-on is this and what language is it written in? In Node.js you can use __dirname to get the path of the directory your add-on is executed from, e.g. here.
Thanks, I hoped there would be some variable to inspect. Logged into the Docker image and ~node/webthings/gateway/run-app.sh contained this variable right at top.
1 Like