What Is a Wildcard SSL Certificate & How to Implement It [2 Methods]

Key Takeaways

• A wildcard SSL certificate secures your main domain and an unlimited number of its subdomains using a single cryptographic key.
• It eliminates repetitive administrative work by automatically protecting any new staging area or portal you build without requiring a new security file.
• Installing a wildcard manually requires running terminal commands and managing 90-day renewals, while Cloudways handles the verification and auto-renewals entirely in the background.

Growing a website almost always means adding subdomains. You set up a shop, a private portal, or a staging area to test things out. On their own, these separate sections are great. Put them all together, though, and securing them turns into a massive administrative headache.

Basic SSL files only lock down one specific address. That forces you to generate, upload, and track a completely separate security file for every new section you build. Forget just one renewal cycle, and your traffic drops because browsers actively block the connection.

This is exactly when site owners start asking about wildcard certificates to see if they actually fix the problem.

Below, we cover what wildcard SSL is and how it functions. We also show you how to set it up manually on a server, along with how the Cloudways Cloudflare Enterprise Add-on automates the whole process for you.

What is a Wildcard SSL Certificate and How Does It Work?

A wildcard certificate is a unique type of digital security file. It protects your main website and multiple subdomains simultaneously.

Normally, you have to verify and install a separate file for every single endpoint on your server. A wildcard ssl certificate bypasses that repetitive process entirely. It uses one cryptographic key to verify your entire first-level domain structure at once.

This changes how your server authenticates connections and significantly reduces your daily administrative workload.

To understand exactly how a wildcard ssl works, you need to look at two specific technical components. It relies on a special asterisk character for its naming structure and a hidden field called the Subject Alternative Name (SAN) to process the code.

Let’s look at how the asterisk handles the naming first.

Automate Your Wildcard SSL Renewals

Stop updating DNS records every 90 days. Host your application on Cloudways to automatically provision and renew Let’s Encrypt wildcard certificates entirely in the background.

Learn More

Securing Subdomains with the Asterisk (*) Character

Regular SSL files only work for one exact web address. Say you buy a certificate for blog.example.com. Putting that exact same file on shop.example.com will cause Chrome or Safari to block the site.

The browser sees the names are different and triggers an error.

A wildcard ssl certificate uses a clever workaround to fix this mismatch. It drops an asterisk right into the domain name so it reads as *.example.com. That star symbol acts as a catch-all.

It essentially forces the web browser to accept anything sitting right in front of your main domain.

You finally stop having to register every single new subdomain you create. One file protects your active staging server today and whatever new client portal you might build next month. You skip the extra server setup completely.

The Subject Alternative Name (SAN) Configuration

The asterisk handles the naming trick on the surface. However, the actual certificate file must process that star symbol through a specific piece of code. This happens in the Subject Alternative Name field.

Engineers usually just call it the SAN extension. Older security files only looked at a single line of code to verify a website. Modern web browsers demand a much more robust system to check multiple addresses at once.

When a provider creates a wildcard ssl certificate today, all the real configuration happens inside this SAN field. They program the extension to hold two completely different domain entries.

The first entry protects your bare root domain, like example.com. The second entry is the wildcard version written out as *.example.com.

Both entries are absolutely necessary. A web browser treats your bare domain and a subdomain as two completely different websites.

By placing the root name and the catch-all asterisk together in the SAN field, the file guarantees your entire network passes the security check simultaneously.

Comparing SSL Types: Single, Multi-Domain, and Wildcard

When you set up SSL, you usually have three main options to pick from. A wildcard certificate is great for saving time, but it isn’t the only way to lock down a site. Plenty of people still use standard single-domain files or try to bundle everything into a multi-domain setup.

To understand why a wildcard often wins out for growing sites, you need to see where the other two fall short. Let’s start by looking at how it stacks up against a basic single-domain certificate.

Single-Domain vs. Wildcard Certificates

