ACME Provider Update - 0.1.22

jimp

After the recent update to acme.sh, backend support for a number of new providers was there, but there was no GUI code to configure them.

I've gone through and added the missing providers, 18 new providers in total.

Given that I don't have accounts with any of them, I can't give them a proper test, but the code is consistent with the others that do work, so I do not expect much trouble. If you try one and it doesn't work, there may not be much to do but disable it for the moment and see if it gets fixed upstream.

The new providers are:

Alwaysdata
ClouDNS
cyon.ch
DigitalOcean
DNSimple
Domain-Offensive / Resellerinterface / Domainrobot
DuckDNS
Dyn.com
Dynu
FreeDNS
Gandi LiveDNS
Infoblox
Knot
Linode
name.com
NS1 (nsone.net)
vscale.io
Yandex

I also alphabetized the list, some had been added out of order, and I moved NSupdate/RFC2136 near the top because it isn't technically a DNS Provider like the others. That is only a cosmetic change, existing settings require no changes.

Reply here with reports of success or failure for the new providers, thanks!

pahrohfit

Not sure when it broken (within the last 3-4 months based upon my expiration) … but for nsupdate/rfc2136 based, you are creating an invalidly formatted key file:

[Wed Nov 1 18:22:29 EDT 2017] Found domain api file: /usr/local/pkg/acme/dnsapi/dns_nsupdate.sh
[Wed Nov 1 18:22:29 EDT 2017] adding _acme-challenge.mydomain.com. 60 in txt "some-acme-nonce"
01-Nov-2017 18:22:29.933 /tmp/acme/mydomain.com/mydomain.com/nsupdate_acme-challenge.mydomain.com.key:1: unknown option '_acme-challenge.mydomain.com...'
01-Nov-2017 18:22:29.934 /tmp/acme/mydomain.com/mydomain.com/nsupdate_acme-challenge.mydomain.com.key:2: unexpected token near end of file
could not read key from /tmp/acme/mydomain.com/mydomain.com/nsupdate_acme-challenge.mydomain.com.{private,key}: unexpected token
update failed: REFUSED
[Wed Nov 1 18:22:30 EDT 2017] error updating domain

The malformed file looks like:

_acme-challenge.mydomain.com IN KEY 257 3 165 secret-key-data

The file should look like:

key _acme-challenge.mydomain.com. {
        algorithm HMAC-SHA512;
        secret "secret-key-data";
};

jimp

Hmm, it worked last time I tried it but I also get that error now. I'll look into it.

kejianshi

This looks like something that can save a lot of people a lot of money. I'll be glad when its a bit more firmed up. I bet the certificate mafias out there are crying big alligator tears right now. Surprised they haven't tried to kill it.

jimp

@pahrohfit:

Not sure when it broken (within the last 3-4 months based upon my expiration) … but for nsupdate/rfc2136 based, you are creating an invalidly formatted key file:

Actually the key format is correct, both ways should work. And indeed it does still work on most of my systems here. I tried a 2.3.5 box, a 2.4.1 box, and other 2.4.2 snapshots all on the newest ACME code and only one of them failed in this way. It's still not clear exactly what that one failed either. It worked fine with one other cert on the same exact box also using RFC2136. All of the files appear to be correctly formatted so far.

I'm still looking into it, but it does not appear to be a widespread issue (only one failure out of about 15 configurations here thus far)

jimp

@jimp:

@pahrohfit:

Not sure when it broken (within the last 3-4 months based upon my expiration) … but for nsupdate/rfc2136 based, you are creating an invalidly formatted key file:

Actually the key format is correct, both ways should work. And indeed it does still work on most of my systems here. I tried a 2.3.5 box, a 2.4.1 box, and other 2.4.2 snapshots all on the newest ACME code and only one of them failed in this way. It's still not clear exactly what that one failed either. It worked fine with one other cert on the same exact box also using RFC2136. All of the files appear to be correctly formatted so far.

I'm still looking into it, but it does not appear to be a widespread issue (only one failure out of about 15 configurations here thus far)

OK, I found the problem. It's a configuration issue. That was a test entry which did not have a proper key type or key algorithm set, I forgot I broke that one deliberately before when checking the formats.

So it's not a package problem that I can see. Make sure it's set correctly (e.g. set to Host Key, and set to the correct matching algo as the source key)

Unless there is something special about HMAC-SHA512 that requires the different key file format, that I could work around. I don't have any using that algo here.

sbreit

@pahrohfit:

Not sure when it broken (within the last 3-4 months based upon my expiration) … but for nsupdate/rfc2136 based, you are creating an invalidly formatted key file:

