Wildcard SSL Certificates Explained: What They Are and How Developers Use Them

When you create a project on DomainDock, your domain is reachable over HTTPS within seconds. No CSR submissions, no waiting for a Certificate Authority to email you, no manual renewal every 90 days.

That speed comes from wildcard SSL certificates. Understanding how they work will help you design better infrastructure and make smarter decisions about SSL for your own projects.

What Is a Wildcard SSL Certificate?

A standard SSL certificate covers exactly one domain: example.com. If you want HTTPS on api.example.com, you need a second certificate. If you want staging.example.com, a third.

A wildcard certificate covers a pattern: *.example.com. The * matches any single label, which means one certificate covers:

• api.example.com
• staging.example.com
• myproject.example.com
• anything-you-want.example.com

One certificate. Unlimited domains under that root.

The Critical Limitation: Single Level Only

This is where most developers get tripped up. The * in a wildcard certificate only matches a single label (one segment between dots).

*.example.com covers:

• api.example.com (yes)
• staging.example.com (yes)

*.example.com does not cover:

• api.v2.example.com (two labels deep)
• deep.api.example.com (two labels deep)

If you need coverage for api.v2.example.com, you'd need a separate certificate for *.v2.example.com or a certificate with both *.example.com and *.v2.example.com in its Subject Alternative Names.

DomainDock's domains (yourproject.digitalweb.host) are one level deep under digitalweb.host, so a single *.digitalweb.host wildcard covers all of them.

The ACME Challenge Problem

Most SSL certificates are issued via the ACME protocol (the same protocol Let's Encrypt uses). There are two main challenge types:

HTTP-01 challenge: Let's Encrypt asks you to place a specific file at http://yourdomain.com/.well-known/acme-challenge/{token}. Easy to automate, but requires the domain to be publicly reachable on port 80. One domain at a time.

DNS-01 challenge: Let's Encrypt asks you to create a DNS TXT record at _acme-challenge.yourdomain.com. This proves domain ownership without needing a running server.

Wildcard certificates can only be issued using DNS-01. HTTP-01 challenges don't work for wildcards because Let's Encrypt can't verify domain ownership for *.example.com by placing a file on one specific server.

How DomainDock Issues Wildcard Certificates

DomainDock uses Traefik's built-in ACME client with Cloudflare's DNS API for the DNS-01 challenge:

1. Traefik requests a *.digitalweb.host certificate from Let's Encrypt
2. Let's Encrypt challenges Traefik to create a DNS TXT record at _acme-challenge.digitalweb.host
3. Traefik calls the Cloudflare API to create that TXT record
4. Let's Encrypt verifies the record, issues the certificate
5. Traefik stores the certificate and uses it for all *.digitalweb.host domains

This happens once. After that, any new domain under digitalweb.host is immediately covered, with no new certificate request needed.

When the certificate approaches expiry (Let's Encrypt certificates last 90 days), Traefik automatically runs the same renewal process in the background.

Wildcard vs. Per-Domain Certificates: When to Use Each

Use a wildcard certificate when:

• You're operating a platform where many domains are created dynamically (like DomainDock)
• You want consistent SSL across all environments (dev, staging, production) under one root
• You want to avoid rate limits: Let's Encrypt limits certificate issuance per domain, and a wildcard counts as one issuance for all of them

Use per-domain certificates when:

• Each domain is completely independent and managed by different teams or customers
• You need different certificate authorities for compliance reasons
• You want to limit the blast radius: if one certificate is compromised, only its specific domain is affected

The rate limit argument

Let's Encrypt allows 50 new certificates per registered domain per week. If you're creating 100 new domains per day on a shared zone (*.example.com), per-domain certs would exhaust this limit immediately. A wildcard cert sidesteps this entirely.

Setting Up Wildcard SSL with Traefik

If you're running your own Traefik instance, here's what the configuration looks like:

traefik.yml (static config):

certificatesResolvers:
  letsencrypt:
    acme:
      email: you@example.com
      storage: /letsencrypt/acme.json
      dnsChallenge:
        provider: cloudflare
        resolvers:
          - "1.1.1.1:53"
          - "8.8.8.8:53"

Environment variables (for the Cloudflare DNS API):

CF_DNS_API_TOKEN=your_cloudflare_api_token_here

The Cloudflare API token needs Zone:DNS:Edit permissions on the zone you want to issue certificates for. Scope it to just that zone, with no broader permissions needed.

Dynamic routing rule (to use the wildcard cert):

http:
  routers:
    myapp:
      rule: "Host(`myapp.example.com`)"
      service: myapp-svc
      entryPoints:
        - websecure
      tls:
        certResolver: letsencrypt
        domains:
          - main: "example.com"
            sans:
              - "*.example.com"

The domains block explicitly requests the wildcard certificate and stores it. Once generated, all subsequent routers that reference certResolver: letsencrypt for *.example.com domains will use the cached wildcard, with no new ACME challenges.

SAN Certificates: Wildcards Are a Subset

Modern SSL certificates typically use Subject Alternative Names (SANs), which are a list of domains the certificate is valid for. A wildcard is just a special pattern that can appear in this list.

You can mix wildcards and specific domains in one certificate:

Subject: example.com
SANs:
  - example.com
  - *.example.com
  - api.example.com
  - *.api.example.com

This single certificate covers example.com, all one-level domains, and all domains under api.example.com.

Certificate Transparency and Privacy

Every SSL certificate issued by a public CA is logged in Certificate Transparency (CT) logs. These logs are public. That means a wildcard certificate for *.example.com won't expose individual domain names, because the wildcard covers all of them without listing them.

Per-domain certificates, however, log each specific domain. If you're issuing certificates for client1.example.com, client2.example.com, etc., those names appear in public CT logs. This can leak information about your customers or internal projects.

Wildcards are more private: the pattern is logged, not the individual domains.

The Bottom Line

Wildcard SSL certificates are the right choice when you control a shared zone and want frictionless HTTPS for everything under it. They're how DomainDock makes every new domain instantly available over HTTPS without any per-domain certificate work.

For your own infrastructure: if you have a VPS running multiple projects under a domain you control, set up a wildcard cert once and never think about SSL again.

Every domain on DomainDock includes HTTPS automatically. Create your free domain today.