DirectAdmin Wildcard Certificate: DNS Challenge Setup

A wildcard certificate secures every first-level subdomain of a domain with one certificate, which is what you want for a SaaS product that gives each customer a subdomain or for a site that creates subdomains dynamically. Certificate authorities only issue wildcards through the DNS-01 challenge, so the ACME client has to place a TXT record at _acme-challenge.example.com and remove it afterwards. DirectAdmin’s ACME system does this itself when it is authoritative for the zone, and since 1.708 it can also work with zones hosted elsewhere through a CNAME.

Short answer: If the DirectAdmin server is authoritative for the zone, tick the wildcard entry on the user’s SSL Certificates page and the ACME client writes the _acme-challenge TXT record itself and renews automatically. If the zone is hosted elsewhere, create a _acme-challenge.example.com CNAME pointing into a zone the server controls and request the wildcard the same way; the certificate covers the apex and every first-level subdomain.

What a wildcard covers on DirectAdmin

Since 1.708 a wildcard certificate requested from the panel covers the apex domain and every first-level subdomain: example.com, www.example.com, app.example.com, and so on. It does not cover a second level such as api.eu.example.com; that needs either a separate certificate or a second wildcard for *.eu.example.com. Each certificate is capped by acme_dns_names_per_cert (25 by default), which is rarely reached with a wildcard because the wildcard entry replaces dozens of individual names.

1.709 made wildcard issuance noticeably faster by shortening the DNS propagation wait, so a fresh wildcard normally lands within a couple of minutes.

Option one: DirectAdmin hosts the DNS

When the domain’s nameservers point at the DirectAdmin server (or a cluster of them, see Multi-server DNS clustering), nothing needs configuring. The ACME client writes the challenge record straight into the zone under /var/named/, reloads named, waits for the record to be visible and requests validation.

In the Evolution skin the user goes to User Level → SSL Certificates, chooses the automatic ACME option, and ticks the wildcard entry in the list of names. Save, and the Provisioning history under the same page (or Admin Level → Provisioning history for all domains) shows the request progress.

The one thing that breaks this is a DNS zone that does not match reality. If the domain uses external nameservers but the server still holds a local zone, the client updates the local zone, the CA queries the real nameservers, and validation fails. Check where the world thinks the domain lives:

dig +short NS example.com
dig +short NS example.com @1.1.1.1

If those do not return your DirectAdmin nameservers, use option two.

Option two: external DNS with a _acme-challenge CNAME

1.708 added detection of a _acme-challenge CNAME. The idea is to delegate only the challenge name to a zone DirectAdmin controls, so the panel can still write the TXT record while the rest of the domain stays on the external provider.

On the external DNS provider create the record:

_acme-challenge.example.com.  CNAME  _acme-challenge.example.com.acme.your-da-hostname.net.

The target can be any name inside a zone the DirectAdmin server is authoritative for. A common pattern is a dedicated zone such as acme.your-da-hostname.net created in Admin Level → DNS Administration whose nameservers are the DirectAdmin server itself. The ACME client follows the CNAME, writes the TXT record at the target name in the local zone, and the CA follows the same CNAME during validation.

Confirm the chain resolves before requesting the certificate:

dig +short CNAME _acme-challenge.example.com
dig +short NS acme.your-da-hostname.net

Then request the wildcard from the user’s SSL page as in option one. If the panel does not detect the CNAME, set acme_use_only_system_resolver=1 with da config-set and try again; split-horizon setups where the server resolves its own zones differently from the outside world confuse the detection.

Applying the certificate to services

A wildcard issued for a user’s domain is installed on that domain’s virtual host automatically. If you want the same wildcard to secure the mail services and the panel for a hostname under that domain, request it as the server certificate instead from Admin Level → Server TLS Certificate; 1.710 syncs a manually set or ACME-issued server certificate to Exim, Dovecot and the web server without extra steps.

Subdomains created after the wildcard is issued are covered immediately, but only if their virtual host references the wildcard certificate. DirectAdmin does that when the subdomain is created under the same domain; a subdomain created as a separate domain in the panel gets its own certificate request instead.

Common pitfall: rate limits and retries

Let’s Encrypt limits failed validations per account per hour and issuances per registered domain per week. A misconfigured CNAME that fails repeatedly will exhaust the failure budget and every domain on the server that uses the same account waits. The acme_disable_after_failures setting exists precisely to prevent this; leave it enabled, fix the DNS, and then re-enable the domain from its SSL page rather than repeatedly clicking request.

Verify

Check the issued certificate directly and confirm the wildcard SAN:

openssl s_client -connect example.com:443 -servername anything.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 'Subject Alternative Name'

Expect DNS:*.example.com, DNS:example.com. Watch the next automatic renewal in Provisioning history; renewals fire at 65 percent of lifetime on 1.711, so with a 90-day certificate the first renewal appears around day 58. The SSL expiry check script run against a few subdomains is a cheap way to be sure the wildcard is actually served everywhere you expect it.

DirectAdmin wildcard certificate at a glance

Official documentation: Let’s Encrypt documentation, DirectAdmin documentation, Linux man pages.

Related guides: DirectAdmin multi-server setup: DNS clustering and shared user/domain checks · Configuring Unbound as the local resolver and enabling HTTPS/SVCB records on DirectAdmin · Migrate DirectAdmin to cPanel with the WHM Transfer Tool or pkgacct-da.

Frequently asked questions