A single-domain file does exactly what its name suggests. It protects one exact web address. If you secure example.com, the coverage stops there. Most Certificate Authorities will throw in the www version for free, but that is the absolute limit.

If you build shop.example.com later on, your original security file will not work. You have to buy a brand new certificate and install it from scratch.

This strict rule is perfectly fine for a basic personal blog. But for a growing site, managing individual files quickly becomes a nightmare. Here is exactly where the wildcard setup wins:

• Single-Domain: Requires a new purchase, a new validation, and a new server setup for every single subdomain you ever create.
• Wildcard: Secures your main site once. Any new subdomain you launch later gets automatic protection instantly without any extra work.

Multi-Domain (SAN) vs. Wildcard Certificates

Multi-domain certificates offer a slightly different approach. They let you bundle several different web addresses into one file. But the way they actually work is pretty strict.

When you buy one, you have to write out the exact name of every single address you want to protect right then and there. If you want it to cover example.com, blog.example.com, and a totally separate site like another-site.com, you must list all three before you checkout.

The Certificate Authority bakes those specific names into the code. This creates a massive headache if your site keeps growing:

• Multi-Domain files force you to go backward. If you spin up a new staging site next month, your current file will not cover it. You actually have to go back to the Certificate Authority, reissue the whole certificate with the new name tacked on, and upload it to your server all over again.
• Wildcard certificates keep you moving forward. Thanks to the asterisk, any new subdomain gets instant protection the moment it goes live. You never have to reissue the file or touch your server settings.

Multi-domain files make sense if you own completely different root websites and want to manage them together. But if you are just adding subdomains to one main brand, a wildcard saves you hours of repetitive work.

Installing a Wildcard SSL Certificate Manually on a Server

Getting the wildcard certificate is just the start. Actually putting it on your server is where you have to get your hands dirty. If your web host doesn’t handle security for you automatically, you have to run the installation yourself.

That means opening up your server’s command line.

For this walkthrough, we’ll use DigitalOcean VPS. Keep in mind, though, these exact same steps apply to almost any standard Linux server.

For the certificate itself, we will use Let’s Encrypt. It is a completely free option. To grab our wildcard file from them, we just need to run a basic command-line tool called Certbot.

Step 1: Install Certbot and Nginx on Your Server

First, log into your server as the root user. If you are following along on DigitalOcean, open the Launch Console from your dashboard.

You want to make sure your server has the latest package lists before you install anything. Type this command and hit Enter:

sudo apt update

Once that update finishes, install the Certbot program:

sudo apt install certbot

Next, install Nginx (the web server we will use to route our traffic):

sudo apt install nginx

Step 2: Initiate the Wildcard Request

With Certbot installed, you are ready to request the wildcard certificate.

Run the following command in your console. For this tutorial, we are using our own domain, but make sure you swap that out for your actual registered domain name:

sudo certbot certonly --manual --preferred-challenges=dns -d "*.yourdomain.com"

Note: The * acts as the wildcard, telling Let’s Encrypt you want to secure every possible subdomain under that root.

As soon as you hit Enter, Certbot will ask you for a few details before it can generate your security keys:

Email Address: Type your email and hit Enter.

Terms of Service: When it asks if you agree to the terms, type Y and hit Enter.

Data Sharing: It may ask if you want to share your email with the EFF. Type N (or Y) and hit Enter.

Step 3: Pass the DNS Challenge

Once your account is registered, Certbot generates the “DNS Challenge.” Because you are requesting a wildcard, you have to prove you actually control the entire domain by adding a specific record to your DNS settings.

The terminal will pause and output a message that looks like this:

Certbot gives you two crucial pieces of information:

• The Name: _acme-challenge.whichserversize.net
• The Value: A long string of random characters (e.g., Okh–KqT…).

Do not press Enter in your terminal yet. If you hit Enter before the record is live on the internet, the validation will fail and you will have to start over.

