Let's Encrypt auto-renewal — how Nodetonet keeps your certs alive

Let's Encrypt certificates expire after 90 days. That window is short enough that any manual renewal process is a quarterly outage waiting to happen — and on a platform that routes traffic through multiple HTTP tunnels, mobile proxies and VPN endpoints, an expired cert means every connection drops at once. So Nodetonet runs a fully automated renewal pipeline with retries, exponential backoff and a clear escalation path when something genuinely breaks. This post is the complete picture of what that pipeline does, what triggers an alert, and what you can do if a domain goes red.

TL;DR: Certs renew automatically 30 days before expiry via DNS-01 challenge. If Let's Encrypt is rate-limiting or unreachable, the queue retries with backoff for up to 27 days. If a cert reaches 7 days to expiry without renewing, you get an email and the panel shows the exact ACME error.

Why 90-day certificates? Why automate?

Let's Encrypt chose a 90-day lifetime deliberately: it limits the damage window if a private key is ever compromised, and it forces automation because no team reliably remembers a quarterly to-do. Nodetonet issues wildcard certificates that cover every subdomain you point at the platform, so one lapsed renewal would break your tunnel URLs, your proxy endpoints and any white-label domain you have under management.

Automation removes the human dependency entirely. The renewal job runs as the platform's own identity — not yours — so there are no credentials to rotate, no personal access tokens to expire, and nothing to install on your own machines. All you need is to keep your domain's NS records pointed at our nameservers, which is the same prerequisite as bringing your own domain in the first place.

The renewal trigger: 30 days before expiry

A scheduled job scans the certificate fleet every hour. For each cert in the database it checks the notAfter timestamp. The moment a cert is fewer than 30 days from expiry, the renewal queue picks it up on the next hourly pass.

Thirty days is slightly later than Let's Encrypt's own recommended 60-day trigger, and that is intentional. Renewal traffic consumes rate-limit budget shared across the platform, and certificates that renew at 60 days leave a shorter absolute buffer if something goes wrong. Thirty days still gives four full weeks of retry headroom before any user-visible breakage. For new domains — added just before expiry, for instance — the same logic applies: any cert with fewer than 30 days left enters the queue immediately.

What a renewal actually does

Structurally, a renewal is identical to first issuance. The pipeline:

1. Generates a new private key — the old key is never reused, because reuse would defeat the rotation benefit of a 90-day cert.
2. Sends a DNS-01 challenge request to Let's Encrypt, which responds with a token that must appear as a _acme-challenge TXT record under your domain. Because Nodetonet runs the authoritative nameserver for your domain, it writes that record automatically — no action needed on your end.
3. Lets DNS propagate (a few seconds on our authoritative cluster), then notifies Let's Encrypt to validate.
4. Receives the signed certificate chain and deploys it to every edge node in the data plane.

The hot-swap is seamless: TLS sessions in flight continue on the old cert until they close naturally; new connections pick up the fresh one immediately. The total end-to-end time from trigger to live cert is typically under two minutes, invisible to any client.

Rate-limit handling: exponential backoff

Let's Encrypt enforces rate limits — most importantly, a cap on certificate issuances per domain per week. If the platform hits that cap, or if Let's Encrypt returns any transient error, the queue does not hammer it. Instead it backs off exponentially:

That schedule means a domain queued 30 days before expiry has roughly 27 daily retries in the worst case before it becomes critical. Even a week-long Let's Encrypt outage — which has never happened — would leave the cert valid through the full outage and well beyond.

The most common cause of rate-limit hits is bulk re-issuance: if many domains on the same root have certs expiring around the same time, the hourly job staggers them automatically by priority (nearest-to-expiry first). You do not need to do anything; the queue self-throttles.

The 7-day alert: when you hear from us

If after repeated attempts the cert reaches 7 days to expiry without a successful renewal, the platform escalates:

• The account owner (and any team member with billing or domain permissions) receives an email listing: the domain, the failure reason, the exact ACME error code and the time of the next scheduled retry.
• The domain row on /domains turns red and shows the last ACME error inline — usually something like urn:ietf:params:acme:error:rateLimited or urn:ietf:params:acme:error:dns with the full server message attached.

At this point your cert is still valid for seven days. You have time to diagnose and act rather than fighting a live outage.

The "Renew now" button and when to use it

The domain detail page exposes a Renew now button. It does one thing: it places the domain at the front of the renewal queue and bypasses the backoff timer. It does not bypass Let's Encrypt itself — so clicking it repeatedly can exhaust Let's Encrypt's per-domain rate limit faster, and the panel will tell you if that happens and lock the button for an hour.

Use it when you have a specific reason to believe the previous failure was a one-off: a transient DNS propagation lag, a brief ACME server error that is now resolved, or a NS record you just corrected. If the renewal queue is already retrying on a sensible schedule, there is no benefit to clicking Renew now — you just advance the next scheduled attempt.

Reading the SSL events log

Every renewal attempt — successful or not — is written to the SSL Events tab under the domain's detail page on /domains. Each entry shows:

• Timestamp of the attempt
• Outcome (success / failure / rate-limited)
• For successes: the new certificate's serial number and fingerprint
• For failures: the verbatim ACME error JSON, including any sub-problem messages that point to the specific DNS or validation failure

Logs are retained for 12 months. If you are troubleshooting an intermittent renewal issue, the events log gives you the exact sequence of attempts and errors without needing to open a support ticket. If you do need help, see getting help: the support flow.

Common root causes for renewal failures

• NS records moved away from our nameservers. If you updated your registrar's NS records to point elsewhere, the DNS-01 challenge TXT record we write will be invisible to Let's Encrypt. The ACME error will say dns or unknownHost. Fix: restore the NS delegation back to us. See authoritative DNS with our nameservers.
• Domain deleted from the panel but still in DNS. If a domain is removed from /domains while DNS still delegates to us, no cert exists to renew. Re-add the domain to restart the issuance flow.
• Platform-wide Let's Encrypt rate limit. Rare, but possible during large bursts of new domain additions. The queue handles this automatically; check the Let's Encrypt status page if you see rateLimited errors persisting beyond 24 hours.

For anything not on that list, the SSL Events log and the email alert both include the raw ACME error. That error code is documented at the Let's Encrypt errors reference and usually points directly at the fix.

What about certificates for proxies and tunnels?

SSL matters beyond just web pages. If you use Nodetonet's HTTP tunnels to expose a local service — or serve a white-label reseller domain — the certificate covering that subdomain follows the same auto-renewal pipeline. The same 30-day trigger, same backoff, same escalation. Your tunnel clients never notice a renewal because the hot-swap happens at the edge layer. For proxy traffic over HTTPS, see also HTTPS proxies and SNI routing.

What's next

• How wildcard SSL is issued — the first-issuance flow this post builds on.
• Bringing your own domain — the prerequisite for any of this to apply.
• Authoritative DNS with our nameservers — why we can answer DNS-01 challenges for you.
• Getting help: the support flow — if a renewal fails and the panel error isn't enough.
• HTTPS proxies and SNI routing — how TLS works at the proxy layer.