[Wed Nov 1 18:22:29 EDT 2017] Found domain api file: /usr/local/pkg/acme/dnsapi/dns_nsupdate.sh
[Wed Nov 1 18:22:29 EDT 2017] adding _acme-challenge.mydomain.com. 60 in txt "some-acme-nonce"
01-Nov-2017 18:22:29.933 /tmp/acme/mydomain.com/mydomain.com/nsupdate_acme-challenge.mydomain.com.key:1: unknown option '_acme-challenge.mydomain.com...'
01-Nov-2017 18:22:29.934 /tmp/acme/mydomain.com/mydomain.com/nsupdate_acme-challenge.mydomain.com.key:2: unexpected token near end of file
could not read key from /tmp/acme/mydomain.com/mydomain.com/nsupdate_acme-challenge.mydomain.com.{private,key}: unexpected token
update failed: REFUSED
[Wed Nov 1 18:22:30 EDT 2017] error updating domain

I have the same issue here, also with different key formats (HMAC-SHA256). I too think that the file is not formatted correctly.

Using the key file as -k parameter to nsupdate will always fail:

nsupdate -k /tmp/acme/pfsense.domainname/pfsense.domainname/nsupdate_acme-challenge.pfsense.domainname.key -v nsupdate.txt
11-Dec-2017 22:14:52.501 /tmp/acme/pfsense.domainname/pfsense.domainname/nsupdate_acme-challenge.pfsense.domainname.key:1: unknown option '_acme-challenge.pfsense.domain...'
11-Dec-2017 22:14:52.502 /tmp/acme/pfsense.domainname/pfsense.domainname/nsupdate_acme-challenge.pfsense.domainname.key:2: unexpected token near end of file
could not read key from /tmp/acme/pfsense.domainname/pfsense.domainname/nsupdate_acme-challenge.pfsense.domainname.{private,key}: unexpected token

However, passing the key differently to nsupdate works as expected:

nsupdate -y 'HMAC-SHA256:_acme-challenge.pfsense.domain:nQ02d88024393209140eIQo37QCM=' -v nsupdate.txt

Investigating further I found out that the .key file format seemed to be wrong. It was

_acme-challenge.pfsense.domain IN KEY 513 3 163 nQ02d88024393209140eIQo37QCM=
```when it should have been```
_acme-challenge.pfsense.domain. IN KEY 513 3 163 nQ02d88024393209140eIQo37QCM=
```instead. Note the missing . after the domain name.

I reckon that's the issue here. @jimp could you look into this?

jimp

It does appear as though the '.' should be there, but that doesn't cause any of mine to fail here. I have quite a few using nsupdate and it works perfectly. Though I think they are almost all HMAC_MD5.

Does adding the '.' to the file let it work? You can add it at line 195 of /usr/local/pkg/acme/acme_sh.inc

Change this:

				file_put_contents("{$nsupdatefileprefix}_acme-challenge.{$nsupdatedomain}.key", "_acme-challenge.{$nsupdatedomain} IN KEY {$flags} {$proto} {$key_algo} {$nsupdatekey}\n");

to this:

				file_put_contents("{$nsupdatefileprefix}_acme-challenge.{$nsupdatedomain}.key", "_acme-challenge.{$nsupdatedomain}. IN KEY {$flags} {$proto} {$key_algo} {$nsupdatekey}\n");

It seems to work either way for me, but if that lets it work for you then I'll go ahead and commit it.

sbreit

@jimp:

Does adding the '.' to the file let it work? You can add it at line 195 of /usr/local/pkg/acme/acme_sh.inc

Unfortunately not. The error messages from nsupdate complaining about the *.key file weren't exactly helpful either…

Anyhow, I've figured out what the issue was. Comparing the key pair generated on my DNS server and in pfSense I've noticed a few lines missing. Adding

Bits: AAA=

in line 200 finally did the trick for me. Tadaaa:

[Tue Dec 12 18:48:06 CET 2017] Cert success.

I have no idea what the "Bits" line does unfortunately, but in the end it seems that this was what was missing.

I generated a HMAC-SHA512 key pair for comparison. It has the same "Bits" line; the request worked as well.

Cheers

jimp

Interesting. Every example I can find of the Bits: line is AAA= but I'd like to find some source for how that's calculated before I go hardcoding it or making a separate field.

kingchong

Are there any plans on adding Google Domains to the list?

jimp

@kingchong:

Are there any plans on adding Google Domains to the list?

It must be supported by the acme.sh project first, but it doesn't look like they're into the idea: https://github.com/Neilpang/acme.sh/issues/180

kingchong

Ahh, bummer. Thanks!