Wildcard SSL vs Multi-Domain SSL: Choose the Right Coverage

Web Hosting & Domains / HTTPS / Certificate planning

Choose wildcard SSL coverage for many subdomains at the same DNS level; choose a multi-domain certificate when a known set of hostnames should share one certificate. Separate certificates can be a better fit when services have different owners or renewal processes. Start with the exact hostnames and where HTTPS connections terminate, rather than choosing by the product label alone.

“SSL certificate” remains a common product name, although modern HTTPS uses TLS. This guide concerns website hostname coverage and operational choices. It does not compare encryption benchmarks or recommend a particular paid certificate vendor.

01 / List the hostnames and their owners

Write down every address visitors or applications actually use. Include the root domain, www, shops, portals, APIs, and any nested names. A certificate for the main website should not be assumed to cover a separate service just because it belongs to the same business.

For each hostname, record the hosting platform, the team responsible, and the place where the HTTPS connection is accepted: for example, a managed website platform, CDN, load balancer, or web server. Ask the provider whether certificate issuance and renewal are included.

Hypothetical inventory: a business uses example.com and www.example.com for its website, app.example.com for a portal, and login.app.example.com for a separate login service. It also owns example.net. These names create different coverage requirements even if one person manages their DNS.

Do not mix certificate planning with moving registration or DNS unless the project requires both. Our domain transfer vs DNS change guide explains those separate responsibilities.

02 / A wildcard matches one label at one level

RFC 9525’s hostname-matching rules restrict the wildcard to the complete leftmost label and allow it to match only one label. Apply that rule to the names themselves, not to the number of websites you run.

For the hypothetical login service, an explicit login.app.example.com entry can match that name. A *.app.example.com entry can match one level below app.example.com, but does not itself match app.example.com. More nesting does not become covered by adding a second asterisk to a hostname pattern.

A wildcard also does not create DNS records, provision an application, or install itself on servers. DigiCert’s wildcard deployment explanation distinguishes the names a certificate can represent from the work needed to deploy it at the service.

Use wildcard coverage when the namespace and operational ownership make sense together. Do not treat it as permission to distribute one private key to every server you operate.

03 / Multi-domain certificates list identities explicitly

A multi-domain certificate uses Subject Alternative Names, usually shortened to SANs, to hold several identities. The entries can represent names under different domains. A wildcard identifier can also appear in a SAN, so “SAN” and “wildcard” are not mutually exclusive technical categories.

DigiCert’s SAN certificate guide explains that the requested hostname must match an identity actually present. An entry for example.com does not automatically add www.example.com. Check the entire requested name list before issuance.

For the hypothetical business, a certificate listing its root, www, portal, and login names is one possible design. Independent managed certificates for the website platform and portal are another. Compare the actual deployment work before deciding that fewer certificate objects means less maintenance.

DigiCert notes that an expiration, revocation, or deployment problem with a shared certificate can affect all included names. Separate certificates can reduce that shared dependency, while requiring more individual lifecycles to manage.

04 / Confirm validation, automation, and key handling

Before a certificate authority issues a certificate, domain-control checks must succeed. The exact workflow depends on the authority, product, and hosting integration.

Let’s Encrypt confirms that it supports both multiple names and wildcard certificates. Its wildcard issuance requires DNS-01 validation. This is a requirement of that issuance workflow; do not assume a host’s ordinary HTTP-based automatic certificate feature includes wildcard support.

DNS-01 uses a DNS TXT record to prove control. For repeatable renewal, confirm that the ACME client or hosting integration can update the appropriate DNS records automatically. Manual certificate issuance is not a complete renewal plan.

Let’s Encrypt recommends narrowly scoped DNS API credentials or a separate validation system rather than placing unrestricted DNS credentials on a web server. Ask what permissions the integration needs, where its credentials are stored, and who can rotate them.

For the deployment itself, assign a named owner for:

• Renewal automation and failure alerts.
• Installation at every endpoint using the certificate.
• Any required service reload or platform deployment.
• Checking the certificate actually served after renewal.
• Private-key access, replacement, and incident response.

If a wildcard and its private key are copied across independently managed servers, a problem on one host can expose credentials used elsewhere. DigiCert’s key-distribution discussion describes this risk. Favor a design whose access and recovery responsibilities your team can maintain.

05 / Check CDN and origin certificates separately

When a CDN or reverse proxy handles HTTPS, the certificate a browser sees may be different from the one on the hosting server. Identify both connections in your inventory: visitor to edge, and edge to origin.

For example, Cloudflare’s Universal SSL limitations say that a full-setup zone’s standard coverage includes the root and first-level subdomains. Deeper names need an appropriate additional coverage option. The documentation distinguishes partial CNAME setups, where certificate provisioning behaves differently; do not apply the full-setup rule to every configuration.

Cloudflare also states that its edge certificate is served for proxied records. For a DNS-only record, the destination server is responsible for the visitor’s TLS connection.

At the origin, Full (strict) requires an unexpired certificate issued by an accepted authority and matching the requested or target hostname. Buying a new origin wildcard does not, by itself, change the names covered by an edge certificate.

For a managed platform, ask which connection it manages and what you must configure elsewhere. A dashboard showing “certificate active” is only useful when you know which endpoint and names it describes.

06 / Compare the complete cost and service scope

Do not assume wildcard or multi-domain coverage necessarily requires a paid certificate. Let’s Encrypt’s FAQ states that its certificates are free, while an integrating provider may charge for administration. Your host’s supported automation and service terms determine the practical options.

When comparing a paid offer with included hosting certificates, request the same scope from each supplier:

• The exact root, subdomain, and nested names covered.
• Who controls validation and renewal.
• Which servers, platforms, or CDN endpoints receive deployment.
• Support for adding names or changing infrastructure later.
• Alerting, recovery assistance, and any separately billed work.

Ask about product limits and charges using your actual inventory. Avoid a generic “unlimited subdomains” promise without checking the naming level and deployment conditions. Also ask whether the certificate product meets any organization-specific validation requirement.

Compare recurring operating work as well as the invoice. A certificate that is inexpensive to obtain can still require substantial manual installation if the chosen platform lacks an integration.

07 / Verify the issued names and live deployment

Before changing production traffic, use a written acceptance checklist. The certificate order, the stored certificate, and the certificate currently presented to a client are three things to compare.

1. Check the issued SAN list. Match each required hostname to an explicit entry or valid wildcard pattern.
2. Check the intended endpoint. Confirm where the certificate and private key are installed.
3. Open each public HTTPS hostname. Inspect certificate details and confirm the name, validity dates, and trust result.
4. Check redirects too. Test both the initial hostname and its destination rather than only the final page.
5. Verify origin separately where applicable. Use the provider’s supported diagnostic method and intended hostname.
6. Review renewal monitoring. Confirm who receives failures and who can fix the deployment.

If one hostname fails, record the exact name, certificate presented, endpoint, and error. A name mismatch, an expired certificate, a missing chain, and a routing problem need different fixes. Do not bypass the warning or weaken certificate verification to conceal an unresolved deployment problem.

Keep the inventory current after adding a shop, login portal, or new domain. A valid certificate for yesterday’s architecture does not establish coverage for a newly introduced hostname.

Frequently asked questions