Wildcard SSL with Let's Encrypt (DNS-01) and DNSSEC

Yes, you can get a wildcard SSL certificate from Let's Encrypt for free, but only through the DNS-01 challenge: your ACME client must create a TXT record at _acme-challenge.example.com that Let's Encrypt looks up before issuing *.example.com. In practice that means the client needs API access to your DNS, or your DNS must run on the same server as the client. If the zone is signed with DNSSEC, the signatures must be valid, because Let's Encrypt checks DNSSEC on every lookup and refuses to issue when validation fails.

Our Let's Encrypt guide covers ordinary certificates, Certbot and rate limits. This article focuses on what is specific to wildcards: how DNS-01 works, how to automate it safely, how the coming lifetime changes affect it, and how DNSSEC and CAA records fit in.

When do you need a wildcard certificate?

A wildcard certificate for *.example.com is valid for shop.example.com, staging.example.com and any other name one level below example.com. It makes sense when:

• you create subdomains often, for example one per customer in a SaaS app (acme.yourapp.com), or one per staging site;
• subdomains are created by software before anyone could add them to a certificate;
• you do not want every subdomain name to appear in public Certificate Transparency logs, since only *.example.com is logged.

It is not always the better choice. A wildcard's private key protects every subdomain, so if it leaks from one server, all of them are exposed. If you have three fixed subdomains, a normal certificate listing those names, issued over HTTP, is simpler and needs no DNS access.

What a wildcard does not cover

Two rules catch people out:

Name	Covered by *.example.com?
www.example.com, shop.example.com	Yes
example.com (the bare domain)	No, add it as a second name
a.b.example.com (two levels down)	No, needs *.b.example.com

A wildcard matches exactly one label, as defined for TLS in RFC 9525. Most setups therefore request two names on one certificate: example.com and *.example.com.

How DNS-01 validation works

Let's Encrypt's challenge types page is the authoritative description. In short:

1. Your ACME client asks for a certificate for *.example.com.
2. Let's Encrypt gives the client a token. The client derives a value from the token and its account key.
3. The client publishes that value as a TXT record at _acme-challenge.example.com.
4. Let's Encrypt queries your authoritative DNS. If the TXT value matches, it issues the certificate.
5. The client removes the TXT record.

HTTP-01 "cannot be used to issue wildcard certificates," so there is no way around DNS. The same page lists the trade-offs. DNS-01 works when port 80 is closed or the web server is not public, and with several web servers behind one name. On the other hand, storing DNS API credentials on a web server is risky, some DNS providers have no API, and some APIs do not tell you when a change has reached all their nameservers, so you may have to wait.

Three ways to automate DNS-01

Manual TXT records work once (certbot certonly --manual --preferred-challenges dns), but a manual certificate does not renew itself. Pick one of these instead.

Approach	How it works	Watch out for
DNS provider API	The ACME client uses a plugin (Certbot DNS plugins, acme.sh, lego) to create the TXT record through your provider's API	Use an API token limited to one zone and to TXT records if your provider allows it
CNAME delegation	Point _acme-challenge.example.com with a CNAME to a name in a separate zone that only the ACME client controls	Let's Encrypt follows the CNAME, as its docs describe; keep the delegated zone small and locked down
DNS on the same server	The ACME client writes the TXT record straight into the authoritative DNS it runs next to	Your nameservers must be reliable, ideally two of them on separate servers

Whichever you choose, clean up old TXT records. Let's Encrypt accepts several TXT values at the same name, but warns that very large responses can be rejected. And if your DNS is spread across many nameservers or an anycast network, make sure every one of them has the record before the client asks for validation.

Shorter lifetimes make automation non-negotiable

Let's Encrypt certificates last 90 days today, and the FAQ also offers opt-in six-day certificates. Its December 2025 plan shortens both certificate lifetimes and the time a successful validation can be reused:

Date	Default (classic) profile	Validation reuse
Now (October 2026)	90-day certificates	30 days
10 February 2027	64-day certificates	10 days
16 February 2028	45-day certificates	7 hours

The opt-in tlsserver profile was scheduled to start issuing 45-day certificates on 13 May 2026. The reuse change matters most for wildcards: with a 7-hour reuse window, practically every renewal needs a fresh TXT record, so DNS automation has to work every time, not just the first time. Let's Encrypt recommends ACME Renewal Information (ARI) or renewing at about two-thirds of a certificate's lifetime, and warns that a fixed 60-day renewal interval will no longer be enough.

Let's Encrypt has also announced DNS-PERSIST-01, a method where a TXT record is set once and does not change on each renewal (announcement). At the time of writing, its challenge types documentation does not list it yet, so do not plan around it until it does.

