DEV Community: Alice Martin

How to Secure Multi-Level Subdomains Using a Wildcard SSL Certificate

Alice Martin — Fri, 16 May 2025 12:46:36 +0000

In today’s web environment, securing your site with HTTPS is a must not just for data protection, but for user trust and SEO credibility. If your site architecture includes multiple subdomains, especially those with more than one level (like dev.blog.example.com), figuring out the right SSL setup can get complicated.

Wildcard SSL certificates are often the first solution people turn to for subdomain coverage. They simplify certificate management and reduce costs, but they’re not a one-size-fits-all answer. When your domain structure starts getting deeper to multi-level, you need a more strategic approach.

What Is a Wildcard SSL Certificate?

A wildcard SSL certificate allows you to secure a main domain and all its subdomains with a single certificate. Instead of managing separate certs for blog.example.com, shop.example.com, and mail.example.com, a wildcard certificate for *.example.com secures them all in one go.

The wildcard symbol (*) acts as a placeholder for any first-level subdomain, making these certificates a great option for dynamic projects or businesses expecting growth. You save time and effort by only installing, renewing, and monitoring one certificate.

Understanding Domain and Subdomain Levels

Before diving deeper, let’s clarify what we mean by domain levels:

Primary Domain: example.com
First-Level Subdomain: shop.example.com
Second-Level Subdomain: secure.shop.example.com
Third-Level Subdomain: api.secure.shop.example.com

A wildcard certificate for *.example.com will secure first-level subdomains only. It won’t extend to deeper structures like secure.shop.example.com or dev.blog.example.com.

Why Wildcard Certificates Fall Short for Multi-Level Subdomains

Here’s the catch: wildcard SSL certificates can only secure one level of subdomains. You can’t get a certificate that secures *.*.example.com - Certificate Authorities (CAs) won’t issue them. This restriction exists for security reasons, as it would be nearly impossible to validate ownership and intent for such wide-ranging domain coverage.

For example:

✅ *.example.com covers shop.example.com

❌ It does not cover login.shop.example.com or analytics.blog.example.com

If your site includes multi-level subdomains, you’ll need to adopt a smarter SSL strategy.

Strategy 1: Use Separate Wildcard Certificates for Each Subdomain Group

One straightforward solution is to issue a wildcard certificate for each subdomain branch that requires it. For instance:

A wildcard for *.blog.example.com will secure media.blog.example.com, dev.blog.example.com
A wildcard for *.shop.example.com will cover login.shop.example.com, secure.shop.example.com

This strategy works well when you have clear groupings of services or regions under different subdomains. The downside? You’ll be managing multiple certificates, which means more tracking, more renewals, and potentially more headaches.

Still, this approach offers clarity and modular control, especially helpful in organizations where different teams or departments manage their own environments.

Strategy 2: Leverage Multi-Domain Wildcard SSL Certificates

For more complex infrastructures, a Multi-Domain Wildcard SSL Certificate (also called a SAN + Wildcard certificate) offers a scalable and centralized alternative. These certificates allow you to list multiple wildcard entries under one certificate using Subject Alternative Names (SANs).

With a single Multi-Domain Wildcard cert, you can secure:

*.example.com
*.blog.example.com
*.shop.example.com
*.dev.shop.example.com

This makes it easier to manage certificates across large projects with distributed or layered subdomain structures, such as SaaS platforms or enterprise-level websites.

You might come across the term "double wildcard SSL" referring to certificates that would hypothetically cover *.*.example.com. In practice, this doesn’t exist. CAs do not issue double wildcard certificates due to the risks and complexities involved in validation. However, you can mimic this functionality by combining multiple SAN-based wildcard entries in a Multi-Domain Wildcard certificate.

Best Practices for Securing Multi-Level Subdomains

To build a reliable SSL strategy, keep these tips in mind:

- Audit Your Domain Structure
Before purchasing any certificate, map out all your subdomains. This ensures you’re not leaving anything unprotected and helps avoid overpaying for unnecessary coverage.

- Avoid Key Reuse Across Servers
While it’s tempting to use the same wildcard certificate across servers, sharing a private key increases security risks. Use secure key management practices to isolate and protect your certs.

- Stay on Top of Expirations
An expired SSL certificate can bring down an entire site. Set calendar reminders or use automation tools to track expiry dates.

- Be Cautious with Certificate Pinning
Pinning can add security but also complexity, especially if you’re rotating wildcard or SAN certificates. If not handled carefully, pinning can cause issues during certificate renewal or provider changes.

