Wildcard SSL Setup: DNS-01, SAN Certificates & Auto-Renewal

A wildcard SSL certificate secures many first-level subdomains under one domain, while a SAN or multi-domain certificate secures an explicit list of hostnames that may span several domains. These solve different certificate-management problems.

For Let’s Encrypt, wildcard identifiers such as *.example.com require DNS-01 validation. The ACME client proves control by publishing a temporary TXT record under _acme-challenge. HTTP-01 cannot issue wildcard certificates.

This guide covers the full workflow: deciding between wildcard and SAN certificates, including the apex domain correctly, DNS-01 validation, CyberPanel automation, cPanel considerations, CAA troubleshooting, Cloudflare proxy/origin TLS behavior, certificate chains, private-key security, and renewal testing.

Last verified: September 26, 2026. ACME challenge behavior, certificate lifetimes, control-panel interfaces, AutoSSL providers, DNS APIs, CAA requirements and Cloudflare TLS modes can change; verify current vendor documentation before production deployment.

---

---

1. Choose the Right Certificate Type First

Do not choose a wildcard merely because multiple HTTPS sites share one IP. SNI allows multiple certificates on the same IP.

---

2. Single-Host vs Wildcard vs SAN Certificates

---

3. What a Wildcard Certificate Covers

A wildcard identifier such as:

*.example.com

can match first-level subdomains such as:

• blog.example.com
• shop.example.com
• api.example.com

---

4. Wildcard Does Not Automatically Cover the Apex Domain

*.example.com and example.com are separate certificate identifiers.

If the same certificate must cover both, request:

example.com
*.example.com

CyberPanel’s current SSL Manager documentation explicitly presents wildcard issuance using both the apex and wildcard names together.

---

5. Wildcards Cover One Label Level

A wildcard such as:

*.example.com

does not automatically cover a deeper hostname such as:

app.eu.example.com

Plan certificate names according to the real hostname hierarchy.

---

6. How ACME Certificate Issuance Works

ACME automates domain validation, certificate issuance, and renewal.

ACME Client
    ↓
Certificate Order
    ↓
Domain Validation
    ↓
Certificate Issued
    ↓
Installed on Server
    ↓
Renewed Automatically

---

7. HTTP-01 vs DNS-01

Let’s Encrypt’s current challenge documentation confirms that HTTP-01 cannot issue wildcard certificates, while DNS-01 can.

---

8. DNS-01 Validation Workflow

DNS-01 proves control of the domain by publishing a TXT record.

Let's Encrypt follows normal DNS resolution for the challenge name. That means the _acme-challenge response can be delegated with a CNAME or NS record to another DNS zone when your ACME tooling supports that architecture. This is useful when you want to keep broad DNS credentials off the web server.

The record is typically under:

_acme-challenge.example.com

Conceptually:

Request certificate
        ↓
Create _acme-challenge TXT
        ↓
Verify authoritative DNS
        ↓
ACME validation
        ↓
Certificate issued
        ↓
Install certificate + chain
        ↓
Reload / deploy to service
        ↓
Verify live TLS endpoint
        ↓
Automate renewal + monitor failures

Do not model DNS-01 as “create the TXT record and immediately retry.” DNS providers can have publication/propagation delays, and different authoritative servers can temporarily disagree. Verify the authoritative nameservers before asking the CA to validate.

---

9. CyberPanel Wildcard SSL Architecture

CyberPanel’s current SSL Manager documentation describes wildcard SSL issuance through DNS-01 validation.

Its documented integrations include:

• Cloudflare API.
• CyberPanel-managed PowerDNS.

This means wildcard issuance does not rely on HTTP access to the origin server in the same way as HTTP-01 validation.

---

10. Determine Where DNS Is Actually Hosted

Before configuring CyberPanel or Cloudflare integration, determine the authoritative DNS provider.

Your architecture can look like:

Domain Registrar
      ↓
Authoritative DNS Provider
      ↓
CyberPanel VPS

The registrar and DNS provider are not necessarily the same company.

The TXT challenge must be written to the authoritative DNS zone.

For DNS architecture, read the DNS Configuration Guide.

---

11. cPanel Wildcard SSL: Current AutoSSL Boundary

