starred/acme-dns
1
0
Fork 0
mirror of https://github.com/acme-dns/acme-dns.git synced 2026-04-27 04:45:48 +03:00
Code Issues 178 Projects Releases 5 Packages Wiki Activity

[GH-ISSUE #119] Add Option to Use staging Let'sEncryptServer during setup #46

New issue
Open
opened 2026-03-13 15:31:41 +03:00 by kerem · 10 comments
kerem commented 2026-03-13 15:31:41 +03:00
Owner
Copy link

Originally created by @dkhughes on GitHub (Oct 7, 2018).
Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/119

Hi!

Thanks for the great piece of software. During setup, I was trying to figure out my firewall for allowing DNS through properly, and I hit the production requests/hr limit accidentally on Let'sEncrypt servers. It would be nice to be able to change to their staging servers during setup and validation of firewall/ethernet settings. Maybe a config option?

Originally created by @dkhughes on GitHub (Oct 7, 2018). Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/119 Hi! Thanks for the great piece of software. During setup, I was trying to figure out my firewall for allowing DNS through properly, and I hit the production requests/hr limit accidentally on Let'sEncrypt servers. It would be nice to be able to change to their staging servers during setup and validation of firewall/ethernet settings. Maybe a config option?
kerem commented 2026-03-13 15:31:52 +03:00
Author
Owner
Copy link

@Ajedi32 commented on GitHub (Oct 8, 2018):

You mean you hit Let's Encrypt's Failed Validation limit while using the autocert feature via the tls = "letsencrypt" config option?

I like the idea of a config option, but I think the better solution to your problem is to just not use tls = "letsencrypt" until after you're already sure the configured autocert port on your server is accessible from the public internet.

<!-- gh-comment-id:427863118 --> @Ajedi32 commented on GitHub (Oct 8, 2018): You mean you hit Let's Encrypt's Failed Validation limit while using the autocert feature via the `tls = "letsencrypt"` config option? I like the idea of a config option, but I think the better solution to your problem is to just not use `tls = "letsencrypt"` until after you're already sure the configured autocert port on your server is accessible from the public internet.
kerem commented 2026-03-13 15:31:57 +03:00
Author
Owner
Copy link

@dkhughes commented on GitHub (Oct 8, 2018):

Yes, I hit the 5 tries per hour limit on the production servers.

The problem I ran into is that the documentation was a little confusing for me since the name of the DNS subdomain, and the name of the DNS nameserver are identical and it's never mentioned that auth.example.com is the NS or the subdomain we're authorizing for. My DNS provider (dnsmadeeasy) doesn't allow the nameserver to have the same name as the subdomain. So, I was adjusting those domain values, and the letsencrypt self authentication name trying to watch debug messages when I hit the limit.

Offering the staging server as an IP choice when a newbie (e.g., me) is fudging around a bit is also a request the letsencrypt folks made, and it would be nice to be able to respect their wishes.

Debugging the certbot hook setup was much easier since you can pass the staging option and fix any errors the hook or bot throws, and not feel bad since it's not hitting the production IP.

<!-- gh-comment-id:427867434 --> @dkhughes commented on GitHub (Oct 8, 2018): Yes, I hit the 5 tries per hour limit on the production servers. The problem I ran into is that the documentation was a little confusing for me since the name of the DNS subdomain, and the name of the DNS nameserver are identical and it's never mentioned that auth.example.com is the NS or the subdomain we're authorizing for. My DNS provider (dnsmadeeasy) doesn't allow the nameserver to have the same name as the subdomain. So, I was adjusting those domain values, and the letsencrypt self authentication name trying to watch debug messages when I hit the limit. Offering the staging server as an IP choice when a newbie (e.g., me) is fudging around a bit is also a request the letsencrypt folks made, and it would be nice to be able to respect their wishes. Debugging the certbot hook setup was much easier since you can pass the staging option and fix any errors the hook or bot throws, and not feel bad since it's not hitting the production IP.
kerem commented 2026-03-13 15:32:02 +03:00
Author
Owner
Copy link

@Yannik commented on GitHub (Oct 8, 2018):

@dkhughes You do not need to set both a NS record and A/CNAME record at your provider. The A/CNAME is ignored anyway, as it is resolved by your own NS.

Have a look at this dig trace:

[yannik@yannik-laptop ~]$ dig +trace acme-dns.mydomain.org
--snip resolve .org tld --

mydomain.org.		86400	IN	NS	ns1.provider.net.
mydomain.org.		86400	IN	NS	ns2.provider.net.
mydomain.org.		86400	IN	NS	ns3.provider.net.
;; Received 610 bytes from 199.249.112.1#53(a2.org.afilias-nst.info) in 55 ms

acme-dns.mydomain.org. 60	IN	NS	mydomain.org.
;; Received 82 bytes from 194.50.113.2#53(ns2.provider.net) in 71 ms

acme-dns.mydomain.org. 3600	IN	CNAME	mydomain.org.
;; Received 92 bytes from 5.45.101.249#53(mydomain.org) in 74 ms
<!-- gh-comment-id:427886773 --> @Yannik commented on GitHub (Oct 8, 2018): @dkhughes You do not need to set both a NS record and A/CNAME record at your provider. The A/CNAME is ignored anyway, as it is resolved by your own NS. Have a look at this `dig` trace: ``` [yannik@yannik-laptop ~]$ dig +trace acme-dns.mydomain.org --snip resolve .org tld -- mydomain.org. 86400 IN NS ns1.provider.net. mydomain.org. 86400 IN NS ns2.provider.net. mydomain.org. 86400 IN NS ns3.provider.net. ;; Received 610 bytes from 199.249.112.1#53(a2.org.afilias-nst.info) in 55 ms acme-dns.mydomain.org. 60 IN NS mydomain.org. ;; Received 82 bytes from 194.50.113.2#53(ns2.provider.net) in 71 ms acme-dns.mydomain.org. 3600 IN CNAME mydomain.org. ;; Received 92 bytes from 5.45.101.249#53(mydomain.org) in 74 ms ```
kerem commented 2026-03-13 15:32:07 +03:00
Author
Owner
Copy link

@dkhughes commented on GitHub (Oct 8, 2018):

I did notice that when I was watching the queries being resolved.

I think the issue for me was more to do with not knowing what I should put specifically into the different values. The comments weren't clear enough for my experience level with acme-dns. For example, the entry in the config file ('https://github.com/joohoi/acme-dns/blob/master/config.cfg#L32'):

# domain name to listen requests for, mandatory if using tls = "letsencrypt"
api_domain = ""

The empty string doesn't provide any help. An example in the comment would be very helpful in knowing that it should point to the public name chosen for your local authentication - I just used the same DNS name (ns0.example.com). When setting it up, I wasn't sure if it was using that value alone or doing an internal combination with the settings that came previously in the config file.

I got there in the end, but it took a few tries which is why I thought it would be nice to be able to specify the staging servers.

<!-- gh-comment-id:427900903 --> @dkhughes commented on GitHub (Oct 8, 2018): I did notice that when I was watching the queries being resolved. I think the issue for me was more to do with not knowing what I should put specifically into the different values. The comments weren't clear enough for my experience level with acme-dns. For example, the entry in the config file ('https://github.com/joohoi/acme-dns/blob/master/config.cfg#L32'): ``` # domain name to listen requests for, mandatory if using tls = "letsencrypt" api_domain = "" ``` The empty string doesn't provide any help. An example in the comment would be very helpful in knowing that it should point to the public name chosen for your local authentication - I just used the same DNS name (ns0.example.com). When setting it up, I wasn't sure if it was using that value alone or doing an internal combination with the settings that came previously in the config file. I got there in the end, but it took a few tries which is why I thought it would be nice to be able to specify the staging servers.
kerem commented 2026-03-13 15:32:12 +03:00
Author
Owner
Copy link

@dkhughes commented on GitHub (Oct 8, 2018):

@Yannik Oh, and what I meant about the DNS record at dnsmadeeasy is the NS record is not allowed to have auth.example.com as the subdomain and the NS record destination. It's not a conflict between the A record and NS, it's in their webgui that blocks that type of entry.

<!-- gh-comment-id:427909383 --> @dkhughes commented on GitHub (Oct 8, 2018): @Yannik Oh, and what I meant about the DNS record at dnsmadeeasy is the NS record is not allowed to have `auth.example.com` as the subdomain *and* the NS record destination. It's not a conflict between the A record and NS, it's in their webgui that blocks that type of entry.
kerem commented 2026-03-13 15:32:18 +03:00
Author
Owner
Copy link

@Yannik commented on GitHub (Oct 8, 2018):

@dkhughes Oh, now I got you. IIRC this would also be against a dns rfc. Is there anything in the docs that made you use this specific setup?

<!-- gh-comment-id:427910396 --> @Yannik commented on GitHub (Oct 8, 2018): @dkhughes Oh, now I got you. IIRC this would also be against a dns rfc. Is there anything in the docs that made you use this specific setup?
kerem commented 2026-03-13 15:32:23 +03:00
Author
Owner
Copy link

@dkhughes commented on GitHub (Oct 8, 2018):

@Yannik No reason other than it was in place already. The change was simple in the config for the NS restriction - the server just got called ns0.auth.example.com. instead of auth.example.com, and then the change propogated through the config file.

acme-dns is the best solution I've come across now for keeping https servers that are on a private subnet with no public http access happy (previously used dehydrated scripts).

<!-- gh-comment-id:427913736 --> @dkhughes commented on GitHub (Oct 8, 2018): @Yannik No reason other than it was in place already. The change was simple in the config for the NS restriction - the server just got called ns0.auth.example.com. instead of auth.example.com, and then the change propogated through the config file. acme-dns is the best solution I've come across now for keeping https servers that are on a private subnet with no public http access happy (previously used dehydrated scripts).
kerem commented 2026-03-13 15:32:28 +03:00
Author
Owner
Copy link

@jrkeen commented on GitHub (Oct 11, 2018):

I need a detailed tutorial for cer-manager using acme-dns thanks

<!-- gh-comment-id:428895411 --> @jrkeen commented on GitHub (Oct 11, 2018): I need a detailed tutorial for cer-manager using acme-dns thanks
kerem commented 2026-03-13 15:32:33 +03:00
Author
Owner
Copy link

@coreyperkins commented on GitHub (Apr 22, 2020):

Is there a workaround for this? I'm using the CertifyTheWeb GUI.

<!-- gh-comment-id:617918294 --> @coreyperkins commented on GitHub (Apr 22, 2020): Is there a workaround for this? I'm using the CertifyTheWeb GUI.
kerem commented 2026-03-13 15:32:38 +03:00
Author
Owner
Copy link

@webprofusion-chrisc commented on GitHub (Apr 24, 2020):

@coreyperkins this issue relates only to the acme-dns server itself (getting it set up and configured to use Let's Encrypt for it's own certificate). For Certify The Web itself supporting for staging (for the certs you generate using it) is coming shortly in v5.

<!-- gh-comment-id:618843363 --> @webprofusion-chrisc commented on GitHub (Apr 24, 2020): @coreyperkins this issue relates only to the acme-dns server itself (getting it set up and configured to use Let's Encrypt for it's own certificate). For Certify The Web itself supporting for staging (for the certs you generate using it) is coming shortly in v5.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
fix_dockerhub
dockerhub
readme2.0
goreleaser_action
refactoring
linter_update_config
update_deps_122
dependabot/go_modules/github.com/valyala/fasthttp-1.34.0
deps_bump
update_goreleaser
update_golint
deps_update
update_dockerfile
v2.0.2
v2.0.1
v2.0
v1.1
v1.0
v0.8
v0.7.2
v0.7.1
v0.7
v0.6
v0.5
v0.4
v0.3.2
v0.3.1
v0.3
v0.2
v0.1
Labels
Clear labels   
Documentation

   
Documentation

   
bug

   
enhancement

   
feature request

   
feature request

   
help wanted

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
security

   
security

   
testing
No labels
Documentation
Documentation
bug
enhancement
feature request
feature request
help wanted
pull-request
question
security
security
testing
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/acme-dns#46
No description provided.