What Is a Wildcard SSL Certificate and How Do You Install It?

What is a wildcard SSL certificate?

A wildcard SSL certificate is a single certificate that secures a domain and all of its first-level subdomains, written as *.example.com. The asterisk stands in for exactly one label. So shop.example.com and blog.example.com share one certificate, but you still have to add the bare domain separately.

We are a digital marketing and web team, not a hosting company. For that reason, we based the technical parts on official documentation and standards. We link every source in the text, so you can verify each step yourself.

Also, we will not explain what SSL is again here. For the basics, read our SSL certificate and HTTPS guide. This article covers only what a wildcard SSL certificate covers, how DNS validation works, how installation flows, and where the limits sit. We also say in each section which jobs you can do yourself and which ones belong with your hosting provider.

Which addresses does a wildcard SSL certificate actually cover?

The standards are clear on this, so there is little room for guessing. RFC 9525 says the wildcard character may appear only as the complete left-most label. It also says a wildcard can match only one label. In practice, the coverage is narrower than most people expect.

A *.example.com certificate secures these addresses:

• www.example.com, because the single label "www" replaces the asterisk.
• Every first-level subdomain, such as shop.example.com or blog.example.com.
• Subdomains you have not created yet but will open later.

The same certificate does not secure these addresses:

• example.com itself, the bare apex domain, because there is no label to match.
• Two-level names such as a.b.example.com, because the asterisk covers only one label.
• A different domain such as example.net.

In practice, you request both example.com and *.example.com. That way the apex domain and every first-level subdomain sit in one file. RFC 9525 also notes that this behavior deliberately differs from wildcard records in DNS. In other words, you cannot carry the scope of a DNS wildcard record over to a certificate one to one.

How does a wildcard SSL certificate differ from single-domain and SAN certificates?

The difference comes down to which names you bundle into one certificate. First, the table below puts the three models side by side. If your subdomain count changes often, the table makes the choice easier.

However, one detail matters here. A wildcard certificate also carries "*.example.com" in the SAN field, technically speaking. So the models do not exclude each other. One certificate can list example.com and *.example.com, and you can even add other domains.

In practice, we use a simple rule of thumb. If your names are few and stable, a SAN certificate is enough. If they are many or volatile, a wildcard is easier to manage. However, if one address is sensitive, put it on its own certificate under either model.

When do you actually need a wildcard SSL certificate?

However, not every site needs one. First, look at how many subdomains you run and how fast they change. For a handful of fixed addresses, a single-domain or SAN certificate is usually simpler and safer.

A wildcard SSL certificate makes sense in these cases:

• You run a software product that opens a separate subdomain for each customer or tenant.
• You create new subdomains often for test, staging, and production environments.
• You manage many campaign or regional subdomains from one place.
• Tracking renewals per subdomain puts a burden on your team.

For example, if a store, a blog, and a support desk live on separate subdomains, a wildcard bundles the work. But if you only have three fixed addresses, three separate certificates strike a better balance than one shared key. Also, we cover the risks in later sections.

There is also a marketing angle. If you publish campaign pages on subdomains, waiting for a certificate for each new address slows every launch. In that case, a wildcard shortens the wait. Still, do not choose it for speed alone.

Is a free wildcard SSL certificate different from a paid one?

Put simply, browsers do not care whether a certificate was free or paid. They look at the chain, the coverage, the expiry date, and whether the name matches. So for a domain-validated (DV) wildcard certificate, do not expect a visible difference on the visitor side.

The difference sits mostly around the certificate. Paid providers usually offer support, warranty terms, and a management panel. With a free option, renewal and monitoring are your job. Prices and lifetimes vary by provider, so we give no figures here. Read current terms on the provider's own page.

• With a technical team that can set up automation, a free option is enough.
• To hand outage responsibility to someone else, a supported product feels safer.
• Where your host offers wildcard through AutoSSL, you may not need to pay separately.

So think about total cost when you decide. The certificate fee may be a small item, but an outage after a failed renewal costs far more. So ask "who is responsible?" together with "is it free?".

Why does wildcard SSL validation work only through DNS?

Before a certificate authority approves a wildcard name, it wants proof that you control the domain. The Let's Encrypt FAQ states that wildcard issuance must use the DNS-01 challenge. Put simply, placing a file on a web server does not work for this job.

