Acme-dns on Nethserver (now with RPM-y goodness!)

That got me to the point of knowing that hyphens weren’t legal in Perl variable names, but not to the point of knowing what to do about it–at least yet. Probably would have found something eventually, but you beat me to it.

I still think this is something Neth should consider providing themselves, perhaps as a subscription benefit–it would avoid the issue of access to port 80, as well as enable wildcard certificates, about as simply as possible for the users. The only thing the users would need to do is set up the CNAME records with their DNS host, once for each (sub)domain. The only thing that would need to be packaged with Neth itself is the hook script.

1 Like

Running into another issue, and I think this is due to how my config database keys are set up. In short, when installing software (including updates) through the software center, I get a red error message at the top of the screen indicating a problem with acme-dns. The problem appears to only be cosmetic–the software installs and runs without issues–but “big red warning banner” is a significant cosmetic issue. Looking in the log, I see

Jul  4 07:06:31 neth esmith::event[21173]: Failed to start acme-dns-api.service: Unit not found.

I use two config database keys, acme-dns and acme-dns-api. The main reason I do this is because the firewall settings will (or at least can) be different between the two–acme-dns itself must be accessible on the red interface (it must answer DNS queries from the outside world), while the API doesn’t need to be. However, there’s only one systemd service, and that’s acme-dns. Here’s how those keys are configured by default:

[root@neth ~]# config show acme-dns
[root@neth ~]# config show acme-dns-api

(OK, mostly by default–the fullchain, key, and UseTLS enabled aren’t there by default). How do I need to change this to avoid these errors?

You may try to change the acme-dns-api to a network service instead of a service:

I’d thought about that, but had somehow gotten the idea that the fw_ keys were only appropriate when all you were doing was setting the firewall (the fw_ prefix probably helped me reach that conclusion). If that’s not the case, that sounds like the easy answer.

The fw_ prefix is not mandatory, it’s just there to have an optical difference between NS controlled services and “firewall only” services.

I tested the acme-dns module and it works. :+1: I followed the instructions from the wiki.

Again I had to use another domain than my servers domain name so I edited /etc/e-smith/templates/etc/acme-dns/config.cfg/10general and did config setprop acme-dns Domain

my $dmn = ${'acme-dns'}{'Domain'} || $DomainName;

my $domain = "acme.".$dmn;
my $nsname = "ns1.acme.".$dmn;
my $nsadmin = "admin.".$dmn;
my $domaindot = "acme.".$dmn.".";
my $nsnamedot = "ns1.acme.".$dmn.".";
my $ns2namedot = "ns2.acme.".$dmn.".";

HTTP worked without an error, I changed to HTTPS and after executing following command the cert is renewed but I got an error (I added the -v switch to get more output).

certbot certonly --manual --manual-auth-hook /etc/letsencrypt/ --preferred-challenges dns --debug-challenges --post-hook "/sbin/e-smith/signal-event certificate-update" -d -v


Hook command "/etc/letsencrypt/" returned error code 1
Error output from
Traceback (most recent call last):
  File "/etc/letsencrypt/", line 154, in <module>
    client.update_txt_record(account, VALIDATION_TOKEN)
  File "/etc/letsencrypt/", line 65, in update_txt_record
  File "/usr/lib/python2.7/site-packages/requests/", line 108, in post
    return request('post', url, data=data, json=json, **kwargs)
  File "/usr/lib/python2.7/site-packages/requests/", line 50, in request
    response = session.request(method=method, url=url, **kwargs)
  File "/usr/lib/python2.7/site-packages/requests/", line 464, in req                                                                                                                                                                                               uest
    resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python2.7/site-packages/requests/", line 576, in sen                                                                                                                                                                                               d
    r = adapter.send(request, **kwargs)
  File "/usr/lib/python2.7/site-packages/requests/", line 431, in sen                                                                                                                                                                                               d
    raise SSLError(e, request=request)
requests.exceptions.SSLError: [SSL: UNKNOWN_PROTOCOL] unknown protocol (_ssl.c:5                                                                                                                                                                                               79)

It worked so maybe the error could be ignored?


…and in this case that’s completely fine; you can use any domain you want for this as long as you can control its DNS records. That seems like a worthwhile patch; I’ll try to incorporate that in the nethserver-acme-dns RPM.

Edit: Updated, should be in the repo in a few minutes.

This I haven’t seen before. For now (since it did work for you), I’d say keep an eye on it and see if it recurs.


Maybe I was too impatient but:

Package nethserver-acme-dns-0.0.1-7.ns7.noarch.rpm is not signed

Oops. Should be fixed now.

1 Like

Thanks. Working as expected! :clap:

hello @danb35 after postponing deploying acme dns for ages, i finally got around to deploying this fantastic tool.

I guess at the time i was not expereinced enough to understand it.

Now after deploying and testing, everything works great, but when i run this final command
curl -s -X POST | python -m json.tool
i get this error

[root@monit ~]# curl -s -X POST | python -m json.tool
No JSON object could be decoded

what could i be doing wrong, or where does the error come from

when running
curl -X POST | python -m json.tool

the error i get is

[root@monit ~]# curl -X POST |python -m json.tool
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (6) Could not resolve host:; Unknown error
No JSON object could be decoded
[root@monit ~]# curl -X POST | python -m json.tool
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (6) Could not resolve host:; Unknown error
No JSON object could be decoded

I assume you’re using your actual domain rather than What do you get if you don’t pipe the output to python? IOW, what’s the output of curl -s -X POST

no error

EDIT: i had used get.

there is an error:

curl: (6) Could not resolve host:; Unknown error

That doesn’t answer the question.

Edit: and after I wrote this, now there is. You need to fix your DNS records.

acme.domain needs the NS record; ns1.acme.domain needs an A record. Per the wiki:

the output is
curl: (6) Could not resolve host:; Unknown error

if i may understand. needs to only be NS, no cmane no A recrods

ie. ns pointing to and

let me sleep on it, maybe tomorrow it would resolve 100%

so today i run the command
curl -s -X POST

and there was no output. does it mean its fine now.

adding -v gives could not resolve erro

No, you should see output. It should look like this:

 dan@Dan-Hack-Mini î‚° ~ î‚° curl -s -X POST

Your problem seems to be that your acme-dns server isn’t visible to most of the world, which sounds like a firewall issue.

now thats a firewall issue in Nethserver, that i have no idea to resolve

I don’t know if the firewall issue would be in Nethserver or upstream, but it certainly looks like there’s one there. When I try a ping from several locations (using Ping Test - Simultaneously Ping From 10 Global Locations | KeyCDN Tools), I’m seeing similar results, in that there’s no (or limited) response from most areas. See also for a test from more locations; from there, out of 13 locations tested, only one completed with 0% packet loss. All 12 of the others had at least 66% loss, and most had 100%.