Wildcard certificates

A wildcard certificate covers a single domain level using an asterisk as a placeholder — *.example.com matches api.example.com, app.example.com, and any other direct subdomain, but not deeper levels like v2.api.example.com. A single certificate and private key serve every matching hostname, which is both their appeal and their principal risk.

This guide covers when wildcard certificates are appropriate, when they are not, and how to manage them safely in an automated environment.

Why wildcards are tempting

The case for wildcards is operational simplicity and, for publicly trusted certificates, cost. Issuing one certificate that covers an entire subdomain namespace avoids requesting and tracking a certificate per service. When new subdomains are added, no certificate work is needed.

For organisations paying per certificate from a commercial CA, a single wildcard can replace dozens of individual certificates. That cost saving is real — but it comes with trade-offs that automation makes easier to avoid.

When wildcards are appropriate

Wildcards are a reasonable choice in a narrow set of circumstances:

TLS terminates at a single point. If all traffic to *.example.com routes through one load balancer or reverse proxy, the private key lives in exactly one place. The blast radius of a compromise is the same as for any other certificate at that host. This is the most defensible use of a wildcard.

The subdomain space is dynamic and unpredictable. When new subdomains are created on demand — for example, per-customer subdomains in a SaaS product — issuing individual certificates for each one at creation time may not be feasible without a fully automated issuance pipeline. A wildcard at the edge covers the entire space without any per-subdomain certificate work.

Non-production environments. Development and staging environments often mirror production domain structures. A wildcard is an acceptable convenience here: the blast radius is low, the data is not sensitive, and reducing friction is a legitimate goal.

Subdomain enumeration is a concern. Every publicly trusted certificate is logged in Certificate Transparency logs, which are public and continuously monitored. Individual per-service certificates expose every hostname you issue a certificate for. A wildcard appears as *.example.com in CT logs, revealing nothing about the services behind it. If your threat model includes adversaries mapping your infrastructure through CT log monitoring — which security researchers have shown can happen within minutes of issuance — a wildcard at the edge reduces that signal.

A third-party system requires it. Some vendor appliances, legacy systems, or SaaS integrations only accept wildcard certificates. Where there is no alternative, a wildcard is acceptable, but it should remain scoped to the integration rather than shared across unrelated services.

When not to use wildcards

Automated environments

Wildcard certificates and automation work against each other. The operational reason to use a wildcard is to avoid managing many certificates — but a mature automation setup does that already, making the trade-off no longer worthwhile.

The friction shows up concretely at renewal time. ACME, the protocol used by most automated certificate issuance workflows, only supports wildcard certificates through the DNS-01 challenge. That requires your automation to hold credentials for your DNS provider API and modify DNS records on every renewal. HTTP-01 and TLS-ALPN-01 validation — which are simpler to operate and do not require DNS write access — cannot issue wildcards.

This creates a dependency chain: your certificate automation now also requires DNS automation, with credentials that have write access to your entire DNS zone. If that automation fails or those credentials are compromised, the impact is far broader than a single certificate.

The net effect is that automating wildcard certificate renewal is harder than automating individual per-service certificates, not easier. With automation in place, issuing fifty individual certificates takes the same effort as issuing one wildcard — the management simplicity argument no longer holds.

This matters especially now. The CA/Browser Forum has been steadily reducing maximum certificate validity: publicly trusted TLS certificates will be capped at 47 days by 2029. At that cadence, manual certificate management is not a viable option regardless of whether you use wildcards. Any organisation planning for that future needs automation, and once that automation exists, wildcard certificates offer no operational advantage over individual ones.

When the private key is distributed across multiple hosts

A wildcard certificate requires the same private key to be deployed to every host that serves a matching subdomain. Each copy of that private key is an independent exposure point. If any of those hosts is compromised, the attacker holds a key that authenticates every service in the wildcard domain.

By contrast, a per-service certificate means a compromised host exposes only that service. Containing the incident does not require revoking TLS for your entire domain.

When revocation needs to be surgical

If a wildcard certificate is compromised or misconfigured, revoking it takes down TLS for every subdomain it covers simultaneously. There is no way to revoke coverage for one service while keeping it for others.

For production systems this is a significant operational risk. A suspected compromise of one host forces an immediate coordinated redeployment across every host that uses the certificate — often under incident conditions.

When you operate your own CA

The cost argument for wildcards only applies to publicly trusted certificates from commercial CAs. If you issue certificates from an internal CA — as is typical in Horizon — there is no per-certificate cost. The economic justification disappears, and the security trade-offs remain. Per-service certificates are the right default for internal PKI.

A note on multi-SAN certificates

A common middle-ground instinct is to consolidate multiple services onto a single certificate with an explicit list of Subject Alternative Names — one certificate for api.example.com, app.example.com, and admin.example.com together. This is not a safer alternative to a wildcard; it combines the drawbacks of both approaches.

The private key is still shared across multiple services, preserving the blast radius problem. All hostnames are still exposed in CT logs, losing the enumeration protection a wildcard provides. And revocation is still all-or-nothing for every service on the certificate.

Multi-SAN certificates also introduce an additional operational fragility: if any domain on the certificate is later associated with a revocation event — for example, because it expired and was re-issued elsewhere — there is a risk of the entire certificate being flagged or revoked. The recommendation is the same as for wildcards: per-service certificates with automation are the better default.

Automating wildcard certificates when you must use them

If you have determined that a wildcard is the right tool for a given use case, the following practices reduce the associated risks.

Centralise the private key

Generate and store the private key in a single, controlled location — a secrets manager, an HSM, or the CLM platform itself using centralised enrollment. Do not generate it on individual hosts. Push the key and certificate to hosts through your deployment automation, and ensure that only the hosts that need it receive it.

Centralised key generation through a CLM like Horizon gives you a single place to enforce key type and size policy, rotate the key at renewal, and audit who retrieved it.

Keep validity short

A shorter certificate lifetime reduces the window during which a compromised key can be used. Even if you cannot achieve the 90-day renewals common for individual certificates, favour 180 days over one year. At renewal, generate a new key pair — do not reuse the previous key.

Monitor deployment with discovery

Because the same certificate is deployed to multiple hosts, you need to verify that every host is running the current version after each renewal. Use Horizon network discovery to scan your hostnames and confirm that the certificate presented matches the one you just issued. A host still presenting the old certificate after renewal is a deployment failure that needs investigation.

Track every host that uses the certificate

Maintain an inventory of every host and service that holds a copy of the private key. This is the list you need to update at renewal and the list you will work from if you need to respond to a compromise. If you cannot enumerate every host from your CLM or CMDB, that is itself a risk worth addressing before the next renewal.

Plan revocation ahead of time

Define a revocation runbook before you need it. A wildcard revocation is a high-pressure, time-sensitive operation: every host must be reprovisioned with a replacement certificate before the revocation takes effect, or services go offline. Having the runbook prepared — including who to notify, which systems are affected, and how to coordinate a simultaneous redeployment — turns an incident into a procedure.

Migrating from wildcards to per-service certificates

If you currently use wildcards and want to reduce risk, migration does not need to happen all at once. A practical approach:

1. Stop issuing new wildcards. All new services get individual certificates.
2. Identify which existing wildcard-covered services can be migrated independently. Start with the lowest-risk ones.
3. Issue a per-service certificate for each host, configure it, and verify the service is using the new certificate via discovery.
4. Once all hosts are migrated, revoke or let the wildcard expire.

Horizon's network discovery makes it straightforward to confirm which certificate each host is currently presenting, so you can track migration progress across a large number of services without manual checking.