Current cPanel & WHM documentation lists Let’s Encrypt as the default AutoSSL provider and confirms that its plugin supports wildcard certificates.

However, cPanel documents an important limitation:

Therefore, do not assume that Cloudflare or another external authoritative DNS provider can simply be connected to cPanel AutoSSL for wildcard issuance. If DNS remains external, use a supported external ACME workflow/client that can automate DNS-01 with that provider, or follow your hosting provider's documented integration.

The relevant current documentation is cPanel's Let's Encrypt AutoSSL plugin documentation.

---

12. Cloudflare DNS Integration

If Cloudflare is authoritative for the domain, CyberPanel or the ACME client can use Cloudflare’s DNS API when supported by the selected workflow.

The validation still occurs using a TXT record such as:

_acme-challenge.example.com
TXT
<challenge-value>

---

13. Use Narrowly Scoped DNS API Tokens

DNS API credentials are security-sensitive because they can modify domain records.

Never place real tokens in:

• Blog posts.
• Screenshots.
• Git repositories.
• Support forums.
• Public shell-history examples.

Documentation examples should use placeholders such as:

CF_DNS_API_TOKEN="YOUR_SCOPED_TOKEN"

---

14. DNS-01 and Cloudflare Proxy Status

DNS-01 validation checks authoritative DNS TXT records rather than retrieving the website through Cloudflare’s HTTP proxy.

Therefore, Cloudflare’s orange-cloud proxy state is not what validates the wildcard DNS-01 challenge.

This is different from an HTTP-01 workflow, where the certificate authority must retrieve a challenge file over HTTP.

---

15. Verify DNS-01 at the Authoritative Nameservers

Do not treat “DNS propagation” as an instant or binary event. First prove that the authoritative nameservers for the zone are serving the expected challenge value.

Step 1: identify authoritative nameservers

dig +short NS example.com

Step 2: query each authoritative server directly

dig @ns1.example-dns.net _acme-challenge.example.com TXT +noall +answer
dig @ns2.example-dns.net _acme-challenge.example.com TXT +noall +answer

Every authoritative server should return the expected TXT value before you tell the ACME client to validate. If one authoritative server is stale or misconfigured, an external validator may reach that server even when your local resolver shows the new value.

Step 3: compare public recursive resolvers

dig @1.1.1.1 _acme-challenge.example.com TXT +short
dig @8.8.8.8 _acme-challenge.example.com TXT +short

A recursive resolver can legitimately cache an older result until TTL expiry. Authoritative-server checks tell you whether the source zone is correct; recursive checks tell you what common resolvers currently see.

Step 4: check for challenge delegation

dig _acme-challenge.example.com CNAME +short
dig _acme-challenge.example.com NS +short

If challenge validation is delegated, inspect the target zone as well. Let's Encrypt's current DNS-01 documentation explicitly permits CNAME or NS delegation for challenge answers.

---

16. Do Not Repeatedly Request Certificates During a DNS Error

If issuance fails because the TXT record is wrong or unavailable, repeatedly generating new certificate orders does not fix the underlying DNS problem.

First diagnose:

1. Nameserver delegation.
2. TXT hostname.
3. TXT value.
4. DNS API permissions.
5. Authoritative DNS consistency and resolver cache delay.
6. CyberPanel/ACME logs.

Certificate authorities enforce issuance limits, so repeated failed production attempts can complicate troubleshooting.

Let's Encrypt's current rate-limit documentation allows up to 5 authorization failures per identifier per account per hour. During development or troubleshooting, use the Let's Encrypt staging environment instead of repeatedly consuming production validation attempts.

# Certbot example — uses Let's Encrypt staging
certbot renew --dry-run

Other ACME clients have their own staging/test syntax. Use the client's current documentation rather than copying Certbot flags to a different ACME client.

---

17. Check CAA and issuewild Before Blaming DNS-01

CAA records can restrict which certificate authorities may issue certificates for a domain.

dig example.com CAA +noall +answer

For Let's Encrypt, a basic authorization can look conceptually like:

example.com. CAA 0 issue "letsencrypt.org"

The issue property controls ordinary issuance and also wildcard issuance when no issuewild records are present. Use issuewild only when wildcard certificates need a different authorization policy.

