Wildcard and multi-domain certificates solve different inventory problems. A wildcard covers an open-ended set of names at one level below a domain. A multi-domain certificate lists the exact names it covers in Subject Alternative Name entries. The first reduces reissuance when sibling hostnames appear; the second makes scope explicit. Neither is automatically safer or easier. The right choice depends on who controls the names, where TLS terminates, how private keys are distributed, and how quickly the certificate can be replaced.
The coverage rule is narrower than it looks. *.example.com can match api.example.com and shop.example.com. It does not match example.com or eu.api.example.com. The apex needs its own SAN, and a deeper namespace needs another wildcard or exact name. A SAN certificate can include example.com, api.example.com, eu.api.example.com, and a name under another registered domain in one object, subject to the certificate authority's policy and name limits. Every included name becomes part of that certificate's replacement schedule.
DomScan's SSL Certificate Checker shows the names on the certificate an endpoint serves, and Certificate Transparency searches can reveal other logged certificates for the domain. That evidence helps compare the intended scope with the live estate. It cannot reveal every private-key copy or prove that the certificate is deployed consistently across all edges. Pair external inspection with the certificate-manager inventory and deployment configuration before deciding whether a shared certificate has a sensible boundary.
Quick path: Start with SSL Certificate Checker to inspect live hostname coverage, then use SSL Grade to review wider TLS posture.
Why wildcard and multi-domain certificate strategy matters in practice
Scope determines coupling. If ten products use one SAN certificate, adding or removing a name may require reissuing and redeploying the certificate everywhere. If hundreds of sibling hosts use one wildcard certificate and private key, a key compromise can force emergency replacement across the namespace. Those outcomes come from deployment design rather than the marketing label. A wildcard issued separately to each ingress cluster can have a smaller operational blast radius than one SAN certificate copied across unrelated systems.
Certificate Transparency creates another tradeoff. An exact SAN list publishes every included DNS name to public logs, which can reveal internal naming habits if public certificates are used carelessly. A wildcard entry publishes the wildcard identifier rather than every host that later uses it, although those hosts may still be visible through DNS, traffic, or other certificates. Do not use a public wildcard to solve an internal naming problem when a private trust model would be more appropriate.
- Wildcard scope is broad and convenient, but not infinitely deep.
- Multi-domain scope is explicit and auditable, but requires deliberate upkeep.
- Ownership boundaries are often more important than price differences.
- Broader coverage raises the value of strong inventory and monitoring.
How wildcard and multi-domain certificate strategy works
A wildcard appears as the complete left-most label of a dNSName in the Subject Alternative Name extension. RFC 9525 limits matching to one label, so broader patterns such as *.*.example.com are not valid TLS service identities. The certificate authority must validate control of the base domain. With Let's Encrypt, wildcard issuance requires the DNS-01 ACME challenge, which means the automation needs a safe way to create temporary DNS TXT records or delegate that validation function.
A SAN certificate also validates every requested identifier, but the methods can vary by CA and automation. Its list is fixed at issuance. Adding a hostname means ordering a replacement certificate, then deploying it to every system that depends on the shared object. That explicit list is useful when the set is stable and centrally owned. It becomes awkward when application teams add names independently or when one slow deployment prevents the old shared certificate from being retired.
Wildcard: *.example.com
Covers: api.example.com, app.example.com, status.example.com
Does not cover: eu.api.example.com, example.com
Multi-domain SAN:
Covers: example.com, api.example.com, app.example.com, status.example.netConsider validation failure as well as key compromise. A wildcard usually depends on DNS automation for the base domain; an outage or permission change in that path can block every renewal using it. A SAN certificate spanning several domains may depend on validation controls owned by different teams, so one unavailable domain can delay replacement of the shared object. Certificate authorities and ACME clients handle partial authorisation differently. Rehearse renewal with all identifiers, document who controls each challenge, and avoid combining names whose validation owners cannot meet the same recovery target. Review client compatibility too. Most current clients implement the left-most-label wildcard rule, but specialised devices and private applications may have stricter certificate policies or trust stores. Test the actual client population before consolidating certificates, especially when the service supports embedded hardware, older mobile systems, or mutual TLS. A design that is valid on paper can still be unsuitable for the clients the service is required to support.
Where teams usually get it wrong
Teams often choose one certificate for everything because the first deployment is convenient. Over time, unrelated services copy the private key, nobody can name every installation, and emergency replacement becomes a search exercise. The opposite mistake is issuing a separate certificate manually for every small hostname without central renewal visibility. That avoids shared keys but creates hundreds of silent expiry paths. Automation and inventory matter more than minimising the certificate count.
Coverage assumptions also cause failures. Teams forget that a wildcard does not cover the apex, or they expect *.example.com to cover api.eu.example.com. SAN certificates develop stale names because removing one requires a coordinated reissue, and abandoned hosts remain attached to the shared lifecycle. Write tests for the expected hostname set and fail deployment when a required name is absent. Separately report extra names so they can be removed after ownership is confirmed.
A more reliable operating model
Draw certificate boundaries around systems that share an owner, deployment mechanism, and incident response path. A platform ingress serving many short-lived sibling hostnames may suit a wildcard if the key stays inside that managed boundary. A small set of stable public names served by the same gateway may suit a SAN certificate. Different business units, cloud accounts, or security classifications usually deserve separate keys and certificates even when one wildcard or SAN object could technically cover them.
A practical workflow
Export hostnames from DNS, ingress configuration, load balancers, certificate managers, and CT logs. Mark the registrable domain, label depth, service owner, TLS termination point, environment, and business tier. Group names that genuinely share deployment and response ownership. Then model both options: how many certificates are needed, where each private key lives, which DNS permissions issuance requires, and what must change if the key is compromised tomorrow.
For each proposed boundary, test normal renewal, adding a name, removing a name, and emergency key replacement. A wildcard often makes adding a sibling hostname easy but makes it harder to know where the key has spread. A SAN certificate makes the approved names visible but couples all of them to list changes. Choose the failure mode the owning team can operate safely, then automate issuance and deployment before moving production traffic.
Minimise DNS credentials used for wildcard issuance. Prefer narrowly scoped API tokens or delegated challenge zones over credentials that can edit an entire production zone. Keep private keys non-exportable where the platform supports it, and do not copy one wildcard key into application repositories or unrelated accounts. If several systems need the same coverage but cannot share secure key custody, issue separate certificates with separate keys rather than distributing one trust object.
What good monitoring looks like
Monitor each live hostname even when a wildcard theoretically covers it. The certificate can be missing from one edge, the wrong certificate may be selected by Server Name Indication, or a nested hostname may fall outside the wildcard rule. For SAN certificates, compare the observed name set with the approved manifest and flag additions as well as omissions. Track certificate fingerprints by endpoint so a shared renewal that reached only some systems is visible.
Watch CT logs for new wildcard and exact-name certificates under owned domains, then match them to expected issuance. Review deployment history after organisational changes: a certificate boundary that made sense for one platform team may become unsafe when products move to separate accounts. Key-access logs and certificate-manager inventory are important here because external scans can see certificates but cannot show how many copies of a private key exist.
Where DomScan helps
Use DomScan to inspect the live certificate for representative hostnames, list its Subject Alternative Names, review TLS posture, and search CT records for the domain. DNS and subdomain discovery can help find names missing from the architecture diagram. Export the resulting candidate inventory to the certificate owner, who can reconcile it with private-key custody and deployment records. External visibility is strongest at finding scope drift; internal records are still required to judge key-sharing risk.
Independent references: RFC 9525 defines current TLS service-identity and wildcard matching rules. Let's Encrypt's challenge documentation explains why its wildcard issuance uses DNS-01 and describes delegation options for validation.
Choose after rehearsing replacement. If the team can identify every deployment, rotate the key quickly, and keep DNS validation credentials narrow, the boundary is probably operable. If one certificate crosses owners or accounts that cannot coordinate an emergency change, split it. The number of certificates on the invoice is a poor design metric; the time and certainty of complete replacement are much better ones.