- Work With Trusted Certificate Authorities
Use well-established CAs with strong customer support and wide browser compatibility. This ensures smooth issuance and fewer compatibility issues.

Debunking Common Myths of Wildcard Certificates

Let’s clear up a few misunderstandings:

“One wildcard cert secures everything.” Not quite. It only covers one level of subdomains.
“I can get a *.*.example.com certificate.” You can’t. CAs won’t issue these.
“Wildcard certs are inherently insecure.” Not true. They’re only risky if private keys are poorly managed.

Final Thoughts

Wildcard SSL certificates are a powerful tool for securing first-level subdomains with minimal hassle. But when your domain structure goes deeper, relying on a single wildcard cert isn’t enough.

For simpler setups, a standard wildcard certificate does the job. But as your architecture becomes more complex like in multi-regional sites or platforms with deep service layers, you’ll need to scale your approach. That could mean managing multiple wildcard certificates or opting for a Multi-Domain Wildcard SSL certificate to keep things consolidated and secure.

Plan ahead, choose your certificates wisely, and you’ll have a setup that’s both secure and sustainable.

Also Read: Top 5 Best Cheapest Wildcard SSL Certificate Providers of 2025

How to Fix ERR_HTTP2_PROTOCOL_ERROR After Enabling HTTPS

Alice Martin — Fri, 09 May 2025 11:58:41 +0000

Transferring your website onto HTTPS is a wise decision because it leads to better security as well as increased SEO and user trust. However, after enabling HTTPS, you might run into a frustrating message in your browser: ERR_HTTP2_PROTOCOL_ERROR. This error is usually accompanied by little context, and you wonder what you did wrong.

In this guide, we’ll break down what causes this error, why it may appear after enabling HTTPS, and how to fix it step by step.

What is ERR_HTTP2_PROTOCOL_ERROR?

ERR_HTTP2_PROTOCOL_ERROR is a browser-side error that occurs when there’s a failure in communication between the web browser and the server using the HTTP/2 protocol. HTTP/2 is the modern version of HTTP, designed to make web pages load faster and more efficiently using features like multiplexing and header compression.

When this error pops up, it typically means that either:

The server is sending malformed or unexpected data, or
The browser is misinterpreting the data due to software bugs or cache conflicts.

Why Does This Error Appear After Enabling HTTPS?

If you’ve recently added an SSL certificate and enforced HTTPS, this error could be triggered by several factors:

1. Improper SSL Configuration
Misconfigured SSL settings can interfere with how the server communicates over HTTP/2.

2. Unsupported or Misconfigured HTTP/2 Module
Not all servers support HTTP/2 by default. If HTTP/2 is not enabled or is incorrectly set up, this error may occur when attempting a secure connection.

3. Conflicting Middleware (e.g., CDN, Proxy, Firewall)
Services like Cloudflare or reverse proxies can sometimes conflict with your server’s HTTPS and HTTP/2 settings.

4. Outdated Browser or OS
If the client (browser) isn’t fully compatible with HTTP/2 or has corrupted cache data, it can misinterpret legitimate responses as protocol errors.

How to Fix ERR_HTTP2_PROTOCOL_ERROR – Step-by-Step

Let’s walk through the most effective solutions to resolve this error after enabling HTTPS.

1. Check SSL Certificate Validity and Configuration

Since this error appears after HTTPS is enabled, start by verifying your SSL certificate.

Use an SSL Checker Tool (like SSL Labs or a browser extension)

Check if the certificate is valid, properly chained, and not expired.
Look for any warning related to intermediate certificate mismatches.

Ensure HTTPS Redirection is Properly Set

Redirect all HTTP traffic to HTTPS via .htaccess (Apache) or server block (Nginx) without causing loops or conflicts.

Apache Example:

apache

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Nginx Example:

nginx

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

2. Confirm HTTP/2 is Enabled on Your Server

Enabling HTTPS doesn’t automatically mean HTTP/2 is active. You need to confirm HTTP/2 support and enable it explicitly.

On Apache:
Make sure the mod_http2 module is enabled:

a2enmod http2

Then add this directive to your SSL-enabled VirtualHost block:

apache

Protocols h2 http/1.1

Restart Apache:

bash

sudo systemctl restart apache2

On Nginx:

Ensure your server block looks like this:

nginx

listen 443 ssl http2;

And that Nginx was compiled with HTTP/2 support (you can verify using nginx -V).

3. Clear Browser Cache and Cookies

Sometimes, after switching to HTTPS and HTTP/2, the browser still holds old cache data, leading to protocol conflicts.

To clear cache in Chrome:

Go to Settings > Privacy and Security > Clear browsing data
Select “Cached images and files” and “Cookies”
Hit “Clear data”

Afterward, reload the page or open it in an incognito window to test.

4. Disable Browser Extensions and Try Incognito Mode

Certain browser extensions (especially those that intercept or filter HTTPS traffic like ad blockers or antivirus extensions) may misinterpret or block parts of the HTTP/2 response.

Disable all extensions temporarily
Visit the site in Incognito Mode using Ctrl + Shift + N
If the error disappears, re-enable extensions one by one to identify the culprit

5. Temporarily Disable Firewall or Antivirus

Some aggressive firewall or antivirus software can interfere with HTTP/2 connections over HTTPS. They may block packets they misidentify as suspicious, even when they are perfectly valid.

To test:

Temporarily disable your antivirus or firewall
Reload the site in the browser

If the error goes away, consider adding your site to the software's exception list.

6. Update Your Browser and Operating System

Outdated browsers may lack full HTTP/2 support or contain unresolved bugs related to HTTPS. The same goes for your operating system's network stack.

Update your browser to the latest version
On Windows, go to Settings > Windows Update
On Mac, go to System Preferences > Software Update

7. Inspect the Network Layer (For Advanced Users)

If you have access to server logs or tools like Chrome DevTools or Wireshark, look for unusual behavior:

Use Chrome DevTools (F12 > Network tab) to monitor failed requests and HTTP response headers
Check if the status code is 502, 503, or if you see frame-level errors (like RST_STREAM)

If you’re using Cloudflare, try:

Disabling HTTP/2 on Cloudflare temporarily
Bypassing Cloudflare by pointing your domain directly to your origin server for testing

Bonus Tip: Fallback to HTTP/1.1 (Temporarily)

If HTTP/2 errors persist and you need the site up immediately, consider falling back to HTTP/1.1 while debugging.

In Apache:

apache

Protocols http/1.1

In Nginx:
Remove http2 from the listen directive.

Note: This is just a temporary solution and should be reversed once HTTP/2 issues are resolved.

Conclusion

Encountering the ERR_HTTP2_PROTOCOL_ERROR after enabling HTTPS can be frustrating, but it's usually solvable with a structured approach. For the most part it’s caused by SSL misconfiguration, incompatible browser extensions or HTTP/2 not working properly on your server.

First things first, check your SSL certificate, confirm the proper configuration of HTTP/2, then clean your browser’s cache, eliminate any client-side hitches. Following these steps, you can be sure to fix the issue and serve your users a secure fast-loading website.

Also Read: How to Fix ERR_SSL_BAD_Record_MAC_Alert: Common Causes & Solutions

SSL Certificate for Subdomains: How to Get One for Your Website

Alice Martin — Wed, 30 Apr 2025 13:13:45 +0000

Most people understand the need to secure their main website with SSL. But what about the subdomains — the blog, the store, the dashboard? If those parts of your site aren’t protected, you’re leaving the door wide open for security risks.

Securing subdomains is just as important as protecting your root domain, especially if they handle sensitive data like logins or transactions. Fortunately, you don’t need a separate certificate for each one. In this guide, we’ll break down how to get an SSL certificate for subdomains, explore the different types available (including wildcard options), and help you avoid common mistakes.

Why SSL Matters Especially for Subdomains?

SSL (or more accurately, TLS — but most people still say SSL) encrypts the connection between your website and your visitors. It prevents data from being intercepted by hackers and gives users that familiar padlock icon in the browser bar.

If your site uses subdomains like shop.example.com, login.example.com, or blog.example.com, each of those acts as its own “mini-site.” And just like your main domain, they can be targeted by attackers.

Without SSL:

Users may see “Not Secure” warnings
Search engines may rank you lower
Sensitive data could be exposed

Long story short: SSL is just as important for subdomains as it is for your main site.

Types of SSL Certificates for Securing Subdomains

When it comes to protecting subdomains, there are a few SSL options. Here’s a simple breakdown:

1. Wildcard SSL Certificate

A wildcard SSL certificate is the go-to for most websites with multiple subdomains. It secures one domain and all its first-level subdomains, anything like *.example.com. So with one certificate, you can secure:

example.com
blog.example.com
shop.example.com
login.example.com

Best for: Websites with several subdomains under the same root
Bonus: Easy to manage, cost-effective
Note: Wildcard SSL does not cover second-level and third-level subdomains.

2. Multi-Domain SSL (SAN Certificate)

This type can secure multiple domains and subdomains, like:

example.com
store.example.com
example2.com
mail.example2.com You list each one individually, so it’s super flexible.

Best for: Businesses with several sites and subdomains
Drawback: Slightly more expensive and technical

3. Individual Certificates

This method means you get a separate SSL certificate for each subdomain. For example, one for example.com, another for blog.example.com, maybe one for shop.example.com—each one handled on its own.

It gives you more control over how each part of your site is secured, which can be handy if you’ve got different teams or tools managing different subdomains. That said, it can also turn into a bit of a chore. You’ll have to install and renew each certificate separately, and that can add up fast if you’ve got a bunch of them.

Best for: Complex setups where different subdomains need unique certificates (e.g., separate dev teams or services).
Drawback: Not scalable for sites with many subdomains can get time-consuming.

4. Multi-Domain Wildcard SSL Certificates

If your setup includes multiple domains, and each of those domains also has its own set of subdomains, then a Multi-Domain Wildcard SSL certificate is the way to go. It’s designed for more complex environments where a standard wildcard or single SAN certificate just isn’t enough. It covers multiple-level subdomains within single SSL.

Let’s break it down with an example:

*.example1.com would cover things like blog.example1.com, shop.example1.com, or mail.example1.com.

If you also need to secure something deeper (second-level or third-level subdomains), like tech.blog.example1.com, you’d use a wildcard for *.blog.example1.com.

Now let’s say you also own example2.com, and want to secure payment.example2.com or support.example2.com — you’d include *.example2.com in the same certificate.

Best for: Businesses or agencies juggling multiple projects, brands, or platforms under different domains.

What to consider: These certificates are powerful, but they’re also more expensive and might be overkill if you’re only working with one domain.

How to Get an SSL Certificate for Subdomains

Here’s a simple step-by-step to help you get SSL set up:

1. Make a List of Your Subdomains

Know what you need to protect- blog, shop, login, etc. This will help you pick the right SSL type.

2. Pick the Right Type of Certificate

Just one domain? Go with single-domain SSL
Many subdomains? Get a wildcard SSL certificate
Multiple sites and subdomains? Choose multi-domain/SAN SSL

3. Choose a Trusted SSL Certificate Provider

Here are some of the popular options for low-cost SSL certificate providers:

DigiCert
Sectigo
RapidSSL
GlobalSign
SSL2Buy

Make sure the provider supports the type of certificate you need.

4. Install the SSL Certificate

Your hosting provider usually helps with this. If you’re using cPanel, it often just takes a few clicks.

5. Redirect to HTTPS

Once installed, redirect your site to use HTTPS, which tells browsers and users to use the secure version of your site.

6. Test Everything

Use SSL checker tools to confirm your certificate is working properly across all your subdomains.

What are the Benefits of Adding SSL to Subdomains?

Better Security – Everything is encrypted and harder to hack
More Trust – The padlock tells visitors your site is safe
SEO Boost – Google likes secure sites
Legal Compliance – Helps with rules like GDPR and PCI-DSS
Peace of Mind – One less thing to worry about

If you’re using a wildcard SSL certificate, managing security is a lot easier — no need to install a separate cert for each subdomain.

Mistakes to Watch Out For When Installing Subdomain SSL:

A few things can go wrong if you’re not careful:

Choosing the wrong certificate (e.g., single-domain instead of wildcard)
Forgetting new subdomains- make sure they’re included
Letting SSL expire- renew on time or set up auto-renew
Not using HTTPS redirects, which can confuse users and search engines

Quick FAQs

Q: Do I need a separate SSL for every subdomain?
A: Yes, if you want them all to be secure. A wildcard SSL can cover them all easily in one certificate.

Q: Is free SSL enough?
A: For small projects, yes. But for business sites or online stores, paid SSL from a trusted provider is better.

Q: Which one is considered the best method for securing subdomains?
A: If you want to cover a single subdomain- you can go for Wildcard SSL, but want to secure multiple subdomains for multiple sites, then always opt for Multi-domain SSL.

Q: Can I mix certificate types?
A: You can, but it’s often easier to manage one wildcard or SAN certificate depending on your setup.

Final Thoughts

Securing your website isn’t just about the homepage. Your subdomains, such as login pages, blogs, and stores, are all part of the picture. Leaving them unprotected is like locking your front door but leaving the back wide open.

By choosing the right SSL certificate for subdomains, you’ll keep your visitors safe, build trust, and stay in good standing with search engines.

So, whether you go with an individual certificate, wildcard SSL certificate, a SAN cert, or a multi-domain wildcard option, just make sure every part of your site is protected.