Clarification on usage of https://auth.acme-dns.io about acme-dns

[joohoi]

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]

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]

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.

[sserdyuk]

@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

[webprofusion-chrisc]

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.

[Ajedi32]

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.

[gucki]

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?

[Ajedi32]

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.

[sserdyuk]

Thank you sir

[VuiDJi]

@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]

It works! :)

[mdella-nutanix]

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