example.com. CAA 0 issue     "example-ca.invalid"
example.com. CAA 0 issuewild "letsencrypt.org"

Do not add or remove CAA entries blindly. Confirm the CA that your actual ACME/control-panel workflow uses—especially when the platform can fall back to another CA.

For paid certificates, re-check the issuing CA before reusing an old CAA policy. For example, SSLs.com states that certificates activated from July 11, 2026 are issued by SSL.com rather than Sectigo. If a domain has restrictive CAA records that authorize only Sectigo, new SSLs.com issuance can fail until the relevant ssl.com authorization is added.

example.com. CAA 0 issue     "ssl.com"
example.com. CAA 0 issuewild "ssl.com"

Add issuewild only when the wildcard authorization policy requires it; otherwise follow the issuing CA's current documented CAA requirements.

---

18. Normal CyberPanel SSL Still Depends on Correct DNS

For ordinary non-wildcard website certificates, make sure the hostname resolves to the intended CyberPanel server before requesting issuance.

Review:

• A records.
• AAAA records.
• Port 80 reachability where HTTP-01 is used.
• Port 443 for HTTPS service.
• Proxy and redirect behavior.

---

19. Check Stale IPv6 Records

A common certificate problem occurs when:

• The A record points to the new server.
• An old AAAA record still points somewhere else.

Some validators or visitors may reach the stale IPv6 destination.

If IPv6 is not configured, do not leave an incorrect AAAA record published.

---

20. Certificate Chain Matters

The server generally needs to present the site certificate together with the appropriate intermediate chain.

Site Certificate
      ↓
Intermediate CA
      ↓
Trusted Root

An incomplete chain can cause trust errors on some clients.

---

21. Certificate and Private Key Must Match

A certificate is associated with a private key.

If you upload a certificate with an unrelated private key, the server cannot use the pair correctly.

Never publish:

• privkey.pem.
• Private PEM blocks.
• Private keys in Git repositories.

If a private key is exposed, replace the affected key and certificate.

Verify a certificate and private key belong together

Comparing public keys works for RSA and EC certificates:

openssl x509 -in cert.pem -pubkey -noout \
  | openssl pkey -pubin -outform DER \
  | sha256sum

openssl pkey -in privkey.pem -pubout -outform DER \
  | sha256sum

The SHA-256 values should match. Do not paste a real private key into an online checker.

For the broader server/account security layer, use the Website Security Checklist.

---

22. SNI Allows Multiple HTTPS Sites on One IP

Server Name Indication allows modern clients to specify the requested hostname during TLS negotiation.

This means one IP address can host several HTTPS virtual hosts using separate certificates.

You do not need a wildcard certificate merely because multiple websites share the same server IP.

---

23. Wildcard Certificates and Private-Key Scope

Wildcards can simplify certificate management across related subdomains.

However, if one wildcard private key is copied to several unrelated systems, compromise of one system can increase the exposure associated with that certificate identity.

Separate certificates may be preferable when:

• Subdomains run on unrelated infrastructure.
• Different teams administer different servers.
• You want narrower private-key exposure.

---

24. Configure HTTPS Redirects Carefully

After confirming that a valid certificate is active, redirect HTTP traffic to HTTPS where appropriate.

http://example.com/page
          ↓
https://example.com/page

Test:

• Apex domain.
• www hostname.
• Wildcard subdomains.
• Application redirects.
• Proxy behavior.

---

25. Avoid Cloudflare Redirect Loops

Cloudflare handles the visitor connection and the origin connection separately.

A redirect loop can occur when the origin believes the request is HTTP while the visitor is already using HTTPS through the proxy.

Cloudflare’s current Full (strict) guidance recommends strict validation whenever the origin can present a suitable certificate. Plain Full mode encrypts the origin connection but does not validate the origin certificate.

---

26. Cloudflare Error 525

Cloudflare documents Error 525 as an SSL handshake failure between Cloudflare and the origin server. A missing or unusable HTTPS configuration on the origin can trigger this when Cloudflare is connecting over HTTPS.

Potential origin-side causes include:

• No usable TLS certificate.
• Port 443 unavailable.
• SNI problems.
• Protocol or cipher incompatibility.
• Other TLS handshake failures.

