If you run multiple subdomains on a single server, managing individual SSL certificates for each one is a maintenance nightmare — different expiry dates, manual renewals, and the ever-present risk of a forgotten certificate taking a subdomain offline at 2 a.m. Plesk wildcard SSL certificate setup solves this by issuing one certificate that covers every first-level subdomain under your domain, and this guide walks you through every step: issuance, application, DNS challenge handling, HSTS, and TLS hardening. Whether you use the free Let's Encrypt path or a paid commercial certificate, the process is the same inside Plesk — the differences lie in validation and renewal automation.
What Is a Wildcard SSL Certificate and When You Need One in Plesk
A wildcard SSL certificate is issued for *.yourdomain.com and is cryptographically valid for any hostname one level deep under that apex: app.yourdomain.com, api.yourdomain.com, shop.yourdomain.com, mail.yourdomain.com, and so on — all covered by a single certificate file.
When you need one:
- You run three or more subdomains on the same server and want a single renewal event instead of staggered individual expirations.
- You provision subdomains dynamically (staging environments, client tenants, feature branches) and cannot predict hostnames in advance.
- You are consolidating several Plesk-hosted sites and want unified SSL management without purchasing per-domain certificates.
What a wildcard does NOT cover:
- The root domain itself (
yourdomain.com) — you must add it as a Subject Alternative Name (SAN) alongside*.yourdomain.com. - Second-level subdomains such as
dev.app.yourdomain.com— these require their own certificate or a second wildcard.
For most Plesk operators running a managed hosting stack, a single wildcard covering *.yourdomain.com and yourdomain.com is sufficient. If your infrastructure is more complex, a managed server management service can design a certificate architecture that matches your subdomain topology without gaps.
Prerequisites: DNS Control and Let's Encrypt Extension in Plesk
1. DNS Control
Wildcard certificates require DNS-01 challenge validation. Unlike HTTP-01 (which writes a file to /.well-known/acme-challenge/), DNS-01 requires you to create a TXT record at _acme-challenge.yourdomain.com. This means:
- DNS hosted in Plesk: Plesk can automate everything. The Let's Encrypt extension writes the TXT record, validates, and removes it automatically.
- DNS hosted externally (Cloudflare, Route 53, GoDaddy, etc.): Plesk cannot touch your DNS zone. You must manually create the TXT record during issuance or install a Certbot DNS API plugin. See Section 6 for the full fix.
2. Let's Encrypt Extension Installed
In Plesk, go to Tools & Settings → Updates and Upgrades → Add/Remove Components and confirm the Let's Encrypt extension is installed. Alternatively, open the Extensions catalogue, search for "Let's Encrypt", and click Install. The extension is free.
3. Plesk Version
Wildcard certificate issuance via Let's Encrypt has been supported since Plesk Obsidian 18.0.22. Run plesk version in SSH to confirm your build is current.
4. Outbound Port 443 to ACME Servers
Verify connectivity to Let's Encrypt:
curl -I https://acme-v02.api.letsencrypt.org/directoryA 200 OK response confirms connectivity. If blocked, open port 443 outbound in your firewall before proceeding.
💡 None of these worked? Skip the guesswork.
Get Expert Help →Issuing a Free Let's Encrypt Wildcard Certificate via Plesk UI
Log in to Plesk, navigate to Websites & Domains, and locate your primary domain. Click SSL/TLS Certificates. If the Let's Encrypt extension is installed, you will see a blue Get it free button or a dedicated Let's Encrypt tab.
Click the Let's Encrypt option. In the certificate request form, enter your email address and check the following domain entries:
yourdomain.com— the root domain*.yourdomain.com— the wildcard, covering all first-level subdomains
Plesk will detect that a wildcard requires DNS-01 and prompt accordingly. If your DNS is managed in Plesk, select Use DNS challenge and click Get it free. Plesk creates the _acme-challenge TXT record, validates with Let's Encrypt, obtains the certificate, and removes the TXT record — all automatically within 30–60 seconds.
If your DNS is external, Plesk will display the required TXT record value. Copy it, log in to your DNS provider, create the record manually, wait for propagation (typically 2–5 minutes), then return to Plesk and click Validate.
Upon success, the SSL/TLS panel shows your new certificate with a validity date 90 days out, covering both yourdomain.com and *.yourdomain.com as SANs. Plesk automatically assigns this certificate to the primary domain's Apache/Nginx virtual host.
Go to Websites & Domains, expand your domain, and click the subdomain (e.g., app.yourdomain.com). Open Hosting Settings.
In the Security section, find the SSL/TLS certificate dropdown. Select the wildcard certificate you just issued. Click OK to save.
Ensure the SSL/TLS support checkbox is ticked. Plesk will reconfigure the Nginx and Apache virtual host for the subdomain to serve the wildcard certificate.
For servers with many subdomains, automate with the Plesk CLI:
# List all subdomains
plesk bin subdomain --list -domain yourdomain.com
# Apply the certificate to a subdomain
plesk bin subdomain -u app -domain yourdomain.com -ssl true -certificate-name "yourdomain.com (Let's Encrypt)"curl -vI https://app.yourdomain.com 2>&1 | grep -E "subject:|issuer:|expire"The output should show subject: CN=*.yourdomain.com and an expiry 90 days from issuance.
Go to Websites & Domains → your domain → SSL/TLS Certificates.
Scroll to the Advanced Settings section. Check Enable HTTP Strict Transport Security (HSTS) and set:
- Max-age:
31536000(one year — minimum for HSTS preload list eligibility) - Include subdomains: checked
- Preload: checked only if you intend to submit to the HSTS preload list
Click OK. Plesk injects the Strict-Transport-Security header into Nginx's server block.
Warning: Once HSTS is live with a long max-age, browsers will refuse HTTP connections for the duration of the policy — even if you remove the header later. Only enable this when you are certain SSL will remain on all subdomains permanently.
Enforcing TLS 1.2 and TLS 1.3 via CLI
# Disable TLS 1.0 and 1.1, keep 1.2 and 1.3
plesk bin server_pref --update -ssl-protocols "TLSv1.2 TLSv1.3"
# Set a strong cipher suite (TLS 1.2 fallback)
plesk bin server_pref --update -ssl-ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384"
# Restart web services
plesk bin service_node --restart sw-nginx
plesk bin service_node --restart sw-cp-serverRun your domain through SSL Labs to confirm the A+ rating.
Fixing Auto-Renewal Failures for External DNS Wildcard Certificates
This is the most common pain point: issuance works, but 60 days later the auto-renewal silently fails because Plesk cannot update the _acme-challenge TXT record in your external DNS provider.
Why It Fails
Let's Encrypt requires a fresh DNS-01 challenge for every renewal. If Plesk does not have API access to your DNS zone, it cannot complete the challenge. The renewal job fails, logs an error in /var/log/plesk/panel.log, and sends an email that is easy to miss. The certificate eventually expires and HTTPS breaks across all subdomains simultaneously.
Fix Option 1: Install a Certbot DNS API Plugin
Example for Cloudflare:
pip3 install certbot-dns-cloudflare
mkdir -p /etc/letsencrypt/dns-credentials
cat > /etc/letsencrypt/dns-credentials/cloudflare.ini << 'EOF'
dns_cloudflare_api_token = YOUR_CLOUDFLARE_API_TOKEN
EOF
chmod 600 /etc/letsencrypt/dns-credentials/cloudflare.ini
# Test renewal
certbot renew --dns-cloudflare --dns-cloudflare-credentials /etc/letsencrypt/dns-credentials/cloudflare.ini --dry-runFor Route 53, use certbot-dns-route53; for GoDaddy, certbot-dns-godaddy.
Fix Option 2: Monitor and Renew Manually
Set a calendar reminder 30 days before expiry and reissue via the Plesk UI, manually updating the TXT record as you did during initial issuance. Simple but requires discipline.
Monitoring Renewal Health
grep -i "let.s encrypt\|certbot\|renewal" /var/log/plesk/panel.log | tail -50Set up an external SSL expiry monitor pointed at one of your subdomains, with an alert at 21 days remaining.
If managing this renewal pipeline sounds like work you would rather not own, a managed server management service can take over certificate lifecycle management entirely — issuance, renewal automation, expiry monitoring, and incident response.
FAQs
Can I use a Let's Encrypt wildcard certificate for all subdomains in Plesk?
Yes. A wildcard certificate issued for *.yourdomain.com covers all first-level subdomains. It does not cover the root domain or second-level subdomains, so include both *.yourdomain.com and yourdomain.com as SANs when requesting the certificate.
Why does my Let's Encrypt wildcard certificate fail to auto-renew in Plesk?
Wildcard renewal requires DNS-01 challenge validation. If your DNS is hosted externally, Plesk cannot create the required _acme-challenge TXT record automatically. Install a Certbot DNS API plugin for your provider or use a pre-renewal hook script to automate the TXT record update.
Does a wildcard SSL certificate cover the root domain?
*.yourdomain.com does not cover yourdomain.com. Always request both as SANs in the same certificate to protect the root domain and all subdomains with a single file.
How do I enable HSTS in Plesk?
Go to Websites & Domains → SSL/TLS Certificates → Advanced Settings, check Enable HTTP Strict Transport Security (HSTS), set max-age to 31536000, and enable Include subdomains. This injects the required header into Nginx's server block for the domain.
Is Let's Encrypt wildcard support free in Plesk?
Yes. The Let's Encrypt Plesk extension is free and wildcard issuance is included at no cost. The only hard requirement is DNS-01 challenge support, meaning you must control the DNS zone for the domain being certified.
A properly configured wildcard SSL certificate in Plesk eliminates an entire category of certificate-expiry incidents — one certificate, one renewal event, and uniform TLS protection across every subdomain. Done correctly, with HSTS enabled and TLS restricted to 1.2/1.3, you get an A+ on SSL Labs and the peace of mind that no subdomain will go dark due to a forgotten renewal. If any step in this process adds complexity — multi-server stacks, external DNS providers, or legacy TLS dependencies — CloudHouse's managed server management service can audit your current certificate posture and implement the full hardened configuration for you.