-
-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Report bugs to 1984Hosting dns api #2851
Comments
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:
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 I chased it down to the login cookie not getting set correctly. On line 171 of |
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 |
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:
|
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. |
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: 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
I think the zone_id failure is from the SOA check failing. When I use |
It has been fixed. |
1984 hosting fixed the HTTP POST issue with the letsencrypt API. |
I think I've narrowed down the login issue. As would be expected, the issue is found in the to: fixes the login issue. There are some other things that need fixed, namely getting the zone id and properly removing the |
The Edit: |
@DerVerruckteFuchs fixed. try again with dev branch.
|
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 |
I think I have narrowed it down in regards to error checking. In |
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 I was able to renew my pfsense cert with my changes. Fix incoming. |
@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. |
|
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 |
@gzm55 That API only allows A records to be set dynamic. |
@phedoreanu sorry, i missed the A records limit. |
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 original:
with more readable formatting:
I made an initial attempt of fixing the CSRF issue by supplying the CSRF token by assigning it to the original
more readable formatting:
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 |
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 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. |
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 Edit: It looks like |
@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='<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>
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 |
I get suddenly a renew error with Curl error 60:
edit
|
Issue
Steps to reproduce
Debug log[2.6.0-RELEASE][root@myserver.myinternaldomain]/usr/local/pkg/acme: ./acme.sh --issue --debug 2 --domain 'publicdomain.tk' --dns 'dns_1984hosting' --domain '.publicdomain.tk' --dns 'dns_1984hosting' --home '/tmp/acme/publicdomain.tk/' --accountconf '/tmp/acme/publicdomain.tk/accountconf.conf' --force --reloadCmd '/tmp/acme/publicdomain.tk/reloadcmd.sh' --dnssleep '60' --log-level 3 --log '/tmp/acme/publicdomain.tk/acme_issuecert.log' [Tue Aug 30 08:23:40 UTC 2022] d='*.publicdomain.tk' [Tue Aug 30 08:23:48 UTC 2022] Sleep 60 seconds for the txt records to take effect ---- removed the verify part as its irrelevant, until txt record creation is fixed. |
If anyone is interested, i just fixed this, used fiddler to check the manual creation and basically this is the issue:
maybe someone wants to update the script on the repo? |
Renewing fails suddenly for me.
|
I'm still getting a login error for the 1984 dns. When I try the post using CURL I always get a CSRF token error. Is there any way to fix this? |
@jonaudunn you were right, CSRF token was missing from the login request. Fixed in #4412. |
As a new user I can't get it to work. Even when trying your new dns_1984hosting.sh from #4412 :
After some own troubleshooting (changing
|
Pushed a fix for the |
Thanks, I can confirm this works! |
I created a I works. The only downside is that the TXT record does not get removed because there is no api on 1984hosting for that, so once the domain was authenticated, the TXT record has to be removed manually (or left there, it does no harm). |
@5im-0n There is an issue with your code. It adds the entry two times if one uses a wildcard cert and by that has a Le_Domain and Le_Alt entry. First for the domain.tld and then again for the *.domain.tld. Both are different, but zerossl expects the first, it should only add one challenge for the domain first, not for the alt right away. This will overwrite the challenge and it fails. |
2 issues , one unresolved, can you please help ?
But :
Any help appreciated ! |
Are you testing with the latest version from #5057 ? |
Great ! This one works perfectly 👍 Thanks a lot !!! 🥇 |
Please report any issues with the 1984Hosting dns api here.
Thanks!
EDIT: add usage guide.
The text was updated successfully, but these errors were encountered: