Privacy and protection with wildcard SSL certificates

Securing websites with SSL certificates has become standard practice. Users expect the padlock in the browser bar, and no confidential information should be transmitted without encryption. However, a less-known aspect of SSL infrastructure is the concept of transparency. What was originally designed to protect users from malicious certificate misuse can actually become a vulnerability, especially for organizations using test environments, internal systems, or sensitive subdomains. Fortunately, there’s a smart and effective way to reduce this risk. We’re talking about the wildcard certificate. We’re happy to tell you more about what wildcard certificates are, why they are particularly valuable in the era of Certificate Transparency (CT), and how they help you hide the structure of your application landscape.

What is an SSL certificate?

An SSL certificate (or more accurately, a TLS certificate) provides encryption between a user’s browser and a web server. It ensures that no third party can view or intercept the transmitted data. Each certificate is issued for a specific domain or subdomain. For example, a certificate for www.example.com only secures that specific subdomain. If you also want to secure app.example.com or test.example.com, you’d typically need separate certificates, unless you choose a wildcard certificate.

What is a wildcard certificate?

A wildcard SSL certificate is a type of certificate that uses an asterisk (*) as a placeholder for multiple subdomains on the same root domain. For example, a wildcard certificate for *.80si.com will secure test.80si.com, dev.80si.com, admin.80si.com, and many others. However, it only covers first-level subdomains. So api.test.80si.com would not be covered under a wildcard for *.80si.com.

Certificate Transparency (CT)

A few years ago, a new policy was introduced: Certificate Transparency (CT). This initiative requires all Certificate Authorities (CAs) to publicly log every SSL certificate they issue into publicly accessible, cryptographically verifiable logs. CT aims to prevent the abuse or misuse of certificates. For example, if a CA mistakenly issues a certificate for a domain you own, you can detect and act on it. It’s essentially a form of public oversight. Although transparency is good in theory, it also exposes sensitive details:

Every domain and subdomain tied to a certificate becomes publicly visible.

Even test or staging environments like test.80si.com, 

old-admin.80si.com, or dev-backup.80si.com end up registered in CT logs.

Attackers can scrape these logs and build an attack map of your infrastructure; 

identifying forgotten endpoints, old test setups, or weakly secured tools.

Once a subdomain is exposed in a CT log, it remains visible forever, even if you take the system offline later.

The wildcard workaround

A wildcard certificate gets logged only once in the transparency register, simply as *.80si.com. That means there’s only one CT log entry instead of one for every subdomain.

You can use that certificate for unlimited subdomains (e.g., test.80si.com, dev2.80si.com, internal-api.80si.com) without disclosing them individually. Let’s give you an example. Say you're working on an internal project and spin up test.80si.com, debug.80si.com, and internal-dev.80si.com. If you use separate SSL certificates for each, all three subdomains show up in Certificate Transparency logs. But if you use a wildcard certificate (*.80si.com), there’s just one log entry and your actual infrastructure remains private.

Key benefits of a wildcard certificate

With a wildcard certificate you can hide your infrastructure. Using a wildcard certificate helps you avoid leaking information about your subdomain structure, especially test or internal tools that don’t need to be known to the public. There is less administrative overhead. With just one certificate, you can secure all your subdomains without repeatedly purchasing, renewing, and managing individual certificates. It’s very cost-efficient. Wildcard certificates are generally more expensive than single-domain certificates, but much cheaper than buying many separate certificates if you operate multiple subdomains. You can launch new environments quickly (e.g., new-feature.80si.com) without waiting for your CA to issue a new certificate. And last but not least, with fewer entries in CT logs, it becomes
significantly harder for malicious actors to map your digital footprint.

The most important drawbacks to consider

Wildcard certificates are powerful but not without limitations. There are some things to consider. Because a single certificate secures multiple systems, it often ends up deployed across several servers. If one server is compromised, the entire certificate - and every subdomain it secures - is at risk. Use secure storage like Hardware Security Modules (HSMs) and restrict access to the private key. A wildcard like *.80si.com only covers one level of subdomains. So deep.test.80si.com is not included. If every environment uses the same certificate, you lose visibility over which systems are using which domains, unless you maintain strict internal documentation.

Best practices for wildcard use

It’s important to protect your private key. Use secure servers and limited permissions. Consider automated rotation or HSM-backed certificate storage. Use the wildcards strategically. They are ideal for internal environments, dynamic subdomains, and dev/test systems. Consider individual certificates for higher control and auditing for public-facing, critical services (e.g., www.80si.com or payments.80si.com). Since CT won’t show every subdomain, implement your own internal logging and monitoring (manually). Avoid downtime or expired certificates. Use tools like Certbot for Let’s Encrypt wildcard certificates (requires DNS-based verification). Our last tip: secure your DNS. Add CAA (Certification Authority Authorization) records to define which CAs are allowed to issue certificates for
your domain and consider enabling DNSSEC for extra integrity.

Wildcard vs. SAN certificates

Wildcard certificates and SAN (Subject Alternative Name) certificates are often confused, but they serve different purposes and operate in different ways. A wildcard certificate allows you to secure an unlimited number of subdomains at a single level under the same root domain. For example, a wildcard for *.80si.com will cover test.80si.com, dev.80si.com, and admin.80si.com, but not deeper subdomains like sub.test.80si.com. In contrast, a SAN

certificate explicitly lists every domain and subdomain you want to secure. This makes SAN certificates ideal when you need to cover multiple domains or different subdomain levels, such as www.80si.com, mail.80si.net, and api.sub.80si.com, all within a single certificate.

Difference in transparency

Another key difference lies in transparency. With a wildcard certificate, only the wildcard entry (*.80si.com) is logged in Certificate Transparency records, keeping the actual subdomains hidden. A SAN certificate, however, exposes each individual domain listed, which can increase visibility - and potentially risk - for your infrastructure. Wildcard certificates are best suited for dynamic environments where subdomains are frequently created and removed, such as in development or testing setups. SAN certificates, on the other hand, are better when managing specific, known endpoints across multiple domains or subdomain levels.

When to use a wildcard certificate?

Wildcard certificates are particularly useful if you frequently create and destroy test environments or subdomains or if you want to avoid exposing infrastructure details in CT logs. They are also useful when you’re looking for a simple, scalable solution for SSL/TLS security or if you want to reduce certificate management workload across your team. Avoid using wildcard certificates if your organization requires strict compartmentalization, traceability, or high-stakes auditing, such as in banking or healthcare.

Want to learn more about wildcard certificates?

Wildcard certificates offer a powerful alternative that enhances security and privacy. By reducing the number of CT log entries to just one wildcard domain, you shield your internal structure from prying eyes. At the same time, you reduce administrative load, simplify deployment, and lower costs. As with all security tools, wildcards must be used wisely, protected by strict key policies and internal monitoring. But for teams that value flexibility and privacy, they remain one of the smartest options available. Want to learn more about how wildcard certificates can enhance your security and simplify domain management? Get in touch with our team. We’re here to help you make the right choice. Contact us today!