Docs › Certificates

Wildcard certificates with acme.sh

acme.sh has a built-in acme-dns integration. Set four variables, then issue as normal.

Where the configuration lives

Environment variables

Configuration

acme.sh

export ACMEDNS_BASE_URL="https://api.home.network/acmedns"
export ACMEDNS_USERNAME="<your username>"
export ACMEDNS_PASSWORD="<your key>"
export ACMEDNS_SUBDOMAIN="<your subdomain>"

acme.sh --issue --dns dns_acmedns \
  -d 'alice.home.network' -d '*.alice.home.network'

The username, password and subdomain come from the setup wizard, which shows them once. They are stored hashed, so a lost set is replaced rather than recovered.

Worth knowing. ACMEDNS_BASE_URL is the base, without /update, which acme.sh appends itself. Adding it produces a 404 that reads like a server fault. acme.sh saves the four variables after the first successful issue, so renewals do not need them re-exported.

Ask for both names

A wildcard does not cover the name it sits under, so a certificate for *.alice.home.network alone leaves alice.home.network without one. Request both in a single certificate.

Check it worked

verify

# the challenge value your client published
dig +short TXT _acme-challenge.alice.home.network @ns1.home.network

# what the certificate ended up covering
echo | openssl s_client -servername nas.alice.home.network \
  -connect nas.alice.home.network:443 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Why only wildcards

Challenge records are writable only at your label apex, so the only certificates obtainable are the wildcard and the label itself. Your individual device names never reach Certificate Transparency logs, which is a consequence of the design rather than a setting to remember.

← All documentation