Closed marco-brandizi closed 10 months ago
Hi,
the certificate is valid for me (auto-renewed anyway):
% curl -v https://ydns.io/api/v1/ip 2>&1 | grep -E '(start|expire) date:'
* start date: Dec 7 09:26:01 2022 GMT
* expire date: Mar 7 09:26:00 2023 GMT
Make sure the time on your system is correct.
Feel free to customize the script to fit your needs. You could also prepare the PATH
environment variable accordingly to list the path to your custom location first.
thanks, @commx. It seems I have a more complicated issue, on an old Western Digital MyCloud device, which has gone unsupported and has no system updates:
WDMyCloud:/tmp$ curl -v https://ydns.io/api/v1/ip
* Adding handle: conn: 0x1f50b20
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x1f50b20) send_pipe: 1, recv_pipe: 0
* About to connect() to ydns.io port 443 (#0)
* Trying 217.115.6.75...
* Connected to ydns.io (217.115.6.75) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: certificate has expired
* Closing connection 0
curl: (60) SSL certificate problem: certificate has expired
More details here: http://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.
WDMyCloud:/tmp$
What it says about --cacert
is another example where an option like --curl-cmd
could be useful.
Most likely the CA certificate bundle is outdated. We're using Let's Encrypt which had some expiring root certificates in the past.
You could try downloading a more up-to-date CA bundle and retry the request against our API endpoint using that CA bundle:
$ curl -s https://curl.se/ca/cacert.pem -o cacert.pem
$ curl -v --cacert cacert.pem https://ydns.io/api/v1/ip
Yes, that's the solution for the specific problem. But my point is it would be better if I could inject a customised curl command into the YNDS updater, else I need to tweak the script manually, every time I update it from github.
As mentioned in my earlier comment, there is no need to tweak the path for curl in the script. You can set PATH
to include the path to your custom curl and it should work out of the box, e.g.
PATH="/path/to/my/curl:$PATH" ./updater.sh …
We might include additional options some time in the future, but we'll focus on creating a new API first which most likely involves changes to the updater script as well.
OK, that could be one way, yet it could help if one could pass a custom curl command to your script, which isn't just about the path.
Please, see if you like how I modified the script for that purpose.
Now, I invoke it this way:
./ydns-updater.sh -V -H "$host" -u "$user" -p "$pwd" -c 'curl --insecure'
This work with something like -c '/usrl/local/bin/curl --insecure'
too.
If I do:
curl https://ydns.io/api/v1/ip -o -
, curl tells me the SSL certificate at the YDNS is expired, if I add --insecure (or usehttp://
), it works fine.This makes the updater script to fail. I had to tweak it to add
--insecure
, but obviously, updating the certificate would be better.Apart from that, it would be good to have some option like
--curl-cmd
, to tell the script how to execute curl exactly (eg, from a non-standard location).