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

    ACME TXT entry and Plesk XML API?

    Scheduled Pinned Locked Moved ACME
    2 Posts 2 Posters 913 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.
    • S
      stilez
      last edited by stilez

      I'll be using certificates on Let's Encrypt, and I'm not sure if the current ACME package does what I need. (If not, I'd hope to discuss the work involved in enhancing it). I'd like to handle ACME by directly adding TXT records.

      My current host + domain manager uses Plesk. The Plesk XML API is in use, and I've played around enough to be sure I can use their XML protocol to add the necessary TXT records to my domain programmatically.

      But I can't figure out whether the nsupdate method shown in the pfSense docs as 'nsupdate validation' is the same as, or can work with, the XML API method shown in the Plesk XML API docs.

      As Plesk is very popular, can someone shed light whether the ACME package can work using nsupdate via the Plesk API (if so how), or does it need enhancing to directly change/create TXT entries in DNS?

      Alternatively, given that my host uses Plesk, what programmatic method would ACME/nsupdate usually be expecting to use, to add its TXT records?

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        That would be a matter of configuring plesk to accept updates via the nsupdate method. Using their API is going to be completely different unless it implements that somehow.

        nsupdate is an implementation of a specific protocol, RFC2136.

        This is a guide on what is required to get a bind server configured to accept updates:

        https://www.netgate.com/docs/pfsense/dns/rfc2136-dynamic-dns.html

        An alternate strategy might be to set up a bind server like in that link that serves as the master of a dynamic zone with the plesk as the slave but that would preclude managing the zone in plesk which is likely undesirable.

        The heavy lifting for this probably needs to be done on the plesk. Instead of accepting updates via their proprietary API they should have a standard method such as RFC2136.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

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