curl performs SSL certificate verification by default, using a “bundle”
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn’t adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you’d like to turn off curl’s verification of the certificate, use
the -k (or --insecure) option.
Signature check failed.
Remove wrong Signature file.
Collected errors:
Check the time on your router. If the time is way off in the future (say, the year 2036), the certs will be expired and you will get this error. You can set the time in LuCI if you have enabled the advanced administration password. Log into LuCi and go to: https://192.168.1.1/cgi-bin/luci/admin/system/system (and replace 192.168.1.1 with your router IP). On that LuCi page, you can click “Sync with browser” to sync your time with browser, and I recommend clicking “Enable NTP client” and then clicking ‘Save and Apply’
Same Problem here, but the Fact that the Signing CA reads “Turris Emergency CA” i suspect that there is some sort of missconfiguration on their end. Guess the best thing would be to wait for them to fix the Repo.
We had this CA prepared for any unforeseen problems for some time, and updater accepts it. And with all the mayhem around StartCom we decided that it is easier and safer to use our own CA for automatic updates than relying on a third-party one. The downside is it shows the warning in a browser, but api.turris.cz isn’t meant to be opened in a browser anyway (if you want to browse the packages, you can go to repo.turris.cz).
Obviously, there was one more place we forgot to update before switching the CA. Wait awhile, I’ll try to think of a solution and either roll back to the old cert temporarily or post some kind of workaround for now, before we propagate the configuration change.
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn’t adequate, you can specify an alternate file using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL).
If you’d like to turn off curl’s verification of the certificate, use the -k (or --insecure) option.
Same here. It has been almost 2 weeks since your post @the-s-a-m. Did you solve it (and if so how?). Is this something we (us users) should act upon - client sided or is this something that has to be solved on by turris.cz?
WARN:Script revision-specific not found, but ignoring its absence as requested
WARN:Script serial-specific not found, but ignoring its absence as requested
WARN:Multiple candidates from same repository with same version for package shairport-sync-openssl
WARN:Lock on //var/lock/opkg.lock released by garbage collector
Are those warnings to be expected?
I additionally followed up on your remark and executed an additional:
$ updater.sh
I do see a new /tmp/crl.pem (already after my first command) but;
I encounter the same problem. When usingopkg update :
root@turris:~# opkg update
Downloading https://api.turris.cz/openwrt-repo/omnia/packages//base/Packages.gz.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:–:-- --:–:-- --:–:-- 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a “bundle”
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn’t adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you’d like to turn off curl’s verification of the certificate, use
the -k (or --insecure) option. […]
Signature check failed.
Remove wrong Signature file.
Collected errors:
Launch updater.sh [NOK] message : unreachable: https://api.turris.cz/openwrt-repo/omnia/packages/printing/hplip_3.16.11-1_mvebu.ipk: curl: (28) Operation timed out after 180000 milliseconds with 12910592 out of 15665115 bytes received
The OS kernel has been updated to version 4.4.39+4-1-80079e1c1e5f9ca7ad734044462a761a-4. Please reboot the device.
The device will be restarted automatically on Sunday, February 26 at 03:30 AM.
News announcements
• wget: making sure busybox wget doesn’t override the real one
• openssl: fix various security issues
• libpcap: fix various security issues
• tcpdump: fix various security issuse, dropped mini variant
And this morning everything works, opkg update does not get me out of certificate errors, it seems that this update has solved my problem.
I am still unable to update packages either using opkg update or through LuCI. Even after I disabled signature verification by commenting option check_signature 1 in LuCI opkg configuration page, I still have curl errors when trying to download packages.