In a DNS-01 challenge, your client creates a TXT record derived from a token and your account key. You publish it at _acme-challenge.example.com. The certificate authority then reads the record from DNS and completes validation. This matches the Let's Encrypt challenge types page.

So the first question for a wildcard SSL certificate is not "is my server ready?" but "who controls DNS, and how?" If DNS sits with another company, the process depends on that company's permission and API.

However, DNS changes can take time to become visible. The Let's Encrypt page lists propagation delay as a drawback. Therefore, do not continue right after adding the TXT record. Look it up with a query tool first, then start validation. Moreover, remove stale _acme-challenge records, because an old value can collide with the new one.

What should you prepare before you start the installation?

First, settle four things before you run any command. In a wildcard SSL project, the most common snag is not technical but about permissions. Who manages the domain, where does DNS live, and who can reach the server?

1. First, confirm that you have access to the domain's DNS management.
2. Then find out whether your DNS provider offers an API.
3. Also list every server that will use the certificate.
4. Finally, decide who receives the alert when renewal fails.

Also save your current DNS records somewhere safe. A DNS lookup tool shows them quickly. Our website backup strategy guide gives you a frame for storing them. A small mistake during a DNS change can break access to your whole site.

Also, pay attention to one more point. If your domain has a CAA record, that record decides which certificate authorities may issue certificates. A separate issuewild tag exists for wildcard names. So if the record does not allow your chosen authority, issuance fails even when validation passes.

How do you get a wildcard SSL certificate from Let's Encrypt step by step?

If you have a VPS or server with root access, Certbot is the most common route. First, install Certbot. Follow the official page (certbot.eff.org) for current instructions, because the method differs by distribution.

The Certbot user guide says DNS validation is the only way to obtain wildcard certificates from Let's Encrypt. Its manual example prefers the DNS challenge. Hook-based automation looks like this:

certbot certonly --manual --preferred-challenges=dns \
  --manual-auth-hook /path/to/dns/authenticator.sh \
  --manual-cleanup-hook /path/to/dns/cleanup.sh \
  -d example.com -d "*.example.com"

If you give no hooks, Certbot asks you to add the TXT record by hand. The flow then goes like this:

1. Certbot shows a TXT value on screen.
2. Next, you create a TXT record named _acme-challenge with that value in your DNS panel.
3. After the record propagates, you continue in Certbot.
4. If validation passes, the certificate files appear.

Do not continue before the record propagates. Check with a DNS lookup or the command line that the TXT record is visible. Otherwise, validation fails. The manual flow suits one-off tests, but you would repeat it every 90 days.

How do you automate wildcard SSL renewal with a DNS API?

The default lifetime of a Let's Encrypt certificate is 90 days, as its FAQ states. So manual renewal does not scale. For automation, you use the Certbot plugin for your DNS provider. Plugins exist for Cloudflare, DigitalOcean, Google, and Route 53, according to the Certbot guide.

The certbot-dns-cloudflare documentation recommends a restricted API token for Cloudflare. In addition, the token carries DNS edit permission for the relevant zone only. Here is how the credentials file looks:

dns_cloudflare_api_token = PUT_YOUR_TOKEN_HERE

Restrict the file's permissions. For that purpose, the documentation shows chmod 600. Anyone who can read the file can make API calls on your behalf. The wildcard command then looks like this:

certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/certbot/cloudflare.ini \
  -d example.com \
  -d "*.example.com"

For renewal, the Certbot guide gives the certbot renew command. You schedule it with cron or a systemd timer. To test first, you can run certbot renew --dry-run. If you use another DNS provider, follow that plugin's documentation in the same order.

How do you connect a wildcard SSL certificate to Nginx and Apache?

By default, Certbot writes the certificate files to /etc/letsencrypt/live/example.com/. There you find fullchain.pem and privkey.pem. In the web server configuration, you only need to point to those two files.

Here is an example Nginx server block:

