Report bugs to 1984Hosting dns api

[phedoreanu]

Please report any issues with the 1984Hosting dns api here.

Thanks!

EDIT: add usage guide.

[DerVerruckteFuchs]

I'm trying to use the acme package for pfsense. I'm getting on _on_issue_err. From what I can tell, the relevant part on the issuecert log is:

invalid domain='_acme-challeng.example.com'
Error add txt for domain:_acme-challenge.example.com
_on_issue_err

At first I thought it had trouble with subdomains, but it seems to also have the same problem with domains. I've had trouble before making the relevant _acme-challenge.subdomain.example.com, and after. The script seems to have no issue logging in, but actually adding the TXT records seems to be an issue. I will note that when I'm logged in, my relevant TXT record shows up as _acme-challenge.subdomain, which may or may not be having an effect.

[DerVerruckteFuchs]

I did some more testing. In _get_root(), the results of _authget() fail to get a response that contains "serial". Using _info to help print out useful information, $_response is {"auth": false, "ok": false}. My username and password are correct, and the script gets past _1984hosting_login(), but fails in _get_root().

I chased it down to the login cookie not getting set correctly. On line 171 of dns_1984hosting.sh there is a broken grep search. The HTTP header has set-cookie, but the grep is looking for Set-Cookie, so $One984HOSTING_COOKIE is left empty. Correcting the grep to look for set-cookie fixes it.

[DerVerruckteFuchs]

I made a pull request (#2961) that should fix this. I've tested it, and it seems to work fine. The script finished and I can see the new TXT record for my domain.

[DerVerruckteFuchs]

After @Neilpang reviewed my pull request, I had to look at why there was difference in capitalization. It came down to a change between HTTP/1.1 -> HTTP/2. HTTP/1.1 is case insensitive, so anything goes with upper/lower case. HTTP/2 is technically also case insensitive, but valid HTTP/2 header fields are lower case. I think the script was originally tested with only HTTP/1.1 header fields. Though technically they are case insensitive, so the script could have failed with a change of case in the HTTP/1.1 set-cookie: header field as well.

[poVoq]

It seems they have an experimental API. When asking their tech support they provided me with a python-script to used with Dehydrated and the warning "it is hidden, half-cooked and not tested with wildcards". Couldn't actually get the script to work with Dehydrated on OpenWRT, but looking at the code the API should work also with acme.sh:

https://api.1984.is/1.0/freedns/letsencrypt/?apikey=yourapikey&domain=yourdomain&challenge=generatedchallenge

[poVoq]

Hmm, I tried it with the login option, but for unclear reasons it does not allow me to log in. Edit: I did get manual mode working though.

It would be much appreciated if someone who knows the system better than me could try it with the API and make a script for it. I had a look if there was a similar api with a simple webhook (the old Linode one maybe?), but I couldn't quite wrapp my head around how the script works exactly.

[DerVerruckteFuchs]

It seems they have an experimental API. When asking their tech support they provided me with a python-script to used with Dehydrated and the warning "it is hidden, half-cooked and not tested with wildcards". Couldn't actually get the script to work with Dehydrated on OpenWRT, but looking at the code the API should work also with acme.sh:

https://api.1984.is/1.0/freedns/letsencrypt/?apikey=yourapikey&domain=yourdomain&challenge=generatedchallenge

I put my freedns api key, domain, and generated challenge into the example URL. Simply taking that and putting that into a browser URL bar was enough to add the TXT record for me. I got this as JSON output:
{"ok": true, "msg": "letsencrypt entry created"}

I did not even need to be logged in and it worked. A simple HTTP POST request might be enough after generating a URL with the necessary variables.

[DerVerruckteFuchs]

I ran acme.sh and manually used the 1984 FreeDNS API URL and I got an updated certificate. The dns_1984hosting.sh is able to login, but it does not seem to be able to remove the TXT record. I'm getting a couple of errors:

Error getting zone_id for _acme-challenge.sub.domain.com
Error removing txt for domain:_acme-challenge.sub.domain.com

I think the zone_id failure is from the SOA check failing. When I use https://management.1984hosting.com/domains/soacheck/?zone=sub.domain.com&nameserver=ns0.1984.is., the JSON output I'm getting is: {"serial": null}. However, when I use https://management.1984hosting.com/domains/soacheck/?zone=domain.com&nameserver=ns0.1984.is., the output I get is {"serial": $NUMBER}. I don't think the API likes subdomains. This might be a part of the half-cooked API 1984 tech support warned about.

[DerVerruckteFuchs]

The experimental letsencrypt API is not currently working for me like it did 2-3 months ago. I'm getting an "Oopsy Daisy!" error page. However, a number of JS and CSS files are 404ing for me, so even the error page is a bit broken at the moment. I remember what the error page looked like at one point when everything loaded successfully. I sent 1984 hosting a message about the letsencrypt API asking about what the current status is.

It has been fixed.

[DerVerruckteFuchs]

1984 hosting fixed the HTTP POST issue with the letsencrypt API.

[DerVerruckteFuchs]

I think I've narrowed down the login issue. As would be expected, the issue is found in the _1984hosting_login() function. On line 148, the $url variable is double quoted. As a result, when print debugging the _post() function from acme.sh, the value of $2, as well as the value of $_post_url, do not have the value of $url, but their value is the variable name of $url as a string.
So changing line 148 from:
response="$(_post "username=$username&password=$password&otpkey=" "$url")"

to:
response="$(_post "username=$username&password=$password&otpkey=" $url)"

fixes the login issue. There are some other things that need fixed, namely getting the zone id and properly removing the _acme-challenge TXT record, but at least it can log in again it seems.

[DerVerruckteFuchs]

The --user-agent "$USER_AGENT" curl argument that shows up in the _post() function results in a 403 error for me. After removing it I am finally getting {"ok": true, "loggedin": true} as part of the response.

Edit:
This is a bit strange since it is a part of the acme.sh file. I've been testing with a new bash script on my laptop where acme.sh and dns_1984hosting.sh are mashed together, so not ideal. I'll test a bit more in a proper deployed setting. The fix for the $url issue works in my deployed setting.