Automatic TLS on *.dmzgate.com — how Let's Encrypt + GoDaddy DNS-01 works behind the scenes

When you create an HTTP tunnel in the panel, it already comes with https://your-tunnel.dmzgate.com serving a valid Let's Encrypt certificate. No browser warning, no self-signed, no certbot to run. Who did that?

This post is somewhat internal — for the infra-curious. Feel free to skip if you just want to use the product.

The problem

Let's Encrypt issues certificates via two challenges: HTTP-01 and DNS-01. HTTP-01 requires the server to respond at a specific URL on the domain — you can't automate it per dynamic subdomain (each tunnel is a different subdomain). DNS-01 needs a TXT record created in the DNS zone.

To issue a wildcard certificate (*.dmzgate.com), only DNS-01 works.

The solution

The dmzgate.com domain is hosted on GoDaddy DNS, which has an API. Each node (spo1, usa1, eur1, asi1) ships with automated hooks:

/usr/local/bin/godaddy-auth.sh    # creates the _acme-challenge TXT
/usr/local/bin/godaddy-cleanup.sh  # removes it after

When certbot renews (60 days before expiration), it calls the hook, GoDaddy gets a PUT on the API, the TXT appears, Let's Encrypt validates, fresh cert, hook cleans the TXT. All automated.

Why GoDaddy and not Cloudflare?

The superdmz.com domain itself uses Cloudflare DNS (with A records for the nodes). But dmzgate.com (customer subdomain root) lives on GoDaddy because it was registered with another registrar earlier — migrating would mean asking every customer to update their pointing. Not worth it.

Renewal

Each node renews independently via its own certbot.timer in systemd. The cert lasts 90 days; renewal kicks in at 60. Today (June 2026) the oldest cert in the fleet is 18 days old — all synchronized during the recent Linux/macOS parity deploy.