DirectAdmin 1.706, released in July 2026, replaced the long-serving letsencrypt.sh certificate flow with a native ACME client built into the panel. Domains that opt in are issued and renewed automatically by a task that runs every 24 hours, with a client based on lego v5 from 1.707 onwards. The old flow still works for domains that have not been migrated, but every release since has added features only to the new system, and 1.711 fixed a local privilege-escalation issue in it, so any server still on the old flow should be on 1.711 or later and moving.
Applies to DirectAdmin 1.706 and later; migration task from 1.708; 1.711 or later recommended
Table of Contents
Short answer: Update to 1.711 or later, then run the TLS migration task from Admin Level → Server TLS Certificate (or queue it through task.queue) so every domain with a letsencrypt.sh certificate is adopted by the native ACME system and renewed at 65 percent of its lifetime. Afterwards review the acme_* keys with da config-get, confirm manually installed certificates landed on the allowlist, and replace any old letsencrypt.sh hooks with the post-renew hooks in scripts/custom/.
What actually changed
Under the old system a cron job called letsencrypt.sh for each domain, wrote certificates into the user’s domains/<domain>/ssl directory and rewrote the web-server configuration. Renewals were driven by a fixed 60-day schedule and failures produced an email to the user with a shell-script error.
The new system tracks each domain’s certificate as a first-class object. It issues, renews at 65 percent of the certificate’s lifetime (a 1.711 change that aligns with the shorter certificate lifetimes the CA/Browser Forum has scheduled), records every attempt in the Provisioning history page added in 1.710, and applies the certificate to Apache or LiteSpeed, Exim, Dovecot and the panel itself. Manually uploaded certificates are kept on an allowlist so the automation never overwrites them. From 1.707 a ZeroSSL account is created automatically as a second provider, and default_acme_profile selects the certificate profile.
The configuration keys changed too. 1.703 removed the letsencrypt_* keys from directadmin.conf in favour of acme_*. The ones that matter operationally:
da config-get acme_disable_after_failures
da config-get acme_dns_names_per_cert
da config-get acme_use_only_system_resolver
da config-get default_acme_profileacme_disable_after_failures stops retrying a domain after repeated failures so that a dead domain does not consume rate-limit budget forever. acme_dns_names_per_cert (default 25, added in 1.708) caps the SANs per certificate. acme_use_only_system_resolver (1.709) forces DNS checks through the server’s resolver rather than authoritative lookups, which helps behind split-horizon DNS.
Only the Evolution skin exposes the new interface. The Enhanced skin is maintenance-only and shows the legacy pages.
Running the migration
1.708 added a migration task that walks every domain with a certificate issued by the old flow, registers it with the new system and marks it for renewal on the new schedule. It is triggered from Admin Level → Server TLS Certificate in Evolution, or queued directly:
echo "action=tls&value=migrate" >> /usr/local/directadmin/data/task.queueCheck the changelog for your build if the task name differs, because the exact queue syntax was documented with the 1.708 release and may have been refined since. Watch the log while it runs:
tail -f /var/log/directadmin/system.log
tail -f /var/log/directadmin/errortaskq.logThe migration does not reissue certificates immediately; it adopts the existing ones and schedules renewal by the new rule. That means a domain whose old certificate has ten days left is renewed on the next daily pass, and a domain with fifty days left waits. No customer-visible change happens on the day of migration unless a certificate was already expired.
Domains with a manually installed certificate are detected and placed on the manual allowlist. Verify this for any domain where a customer paid for an EV or OV certificate, because if the detection misses one the automation will replace the paid certificate with an ACME one at the next renewal.
Per-domain opt-in and existing customisations
New domains are opted into automatic TLS by default from 1.706. Existing domains that never had a certificate are not, and users enable it from User Level → SSL Certificates. Administrators can enable it in bulk by setting ssl=ON in each domain’s domains/<domain>.conf and issuing a rewrite, or by scripting the /api/ endpoints.
If you had a custom letsencrypt.sh hook, a custom/ssl/ script or a post-issue hook that pushed certificates to another server, none of it runs under the new system. The equivalent is the post-renew hooks in /usr/local/directadmin/scripts/custom/; check which hook names the current build calls before relying on them, since this area changed between 1.706 and 1.710.
Common pitfall: the hostname certificate
The server hostname’s certificate is handled separately and is the one most likely to stall. From 1.710 the panel syncs manually set server certificates to Exim, Dovecot and the web server, but only if the hostname resolves to the server and port 80 reaches it. A hostname behind a proxy or with an old A record fails the HTTP challenge and the Provisioning history shows it. Fix DNS, then request the certificate again from Admin Level → Server TLS Certificate.
Verify
After migration, list the domains and check the state of a few:
grep -l 'ssl=ON' /usr/local/directadmin/data/users/*/domains/*.conf | wc -l
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -issuerOpen Admin Level → Provisioning history and confirm that the most recent entries are successes. Then run our SSL expiry check across all hosted domains weekly for the first month; it catches the domains that were silently disabled by acme_disable_after_failures before their certificates run out. If a domain keeps failing, the troubleshooting steps in Certificate not renewing on DirectAdmin start from the history page.
DirectAdmin ACME TLS migration at a glance
Official documentation: Let’s Encrypt documentation, DirectAdmin documentation, Linux man pages.
Related guides: KernelCare on cPanel and DirectAdmin servers: setup, verification and rollback · Enabling ModSecurity with OWASP CRS or Comodo rules on DirectAdmin and managing per-domain exclusions · Installing and tuning CSF/LFD on DirectAdmin (the DirectAdmin fork, post-1.689 defaults).
Frequently asked questions
Does the ACME migration also apply to wildcard certificates issued with a DNS challenge?
Yes, provided the DNS challenge is configured in the new system; the migration adopts the existing wildcard certificate, but renewal only succeeds once the DNS provider credentials or the DirectAdmin-hosted zone update path are set up for the native client.
How long does the TLS migration task take?
A few minutes for a few hundred domains, because it registers existing certificates rather than reissuing them; the actual renewals then happen over the following weeks on the normal daily pass as each certificate reaches its renewal point.
Can I undo this?
Not cleanly. The old letsencrypt.sh flow is no longer maintained and its letsencrypt_* keys were removed in 1.703, so the practical fallback for a problem domain is to install a certificate manually, which places it on the allowlist and stops the automation touching it.
Maintenance record
This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.
- Maintained by
- srvScripts editorial team
- Supported versions
- DirectAdmin 1.706 and later; migration task from 1.708; 1.711 or later recommended
- Last full review
- Next review