acmesh-official
Report bugs to 1984Hosting dns api
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.
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.
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.
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.
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
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.
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.
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.
~~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.
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.
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.
@DerVerruckteFuchs fixed.
try again with dev branch.
acme.sh --upgrade -b dev
@DerVerruckteFuchs fixed.
try again with dev branch.
acme.sh --upgrade -b dev
I tried again with the dev branch. Testing cert renewal with the letsencrypt staging server was successful with pfsense. I was not able to renew the production cert as the _acme.challenge TXT record is not getting set, and the HTTP response is the "OOPSIE DAISY!" error page. For whatever reason this is not detected as an error by the dns_1984hosting.sh script. It just continues to check for the _acme.challenge TXT record as if it was set correctly. I can see that I am successfully getting a login cookie, so the problem seems to be right where _acme.challenge is supposed to get set.
I think I have narrowed it down in regards to error checking. In dns_1984hosting.sh, the dns_1984hosting_add() function checks if the response contains an <html> tag. The response I am getting contains a <!DOCTYPE html> and <html lang="en"> tags and not a plain <html> tag, so the error response does not get detected. Changing response checking to look for html> instead of <html> properly catches the error response as it covers <!DOCTYPE html>, <html>, and the closing </html> tag cases. The alternative is to check for <!DOCTYPE html>, <html>, and <html lang="en">. Changing the response check to look for a closing </html> tag could potentially work just as good. An alternative method would be to check if the response is HTML instead of JSON.
I figured out why the _acme-challenge TXT record was not getting added for domains with subdomains like subdomain.example.com. The issue is at lines 207 and 208 in the _get_root() function. Using https://management.1984hosting.com/domains/soacheck/?zone=subdomain.example.com&nameserver=ns0.1984.is. returns a {"serial": null} JSON response. The if statement on line 208 only checks if serial is contained in the response. This results in _domain getting assigned the value subdomain.example.com and _sub_domain getting assigned _acme-challenge. There is no zone subdomain.example.com as my subdomain is part of the same zone my root domain is in. This results in the attempt to add a DNS record for the nonexistent zone predictably failing. (As an aside, if subdomain.example.com and example.com are separate zones, there is a possibility dns_1984hosting.sh would not fail to issue/renew certs for either zone in its currently broken state.) Changing the if statement to check if the response contains serial and does not contain null results in the while loop continuing until _domain gets assigned the value example.com and _sub_domain gets assigned _acme-challenge.subdomain. The final result is that the _acme-challenge TXT record actually gets set. The fix should also work for subdomains like foo.bar.subdomain.example.com and other URLs with larger/"deeper" subdomain depths where the root domain and subdomain are part of the same zone.
I was able to renew my pfsense cert with my changes. Fix incoming.
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 do you still have that python-script? The last few commits mostly fixed things, so using the dev branch works again with 1984 hosting. However, I was curious to see If getting the DNS API to work with 1984's letsencrypt API might improve things. At least with an experimental branch until an official release anyway. I have an initial start with an experimental branch here, but it still needs to be able to delete _acme-challenges when validation is finished.
dns_1984hosting_rm() is failing to remove _acme-challenge TXT record after validation. I think I've traced it down to dns_1984hosting_rm() failing to get the zone id. The issue has to do with _htmlget() somehow managing to get the HTML for the user nav (the user email dropdown with options for account settings, logout, etc.), instead of the HTML for the domain that has the zone id. The HTML response's first line is the user nav, and a few lines down the zone id and domain are present. Removing _head_n 1 from _htmlget() allows 4-6 lines or so to be part of _response and contain the zone id so it can get parsed. The entry number for the _acme-challenge TXT record is successfully obtained. I tried manually running https://management.1984hosting.com/domains/delentry/entry=$entry_number in the browser, but got an {"ok": false} response. I am not sure if it is just because I tried submitting a POST request from the browser's URL bar, or if there is more going on that needs fixed.
Yes I think I still have it, but other then the line above it just handles some Dehydrated side stuff, so no real point in sharing it (and back then the tech-support asked me not to spread it around too much).
https://management.1984hosting.com/domains/freednsapi/
@phedoreanu it seems the 1984hosting has supported the dynamic dns api
1984 Hosting has updated their website, which has introduced some breaking changes with the 1984Hosting DNS API. I managed to fix an HTTP header issue that causes the login to fail. It was the sessionid cookie yet again, lol. Fix here: #3697. There is at least one missing HTTP header. This is the HTML response I'm getting when the script tries to POST a new entry for an _acme-challenge TXT record:
original:
<!DOCTYPE html><html lang="en"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"><meta name="robots" content="NONE,NOARCHIVE"><title>403 Forbidden</title><style type="text/css">html * { padding:0; margin:0; }body * { padding:10px 20px; }body * * { padding:0; }body { font:small sans-serif; background:#eee; color:#000; }body>div { border-bottom:1px solid #ddd; }h1 { font-weight:normal; margin-bottom:.4em; }h1 span { font-size:60%; color:#666; font-weight:normal; }#info { background:#f6f6f6; }#info ul { margin: 0.5em 4em; }#info p, #summary p { padding-top:10px; }#summary { background: #ffc; }#explanation { background:#eee; border-bottom: 0px none; }</style></head><body><div id="summary"><h1>Forbidden <span>(403)</span></h1><p>CSRF verification failed. Request aborted.</p><p>You are seeing this message because this HTTPS site requires a “Referer header” to be sent by your Web browser, but none was sent. This header is required for security reasons, to ensure that your browser is not being hijacked by third parties.</p><p>If you have configured your browser to disable “Referer” headers, please re-enable them, at least for this site, or for HTTPS connections, or for “same-origin” requests.</p><p>If you are using the <meta name="referrer" content="no-referrer"> tag or including the “Referrer-Policy: no-referrer” header, please remove them. The CSRF protection requires the “Referer” header to do strict referer checking. If you’re concerned about privacy, use alternatives like <a rel="noreferrer" …> for links to third-party sites.</p></div><div id="explanation"><p><small>More information is available with DEBUG=True.</small></p></div></body></html>
with more readable formatting:
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<meta name="robots" content="NONE,NOARCHIVE">
<title>403 Forbidden</title>
<style type="text/css">html * { padding:0; margin:0; }body * { padding:10px 20px; }body * * { padding:0; }body { font:small sans-serif; background:#eee; color:#000; }body>div { border-bottom:1px solid #ddd; }h1 { font-weight:normal; margin-bottom:.4em; }h1 span { font-size:60%; color:#666; font-weight:normal; }#info { background:#f6f6f6; }#info ul { margin: 0.5em 4em; }#info p, #summary p { padding-top:10px; }#summary { background: #ffc; }#explanation { background:#eee; border-bottom: 0px none; }</style>
</head>
<body>
<div id="summary">
<h1>Forbidden <span>(403)</span></h1>
<p>CSRF verification failed. Request aborted.</p>
<p>You are seeing this message because this HTTPS site requires a “Referer header” to be sent by your Web browser, but none was sent. This header is required for security reasons, to ensure that your browser is not being hijacked by third parties.</p>
<p>If you have configured your browser to disable “Referer” headers, please re-enable them, at least for this site, or for HTTPS connections, or for “same-origin” requests.</p>
<p>If you are using the <meta name="referrer" content="no-referrer"> tag or including the “Referrer-Policy: no-referrer” header, please remove them. The CSRF protection requires the “Referer” header to do strict referer checking. If you’re concerned about privacy, use alternatives like <a rel="noreferrer" …> for links to third-party sites.</p>
</div>
<div id="explanation">
<p><small>More information is available with DEBUG=True.</small></p>
</div>
</body>
</html>
I made an initial attempt of fixing the CSRF issue by supplying the CSRF token by assigning it to the _H2 header variable and Referer: https://management.1984hosting.com/domains/zone/$zone_number/ to the _H3 header variable. It still failed, but the HTML response changed:
original
<!DOCTYPE html><html lang="en"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"><meta name="robots" content="NONE,NOARCHIVE"><title>403 Forbidden</title><style type="text/css">html * { padding:0; margin:0; }body * { padding:10px 20px; }body * * { padding:0; }body { font:small sans-serif; background:#eee; color:#000; }body>div { border-bottom:1px solid #ddd; }h1 { font-weight:normal; margin-bottom:.4em; }h1 span { font-size:60%; color:#666; font-weight:normal; }#info { background:#f6f6f6; }#info ul { margin: 0.5em 4em; }#info p, #summary p { padding-top:10px; }#summary { background: #ffc; }#explanation { background:#eee; border-bottom: 0px none; }</style></head><body><div id="summary"><h1>Forbidden <span>(403)</span></h1><p>CSRF verification failed. Request aborted.</p></div><div id="explanation"><p><small>More information is available with DEBUG=True.</small></p></div></body></html>
more readable formatting:
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<meta name="robots" content="NONE,NOARCHIVE">
<title>403 Forbidden</title>
<style type="text/css">html * { padding:0; margin:0; }body * { padding:10px 20px; }body * * { padding:0; }body { font:small sans-serif; background:#eee; color:#000; }body>div { border-bottom:1px solid #ddd; }h1 { font-weight:normal; margin-bottom:.4em; }h1 span { font-size:60%; color:#666; font-weight:normal; }#info { background:#f6f6f6; }#info ul { margin: 0.5em 4em; }#info p, #summary p { padding-top:10px; }#summary { background: #ffc; }#explanation { background:#eee; border-bottom: 0px none; }</style>
</head>
<body>
<div id="summary">
<h1>Forbidden <span>(403)</span></h1>
<p>CSRF verification failed. Request aborted.</p>
</div>
<div id="explanation">
<p><small>More information is available with DEBUG=True.</small></p>
</div>
</body>
</html>
The manually created Referer header I provided seems to have done something. I am not sure if there are missing headers still, the referrer URL is not quite right, or if the CSRF token needs to be formatted differently. I searched the error message More information is available with DEBUG=True. and it seems to be a Django error message. I can make new entries on the website just fine. The lack of any info in the error message is a bit bothersome, but might indicate an issue with the CSRF token itself.
All necessary fixes were merged from #3697. The 1948Hosting DNS API plugin should work now.
I found a new issue today. The 1984Hosting DNS API plugin fails when TOTP is enabled for 1984 Hosting. Disabling TOTP allows the script to work as expected. TOTP is probably applicable to more than a few of the supported hosting providers that it should be part of acme.sh. I am thinking a general _totp() function may be appropriate in the future.
I was browsing through the merge requests, and found that TOTP support was added for synology. It looks like it is pretty simple to add.
~~There is a separate issue where removing the TXT record for _acme-challenge.example.tld is failing. I'm going to debug a bit and see if it is a simple fix. 1984 Hosting may have changed their HTML again.~~
Might just be a timing issue. I've had issues in the past with timing. The TXT record was deleted just fine this time.
I created a TOTP branch. The code works fine locally on my machine, but the Docker workflow is not working. I managed to set secrets up for generating the OTP, but the otpkey is set to be an empty string even after generation. As far as I am aware, oathtool is not getting installed in the docker image. I'll need to get this sorted before I can make a pull request.
Edit:
It looks like plat.conf from the acmetest repository is responsible for installing packages. Adding oathtool to the list of packages there would be necessary for the TOTP tests to pass for the Docker workflow. The other workflows that I managed to get working were the FreeBSD, MacOS, PebbleStrict, and Ubuntu workflows. However, I'm concerned about the Solaris and Windows workflows. The Oracle Solaris repository does not have oathtool, nor does chocolatey/cygwin for Windows. Building from source may be cumbersome for a GitHub workflow, and I'm not familiar with alternative repositories for Solaris and Windows that would have oathtool. I also don't like the idea of feature support being OS dependent for a cross-platform tool like this. This would also be an issue for TOTP support for other DNS APIs.
@DerVerruckteFuchs Thanks for all your work into the 1984 API and posting updates here - very helpful to see what's happening. I've ran into the CSRF issue, same error you've posted:
[Tue 15 Mar 2022 06:43:48 PM PDT] response='403 Forbidden Forbidden (403)
CSRF verification failed. Request aborted.
You are seeing this message because this site requires a CSRF cookie when submitting forms. This cookie is required for security reasons, to ensure that your browser is not being hijacked by third parties.
If you have configured your browser to disable cookies, please re-enable them, at least for this site, or for “same-origin” requests.
More information is available with DEBUG=True.
'
I love that GitHub renders the HTML lol. I see that my SAVED_One984HOSTING_CSRFTOKEN_COOKIE is blank (empty string), has this error happened to you recently?
@heyheyhello The appreciation is very welcome!
The CSRF issue you are referring to was fixed some months ago with #3697. Given the date on your error message, I expect your 403/CSRF issue is the same I've been recently experiencing. 1984 Hosting changed their URL from 1984hosting.com to 1984.hosting. From the WHOIS information, 1984.hosting was created on December 23, 2020. The last the record was updated was April 16, 2022. March 26 is when my pfsense box stopped being able to auto-renew its TLS certificate. Checking your error message's date, I expect sometime on, or before, March 15 was about the time that 1984 Hosting switched their primary domain. Their old 1984hosting.com URL redirects to 1984.hosting. This URL change broke the DNS API script and it prevented my pfsense box from renewing its TLS certificate. I have submitted a pull request that fixes this: #4039.
The SAVED_One984HOSTING_CSRFTOKEN_COOKIE will be blank if the login fails. The server provides the CSRF token cookie, along with the sessionid cookie, after a successful login so you do not need to re-login/authenticate yourself every time you want to make changes, navigate to different web pages on the site, etc. The login fails if the script is using the older URL, since that URL is no longer handling logins. As a result, you will not have any cookies to set for either SAVED_One984HOSTING_CSRFTOKEN_COOKIE or SAVED_One984HOSTING_SESSIONID_COOKIE.
I get suddenly a renew error with Curl error 60:
[Do 21. Apr 16:27:46 CEST 2022] ===Starting cron===
[Do 21. Apr 16:27:47 CEST 2022] Already uptodate!
[Do 21. Apr 16:27:47 CEST 2022] Upgrade success!
[Do 21. Apr 16:27:47 CEST 2022] Auto upgraded to: 3.0.3
[Do 21. Apr 16:27:47 CEST 2022] Renew: '<dedacted>'
[Do 21. Apr 16:27:56 CEST 2022] Using CA: https://acme.zerossl.com/v2/DV90
[Do 21. Apr 16:27:56 CEST 2022] Multi domain='DNS:<dedacted>,DNS:*.<dedacted>'
[Do 21. Apr 16:27:56 CEST 2022] Getting domain auth token for each domain
[Do 21. Apr 16:28:33 CEST 2022] Getting webroot for domain='<dedacted>'
[Do 21. Apr 16:28:33 CEST 2022] Getting webroot for domain='*.<dedacted>'
[Do 21. Apr 16:28:34 CEST 2022] Adding txt value: <dedacted> for domain: _acme-challenge.<dedacted>
[Do 21. Apr 16:28:34 CEST 2022] Add TXT record using 1984Hosting
[Do 21. Apr 16:28:34 CEST 2022] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 60
[Do 21. Apr 16:28:34 CEST 2022] 1984Hosting login failed for user <dedacted>. Check /root/.acme.sh/http.header file
[Do 21. Apr 16:28:34 CEST 2022] Error add txt for domain:_acme-challenge.<dedacted>
[Do 21. Apr 16:28:34 CEST 2022] Please check log file for more details: /root/.acme.sh/acme.sh.log
[Do 21. Apr 16:28:49 CEST 2022] Error renew <dedacted>.
edit
Was able to fix it by changing the domain in the dnsapi/dns_1984hosting.sh file inside the acme.sh folder:
sed -i 's/management.1984hosting.com/1984.hosting/' dnsapi/dns_1984hosting.sh
