Multi-Domain Wildcard SSL Certificates

A multi-domain wildcard SSL certificate combines two products into one: a multi-domain (SAN) certificate and a wildcard certificate. Instead of buying both separately or running multiple certificates across your infrastructure, you cover several distinct domains and the subdomains under each from a single issued certificate.

The mechanics rest on the SAN field. SAN, or Subject Alternative Name, is an X.509 extension that lists every domain a single certificate covers. Inside that field, entries can be regular domain names, wildcard entries, or a mix of both.

A typical configuration looks like this:

• example.com
• *.example.com
• *.brand.net

That single certificate now secures the bare example.com, every first-level subdomain under it (shop.example.com, blog.example.com, and so on), and every first-level subdomain under brand.net.

Most products in this category support up to 250 SANs in total, though some brands cap lower by default and others go higher. Note that the wildcard character * covers exactly one subdomain level.

Picking between the three comes down to your domain shape:

• Run one website with many subdomains? A wildcard handles it.
• Have several separate websites with no subdomain structure to worry about? A multi-domain (SAN) certificate is cheaper and simpler.
• Once you have several websites and subdomains under each, the multi-domain wildcard is the only product that covers both patterns in one certificate, which is why buyers with portfolios of brands or hosted client domains end up here.

Multi-domain wildcard certificates are issued at two validation levels: Domain Validation and Organization Validation. Each verifies something different about the requester before the certificate is issued.

• DV only verifies that the applicant controls the listed domains.
  Validation runs through one of three methods (email, DNS record, or HTTP file check) and certificates are issued in minutes. Personal sites and dev/test environments fit here, alongside internal tools and SaaS platforms where speed matters more than displayed organization identity.
• OV verifies the requesting business through official records:
  Business registration, registered address, and a callback to a verified phone number. Issuance takes 1–2 business days. The verified business name appears in the certificate details, where buyers and security teams (and procurement reviewers, in larger deals) can see it. E-commerce sites, regulated industries, and any property where the certificate’s identity claim has commercial value benefit from the OV check.

Extended Validation is not offered for any multi-domain wildcard product, anywhere.

The CA/Browser Forum’s Baseline Requirements prohibit wildcard SAN entries on EV certificates, and the rule applies to any certificate that includes even one wildcard entry. This has been the case since EV was first defined and has not changed. Pages claiming an “EV multi-domain wildcard” exists are wrong. If you need EV for one specific domain, buy that as a separate EV single-domain certificate alongside your multi-domain wildcard.

One last point worth stating directly: encryption strength is identical across DV, OV, and EV. All three negotiate the same 256-bit symmetric encryption during the TLS handshake. Validation level changes what the CA verifies about the requester, not what gets encrypted on the wire.

On April 11, 2025, the CA/Browser Forum approved Ballot SC-081v3, a phased schedule that compresses the maximum lifespan of every public TLS certificate down to 47 days. The schedule has three phases:

• Phase 1 — already in effect since March 15, 2026: maximum public TLS certificate validity is now 200 days.
• Phase 2 — March 15, 2027: the cap drops to 100 days.
• Phase 3 — March 15, 2029: the cap drops to 47 days.

The rule applies to all public TLS certificates, every validation level (DV, OV, EV), and every product type: wildcard, multi-domain, and multi-domain wildcard included.

Multi-domain wildcard buyers feel the change harder than single-cert buyers. A renewal here is heavier because you re-prove control of each domain in the SAN list, not just one. As the validity ceiling drops, that operational cost compounds. By 2029, you’ll be running that renewal cycle roughly every 6–7 weeks. Anyone planning multi-year operations on a portfolio of domains should be thinking about automation now, not in 2029.

If you’re ready to automate, start with our ACME page. One honest caveat: not every multi-domain wildcard product on the market is equally automation-friendly. DV products with simple domain control checks automate cleanly; OV products that require organization re-validation cycles add friction that ACME alone won’t remove.

SSL Dragon carries EV certificates from four Certificate Authorities.

• Multi-brand corporate portfolios
  A company that owns several brand domains plus subdomains under each (brandA.com, *.brandA.com, brandB.net, *.brandB.net) can replace four or more separate certificate purchases with one issued certificate.
• SaaS platforms with tenant subdomains
  When every customer gets a custom subdomain like customer1.app.com and customer2.app.com, wildcard coverage on the app domain handles unlimited tenants. The remaining SAN slots cover the marketing site, status page, and API on different domains.
• Hosting providers and agencies
  Managing client domains across many brands, all served from shared infrastructure, fits this product cleanly. One certificate, one renewal cycle, one private key to rotate.
• Microsoft Exchange and Communications environments
  Multi-domain wildcards function as Unified Communications Certificates (UCC), which is what Exchange requires when it needs multiple service hostnames — autodiscover, mail, webmail, and others — represented on the same certificate.

1. All listed domains are public on the certificate. Anyone who clicks the padlock and inspects the certificate details can read every domain in the SAN list. If you don’t want two of your brands publicly associated with each other, use separate certificates instead.
2. A wildcard SAN doesn’t automatically cover the bare domain. A SAN entry of *.example.com covers mail.example.com and shop.example.com, but it does not cover example.com itself. Add the bare domain as its own SAN if you need it.
3. Standard wildcards cover one subdomain level. *.example.com covers mail.example.com but not dev.mail.example.com. To secure deeper levels, add the deeper wildcard as a separate SAN entry such as *.mail.example.com.
4. Reissues are free, but the expiration date carries over. Adding or removing a SAN mid-cycle doesn’t reset the clock; the new certificate inherits the original expiration date. For DV products, no re-validation is required to modify SANs; for OV products, the existing organization validation can typically be reused if the change happens within the validity window.