Do not assume that replacing the visitor-facing certificate will fix a Cloudflare-to-origin handshake problem.

---

27. Cloudflare Error 526

Error 526 is associated with origin-certificate validation problems when Cloudflare is validating the origin certificate in Full (strict) or another strict-validation mode.

For Full (strict), the origin certificate should be:

• Unexpired.
• Issued by a trusted public CA or Cloudflare Origin CA.
• Valid for the requested hostname.

Cloudflare notes that an origin that does not meet these requirements can produce a 526 error.

---

28. Cloudflare Origin CA Is Different from a Public Browser Certificate

Cloudflare Origin CA certificates are designed to secure traffic between Cloudflare and the origin.

They are suitable when the origin receives traffic through proxied Cloudflare hostnames and you are using an appropriate strict origin-encryption configuration. Cloudflare Origin CA certificates are not intended to be trusted directly by ordinary browsers connecting straight to the origin.

Do not confuse:

• Visitor-to-Cloudflare TLS.
• Cloudflare-to-origin TLS.

They are separate connections.

---

29. Verify the Installed Certificate With OpenSSL

After issuance or renewal, inspect the certificate actually presented by the server rather than relying only on the control-panel success message.

openssl s_client -connect example.com:443 -servername example.com -showcerts

Check the presented hostname coverage, validity dates, issuer and chain. If a CDN or reverse proxy terminates public TLS, this command tests the certificate presented on that path; test the origin separately when origin TLS is also part of the troubleshooting scope.

A compact live-certificate summary:

echo | openssl s_client \
  -connect example.com:443 \
  -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Run the same check for representative wildcard hostnames such as shop.example.com. A wildcard certificate can be correctly issued yet the server may still present an older certificate because the web server was not reloaded or the wrong virtual host is serving the request.

---

30. Monitor Certificate Renewal

Certificate automation can fail later even if initial issuance succeeded. DNS-01 renewal still depends on the ACME client being able to create or update the required challenge record, and deployment still depends on the renewed files reaching the correct service.

Common failure causes include:

• Expired or revoked DNS API credentials.
• DNS-provider migration or changed nameservers.
• Removed challenge delegation.
• Changed CAA policy.
• Broken ACME cron/systemd jobs.
• Changed certificate paths or permissions.
• Web server reload failure after renewal.

Use independent certificate-expiry monitoring. For monitoring, continue with the Uptime Kuma Monitoring Guide.

As of September 26, 2026, Let's Encrypt's default/classic certificates are still 90 days. Its published schedule changes the default classic profile to 64 days on February 10, 2027 and 45 days on February 16, 2028. An opt-in 45-day tlsserver profile has already been available since May 2026.

This makes reliable ACME renewal, deployment and expiry monitoring more important. Let's Encrypt also states that ordinary renewals are exempt from its new-order rate limits, so the shorter lifetime transition is primarily an automation/reliability concern rather than a reason to manually request certificates more often.

---

31. Test Renewal and Deployment as Separate Steps

Do not assume that initial issuance proves future renewal—or that successful renewal proves the new certificate is live.

For Certbot-managed systems, certbot renew --dry-run uses the Let's Encrypt staging environment. For CyberPanel, cPanel or another ACME integration, use that platform's supported renewal/test mechanism and logs.

---

32. Recovery Workflow When Renewal or Deployment Fails

1. Do not delete the currently working certificate/key. Preserve the last known-good files until the replacement is verified.
2. Identify the failure stage: DNS challenge, CA authorization, issuance, installation, service reload or TLS presentation.
3. Verify authoritative DNS: nameservers, challenge TXT/CNAME/NS delegation and CAA.
4. Use staging/dry-run while repairing validation.
5. Verify the new certificate locally: SANs, dates, issuer, chain and private-key match.
6. Validate web-server configuration before reload. Use the server's native configuration test command where available.
7. Reload gracefully rather than restarting blindly.
8. Verify the certificate from outside the server.
9. Only remove old certificate files/challenge records after the new deployment is proven healthy.

If the problem is near expiry and automation cannot be restored safely, use the provider/control panel's documented emergency/manual certificate path rather than repeatedly issuing new orders without understanding the failure.