DNSSEC and wildcard certificates

DNSSEC signs a DNS zone so that validating resolvers can detect forged answers. It matters for certificates because a CA's DNS lookups are how it decides who controls a domain. Let's Encrypt staff have stated that Let's Encrypt always verifies DNSSEC on its lookups, while not requiring domains to be signed.

That has two consequences:

• Benefit: if your zone is signed, an attacker who forges DNS answers to Let's Encrypt's resolvers cannot fake your _acme-challenge TXT record or your CAA record, because the forgery fails validation.
• Risk: if your DNSSEC is broken, for example a stale DS record at the registrar after a key change, Let's Encrypt gets a SERVFAIL and refuses to issue. Its CAA documentation says a SERVFAIL on a signed zone "most often" indicates a DNSSEC validation failure, and suggests a debugger such as dnsviz.net.

When you enable DNSSEC, publish the DS record at the registrar only after the zone is signed. When you disable it, do the reverse: remove the DS record first, wait for its TTL to expire, and only then stop signing. Turning signing off while the DS record is still published makes the whole domain fail to resolve for validating resolvers, not just certificate issuance.

CAA records for wildcards

A CAA record lists which certificate authorities may issue for your domain. Let's Encrypt's CAA page explains the tags that matter here:

Tag	Effect
issue "letsencrypt.org"	Allows Let's Encrypt for normal and wildcard names, unless issuewild says otherwise
issuewild	Separate permission for wildcard names only
accounturi parameter	Limits issuance to your own ACME account, so someone who briefly hijacks your DNS cannot use theirs
validationmethods parameter	Limits which challenge types may be used, for example only dns-01

CAA records are most trustworthy in a DNSSEC-signed zone, for the same reason as the TXT records.

Wildcard SSL and DNSSEC in ZoPanel

ZoPanel takes the "DNS on the same server" route. When the administrator installs the DNS server (PowerDNS) and a domain's zone is hosted and delegated to it, a website's SSL tab offers Also *.example.com (wildcard). Tick it and click Issue certificate: ZoPanel writes the TXT record into its own zone, so no third-party API key is stored anywhere. The certificate covers example.com and *.example.com; aliases the wildcard already covers, such as www, are dropped from the order because Let's Encrypt refuses redundant names. Renewals keep the wildcard and run on their own, with alerts if a renewal fails (SSL docs).

On the same zone you can turn on DNSSEC with one switch; ZoPanel shows the DS records to add at your registrar, and the DNS docs spell out the safe order for turning it off. New zones also get a CAA record that allows only Let's Encrypt.

The honest limitation: ZoPanel does not issue wildcards through Cloudflare's or another provider's DNS API. If your zone stays at Cloudflare, ZoPanel refuses the wildcard request and points you to the DNS page; use a Cloudflare Origin certificate instead, as described in our Cloudflare guide. To run your own nameservers, see how to create private nameservers, and the DNS features page for the whole DNS toolset.

Conclusion

A free wildcard SSL from Let's Encrypt is a DNS problem more than a certificate problem. Request both the bare domain and *.example.com, automate the TXT record with a scoped API token, CNAME delegation or DNS on the same server, and make sure it works for every renewal, since lifetimes and validation reuse shrink from February 2027. If you sign the zone with DNSSEC, keep the DS record in sync, because a broken signature blocks issuance.

To try wildcard certificates and DNSSEC without wiring up APIs, ZoPanel's Free plan includes the DNS server, wildcard SSL and DNSSEC for 3 hosting accounts and 10 websites, with no time limit.

Frequently asked questions

Is a Let's Encrypt wildcard certificate really free?

Yes. Let's Encrypt charges nothing for any certificate, wildcards included. The cost is operational: you need DNS automation that can create a TXT record for each renewal.

Does a wildcard certificate cover the main domain?

No. *.example.com covers names one level below example.com, not example.com itself and not deeper names like a.b.example.com. Request example.com and *.example.com on the same certificate.

Can I get a wildcard with HTTP validation?

No. Let's Encrypt's documentation states that the HTTP-01 challenge cannot be used for wildcard certificates. Only DNS-01 works.

Does DNSSEC break Let's Encrypt?

A correct DNSSEC setup does not; it makes validation more trustworthy. A broken one does: if signatures or DS records are wrong, Let's Encrypt's lookups fail with SERVFAIL and no certificate is issued. Test the zone with a DNSSEC debugger before you request the certificate.

How often does a wildcard certificate renew?

Today, typically every 60 days for a 90-day certificate. From 10 February 2027 the default lifetime drops to 64 days and from 16 February 2028 to 45 days, so renewals become more frequent. Let your client schedule them from the real expiry date or ARI, not a fixed interval.