HTTPS, SSL & Security
What is an SSL wildcard certificate?
An SSL wildcard certificate is an SSL certificate that covers a domain and all of its single-level subdomains with a single certificate, using an asterisk as a wildcard character in the Subject Alternative Name. A wildcard certificate issued for *.example.com is valid for www.example.com, blog.example.com, api.example.com, shop.example.com, and any other subdomain of example.com: unlimited subdomains covered by one certificate.
The asterisk, *: is the wildcard character that gives these certificates their name. In the certificate’s Subject Alternative Name field the asterisk matches any single label, any single subdomain component. *.example.com matches anything.example.com where anything is a single label, one level of subdomain. The asterisk matches exactly one label, not zero labels and not multiple labels.
Wildcard certificates exist because managing individual SSL certificates for every subdomain of a domain is operationally burdensome at scale. An organisation running www.example.com, api.example.com, app.example.com, docs.example.com, status.example.com, and dozens of other subdomains would need to obtain, install, and renew a separate certificate for each without wildcard certificates. A single wildcard certificate covers all of them, simplifying certificate management dramatically.
For redirect management wildcard certificates are particularly valuable, a redirect platform serving all subdomains of a connected domain can use one wildcard certificate rather than provisioning individual certificates for each subdomain being redirected.
How wildcard certificates work
A wildcard certificate is a standard X.509 certificate with a wildcard pattern in its Subject Alternative Name, the list of domain names the certificate is valid for.
Wildcard SAN notation: the wildcard is expressed as *.domain.com in the SAN field. The asterisk matches any single DNS label, a sequence of characters without dots. *.example.com matches www.example.com: where www is the matching label, and api.example.com: where api is the matching label. It does not match example.com: the apex domain, because the apex has no label before example.com for the asterisk to match. It does not match sub.www.example.com: where there are two labels before example.com: because the asterisk matches only one label.
Browser matching logic: when a browser receives a wildcard certificate during a TLS handshake it checks whether the domain it is connecting to matches the wildcard pattern. The matching algorithm checks that the non-wildcard portion of the SAN, example.com: matches the end of the requested domain, that the wildcard portion, *: matches exactly one label, and that the matched label does not contain a dot. api.example.com matches *.example.com: api is one dotless label. api.v2.example.com does not match, api.v2 contains a dot.
Certificate issuance: wildcard certificates are issued through the same processes as standard certificates, with additional validation requirements. Domain validation for wildcard certificates requires DNS-01 challenge validation, the HTTP-01 challenge can only validate a specific hostname, not a wildcard. DNS-01 validation proves control of the entire DNS zone, which is the appropriate proof for a certificate covering all subdomains.
Let’s Encrypt issues wildcard certificates through DNS-01 validation, the ACME client creates a TXT record at _acme-challenge.example.com and Let’s Encrypt verifies it before issuing *.example.com. Automated wildcard certificate issuance requires an ACME client with DNS provider API integration, the client must be able to create and delete DNS TXT records automatically for DNS-01 challenges.
Wildcard certificate scope and limitations
Understanding what wildcard certificates cover, and what they do not, prevents misconfiguration and unexpected certificate errors.
Single-level subdomain coverage: a wildcard certificate for *.example.com covers all single-level subdomains, one label before example.com. This is the most important limitation. Deep subdomains, app.staging.example.com, v2.api.example.com: are not covered by *.example.com. They require either individual certificates for each specific name or a separate wildcard certificate for their parent subdomain, *.staging.example.com for app.staging.example.com.
For redirect management this limitation matters when redirect rules involve multi-level subdomain patterns. A redirect source like *.staging.example.com requires a separate wildcard certificate for the staging.example.com subdomain, not coverage by the parent *.example.com wildcard.
Apex domain not covered: *.example.com does not cover example.com: the apex domain. The asterisk requires at least one label before example.com and the apex has none. A certificate covering both the apex and all subdomains requires a multi-domain SAN certificate listing both example.com and *.example.com as Subject Alternative Names.
This is a common source of certificate errors, an organisation obtains a wildcard certificate believing it covers the root domain, but visitors to https://example.com receive certificate errors because the apex is not covered. When connecting an apex domain to redirect management infrastructure a certificate covering both example.com and *.example.com ensures complete coverage.
One wildcard level per certificate: a wildcard certificate cannot cover multiple levels simultaneously. *.example.com does not match *.sub.example.com: separate wildcards are needed for each subdomain level that needs coverage. Organisations with complex subdomain hierarchies may need multiple wildcard certificates to achieve complete coverage.
Same certificate for all matched subdomains: all subdomains matched by a wildcard certificate share the same certificate. This means the certificate’s validity period, issuing CA, and all other certificate properties are the same for all covered subdomains. Organisations that need different certificate validity periods, different CAs, or different certificate profiles for different subdomains cannot achieve this with a wildcard, they need individual certificates for each.
Wildcard certificates and security considerations
Wildcard certificates introduce specific security considerations compared to individual subdomain certificates.
Broader compromise impact: a wildcard certificate’s private key is used to authenticate all covered subdomains. If the private key is compromised, extracted from a server, exposed through a vulnerability, or otherwise obtained by an attacker, the attacker can impersonate any subdomain covered by the wildcard. This is a broader attack surface than individual subdomain certificates where key compromise affects only the specific subdomain.
Organisations with high security requirements, financial institutions, healthcare providers, may prefer individual subdomain certificates specifically to limit the blast radius of private key compromise. For most organisations the convenience of wildcard certificates outweighs this theoretical risk, particularly when certificates are stored securely and renewed frequently.
Key distribution across servers: when multiple servers need to serve subdomains covered by a wildcard certificate the same private key must be distributed to all of them. Each copy of the private key on each server is a potential compromise point. Key management practices, restricting access, using hardware security modules, monitoring key usage, are important when wildcard private keys are distributed across many servers.
CAA records and wildcards: CAA records control which certificate authorities can issue certificates for a domain. The issue tag controls standard certificate issuance. The issuewild tag specifically controls wildcard certificate issuance, an issue record without a corresponding issuewild record does not authorise wildcard issuance even from the same CA.
Organisations using wildcard certificates must ensure their CAA records include issuewild entries alongside issue entries for the CAs they use:
Missing the issuewild record blocks wildcard certificate issuance from Let’s Encrypt, preventing automated wildcard provisioning in redirect management platforms.
Certificate transparency and subdomain exposure: wildcard certificates are logged in certificate transparency logs like all other certificates. The CT log entry for *.example.com reveals that the organisation operates subdomains under example.com: though it does not reveal which specific subdomains exist. Organisations with subdomain privacy requirements, where the mere existence of subdomains is sensitive, may prefer individual subdomain certificates issued as needed rather than a wildcard that broadly signals subdomain usage.
Wildcard certificates and redirect management
Wildcard certificates are particularly useful in redirect management, reducing certificate management complexity for platforms handling many subdomains of connected domains.
Covering all redirect source subdomains: when a domain is connected to a redirect management platform the platform may need to serve HTTPS for any subdomain of that domain, including subdomains specified in redirect rules and subdomains matched by wildcard redirect rules. A wildcard certificate for *.customer-domain.com covers all single-level subdomains, any subdomain specified in redirect rules and any subdomain matched by wildcard patterns is covered by the same certificate.
Without a wildcard certificate the platform would need individual certificates for each subdomain, requiring certificate provisioning before any redirect rule for that subdomain can serve HTTPS traffic. Wildcard certificates enable immediate HTTPS coverage for any subdomain as soon as a redirect rule is created.
DNS-01 challenge for wildcard automation: automated wildcard certificate issuance requires DNS-01 challenge completion, the ACME client must create TXT records in the domain’s DNS zone. For redirect management platforms to automate wildcard certificate provisioning they need either DNS provider API access for each connected domain or a mechanism that delegates DNS validation authority to the platform.
Some redirect management platforms use CNAME-based DNS validation delegation, the domain owner adds a CNAME record like _acme-challenge.example.com CNAME _acme-challenge.example.com.redirect-platform.com. The redirect platform controls the target of the CNAME and can create and remove TXT records there, completing DNS-01 challenges for any certificate covering example.com subdomains without requiring access to the customer’s DNS provider directly.
Wildcard certificates in SNI infrastructure: redirect management platforms use SNI to serve the correct certificate for each incoming connection. With wildcard certificates the SNI lookup must match incoming hostnames against wildcard patterns, a connection for www.example.com should match the *.example.com wildcard certificate. SNI matching logic in the platform’s certificate selection must handle wildcard matching correctly, returning the wildcard certificate for any subdomain that matches it.
Mixed individual and wildcard certificates: redirect management platforms may use a combination of wildcard certificates and individual subdomain certificates. A wildcard certificate covers all standard subdomains. Specific subdomains with special requirements, different certificate profiles, specific CA requirements, or deeper nesting, have individual certificates. The platform’s certificate selection logic handles both, returning the most specific matching certificate for each incoming SNI value.
Obtaining wildcard certificates
Wildcard certificates can be obtained from the same sources as standard certificates, with the additional requirement of DNS-01 validation.
Let’s Encrypt wildcard certificates: Let’s Encrypt issues free wildcard certificates through DNS-01 validation. The ACME client must support DNS-01 challenges and have API access to the domain’s DNS provider. Let’s Encrypt wildcard certificates are valid for 90 days and renewed automatically through the ACME client. The short validity period is well-suited to automated environments, renewal is handled without manual intervention.
ACME clients with broad DNS provider support, acme.sh supports over 150 DNS providers, enable automated wildcard certificate issuance for most DNS configurations. Certbot with DNS provider plugins handles automated wildcard issuance for common DNS providers.
Commercial wildcard certificates: commercial CAs, DigiCert, Sectigo, GlobalSign, sell wildcard certificates with validity periods of one to two years. Commercial wildcard certificates require DNS-01 or other validation methods and include organisation validation options for OV wildcard certificates. Commercial wildcard certificates are appropriate for organisations that prefer longer validity periods or need OV wildcard certificates, not available from Let’s Encrypt.
Cloud provider wildcard certificates: AWS Certificate Manager issues free wildcard certificates for use with AWS services, CloudFront, ELB, API Gateway. Google-managed SSL certificates support wildcards for Google Cloud Load Balancing. These cloud wildcard certificates are available only within their respective cloud ecosystems.
Wildcard vs individual subdomain certificates, when to use each
The choice between wildcard and individual subdomain certificates depends on the specific use case, security requirements, and operational context.
Use wildcard certificates when: managing many subdomains that all need HTTPS. The overhead of individual certificate management for each subdomain is significant. Subdomains are dynamically created, new subdomains appear regularly and should be covered immediately without certificate provisioning delay. The security trade-off of shared private key across all subdomains is acceptable. The subdomains are all at the same level, *.example.com rather than a mix of levels.
Use individual subdomain certificates when: specific subdomains have distinct security requirements. The private key compromise blast radius must be minimised. Different subdomains need certificates from different CAs, perhaps specified through CAA records. Compliance requirements mandate individual certificates for specific high-security subdomains. Deeper subdomain nesting beyond single-level requires certificates for specific names anyway.
Use both: a common practical approach for redirect management. A wildcard certificate covers standard single-level subdomains. Individual certificates handle specific high-security subdomains, deeper subdomain levels, and apex domain coverage. The wildcard provides broad efficient coverage while individual certificates handle edge cases and special requirements.