---

33. When a Wildcard Certificate Is a Good Fit

A wildcard can be useful when:

• You operate many related subdomains.
• Subdomains are created dynamically.
• You can securely automate DNS-01.
• Centralized certificate management is operationally useful.

---

34. When Separate Certificates May Be Better

Separate certificates can be preferable when:

• You have only a few fixed hostnames.
• Subdomains run on unrelated servers.
• Different teams control different systems.
• You want narrower private-key exposure.

Wildcard is a management choice, not a universal upgrade.

---

35. Wildcard SSL Does Not Make WordPress Faster

Using one wildcard certificate instead of several valid certificates does not inherently improve WordPress performance.

Choose certificate architecture based on:

• Hostname coverage.
• Operational complexity.
• Renewal automation.
• Security scope.

Do not use wildcard SSL as a performance claim.

---

36. HTTPS Does Not Guarantee Rankings

HTTPS is important for secure transport and modern website operation, but a certificate alone does not guarantee:

• Higher rankings.
• Indexing.
• Core Web Vitals.
• Conversions.

Keep security, crawling, indexing, performance, and content quality as separate technical concerns.

---

37. CyberPanel Wildcard SSL Troubleshooting Workflow

1. Confirm the exact hostnames required.
2. Decide whether the apex domain also needs coverage.
3. Check authoritative nameservers.
4. Confirm DNS-01 for wildcard issuance.
5. Check Cloudflare/PowerDNS integration.
6. Verify DNS API permissions.
7. Check the _acme-challenge TXT record.
8. Verify the TXT value on every authoritative nameserver, then check recursive resolvers if needed.
9. Review CyberPanel/ACME logs.
10. Check certificate hostname coverage.
11. Check the certificate chain.
12. Confirm the certificate and private key match.
13. Test HTTPS externally.
14. Check proxy/origin TLS mode if using Cloudflare.
15. Verify renewal.

---

38. DNS-PERSIST-01 Is Emerging, Not a Universal Replacement Yet

In February 2026, Let's Encrypt announced work on DNS-PERSIST-01, an emerging ACME validation model based on persistent DNS authorization records. It is intended to reduce repeated DNS changes at renewal time and can include wildcard scope.

Do not rewrite an existing production DNS-01 workflow around it unless your chosen ACME client and CA explicitly support the finalized/current implementation. For today's broadly supported wildcard automation, DNS-01 remains the baseline documented in this guide.

---

39. When Setup Intent Becomes Certificate-Selection Intent

If the question is no longer “how do I issue or renew this certificate?” but instead “which certificate type or provider should I choose?”, move to the Best SSL Certificates guide.

Keep setup and buying intent separate: a free ACME wildcard may be appropriate for many technical deployments, while some organizations may require different validation levels, support models, warranties or enterprise procurement.

If a paid wildcard is required, validation level is separate from wildcard coverage. SSLs.com currently lists DV and OV wildcard products and states that EV is not available for wildcard certificates. For provider/product selection, keep using the Best SSL Certificates guide rather than adding a checkout CTA to this implementation tutorial.

For SSLs.com-specific issuer, CAA, pricing, product and reissue details, use the SSLs.com Review.

---

40. Related Digital Bhatti Guides

• CyberPanel installation: CyberPanel + OpenLiteSpeed Installation Guide.
• DNS configuration: DNS Configuration Best Practices.
• Monitoring: Uptime Kuma Monitoring Guide.
• Hosting architecture: Shared vs VPS vs Cloud Hosting.
• Certificate selection: Best SSL Certificates.

---

CyberPanel Wildcard SSL Checklist