server {
    listen 443 ssl;
    server_name example.com *.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

Apache follows the same logic. You put the full chain in the SSLCertificateFile line and the private key in the SSLCertificateKeyFile line. Then you test the configuration and reload the service.

After renewal, the server has to read the new file. You can attach your reload command with Certbot's --deploy-hook option. If several servers will share the certificate, move the private key with care. Every copy of the key is another point of risk. For that reason, consider renewing the certificate separately on each server.

How do you install a wildcard SSL certificate in cPanel?

On shared hosting, your provider decides most of this. According to the cPanel SSL guide, a wildcard certificate secures subdomains that share an IP address with one certificate. However, it does not secure the example.com domain itself.

The same guide says the Let's Encrypt provider secures wildcard domains. AutoSSL, on the other hand, includes only the domains that pass domain control validation (DCV). So everything depends on your provider's AutoSSL setup.

If you already hold a wildcard certificate, the general flow looks like this:

1. Open the SSL/TLS interface in cPanel.
2. Go to the "Install and Manage SSL for your site (HTTPS)" section.
3. Paste the certificate, the private key, and the CA bundle if you have one into the matching fields.
4. Pick the domain that will use the certificate and finish the installation.

Menu names can differ by cPanel version and by your provider's settings. Also, according to the cPanel documentation, you cannot buy a wildcard certificate in the Advanced interface. You use the Simple interface for purchases. If you get stuck, writing to your provider's support team is the fastest fix.

How do you verify a wildcard SSL installation?

After installation, check three things: which names the certificate carries, its expiry date, and whether the chain is complete. For a quick check, an SSL checker does the job. If you prefer the command line, you can list the names in the certificate with openssl.

openssl s_client -connect shop.example.com:443 -servername shop.example.com </dev/null | openssl x509 -noout -ext subjectAltName -dates

The output should show example.com and *.example.com. Then open several subdomains in a browser and check the lock icon. Test each subdomain separately, because some of them may run on a different server.

Test automatic renewal too. The certbot certificates command lists the certificates you hold and their expiry dates. If a renewal attempt fails, the error message usually points to the DNS record or the API permission. Run this check right after installation, and repeat it at regular intervals.

Why does wildcard SSL not work for multi-level subdomains?

This is the most misunderstood limit. A *.example.com certificate secures api.example.com but not v1.api.example.com. RFC 9525 says the asterisk can match only one label. As a result, a second-level address shows a certificate error in the browser.

You have three options:

• Get a separate wildcard certificate named *.api.example.com for the second level.
• Add those addresses to the certificate one by one as SANs.
• Flatten your address structure to one level, for example v1-api.example.com.

Review your domain plan before you decide on the structure. Our guide to choosing a domain name helps with that planning. If your product opens nested subdomains per customer, building the right hierarchy at the start costs less than a fix later.

What are the risks of a wildcard SSL certificate?

The biggest risk of a wildcard SSL certificate is the single key. The same private key sits on many subdomains and often on several servers. If it leaks, an attacker holds a valid certificate for every subdomain in scope.

The Let's Encrypt documentation lists the risk of storing API credentials on web servers among the drawbacks of DNS-01. It also notes that not every DNS provider offers the API you need. These two points are a real cost to weigh before you build automation.

How can you reduce the risks of a wildcard certificate?

You cannot remove the risk, but you can manage it. First, keep the key in as few places as possible. Second, narrow the DNS permission. Finally, keep critical addresses outside the wildcard.

• Limit the API token to the relevant DNS zone and to DNS edit permission only.
• Store the credentials file with permissions that only the required user can read.
• Give sensitive subdomains, such as payments, admin panels, and customer data, their own certificate.
• Do not copy the wildcard key to development and test servers.
• Set up an independent monitor or calendar alert for the expiry date.

You can also delegate DNS validation to another zone. According to the Let's Encrypt documentation, you can use CNAME or NS records to delegate the challenge to a different DNS zone. That way, you avoid giving your main zone's API permission to the server. This approach needs careful setup, so we suggest getting expert help.

Which mistakes do people make when they set up a wildcard SSL certificate?

Most problems come from the same five places. Knowing them helps you find the cause in minutes. So read the list once before you start.

1. Forgetting to add the apex domain to the certificate. As a result, example.com shows an error.
2. Starting validation before the TXT record propagates.
3. Adding the _acme-challenge record under the wrong name. For example, it ends up as example.com.example.com.
4. Giving the API token the wrong zone or too little permission.
5. Skipping the web server reload after renewal.

The fifth item is especially sneaky. Certbot writes the new file, but the running server may keep the old certificate in memory. So add a reload step to your automation. Search for error messages in the Certbot log and in the web server log.

There is also a management mistake: nobody owns the certificate. When the person who set it up leaves the company, renewal quietly stops. For that reason, name an owner and a backup owner in writing.

How do you monitor the expiry date of a wildcard SSL certificate?

Automatic renewal alone is not enough, because automation breaks too. A DNS token can expire, a record can change, or a timer can stop. So watch the expiry date through an independent path.

• Run certbot certificates on the server at regular intervals to see expiry dates.
• For an outside view, use an SSL checker together with a calendar reminder.
• Ship the renewal log somewhere, so errors do not stay silent.
• Send the near-expiry alert to at least two people.

Also monitor per subdomain. A subdomain may run on another server with an old certificate. Even though a wildcard is one certificate, each server renews its own copy. Therefore, a "certificate renewed" message does not mean "every address renewed".

What should you watch when you move a wildcard SSL certificate to a new server or host?

When you migrate, you have two options: copy the same certificate or issue a new one on the new server. Copying is fast, but the private key travels to a new place. Issuing a new one takes a little time, yet the key stays only where you use it.

1. List which subdomains will run on the old and on the new server.
2. Prepare the certificate on the new server before you change DNS records.
3. After the switch, test every subdomain in a browser and with a checker.
4. Delete the key copies on the old server in a safe way.

You may also want a backup while you move. However, a backup of the private key is far more sensitive than the certificate itself. So store the key only in an encrypted place with limited access. Our website backup strategy guide is a good starting point for the backup routine.

Why are forgotten subdomains dangerous when you use wildcard SSL?

A wildcard certificate also covers subdomains that do not exist yet. So a forgotten DNS record, meaning a subdomain that points to a service you no longer use, creates a separate risk. If someone else takes over that service, they can serve a page on your address that looks valid under your certificate.

The certificate itself is not at fault here. However, a wildcard widens the trust scope, so the result grows. Therefore, think about the certificate decision together with a DNS cleanup.

• Review the records in your DNS zone at regular intervals.
• Delete CNAME records that point to services you no longer use.
• When you open a new subdomain, write down the record and its owner.
• Remove test environment addresses from DNS when the work ends.

For the wider web security picture, our OWASP Top 10 article is a good reference point. You can also review your records by hand with a DNS lookup.

Which checklist should you run after the installation?

The work does not end when the install finishes. A small checklist reduces surprises months later. Keep it in writing and share it with your team.

1. Does the certificate carry both example.com and *.example.com?
2. Does every critical subdomain open in the browser without a warning?
3. Did the dry run for automatic renewal succeed?
4. Does the web server load the new file after renewal?
5. Does the API token hold only the permission it needs?
6. Is an independent alert set for the expiry date?
7. Is it written down who owns the certificate and the key?

Run this list again after every major DNS or server change. For example, when you switch hosts or open a new group of subdomains, the list matters again.

When should you not install wildcard SSL yourself and leave it to your hosting provider?

Let us be honest: you do not have to do everything yourself. In some cases, leaving it to your provider is both safer and cheaper. We do not run hosting, so we can describe this choice without a stake in it.

Leave the job to your provider in these cases:

• You are on shared hosting and have no root access on the server.
• Your DNS records sit with another company and you cannot get API access.
• The command line is unfamiliar to you and one mistake could take your site down.
• You run a store that takes payments and cannot carry the risk of an outage.
• You work in a corporate or regulated setup that needs a policy for key management.

In that case, ask your provider: "Do you offer wildcard certificates through AutoSSL, and who watches renewal?" Our guide to choosing web hosting also collects questions to ask when you pick a provider. For the security side, the OWASP Top 10 article gives the general frame.

In what order should you decide on wildcard SSL?

The order is simple. First question the need, then weigh the risk, and only then pick the tool. For most businesses, the right answer is a mix: separate certificates for fixed addresses and a wildcard for changing ones.

1. How many subdomains do you have, and how often do they change?
2. Must sensitive services share the same certificate?
3. Does your DNS provider support validation through an API?
4. Who will watch renewal, and who gets the alert when it fails?
5. Should your provider manage the certificate, or should you?

A certificate decision is not a marketing job on its own, but it ties closely to your site's trust and speed. When HTTPS breaks, visitors see a browser warning, and paid and organic traffic go to waste. Our notes on how site speed affects SEO and SEO consulting explain that link. If you plan a new site, we can settle these infrastructure choices together within our web design service.