[GH-ISSUE #120] Clarification on usage of https://auth.acme-dns.io

kerem commented

2026-03-13 15:31:41 +03:00

Owner

Originally created by @gucki on GitHub (Oct 12, 2018).
Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/120

I couldn't find any information if https://auth.acme-dns.io is official and can be used in production? Or is it just a demo and could go away anytime? Would be great to have this clarified in the readme or at https://www.acme-dns.io. Thank you.

Originally created by @gucki on GitHub (Oct 12, 2018). Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/120 I couldn't find any information if https://auth.acme-dns.io is official and can be used in production? Or is it just a demo and could go away anytime? Would be great to have this clarified in the readme or at https://www.acme-dns.io. Thank you.

kerem added the

Documentation

label

2026-03-13 15:31:41 +03:00

kerem commented

2026-03-13 15:31:52 +03:00

Author

Owner

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

Pretty sure you can use it in production, but if you do you're technically giving the owner of that domain the ability to issue certs for your website.

This is documented in the README:

You are encouraged to run your own acme-dns instance, because you are effectively authorizing the acme-dns server to act on your behalf in providing the answer to the challenging CA, making the instance able to request (and get issued) a TLS certificate for the domain that has CNAME pointing to it.

In the future it might be possible to fix that using ACME CAA extensions with the accounturi parameter, but until that's implemented I'd recommend against using auth.acme-dns.io in production.

@Ajedi32 commented on GitHub (Oct 12, 2018): Pretty sure you _can_ use it in production, but if you do you're technically giving the owner of that domain the ability to issue certs for your website. This is [documented in the README](https://github.com/joohoi/acme-dns#self-hosted): > You are encouraged to run your own acme-dns instance, because you are effectively authorizing the acme-dns server to act on your behalf in providing the answer to the challenging CA, making the instance able to request (and get issued) a TLS certificate for the domain that has CNAME pointing to it. In the future [it might be possible to fix that](https://github.com/joohoi/acme-dns/pull/94#issuecomment-403609162) using [ACME CAA extensions](https://tools.ietf.org/html/draft-ietf-acme-caa-05) with [the accounturi parameter](https://tools.ietf.org/html/draft-ietf-acme-caa-05#section-3), but until that's implemented I'd recommend against using `auth.acme-dns.io` in production.

kerem commented

2026-03-13 15:31:57 +03:00

Author

Owner

@gucki commented on GitHub (Oct 17, 2018):

Thanks. But this doesn't state who is runningauth.acme-dns.io. If it would be a trustworthy party (letsencrypt itself?) it wouldn't be a problem at all. I wonder why letsencrypt is not running this service on their infrastructure (are they?) so it's not needed to haven dozens of custom installs. Shouldn't cause to much traffic/ costs compared to the signing infrastructure?

@gucki commented on GitHub (Oct 17, 2018): Thanks. But this doesn't state who is runningauth.acme-dns.io. If it would be a trustworthy party (letsencrypt itself?) it wouldn't be a problem at all. I wonder why letsencrypt is not running this service on their infrastructure (are they?) so it's not needed to haven dozens of custom installs. Shouldn't cause to much traffic/ costs compared to the signing infrastructure?

kerem commented

2026-03-13 15:32:02 +03:00

Author

Owner

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

Let's Encrypt is just a CA. They don't develop ACME clients or run servers for third-party tools.

I don't know who runs auth.acme-dns.io. Probably @joohoi, I assume.

@Ajedi32 commented on GitHub (Oct 17, 2018): Let's Encrypt is just a CA. They don't develop ACME clients or run servers for third-party tools. I don't know who runs auth.acme-dns.io. Probably @joohoi, I assume.

kerem commented

2026-03-13 15:32:07 +03:00

Author

Owner

@joohoi commented on GitHub (Oct 18, 2018):

Yes. I'm running acme-dns.io and the statement in README.md stands true. However there is something brewing that would address the trust issue once and for all. validationmethods extension to CAA, RFC draft of which you can check out. It's not yet deployed to Let's Encrypt production, but it available on staging environment. You can read more about this from Let's Encrypt community forum post.

TL;DR: CAA extension allows you to redstrict certificate issuance to a specific ACME account, making it feasible to use third party service for providing the TXT record as the issuance is restricted to your specific local ACME account.

@joohoi commented on GitHub (Oct 18, 2018): Yes. I'm running `acme-dns.io` and the statement in `README.md` stands true. However there is something brewing that would address the trust issue once and for all. `validationmethods` extension to CAA, [RFC draft](https://tools.ietf.org/html/draft-ietf-acme-caa-05) of which you can check out. It's not yet deployed to Let's Encrypt production, but it available on staging environment. You can read more about this from Let's Encrypt [community forum post](https://community.letsencrypt.org/t/acme-caa-validationmethods-support/63125). TL;DR: CAA extension allows you to redstrict certificate issuance to a specific ACME account, making it feasible to use third party service for providing the TXT record as the issuance is restricted to your specific local ACME account.

kerem commented

2026-03-13 15:32:13 +03:00

Author

Owner

@joohoi commented on GitHub (Oct 18, 2018):

On additional note, I try to discourage people to use auth.acme-dns.io in their production and instead host their own because of how the trust mechanism without validationmethods work. However I'm trying to keep auth.acme-dns.io up and running, and am striving to preserve the existing database might any upstream changes to the software happen.

@joohoi commented on GitHub (Oct 18, 2018): On additional note, I try to discourage people to use `auth.acme-dns.io` in their production and instead host their own because of how the trust mechanism without validationmethods work. However I'm trying to keep `auth.acme-dns.io` up and running, and am striving to preserve the existing database might any upstream changes to the software happen.

kerem commented

2026-03-13 15:32:18 +03:00

Author

Owner

@sserdyuk commented on GitHub (Jun 24, 2019):

@joohoi Thank you for providing auth.acme-dns.io in the past as a simple solution for the ones that don't want to run the whole system. I noticed it is not working now. The DNS isn't resolving. Does that mean you've discontinued service and we should migrate?

nslookup auth.acme-dns.io 8.8.8.8
Server:		8.8.8.8
Address:	8.8.8.8#53

** server can't find auth.acme-dns.io: SERVFAIL

@sserdyuk commented on GitHub (Jun 24, 2019): @joohoi Thank you for providing `auth.acme-dns.io` in the past as a simple solution for the ones that don't want to run the whole system. I noticed it is not working now. The DNS isn't resolving. Does that mean you've discontinued service and we should migrate? ``` nslookup auth.acme-dns.io 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 ** server can't find auth.acme-dns.io: SERVFAIL ```

kerem commented

2026-03-13 15:32:23 +03:00

Author

Owner

@webprofusion-chrisc commented on GitHub (Jun 25, 2019):

I've been considering offering a low-cost hosted acme-dns option for a while now, mainly to service users of https://certifytheweb.com but it could work for other clients. If auth.acme-dns.io is permanently offline that may become more of a necessity, I'd possibly also be willing to host it depending on the type of costs you're seeing in your current implementation.

@webprofusion-chrisc commented on GitHub (Jun 25, 2019): I've been considering offering a low-cost hosted acme-dns option for a while now, mainly to service users of https://certifytheweb.com but it could work for other clients. If auth.acme-dns.io is permanently offline that may become more of a necessity, I'd possibly also be willing to host it depending on the type of costs you're seeing in your current implementation.

kerem commented

2026-03-13 15:32:28 +03:00

Author

Owner

@joohoi commented on GitHub (Jun 25, 2019):

auth.acme-dns.io is back up now. It was left offline because of hurried maintenance tasks before midsummer festives (a big thing in Finland). When the CAA extensions draft gets finalized and enforcing of it is turned on for Let's Encrypt, I'm planning on hosting a public instance on a more fault tolerant infrastructure.

That said, I'm planning to keep the auth.acme-dns.io running even in its current state regardless.

@joohoi commented on GitHub (Jun 25, 2019): `auth.acme-dns.io` is back up now. It was left offline because of hurried maintenance tasks before midsummer festives (a big thing in Finland). When the [CAA extensions draft](https://tools.ietf.org/html/draft-ietf-acme-caa-10) gets finalized and enforcing of it is turned on for Let's Encrypt, I'm planning on hosting a public instance on a more fault tolerant infrastructure. That said, I'm planning to keep the `auth.acme-dns.io` running even in its current state regardless.

kerem commented

2026-03-13 15:32:33 +03:00

Author

Owner

@sserdyuk commented on GitHub (Jun 25, 2019):

Thank you sir

@sserdyuk commented on GitHub (Jun 25, 2019): Thank you sir

kerem commented

2026-03-13 15:32:38 +03:00

Author

Owner

@VuiDJi commented on GitHub (Jan 24, 2023):

@joohoi Thank you for providing auth.acme-dns.io service. However it is not working now (DNS isn't resolving). Can you please tell me if it is planned to resume its operation, and if so, when? Thank you!

@VuiDJi commented on GitHub (Jan 24, 2023): @joohoi Thank you for providing auth.acme-dns.io service. However it is not working now (DNS isn't resolving). Can you please tell me if it is planned to resume its operation, and if so, when? Thank you!

kerem commented

2026-03-13 15:32:43 +03:00

Author

Owner

@VuiDJi commented on GitHub (Jan 24, 2023):

It works! :)

@VuiDJi commented on GitHub (Jan 24, 2023): It works! :)

kerem commented

2026-03-13 15:32:48 +03:00

Author

Owner

@mdella-nutanix commented on GitHub (Oct 3, 2023):

So how would you host your own service? or can you basically give the application the DDNS key for the CNAME destination TXT file?

@mdella-nutanix commented on GitHub (Oct 3, 2023): So how would you host your own service? or can you basically give the application the DDNS key for the CNAME destination TXT file?

kerem referenced this issue

2026-03-13 16:14:40 +03:00

[PR #51] [MERGED] Add configuration option to disable registration endpoint #270

Rows
Columns

[GH-ISSUE #120] Clarification on usage of https://auth.acme-dns.io #47