Short answer: When you rename a domain in DirectAdmin 1.712, the old certificate is carried over under the new name, and within about a minute DirectAdmin asks the ACME provider for a new certificate covering the new name and its www, mail, ftp, pop and smtp names. That only works if the new name already points at the server. If it does not, DirectAdmin silently skips the request and keeps serving the old domain’s certificate, so point DNS first, rename second, and run da taskq --run "action=rewrite&value=letsencrypt&domain=new.example.com" if the certificate does not appear.
A DirectAdmin domain rename (a rebrand, a typo at signup, a move from a temporary name to the real one) touches the web server, mail, FTP and DNS configs at once, and the TLS certificate is the part most likely to go wrong without anyone noticing. We renamed a test domain three times on a DirectAdmin 1.712 server, once to a name that did not resolve, and watched what the panel did.
Table of Contents
How to rename the domain
In the Evolution skin the option is called Rename Domain, under the user’s Domain Setup. The same action is available through the legacy API, which is what we used for the test:
curl -s -X POST "https://server.example.com:2222/CMD_CHANGE_DOMAIN?json=yes" \
-u "admin:LOGIN_KEY" \
--data "old_domain=old.example.com&new_domain=new.example.com"It returned Domain name has been successfully changed in under a second, and /var/log/directadmin/system.log recorded domain old.example.com swapped to new.example.com. Use a login key for API calls, not the admin password; on the server itself, da api-url creates a temporary one.
What DirectAdmin does in the first minute
The rename itself only renames files and queues work. Within the next minute the task queue (dataskq) runs these tasks, which we saw in /usr/local/directadmin/data/task.queue straight after the rename:
action=dovecot&value=reload
action=rewrite&domain=new.example.com&value=letsencrypt
action=rewrite&user=admin&value=httpd
action=named&value=reload
action=httpd&value=reload| Time after rename | What we saw on the new name |
|---|---|
| 0 seconds | The rename returned at once; the tasks above were waiting in the queue. |
| about 30 seconds | The rewrite … letsencrypt task started an ACME order for new.example.com, www, mail, ftp, pop and smtp. |
| about 60 seconds | The new certificate was issued (the ACME run took 30 seconds) and served on 443, 465 (SMTPS) and 993 (IMAPS). |
A second rename to another resolving name behaved the same way (new certificate served after about 70 seconds). So when the new name already resolves, expect roughly a minute in which the certificate may not match the name. Do it at a quiet time, not during a sale.
What carries over and what is left behind
- The old certificate is renamed, not replaced. The files under
/usr/local/directadmin/data/users/USER/domains/becomenew.example.com.cert,.keyand so on, but the certificate inside still lists the old names until the new one is issued. - Per-domain ACME settings move with the domain. Our test domain was set to a non-default provider (Let’s Encrypt staging), and the new name kept it:
GET /api/domain-tls/new.example.com/acme-configshowed the same provider and key type. - Domain pointers stay attached. An alias pointer created before the rename stayed on the renamed domain and kept its own, separate certificate. If the alias belongs to the old brand, remove it yourself.
- The old name stops being served. Requests for the old name on port 443 got the server’s self-signed certificate afterwards. The old certificate is not revoked; it simply expires.
- A stray file can stay behind. On our server a
old.example.com.dnsproviderfile was left in the domains folder. It did no harm, but it is worth knowing if you script against those files.
If the new name does not point at the server yet
This is the case that causes trouble. We renamed the domain to a name with no DNS record and waited:
- No ACME request was sent. DirectAdmin checks each name before asking the certificate authority, and every name failed that check.
- Nothing was recorded: no entry in Provisioning history, no failure counted towards
acme_disable_after_failures, no message to the admin. - The domain kept serving the old domain’s certificate for the new name, which every browser and mail client rejects as a name mismatch.
- The certificate API even reported
"missingDNSNames": []for the domain, so a monitor built on that field would see nothing wrong.
The dry run shows the real state. It is read-only and safe to run at any time:
curl -s -X POST -u "admin:LOGIN_KEY" \
"https://server.example.com:2222/api/domain-tls/new.example.com/provision-certs-dry-run"Names that fail the local check are listed under dnsNamesFailedChallenge, and the leftover certificate appears under certsObsolete. Once DNS points at the server, request the certificate yourself:
da taskq --run "action=rewrite&value=letsencrypt&domain=new.example.com"On our server this command finished in about 4 seconds and the new certificate was served immediately. We could not test how long DirectAdmin waits before it retries by itself once DNS is fixed, so do not rely on that; run the command. For failures that do reach the certificate authority, see DirectAdmin certificate not renewing.
A safe order for a DirectAdmin domain rename
- Before: lower the TTL of the new name’s records a day ahead, then create A (and AAAA, if the server has IPv6) records for new.example.com, www, mail, ftp, pop and smtp pointing at the server. If a CDN proxy sits in front, make sure it passes
/.well-known/acme-challenge/through on port 80. - Check:
dig +short new.example.comanddig +short mail.new.example.comfrom outside the server return the server’s IP. - Rename in Domain Setup.
- Verify after a minute:
echo | openssl s_client -connect new.example.com:443 -servername new.example.com 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName, and the same formail.new.example.comon port 993. If you still see the old names, run the dry run and theda taskqcommand above. - After: update mail clients that connect to
mail.old.example.com, the domain’s SPF, DKIM and DMARC records under the new name, and any external monitor. Mail and DNS are not renamed for you outside the server.
Each rename starts a new certificate order. Let’s Encrypt allows 50 new certificates per registered domain every 7 days, and DirectAdmin has its own cap, letsencrypt_max_requests_per_week (200 on our server). That only matters if you rename many subdomains of one domain in a short time.
How we tested
- Server: DirectAdmin 1.712 on AlmaLinux 9.8, Apache 2.4.69, Exim 4.100.1, Dovecot 2.4.5, lego 5.5.2, 19 October 2026.
- Certificates: Let’s Encrypt staging (to protect production rate limits), HTTP-01 challenge, ECDSA P-256 keys.
- Renames: a resolving name to another resolving name; a resolving name to a name with no DNS record; that name back to a resolving one. Each checked with the certificate API, the task queue, Provisioning history and
openssl s_clienton 443, 465 and 993. - Not tested: renames with DNS-01 (wildcard) certificates, renames on servers using nginx or LiteSpeed, and the automatic retry interval after DNS is fixed.
FAQ
Does DirectAdmin get a new certificate automatically after a domain rename?
Yes, if the new name already resolves to the server. On DirectAdmin 1.712 the new certificate was served about a minute after the rename. If the name does not resolve yet, no request is made and the old domain’s certificate stays in place.
Why does my renamed domain still show the old domain’s certificate?
Usually because the new name did not point at the server when you renamed it, so DirectAdmin skipped the request without logging it. Fix DNS, then run da taskq --run "action=rewrite&value=letsencrypt&domain=new.example.com".
Do email and FTP get the new certificate too?
Yes. The new certificate covered mail, ftp, pop and smtp names, and Exim (465) and Dovecot (993) served it without a manual restart. If they keep serving an old certificate after a normal renewal, see Exim or Dovecot still serving the old certificate.
Is the old domain’s certificate revoked?
No. It is no longer served and simply expires. Revoke it yourself only if the private key may have leaked.
At a glance
