starred/acme-dns

Fork 0

mirror of https://github.com/acme-dns/acme-dns.git synced 2026-04-27 04:45:48 +03:00

[GH-ISSUE #216] Some basic form of access control #101

New issue

Open

opened 2026-03-13 15:46:47 +03:00 by kerem · 5 comments

kerem commented

2026-03-13 15:46:47 +03:00

Owner

Originally created by @emilazy on GitHub (Mar 19, 2020).
Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/216

Currently, if running an acme-dns server locally, any user can pollute the database with curl -X POST .../register, and if serving the API over the network then firewalling is the only access control available.

It's probably not a good idea for acme-dns to grow complex authentication mechanisms – anyone exposing it over the network with such needs should probably be running it behind a reverse proxy anyway – but it would be nice if e.g. HTTP Authorization: Basic with a simple shared secret was supported.

Originally created by @emilazy on GitHub (Mar 19, 2020). Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/216 Currently, if running an acme-dns server locally, any user can pollute the database with `curl -X POST .../register`, and if serving the API over the network then firewalling is the only access control available. It's probably not a good idea for acme-dns to grow complex authentication mechanisms – anyone exposing it over the network with such needs should probably be running it behind a reverse proxy anyway – but it would be nice if e.g. HTTP `Authorization: Basic` with a simple shared secret was supported.

kerem added the

feature request

enhancement

labels

2026-03-13 15:46:47 +03:00

kerem commented

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

Author

Owner

@webprofusion-chrisc commented on GitHub (Mar 20, 2020):

You'd probably need it to be done in a way that your acme client doesn't need modification, so the easiest thing may be a token in the base url e.g. https://your-acme-dns/6469b532-bf2b-4523-b533-ca8ae4de3f08/register - any other compatible ways?

You can also (as a workaround) just put your http api behind a free cloudflare worker and have that require an auth token as part of the request url (your worker would then validate it, strip out the extra token and forward the real request).

@webprofusion-chrisc commented on GitHub (Mar 20, 2020): You'd probably need it to be done in a way that your acme client doesn't need modification, so the easiest thing may be a token in the base url e.g. https://your-acme-dns/6469b532-bf2b-4523-b533-ca8ae4de3f08/register - any other compatible ways? You can also (as a workaround) just put your http api behind a free cloudflare worker and have that require an auth token as part of the request url (your worker would then validate it, strip out the extra token and forward the real request).

kerem commented

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

Author

Owner

@emilazy commented on GitHub (Mar 20, 2020):

That seems like a reasonable approach; in my integration registration is performed separately to the ACME client so compatibility isn't a big concern, but I agree it's a relevant consideration.

I think an authentication-aware reverse proxy is the best approach for deployment over the internet, but unfortunately it doesn't work very well for the local server case; you can use network namespaces and iptables to do it, but it's a lot of moving parts. Of course, local users being able to register useless subdomains is not much of an attack vector beyond the theoretical DoS potential, but unauthenticated local TCP servers are a bugbear of mine...

In an ideal world acme-dns could listen on a Unix socket and you could use the operating system's usual access control mechanisms. Unfortunately I doubt any ACME client at all supports HTTP over Unix domain sockets :)

@emilazy commented on GitHub (Mar 20, 2020): That seems like a reasonable approach; in my integration registration is performed separately to the ACME client so compatibility isn't a big concern, but I agree it's a relevant consideration. I think an authentication-aware reverse proxy is the best approach for deployment over the internet, but unfortunately it doesn't work very well for the local server case; you can use network namespaces and iptables to do it, but it's a lot of moving parts. Of course, local users being able to register useless subdomains is not much of an attack vector beyond the theoretical DoS potential, but unauthenticated local TCP servers are a bugbear of mine... In an ideal world acme-dns could listen on a Unix socket and you could use the operating system's usual access control mechanisms. Unfortunately I doubt any ACME client at all supports HTTP over Unix domain sockets :)

kerem commented

2026-03-13 15:47:08 +03:00

Author

Owner

@jvanasco commented on GitHub (Jun 1, 2020):

I address this concern with another workaround, by toggling whether the /registration endpoint is active or not by adjusting the disable_registration config option.

This method has worked for me, because I only spin up acme-dns via scripts when renewing (or enrolling) domains. The same scripts adjust the iptables too.

I am +1 on there being some sort of access. I like the idea of using a generic token prefix, since that could be easier than HTTP Authorization for most of the clients I have seen – though this is a biased view. (The inverse can also be true and I have no idea what the capabilities are in the total ecosystem or the top 10% of clients.)

The iptables approach i've been using is described in #67

@jvanasco commented on GitHub (Jun 1, 2020): I address this concern with another workaround, by toggling whether the `/registration` endpoint is active or not by adjusting the `disable_registration` config option. This method has worked for me, because I only spin up acme-dns via scripts when renewing (or enrolling) domains. The same scripts adjust the iptables too. I am +1 on there being some sort of access. I like the idea of using a generic token prefix, since that could be easier than HTTP Authorization for most of the clients I have seen – though this is a biased view. (The inverse can also be true and I have no idea what the capabilities are in the total ecosystem or the top 10% of clients.) The iptables approach i've been using is described in #67

kerem commented

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

Author

Owner

@dereckson commented on GitHub (Sep 24, 2020):

A best practice could be to listen publicly to the port 53, but only bind the HTTP endpoint to a private IP accessible by all your servers.

To have a private network across all the servers, through what the ISP offers (vRack at OVH, RPN as Online, VPC at AWS, etc.), virtual cards when you manage your VMs on a hypervisor and at worst GRE tunnels when nothing else can work is a luxury very convenient to solve this kind of problems and avoid a lot of security issues.

@dereckson commented on GitHub (Sep 24, 2020): A best practice could be to listen publicly to the port 53, but only bind the HTTP endpoint to a private IP accessible by all your servers. To have a private network across all the servers, through what the ISP offers (vRack at OVH, RPN as Online, VPC at AWS, etc.), virtual cards when you manage your VMs on a hypervisor and at worst GRE tunnels when nothing else can work is a luxury very convenient to solve this kind of problems and avoid a lot of security issues.

kerem commented

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

Author

Owner

@candlerb commented on GitHub (Feb 21, 2022):

For me, I would simply like to have an "allowed_registration" set of IP blocks, comparable to "allowfrom" for DNS updates.

That is: I don't want to disable registration entirely. But I do want to be able to do register domains on a local trusted host, and then push out the username/password/subdomain to some remote host which is going to request the certificate.

@candlerb commented on GitHub (Feb 21, 2022): For me, I would simply like to have an "allowed_registration" set of IP blocks, comparable to "allowfrom" for DNS updates. That is: I don't want to disable registration entirely. But I do want to be able to do register domains on a local trusted host, and then push out the username/password/subdomain to some remote host which is going to request the certificate.

kerem referenced this issue

2026-03-13 16:16:02 +03:00

[PR #101] [MERGED] Better error messages for missing DB config values #296