Bandwith and CPU resources aside, there's no real problem with it.
If you wish to add authentication in front of acme-dns, you could for example use a reverse Nginx proxy and set up basic authentication in it. That will require slight modifications to the hook script however.
Firewall rules are probably the best way to restrict the API access, if you control a somewhat static set of potential clients.
That is a good idea, something like this should work (it is just an example...):
Create the htpasswd file:
htpasswd -c /etc/nginx/acme-dns.htpasswd username
Create the nginx conf file:
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name auth.domain.tld;
ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
ssl_protocols TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
ssl_prefer_server_ciphers on;
location /register {
proxy_pass http://localhost:8080/register;
proxy_buffering off;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
auth_basic "acme-dns restricted";
auth_basic_user_file /etc/nginx/acme-dns.htpasswd;
}
location /update {
proxy_pass http://localhost:8080/update;
proxy_buffering off;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
and using for example curl to register without username and password:
$ curl -X POST https://auth.domain.tld/register
<html>
<head><title>401 Authorization Required</title></head>
<body bgcolor="white">
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx/1.12.2</center>
</body>
</html>
and using the right user and password:
$ curl -u username:password -X POST https://auth.domain.tld/register
{"username":"120df7c5-2gb8-4ef3-875e-fec18ffbf714","password":"aMOPy2PYIrzLlfnOf7CTGfVBIrlyP_yE8mpxTdb6","fulldomain":"e8fe56ea-2157-4f39-a780-3800bc912c8c.auth.domain.tld","subdomain":"e8fe56ea-2157-4f39-a780-3800bc912c8c","allowfrom":[]}
Gents,
I have been following this thread since I got a reply in another thread from danb35.
I’ve been able to manually acquire my wildcard ssl cert thanks to everyone’s help so far but I need to get this working using acme-dns as there are many wildcard ssl certs to get and it’s not practical to manually get and update the txt records every 60 days for all the domains.
BUT… What I can’t grasp still for this automatic acme-dns method is where in the procedure does LE let’s me know what the txt record it is looking for so I can post the credentials and txt to my acme-dns server.
I must be missing something fundamentally simple and it’s in front of my nose and I can’t see it.
Do I manually get the txt record necessary and use that to update the acme-dns instance BUT… that would defeat the automatic part of updating it.
Confused and Crossed eyed now.
Victor
The idea is that you also run a Let’s Encrypt client application like Certbot. The Let’s Encrypt client receives the details of the TXT record that the CA wants to have created via the ACME protocol.
With Certbot, this can be used with something like
to then make the necessary updates in acme-dns. After all, acme-dns is not an alternative to a Let’s Encrypt client like Certbot; it’s a complement to the Let’s Encrypt client that exists in order to let it perform a DNS-01 challenge without having a separate DNS provider that supports API-based TXT record updates.