1. Home
  2. pfSense Packages
  3. ACME
  4. ACME Provider Update - 0.1.22

ACME Provider Update - 0.1.22

  • jimp
    Rebel Alliance Developer Netgate

    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!

    0
  • P

    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";
};
    0
  • jimp
    Rebel Alliance Developer Netgate

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

    0
  • K

    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.

    0
  • jimp
    Rebel Alliance Developer Netgate

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

    0
  • jimp
    Rebel Alliance Developer Netgate

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

    0
  • S

    @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?
    0
  • jimp
    Rebel Alliance Developer Netgate

    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.

    0
  • S

    @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

    0
  • jimp
    Rebel Alliance Developer Netgate

    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.

    0
  • K

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

    0
  • jimp
    Rebel Alliance Developer Netgate

    @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

    0
  • K

    Ahh, bummer. Thanks!

    0
Log in to reply
 

Products

Services

Support

News

Resources

Company

Our Mission

We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

Subscribe to our Newsletter

Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

© 2020 Rubicon Communications, LLC | Privacy Policy