Understanding SSL Wildcard Certificates

What a wildcard SSL certificate is

An SSL/TLS certificate binds a public key to one or more hostnames so that browsers can verify they are talking to the right server and encrypt the connection. A standard certificate lists specific names, such as example.com and www.example.com. A wildcard certificate instead contains a name with an asterisk in the leftmost position, such as *.example.com, which matches any single label in that position.

That one entry covers shop.example.com, blog.example.com, api.example.com and any other first-level subdomain you create later, without reissuing the certificate. For organisations that add subdomains regularly, this can remove a lot of certificate management work.

What a wildcard does and does not cover

Wildcard matching follows strict rules defined in the TLS and certificate standards. The asterisk replaces exactly one label, and only in the leftmost position.

In practice, most certificate authorities include the bare domain alongside the wildcard automatically, or let you request both names together. When ordering, confirm that the certificate lists both example.com and *.example.com.

Validation levels available

Wildcards can be issued as domain-validated (DV) certificates, which prove control of the domain, or organisation-validated (OV) certificates, which also verify the legal organisation. Industry rules do not permit extended validation (EV) wildcards, so if you need EV for a particular hostname, it must be listed explicitly.

Wildcard vs multi-domain (SAN) certificates

The main alternative is a multi-domain certificate, which lists several specific names in its Subject Alternative Name (SAN) field. The two approaches solve different problems, and they can be combined in one certificate.

A useful side effect of wildcards is privacy: certificate transparency logs publish every name in every publicly trusted certificate. A SAN certificate reveals each internal hostname, while a wildcard shows only the pattern. This is not a security control on its own, but it does reduce how much of your infrastructure is listed publicly.

How to get a wildcard certificate

Commercial certificate authorities sell wildcard certificates, and ACME-based authorities such as Let’s Encrypt issue them free of charge. In both cases you generate a private key and certificate signing request (CSR), prove control of the domain and install the issued certificate.

DNS-01 validation

For wildcard names, ACME authorities require the DNS-01 challenge. You prove control by publishing a TXT record at _acme-challenge.example.com containing a token supplied by the authority. HTTP-based validation is not accepted for wildcards because serving a file on one host does not prove control of every possible subdomain.

With Certbot, a manual request looks like this:

certbot certonly --manual --preferred-challenges dns -d example.com -d "*.example.com"

Manual DNS validation does not renew automatically. For hands-off renewal, use a DNS plugin or ACME client that supports your DNS provider’s API, so the client can create and remove the TXT record by itself. You can confirm the record is visible before validation:

dig +short TXT _acme-challenge.example.com

If you use CAA records to restrict which authorities may issue for your domain, note that wildcard issuance can be controlled separately with the issuewild property. Our guide on configuring CAA records correctly explains the syntax.

Wildcard SSL for e-commerce sites

Online stores often spread their platform across subdomains: the storefront on www, a customer account area on account, a checkout on checkout or pay, a help centre on help, static assets on cdn and regional stores on uk or de. A wildcard certificate can cover all of these with one order and one renewal date, which brings several practical benefits:

• Faster launches. New campaign pages, regional shops or staging environments get valid HTTPS immediately.
• Fewer gaps. A forgotten subdomain without HTTPS triggers browser warnings that can damage trust at the worst possible moment.
• Simpler administration. One certificate to monitor instead of many separate ones with different expiry dates.

The benefits must be weighed against risk. Payment pages are the most sensitive part of a store, and compliance frameworks such as PCI DSS expect strong key protection and clear network segmentation. Many teams therefore use a dedicated certificate for checkout and payment hosts, and a wildcard for marketing, content and asset subdomains. Discuss the right design with whoever handles your compliance assessment; this is general information, not legal or compliance advice.

Security risks and good practice

The biggest risk with a wildcard is that one private key protects every matching subdomain. If the key leaks from any server that holds it, an attacker could impersonate any subdomain until the certificate is revoked and replaced. Reduce that risk with these habits:

1. Limit deployment. Install the wildcard only on servers you control and maintain, not on third-party or legacy systems.
2. Prefer termination points. Terminate TLS at a load balancer or reverse proxy so fewer machines hold the key.
3. Protect the key. Restrict file permissions, avoid emailing keys and use a secrets manager or hardware module where available.
4. Use separate certificates for high-risk hosts. Payment, admin and authentication endpoints benefit from their own keys.
5. Have a revocation plan. Know how to revoke and reissue quickly if a server is compromised.
6. Watch for subdomain takeover. Remove DNS records for services you no longer use, because a valid wildcard makes a hijacked subdomain look fully trustworthy.

Certificate lifetimes and renewal tracking

Publicly trusted certificate lifetimes are getting shorter. Under the CA/Browser Forum’s schedule, the maximum validity dropped from 398 days to 200 days in March 2026, with further reductions planned to 100 days in 2027 and 47 days in 2029. Free ACME certificates are already short-lived and are designed to be renewed automatically. Check your certificate authority’s current policy, as the exact dates and practices may be adjusted.

Shorter lifetimes make automation essential, but automation still fails: DNS API credentials expire, a server is migrated and the renewal job is not copied, or a manually issued wildcard is simply forgotten. Because a wildcard often protects many services at once, a missed renewal can take down a whole platform rather than a single site. Check the current certificate on any host with:

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

TLDix can track SSL certificate expiry dates alongside domains and hosting plans, and send alerts before they lapse. Add your hosts in the TLDix panel, and see our domain security best practices for related protections.

Installing and testing a wildcard certificate

Once issued, a wildcard is installed like any other certificate: upload the certificate, the intermediate chain and the private key to your web server, load balancer or hosting panel. Missing intermediates are a frequent cause of errors on some devices, so always install the full chain the certificate authority provides. After installation, test several subdomains rather than just one, because each virtual host may reference a different certificate file. Check that HTTP requests redirect to HTTPS, that the certificate names and expiry date are correct and that older protocol versions are disabled according to your server’s current security recommendations.

Is a wildcard right for you?

A wildcard certificate is a good choice when you run many subdomains under one domain, create new ones frequently and can keep the private key on a small number of well-managed systems. A SAN certificate or individual certificates are often better when you serve several different domains, need EV for a particular host, or want to isolate sensitive services. Many organisations end up using a mix: wildcards for general subdomains, dedicated certificates for critical endpoints and automated renewal with independent expiry monitoring for all of them.