Instead, open a new browser tab and log into your domain registrar or DNS provider. For our example, the domain is managed through Cloudflare.

• From your Cloudflare dashboard, click on your domain.

• Click on DNS Records.

• Click the + Add record button.

• Change the Type dropdown to TXT.
• Paste the Name (_acme-challenge) and the Value exactly as they appear in your terminal.

• Click Save.

Step 4: Generate the Certificate Files

DNS changes usually take a minute or two to propagate across the web. Give it about 60 seconds, then go back to your DigitalOcean terminal and press Enter.

Certbot will reach out to the internet, find that TXT record, and verify your ownership. Once it passes, you will see a success message confirming your certificate is active.

The success message tells you exactly where your new files live (usually in a directory like /etc/letsencrypt/live/whichserversize.net/). Your server now officially holds the cryptographic keys needed to secure your main domain and any subdomains.

Step 5: Update Your Web Server Configuration

Getting the files on your server is great, but your website cannot use them yet. You have to tell your web server exactly where to find them and ensure it is listening for secure traffic.

Open your default Nginx configuration file in the terminal text editor:

sudo nano /etc/nginx/sites-available/default

Use your arrow keys to scroll down to the server { block and look for the # SSL configuration section. You need to do two things here:

1. Add your certificates: Paste these two lines right below the SSL configuration header:
ssl_certificate /etc/letsencrypt/live/whichserversize.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/whichserversize.net/privkey.pem;

2. Open Port 443: Right below where you pasted that, you will see two lines telling Nginx to listen for SSL traffic. They are “commented out” with a # symbol. Delete the # so they look like this:
listen 443 ssl default_server;
listen [::]:443 ssl default_server;

Press Ctrl+O and hit Enter to save, then press Ctrl+X to exit the editor.

Finally, test your configuration, open your firewall, and restart the server:

sudo nginx -t

If the test is successful, just restart Nginx (sudo systemctl restart nginx). Your wildcard certificate is now fully installed and protecting your network.

Step 6: Verify Your Wildcard SSL in the Browser

To verify if your wildcard certificate is working, we need to leave the terminal and head to our browser.

Because we installed a wildcard (*.whichserversize.net), we can now invent any subdomain we want, point it to our server’s IP address, and it will be secure instantly.

To test, we’ll:

• Go to the DNS settings in Cloudflare.
• Add an A Record.
• Set the Name to test (or any subdomain you want).
• Point it to your server’s IP address. We’ll point it to our DigitalOcean droplet’s IPV4. (Note: If using Cloudflare, toggle the Proxy status to “DNS only” / Grey Cloud so you can see the Let’s Encrypt certificate directly).

• We’ll now go to https://test.whichserversize.net. And since we can see that secure padlock icon next to our URL, congratulations, this means our manual wildcard SSL setup is 100% complete.

Automating Wildcard SSL Installation with Cloudways

While the manual method gets the job done, it has a massive hidden catch: manual wildcard certificates do not auto-renew.

Every 90 days, you must log into your server, run Certbot, update your Cloudflare DNS, and restart Nginx. If you miss that window, every subdomain you own will instantly display a “Not Secure” warning to your visitors.

Managing server infrastructure every three months is a huge headache.

At Cloudways, we replace that complex terminal process with a simple dashboard. We handle the Let’s Encrypt validation, configure your server, and automate those 90-day renewals completely in the background.

Here is how to deploy a wildcard SSL on your Cloudways server in just a few clicks.

Step 1: Navigate to SSL Management

Log into your Cloudways account and open the application where your website is hosted.

On the left sidebar, click on SSL Certificate.

Step 2: Request the Wildcard Certificate

We integrate directly with Let’s Encrypt to provide free certificates right from the dashboard.

• Ensure Let’s Encrypt is selected from the dropdown menu.
• Enter your email address.
• Enter your domain name with the wildcard prefix (e.g., *.whichserversize.net).
• Check the box that says Apply Wildcard.

Stop right there and do not click any buttons yet. Right below the checkbox, the screen displays the exact CNAME record you need to configure your DNS. It gives you the Name (_acme-challenge) and the specific Target URL (your Cloudways app URL). Leave this browser tab open.

Step 3: Add the CNAME Record to Cloudflare

Now, switch over to your domain provider to add that CNAME record to your DNS settings. We’re using Cloudflare.

• Open your Cloudflare dashboard and go to your DNS Records.
• Add a new CNAME record.
• Set the Name to _acme-challenge.
• Paste the Target URL provided on your Cloudways screen into the Value/Target field.
• Crucial: If you are using Cloudflare, make sure the Proxy status is set to “DNS only” (Grey Cloud) for this specific record.
• Click Save.

Why a CNAME?

By pointing this record to Cloudways permanently, you give our servers permission to answer the Let’s Encrypt DNS challenge. This allows us to auto-renew your wildcard certificate entirely in the background.

Step 4: Verify DNS and Finish Installation

Go back to your Cloudways dashboard. Give the DNS about 60 seconds to propagate, then click the Verify DNS button.

Once the DNS is verified, you will see a success notification pop up in the top right corner. You will also notice that the Install Certificate button is now blue and active.

Click Install Certificate.

Behind the scenes, we instantly communicate with Let’s Encrypt, download your cryptographic keys, and configure your server automatically.

Once the installation finishes, the dashboard will update to show your active certificate and its upcoming expiry date. Most importantly, you will see the Auto Renewal toggle is enabled by default.

As long as you leave that CNAME record in your DNS settings, your main domain and all current or future subdomains remain completely secure, and you never have to manually renew the certificate again.

Offloading Wildcard SSL to the Edge with Cloudflare Enterprise

The Let’s Encrypt method above automates wildcard SSLs directly on your origin server. As your subdomains generate more traffic, handling every secure connection locally consumes your server’s resources.

If you are running business-critical subdomains, you can offload this work entirely using the Cloudways Cloudflare Enterprise Add-on.

Instead of processing SSL handshakes locally, the add-on deploys an enterprise-grade wildcard SSL at the network edge. This secures your subdomains closer to your users, making connections faster and reducing the processing load on your origin server.

Beyond just wildcard SSL, the add-on instantly applies an Enterprise Web Application Firewall (WAF), global image optimization, and rate limiting to protect your bandwidth from malicious scrapers.

It also utilizes Argo Smart Routing to route your traffic across the fastest paths available, while providing advanced mitigation against various types of DDoS attacks to keep your entire network online.

Going directly to Cloudflare for these enterprise features requires a custom annual contract that typically costs thousands of dollars a month.

Thanks to our integration, you get access to this infrastructure at a fraction of the standard Cloudflare Enterprise pricing, starting at just $4.99 per domain per month directly from your Cloudways dashboard.

Note: We have a detailed guide that walks you through the complete steps of enabling Cloudflare Enterprise addon on Cloudways.

Offload SSL Processing to the Network Edge

Stop wasting server resources on local SSL handshakes. Route your subdomains through the Cloudways Cloudflare Enterprise Add-on for edge encryption, advanced WAF, and DDoS mitigation.

Learn More

Wrapping Up!

Securing a growing website doesn’t have to mean managing a massive spreadsheet of SSL certificates. By using a wildcard certificate, you can protect your root domain and an unlimited number of subdomains with a single cryptographic key.

While you can install Let’s Encrypt certificates manually on a VPS, the 90-day renewal cycle quickly becomes a repetitive administrative burden. Forgetting to update a DNS TXT record means instant “Not Secure” warnings across your entire network.

By hosting your application on Cloudways, you eliminate that risk entirely. Our platform handles the DNS verification, configures the server, and automates your wildcard renewals in the background. You get enterprise-grade security for your entire network without ever having to touch a command line.