• Use wildcard certificates only where the hostname structure benefits from them.
• Remember that *.example.com does not automatically cover example.com.
• Remember that wildcards cover one hostname-label level.
• Use DNS-01 for Let’s Encrypt wildcard validation.
• Do not attempt wildcard issuance using HTTP-01.
• Verify authoritative DNS before configuring CyberPanel integration.
• Use Cloudflare API or supported PowerDNS integration where appropriate.
• Use narrowly scoped DNS API credentials.
• Never publish private keys or API secrets.
• Verify the TXT challenge on every authoritative nameserver before retrying issuance.
• Do not create repeated certificate orders while DNS is broken.
• Check A and AAAA records for ordinary certificate issuance.
• Verify certificate hostname coverage.
• Install the required certificate chain.
• Configure HTTP-to-HTTPS redirects without loops.
• Understand Cloudflare visitor TLS vs origin TLS.
• Monitor certificate expiration independently.
• Verify the renewed certificate is actually served after deployment/reload.
• Use staging/dry-run during DNS-01 troubleshooting.
• Check CAA issue/issuewild policy when authorization fails.
• Test automated renewal.
• Monitor certificate expiry independently as certificate lifetimes shorten.
• Re-check CAA when changing certificate authorities or certificate providers.

Frequently Asked Questions

How do I install a wildcard SSL certificate in cPanel?

Current cPanel Let’s Encrypt AutoSSL supports wildcard certificates, but cPanel documents a key limitation: its wildcard flow cannot use third-party DNS hosting. DNS must be hosted locally on the cPanel/WHM server or within its DNS cluster. If your authoritative DNS remains with an external provider such as Cloudflare, use a supported external ACME/DNS-01 workflow or your host's documented solution.

Can a wildcard certificate cover multiple domains?

Not by the wildcard alone. *.example.com covers first-level subdomains of example.com. To cover unrelated domains or additional explicit hostnames, use SAN entries or separate certificates.

Can CAA block wildcard SSL issuance?

Yes. If issuewild exists, it controls wildcard authorization separately. If no issuewild records exist, the applicable issue records govern wildcard issuance too. Verify the CA your control panel or ACME client actually uses.

Can Let’s Encrypt issue wildcard certificates?

Yes. Let’s Encrypt supports wildcard certificates, but wildcard validation requires a DNS-based challenge such as DNS-01.

Can HTTP-01 issue a wildcard certificate?

No. Let’s Encrypt’s current challenge documentation states that HTTP-01 cannot issue wildcard certificates.

Does *.example.com cover example.com?

No. The apex domain must be included separately if the certificate needs to cover both example.com and *.example.com.

Can CyberPanel issue wildcard SSL certificates?

CyberPanel’s current SSL Manager documents wildcard issuance through DNS-01 and supports integrations including Cloudflare API and PowerDNS.

Do I need to disable Cloudflare proxying for DNS-01?

DNS-01 validates the TXT record through authoritative DNS rather than through the proxied HTTP request path. That is different from HTTP-01 validation.

Why does CyberPanel wildcard SSL issuance fail?

Common causes include incorrect authoritative DNS, wrong or stale TXT records on one authoritative server, insufficient DNS API permissions, CAA restrictions, incorrect hostname coverage, certificate-authority limits, or ACME integration problems. Verify authoritative DNS first instead of repeatedly creating new orders.

What does Cloudflare Error 525 mean?

Cloudflare documents Error 525 as an SSL handshake failure between Cloudflare and the origin server. A missing or unusable HTTPS configuration on the origin can trigger this when Cloudflare is connecting over HTTPS.

What does Cloudflare Error 526 mean?

Error 526 is associated with origin-certificate validation problems in strict TLS validation. Check certificate validity, hostname coverage, trust and chain configuration.

Is wildcard SSL better than separate certificates?

Not universally. Wildcards can simplify management across related subdomains, while separate certificates can provide narrower key exposure and cleaner isolation between unrelated systems.

Are Let's Encrypt certificates still valid for 90 days?

Yes for the default/classic profile as of September 26, 2026. Let's Encrypt plans to move that default to 64 days on February 10, 2027 and 45 days on February 16, 2028. Automated renewal and live-certificate monitoring should therefore be treated as required operational controls.

Does shorter certificate lifetime mean Let's Encrypt renewals will hit new-order rate limits?

Let's Encrypt says ordinary renewals are exempt from its new-order rate limits. The main operational requirement is reliable automated renewal and deployment, not manually creating more certificate orders.

Can I get an EV wildcard certificate?

Do not assume so. SSLs.com currently lists DV and OV wildcard products and states that EV is not available for wildcard certificates.

Does wildcard SSL improve website speed?

No general performance improvement should be assumed simply because one wildcard certificate is used instead of several valid certificates.