Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    DNS-NSupdate / RFC 2136 Acme 0.6.2

    Scheduled Pinned Locked Moved ACME
    2 Posts 1 Posters 484 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      michaelschefczyk
      last edited by

      Dear All,

      On Acme 0.6.2, I increasingly get problems when using DNS-NSupdate / RFC 2136 for wildcard domains. Webroot for single domains does work without issues.

      It seems that the verification does not take place between adding and removing the TXT challenge and/or AFTER successfully removing the TXT challenge, there is a line indicating a SERVFAIL line indicating that the TXT challenge could not be found (not surprising, I think). My impression is that setting DNS-Sleep shorter (like 30 seconds) or longer (like 240 seconds) does not solve the issue. Specifying the zone does not seem to make a difference either.

      My log looks like:

      domain.info
      Renewing certificate
      account: Accountname v2
      server: letsencrypt-production-2

      /usr/local/pkg/acme/acme.sh --issue -d '*.domain.info' --dns 'dns_nsupdate' --home '/tmp/acme/domain.info/' --accountconf '/tmp/acme/domain.info/accountconf.conf' --force --reloadCmd '/tmp/acme/domain.info/reloadcmd.sh' --dnssleep '30' --ocsp-must-staple --log-level 3 --log '/tmp/acme/domain.info/acme_issuecert.log'

      Array
      (
      [path] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/
      [PATH] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/
      [NSUPDATE_SERVER] => /tmp/acme/domain.info/.domain.infonsupdate
      [NSUPDATE_KEYNAME] => nsupdate
      [NSUPDATE_KEYALGO] => 165
      [NSUPDATE_KEY] => /tmp/acme/domain.info/
      .domain.infonsupdate
      [NSUPDATE_ZONE] =>
      )
      [Sat Sep 21 20:09:19 CEST 2019] Single domain='.domain.info'
      [Sat Sep 21 20:09:19 CEST 2019] Getting domain auth token for each domain
      [Sat Sep 21 20:09:23 CEST 2019] Getting webroot for domain='
      .domain.info'
      [Sat Sep 21 20:09:23 CEST 2019] Adding txt value: 2fDtg1nBfYGm-vYwJKW5Bd7qLXROxKTKzgNr39LoCeY for domain: _acme-challenge.domain.info
      [Sat Sep 21 20:09:23 CEST 2019] adding _acme-challenge.domain.info. 60 in txt "2fDtg1nBfYGm-vYwJKW5Bd7qLXROxKTKzgNr39LoCeY"
      [Sat Sep 21 20:09:23 CEST 2019] The txt record is added: Success.
      [Sat Sep 21 20:09:23 CEST 2019] Sleep 30 seconds for the txt records to take effect
      [Sat Sep 21 20:09:53 CEST 2019] Verifying: *.domain.info
      [Sat Sep 21 20:09:57 CEST 2019] Pending
      [Sat Sep 21 20:10:01 CEST 2019] Removing DNS records.
      [Sat Sep 21 20:10:01 CEST 2019] Removing txt: 2fDtg1nBfYGm-vYwJKW5Bd7qLXROxKTKzgNr39LoCeY for domain: _acme-challenge.domain.info
      [Sat Sep 21 20:10:01 CEST 2019] removing _acme-challenge.domain.info. txt
      [Sat Sep 21 20:10:01 CEST 2019] Removed: Success
      [Sat Sep 21 20:10:01 CEST 2019] *.domain.info:Verify error:DNS problem: SERVFAIL looking up TXT for _acme-challenge.domain.info
      [Sat Sep 21 20:10:01 CEST 2019] Please check log file for more details: /tmp/acme/domain.info/acme_issuecert.log

      I did also try running the command from the command line (without --force). That, however, did not reveal much either. Sometimes it said that the key was "unreadable" while a simple cat command did show the key. Sometimes I was rate limited, of course.

      Can someone point me to the right direction, please?

      Regards,

      Michael Schefczyk

      1 Reply Last reply Reply Quote 0
      • M
        michaelschefczyk
        last edited by

        Dear All,

        This is resolved. The cause was a DNS configuration error outside the scope of Acme - sorry. I have had difficulties setting up dnssec. In so doing, I did modify the SOA entry. As a consequence, my slave DNS servers did not track master DNS server changes. Hence, Acme verification had no chance to work.

        Regards,

        Michael Schefczyk

        1 Reply Last reply Reply Quote 0
        • First post
          Last post
        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.