DNS API Tests fail on Solaris

[nosilver4u]

I'm working on an integration for the new Bunny.net DNS API, and I've got it working great. But I thought I'd see if I could run the test suite to contribute the script for others to use and ran into an issue.

The Solaris VM appears to have trouble validating the SSL certs for api.bunny.net, as evidenced by a cURL error 60:

  [Tuesday, September  6, 2022 at 12:23:51 AM UTC] url='https://api.bunny.net/dnszone'
  [Tuesday, September  6, 2022 at 12:23:51 AM UTC] timeout=
  [Tuesday, September  6, 2022 at 12:23:52 AM UTC] Http already initialized.
  [Tuesday, September  6, 2022 at 12:23:52 AM UTC] _CURL='curl --silent --dump-header /root/.acme.sh/http.header  -L  -g '
  [Tuesday, September  6, 2022 at 12:23:52 AM UTC] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 60
  [Tuesday, September  6, 2022 at 12:23:52 AM UTC] ret='60'
  [Tuesday, September  6, 2022 at 12:23:52 AM UTC] error in domain_list response: 
  [Tuesday, September  6, 2022 at 12:23:52 AM UTC] domain not found in your account for addition
  [Tuesday, September  6, 2022 at 12:23:52 AM UTC] Error add txt for domain:_acme-challenge.***

I don't think there's anything I can do about that, is that something you can resolve, or should I just submit pull request regardless?

[github-actions[bot]]

Please upgrade to the latest code and try again first. Maybe it's already fixed. acme.sh --upgrade If it's still not working, please provide the log with --debug 2, otherwise, nobody can help you.

[nosilver4u]

Thanks bot, I'm running the latest, and already provided the relevant bit from the log :)

[Neilpang]

please send PR first, so that I could check the solaris issues.

Thanks

[nosilver4u]

I used your Solaris vm/shell and it complains that the cert is expired. The shell timed out before I could investigate too much more. The cert for api.bunny.net is issued by LE and expires in November, but I wonder if it's hitting an issue with the "cross-signed" root from the LE root CA transition a while back? If memory serves correctly, it can be fixed with newer versions of openssl, but this says there might be some workarounds: https://community.letsencrypt.org/t/production-chain-changes/150739/3

At any rate, I'll submit a PR and we'll take it from there!

[bbruun]

I have the same issue in the dns_dnsservices.sh script - it fails with

[Sunday, August 28, 2022 at 1:53:38 PM UTC] GET
[Sunday, August 28, 2022 at 1:53:38 PM UTC] url='https://dns.services/api/dns'
[Sunday, August 28, 2022 at 1:53:38 PM UTC] timeout=
[Sunday, August 28, 2022 at 1:53:38 PM UTC] Http already initialized.
[Sunday, August 28, 2022 at 1:53:38 PM UTC] _CURL='curl --silent --dump-header /root/.[acme.sh/http.header](http://acme.sh/http.header) -L -g '
[Sunday, August 28, 2022 at 1:53:39 PM UTC] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 60
[Sunday, August 28, 2022 at 1:53:39 PM UTC] ret='60'

It didn't ~1-1½ months ago. The DNS API's certificate was LE updated automatically on August 16th.

I can fix it in the Solaris OVA version by adding a task in the Solaris actions list rm -f /etc/certs/ssl/DST_Root_CA_X3.pem && /usr/sbin/svcadm restart /system/ca-certificates but that does not work on the GitHub Actions Solaris version as it seems to be a Mac and not Solaris.

[Neilpang]

please rebase to the latest dev branch. And define a secret, "HTTPS_INSECURE=1" The solaris tests will ignore the https errors.

[nosilver4u]

I had forked only the master branch, so I just deleted and recreated my fork. Which is probably for the best, since I forgot to create a separate branch on my fork and was working on 'master'!

Anyway, it just passed the Solaris test, 3 more (I think) to go!

[bbruun]

I concure - the Solaris test is working now - on the Dev branch.