A SAN certificate is a multi-domain TLS certificate that secures several distinct domain names in a single certificate using the Subject Alternative Name extension. This guide explains how to request a SAN certificate, when to choose one over wildcard or single-domain alternatives, and best practices for managing multi-domain certificates at scale.
A SAN certificate — also called a multi-domain certificate or Unified Communications Certificate (UCC) — is a single TLS/SSL certificate that secures multiple distinct domain names, subdomains, or IP addresses by listing each one in the Subject Alternative Name extension. Instead of purchasing and managing a separate certificate for every hostname, organizations can consolidate five, ten, or even a hundred domains onto a single certificate.
SAN certificates are the standard choice for environments where multiple unrelated domains need TLS protection under one deployment: Microsoft Exchange and Office 365 setups, SaaS platforms serving branded customer domains, CDN edge nodes, and multi-tenant hosting infrastructure. They offer a balance between the minimal coverage of a single-domain certificate and the subdomain-only flexibility of a wildcard certificate.
This guide focuses on the SAN certificate as a product — how to request one, when to choose it over alternatives, pricing considerations, and how to manage SAN certificates at enterprise scale. For a deep dive into the X.509 SAN extension itself, see the dedicated Subject Alternative Name guide.
A SAN certificate is a TLS/SSL certificate designed to protect multiple hostnames within a single certificate file. The term "SAN" refers to the Subject Alternative Name extension defined in the X.509 standard, which allows a certificate to list additional identities beyond the Subject Common Name.
In practice, every modern TLS certificate uses the SAN extension — browsers validate server identity against SAN entries, not the CN field. However, when the industry refers to a "SAN certificate," it specifically means a multi-domain certificate that lists several distinct fully qualified domain names (FQDNs) as SAN entries. A SAN certificate for a company might include `example.com`, `www.example.com`, `app.example.net`, and `portal.example.org` — all protected by one certificate and one private key.
Certificate Authorities (CAs) sell SAN certificates with a base number of included domains (typically 3 to 5) and offer additional SAN slots at an extra cost per domain. This pricing model makes SAN certificates the most economical option when you need to secure a moderate number of unrelated domains without purchasing individual certificates for each one.
The mechanics of a SAN certificate are straightforward. Every domain the certificate must protect is explicitly listed as a `dNSName` entry in the Subject Alternative Name extension. When a TLS client connects to a server, it compares the requested hostname against each SAN entry in the certificate. If any entry matches, the connection proceeds.
One critical detail: when you need to add a new domain to an existing SAN certificate, you cannot simply append it. You must submit a new CSR with the updated SAN list and have the CA reissue the certificate. Most commercial CAs allow free reissuance during the certificate's validity period, but the revalidation and redeployment process still takes time.
Compile the complete list of FQDNs, subdomains, and optionally IP addresses that the certificate must cover. Unlike a wildcard certificate, every hostname must be explicitly enumerated — there is no pattern matching.
Create a Certificate Signing Request that includes all target domains in the `extensionRequest` attribute. With OpenSSL, this requires a configuration file specifying each SAN. With most CA web portals, you simply enter the additional domains during the order process.
The Certificate Authority must validate control over every domain listed in the certificate. For DV certificates, this means completing a DNS challenge, HTTP challenge, or email challenge for each domain independently. This is the step that takes the most time when many SANs are involved.
After all domains pass validation, the CA issues a single certificate containing every domain in the SAN extension. The certificate also includes the full chain of trust needed for browsers to verify it.
Install the certificate and its private key on each server or load balancer that serves the listed domains. Every server presenting this certificate can respond to connections for any domain in the SAN list.
Choosing between a SAN certificate, a wildcard, and a single-domain certificate depends on your domain architecture and operational needs.
A single-domain certificate is the simplest and cheapest option, but it protects exactly one hostname. If you manage more than a handful of domains, the operational cost of tracking dozens of individual certificates quickly outweighs the savings.
A wildcard certificate covers unlimited subdomains under a single domain (e.g., `*.example.com`), but it cannot protect different base domains. It also cannot achieve EV validation. If your infrastructure spans multiple base domains, a wildcard alone is not enough.
A SAN certificate is the right choice when you need to secure several distinct domains — `example.com`, `example.net`, `brand.io` — under a single certificate. It supports EV validation, allows mixing domains and subdomains freely, and some CAs even allow combining wildcard entries with standard SANs in a single certificate.
Many organizations combine these approaches: a wildcard for `*.example.com` to cover internal subdomains, plus a SAN certificate for customer-facing domains across multiple brands.
Covers one FQDN. Adding a new name requires a new certificate. Available in DV, OV, and EV at the lowest cost. Best for single applications and microservices.
Covers one domain and all single-level subdomains. New subdomains are covered automatically. Available in DV and OV only (no EV). Medium cost. Best for many subdomains under one domain.
Covers multiple unrelated FQDNs. Adding a new domain requires reissuance with an updated SAN list. Available in DV, OV, and EV. Medium to high cost with per-SAN pricing. Best for multiple distinct domains, Exchange/O365, and multi-brand hosting.
The process of requesting a SAN certificate revolves around building a CSR that includes all the domains you need. Here is how to add SANs in a certificate request using OpenSSL, the most common tool.
For environments using automated certificate management, tools that support the ACME protocol can programmatically request SAN certificates by specifying multiple domain identifiers in the certificate order. This eliminates manual CSR creation and validation entirely.
Write a config file (e.g., `san.cnf`) that defines your SAN entries. Under the `[req]` section, set `req_extensions = v3_req`. Under `[v3_req]`, add `subjectAltName = @alt_names`. Under `[alt_names]`, list each domain: `DNS.1 = example.com`, `DNS.2 = www.example.com`, `DNS.3 = app.example.net`, `DNS.4 = portal.example.org`. You can also add IP addresses with `IP.1 = 192.168.1.1` if needed.
Run `openssl req -new -newkey rsa:2048 -nodes -keyout multi.key -out multi.csr -config san.cnf`. This produces a private key and a CSR containing all your SAN entries. For stronger security, use `-newkey rsa:4096` or generate an ECDSA key with `openssl ecparam -genkey -name prime256v1`.
Before submitting, inspect the CSR with `openssl req -text -noout -in multi.csr` and confirm every domain appears under "X509v3 Subject Alternative Name." Missing a domain at this stage means reissuing the certificate later.
Upload the CSR through your CA's portal or API. Most CAs also provide a web form where you can enter additional SANs during the order, which the CA appends to whatever is already in the CSR. Select the number of SAN slots your plan includes and add extra slots if your domain count exceeds the base.
The CA sends a validation challenge for every domain in the SAN list. For DNS validation, you create a TXT record for each domain. For HTTP validation, you place a file on each domain's web server. All domains must pass validation before the certificate is issued.
Retrieve the issued certificate, install it alongside the private key on your server, and configure your web server or load balancer to present it for all listed domains.
Exchange servers require certificates covering multiple hostnames: `mail.example.com`, `autodiscover.example.com`, `owa.example.com`, and the server's internal FQDN. A SAN certificate is the standard solution recommended by Microsoft for Exchange and hybrid Office 365 deployments.
Companies operating multiple brands or product lines under different domains — `brand-a.com`, `brand-b.com`, `brand-c.io` — can consolidate all domains onto a single SAN certificate, reducing the number of certificates to manage and renew.
SaaS providers that allow customers to use their own domains need a certificate covering every customer domain. A SAN certificate with a high SAN limit (some CAs support 100+ entries) can handle this, though automated management becomes essential at scale.
A single load balancer terminating TLS for multiple backend applications can use one SAN certificate instead of managing separate certificates for each application. This simplifies configuration and reduces the number of certificates stored on the device.
VoIP platforms, video conferencing servers, and messaging systems often expose multiple service endpoints under different hostnames. UC-specific SAN certificates (UCCs) are designed for this exact scenario, commonly used with Microsoft Skype for Business and Lync.
Teams that maintain parallel environments across multiple domains — `dev.example.com`, `staging.example.net`, `test.example.org` — can use a single SAN certificate to provide valid TLS across all environments without individual certificate management.
SAN certificate pricing follows a base-plus-per-SAN model. A typical commercial SAN certificate includes 3 to 5 domains in the base price, with additional domains costing between $10 and $50 per SAN per year depending on the CA and validation level.
Key cost factors to evaluate:
- Base SAN count: Some CAs include more base SANs than others. If you need 10 domains, a CA offering 5 base SANs is cheaper than one offering 3. - Maximum SAN limit: CAs typically cap SAN certificates at 100 or 250 entries. If you approach these limits, you may need multiple certificates regardless. - Reissuance policy: Confirm that adding or removing SANs via reissuance is free during the certificate's validity period. Most major CAs allow unlimited reissuance. - Validation level: OV and EV SAN certificates cost significantly more per SAN than DV certificates. Evaluate whether the visual trust indicators of EV justify the premium for your use case. - Free alternatives: Let's Encrypt and other ACME-based CAs issue SAN certificates at no cost, with up to 100 SANs per certificate. For organizations with the automation infrastructure to handle frequent renewals, this eliminates certificate costs entirely.
SAN certificates simplify deployment by consolidating domains, but they introduce their own management complexity. Every time a domain is added, removed, or changed, the entire certificate must be reissued and redeployed to every server that uses it. In large environments, this creates coordination challenges that manual processes cannot handle reliably.
The main operational risks with SAN certificates at scale are:
Reissuance cascades. Adding one domain to a 50-SAN certificate triggers revalidation, reissuance, and redeployment across every server presenting that certificate. Without automation, this is error-prone and time-consuming.
Blast radius. If the private key of a SAN certificate is compromised, every domain on the certificate is exposed. The more domains on the certificate, the larger the blast radius. Organizations must weigh consolidation benefits against this risk.
Renewal coordination. When a SAN certificate expires, every domain it protects loses TLS simultaneously. A missed renewal is not a single-domain outage — it is a multi-domain outage. Proactive monitoring and automated renewal workflows are essential.
SAN list drift. Over time, domains are added and removed from SAN certificates without centralized tracking. The result is certificates protecting domains that no longer exist and missing domains that were supposed to be covered. A certificate inventory that tracks every SAN entry is the only defense against this drift.
Only include domains that genuinely need to share a certificate. Every additional SAN increases the blast radius of a key compromise and the coordination cost of reissuance. If domains have different security requirements or lifecycle schedules, use separate certificates.
Manual CSR creation for multi-domain certificates is the most common source of errors — missed domains, typos, and forgotten SANs. Use automated tooling or a CLM platform that generates CSRs programmatically and handles per-domain validation.
Document your reissuance workflow before the first time you need to add a domain. Know which CA portal or API to use, who has authorization to modify the SAN list, and how the updated certificate reaches every deployment point.
A SAN certificate expiring is a multi-domain event. Set up alerts well in advance of expiration — 90, 60, and 30 days — and verify that every server presenting the certificate receives the renewed version.
Some CAs allow wildcard entries (e.g., `*.example.com`) alongside standard SANs in the same certificate. This lets you cover unlimited subdomains under one domain while also including unrelated domains, giving you maximum flexibility in a single certificate.
The private key for a SAN certificate protects every domain listed. Store it in a hardware security module or secure vault, limit distribution to the minimum number of systems, and rotate it on every renewal cycle.
Centralized SAN certificate inventory — Evertrust CLM discovers and tracks every SAN certificate in your infrastructure, providing full visibility into which domains are covered, where each certificate is deployed, and when it expires. No more SAN list drift or surprise expirations.
Automated multi-domain enrollment — Request SAN certificates through a single interface, with Evertrust handling CSR generation, SAN list assembly, and per-domain validation automatically. Add or remove domains and trigger reissuance without manual intervention.
Policy control over SAN composition — Define rules governing which domains can appear on the same certificate, maximum SAN counts, required validation levels, and allowed domain patterns. Evertrust enforces these policies at request time, preventing certificate sprawl and security misconfigurations.
Lifecycle automation at scale — Evertrust monitors every SAN certificate, triggers renewal before expiration, and deploys updated certificates to all affected servers. Whether you manage 10 SAN certificates or 10,000, the renewal process is fully automated and auditable.
