Three Names, One Certificate: Resolving the Terminology
Multi-domain SSL certificate, SAN SSL certificate, and Unified Communications Certificate (UCC) are three names for the same product type. They describe a TLS certificate that can secure multiple fully qualified domain names (FQDNs), subdomains, and IP addresses in a single certificate through the Subject Alternative Name (SAN) extension in the X.509 certificate structure.
The three names come from three different audiences:
- SAN certificate: The technically accurate name. SAN refers to the X.509 extension (Subject Alternative Name, defined in RFC 5280) that allows a certificate to list multiple hostnames. Every multi-domain certificate uses the SAN extension.
- Multi-domain SSL certificate: The plain-English marketing name that hosting providers and resellers use. No technical meaning beyond what SAN describes; exists so buyers can find the product without knowing X.509 terminology.
- UCC / Unified Communications Certificate: Microsoft’s name for this certificate type, coined when Exchange Server and Office Communications Server required certificates covering multiple hostnames per server before SNI (Server Name Indication) was widely supported. The UCC label stuck in enterprise environments for any multi-domain certificate used with Microsoft products.
When shopping for this certificate type, searching any of the three terms returns the same product from any CA. Sectigo calls it PositiveSSL Multi-Domain. DigiCert calls it Secure Site Multi-Domain. SSL.com calls it UCC/SAN. The underlying certificate is identical.
What a Multi-Domain Certificate Is and How It Works
A multi-domain certificate contains a SAN extension listing all the hostnames the certificate is valid for. When a client connects to any of those hostnames, the server presents this single certificate, and the client validates the hostname against the SAN list. If the connecting hostname appears in any SAN entry, the certificate is valid for that connection.
A single certificate might list: example.com, www.example.com, shop.example.com, example.net, www.example.net, mail.example.org, and api.example.io. All different domains, different TLDs, different subdomains. One certificate, one private key, one renewal event.
The SAN extension can include: DNS names (dNSName entries for hostnames), IP addresses (iPAddress entries for services accessed by IP rather than hostname), wildcards in dNSName entries (allowing *.example.com to be a SAN entry within a multi-domain certificate), email addresses (rfc822Name entries, relevant for S/MIME but rarely used in TLS certificates), and URIs.
The number of SANs a certificate can technically contain is large. Most commercial CAs offer packages starting with 3 to 5 SANs at base price, with additional SANs purchasable in increments. SSL.com’s UCC/SAN supports up to 500 SANs per certificate. For practical purposes, most deployments use far fewer.
A multi-domain certificate is not the same as a wildcard certificate and not a substitute for one. A wildcard covers all single-label subdomains of one domain (*.example.com). A multi-domain certificate covers a specific list of explicitly named hostnames, potentially across completely different domains (example.com and example.net). A multi-domain wildcard certificate combines both: it includes wildcard SAN entries alongside explicit SAN entries, covering all subdomains of multiple domains.
Why UCC Certificates Exist: The Exchange and Pre-SNI Context
Understanding why the UCC name exists requires a brief historical detour into how HTTPS worked before Server Name Indication (SNI) became universal.
Before SNI, every TLS-protected hostname required its own dedicated IP address. A server could host multiple websites but TLS required the server to present a certificate before it knew which hostname the client was requesting. Without SNI, the server presented one certificate for one IP address. Organizations running multiple HTTPS services on a server needed multiple IP addresses or a certificate that covered all the hostnames at once.
Microsoft Exchange Server is the canonical example. A standard Exchange deployment needs to respond to several different hostnames: the server’s internal FQDN (mail.corp.example.com), the external mail hostname (mail.example.com), the Autodiscover service (autodiscover.example.com), the Outlook Web Access URL (owa.example.com), ActiveSync endpoints, and Lync/Skype for Business URLs if applicable. Before SNI, all of these hostnames had to be on one certificate for them to work correctly when accessed via HTTPS.
Microsoft coined the term Unified Communications Certificate for the multi-SAN certificate covering all these Exchange hostnames. The term unified referred to unifying the certificate for all the communications endpoints that Exchange served. When SNI became broadly supported (all modern browsers and servers support it), the specific IP-sharing rationale became less critical, but Exchange still requires all its hostnames to be on a single certificate because Exchange’s certificate management processes are designed around that assumption.
Multi-Domain Certificates for Microsoft Exchange: The SANs Required
If you are configuring a multi-domain certificate for a Microsoft Exchange Server deployment, the specific SAN entries required depend on your Exchange version and configuration. A typical modern on-premises Exchange hybrid deployment requires the following SAN entries:
| SAN entry | Purpose | Required for |
| mail.yourdomain.com | Primary external mail and OWA hostname | All Exchange deployments with external access |
| autodiscover.yourdomain.com | Autodiscover service for Outlook auto-configuration | All deployments where Outlook clients auto-configure |
| exchserver.yourdomain.com (internal FQDN) | Internal server FQDN for server-to-server connections | On-premises deployments |
| exchserver (NetBIOS name) | Short name for internal connections (some configurations) | Legacy configurations; less common in modern Exchange |
| owa.yourdomain.com | Outlook Web Access if using a separate OWA hostname | OWA deployments with dedicated hostname |
| activesync.yourdomain.com | ActiveSync mobile device connections if separate hostname | Mobile ActiveSync with dedicated endpoint |
| meet.yourdomain.com / dialin.yourdomain.com | Skype for Business / Lync meeting and dial-in URLs | SfB/Lync on-premises integration |
| *.yourdomain.com (wildcard SAN) | Covers all subdomains in one entry if needed | When subdomain coverage preferred over explicit listing |
For Office 365 hybrid deployments (Exchange Online with on-premises connector), the SAN requirements focus on the on-premises endpoints: the internal Exchange server FQDN, the Autodiscover endpoint, and the hybrid mail flow hostname. The Office 365 side uses Microsoft’s own certificates.
When planning an Exchange certificate, generate a list of all hostnames that appear in your Exchange configuration by running the Get-ExchangeCertificate and Get-ClientAccessService cmdlets in the Exchange Management Shell. This gives you the exact list of hostnames Exchange expects to use, which maps directly to the SAN entries you need on the certificate. Ordering a certificate with missing SANs is a common source of Exchange connectivity errors.
Multi-Domain Certificates Beyond Exchange: Modern Use Cases
The UCC/Exchange framing makes multi-domain certificates sound like a legacy enterprise product. In practice, multi-domain certificates are used across a wide range of modern deployments.
Multi-brand and multi-property web hosting
Organizations running multiple websites across different domains (a parent company and several subsidiary brands, a media company with multiple publications, a SaaS company with separate marketing site and app domain) can consolidate under one certificate covering all their public-facing domains. Management simplification is the primary benefit: one renewal event, one certificate in inventory, one monitoring alert to track.
API and service endpoints
A single organization might operate api.example.com, app.example.com, cdn.example.io, and status.example.net. These are different hostnames, potentially on different servers, serving different functions, but all representing the same organization’s infrastructure. A multi-domain certificate covering all of them allows consistent certificate management across the infrastructure without requiring a wildcard that covers subdomains the organization does not use.
Internal network services
Multi-domain certificates are the right choice for internal services accessed by both hostname and IP address. An internal monitoring dashboard might be accessed as monitoring.corp.example.com by some systems and by its IP address (192.168.1.50) by others. A single certificate with both a dNSName SAN for the hostname and an iPAddress SAN for the IP address covers both access patterns.
Internal private CA certificates (from AD CS or similar) can also be issued as multi-domain certificates and are not subject to the public CA rate limits and validation requirements that apply to publicly trusted certificates.
Testing and staging environments
Development teams running staging.example.com, uat.example.com, demo.example.com, and test.example.com can cover all staging environments under a single certificate. The alternative is managing separate certificates for each environment, which multiplies the renewal and monitoring burden without adding security value.
Operational Features: Adding, Removing, and Managing SANs
A significant operational advantage of paid multi-domain certificates from commercial CAs is the ability to modify the SAN list and have the certificate reissued within the same validity period. If you add a new domain to your infrastructure mid-cycle, you do not need to purchase a new certificate. You request a reissuance with the updated SAN list, the CA validates the new domain(s), and a new certificate is issued with the revised list and the same expiry date.
This contrasts with a certificate issued with a fixed hostname baked in at purchase time. The ability to add SANs during the validity period is a meaningful operational feature for organizations whose domain list evolves over time.
The process for reissuance varies by CA. Most require: generating a new CSR (Certificate Signing Request) that includes all SANs including new ones, submitting a reissuance request to the CA’s management portal, completing domain validation for any newly added domains, and receiving the updated certificate. The private key typically stays the same unless you generate a new CSR with a new key.
When a multi-domain certificate is reissued to add or remove SANs, the new certificate must be deployed to all servers that use it. If you add example.net to an existing certificate and only deploy the new certificate to one server, the other servers continue presenting the old certificate without example.net coverage. Deploy the updated certificate to all servers in the configuration after every reissuance.
Validation Levels for Multi-Domain Certificates
Multi-domain certificates are available at all three validation levels. The validation level determines what appears in the certificate’s identity fields and what the CA verifies.
| Validation level | What the CA verifies | Publisher shown | Right for |
| DV (Domain Validated) | Domain control for each SAN entry | Domain names only; no organization name | Personal sites, developer tools, internal services, non-enterprise deployments |
| OV (Organization Validated) | Domain control plus legal organization name, address, authorized requestor | Verified organization name in certificate details | Business sites, enterprise deployments, any context where organization identity matters |
| EV (Extended Validation) | All OV requirements plus multi-document legal existence and operational verification for each domain in scope | Verified organization name via full extended validation | High-value transactional sites, financial services, contexts requiring the strongest identity assurance across multiple domains |
For Exchange and Microsoft infrastructure deployments, OV is the standard choice: it covers the organization name in the certificate details that IT administrators see when inspecting certificates, and it satisfies enterprise procurement requirements that often specify OV or better.
EV multi-domain certificates exist and are available from CAs like SSL.com (Enterprise EV UCC/SAN at $399/year with $1.75M warranty). These are appropriate for organizations that need verified EV identity across all of their public-facing domains simultaneously.
Multi-Domain vs Single-Domain vs Wildcard: Which Fits Your Situation
| Certificate type | What it covers | Right when | Not right when |
| Single-domain | One specific hostname (e.g., www.example.com) | You have one or two hostnames to secure | You have three or more hostnames; cost per hostname becomes inefficient |
| Wildcard | All first-level subdomains of one domain (*.example.com) | You have many subdomains of one domain and the list is growing or unknown | You need to cover multiple different domains (example.com and example.net); you need second-level subdomain coverage |
| Multi-domain / SAN / UCC | Specific list of named hostnames across any domains | You have a defined list of different domains or subdomains to secure; Exchange deployments; you want a single certificate across multiple brands | You have an unlimited or rapidly growing list of subdomains (wildcard is better); you need coverage that automatically includes future subdomains |
| Multi-domain wildcard | Wildcard SAN entries plus explicit SANs in one certificate | You need to cover all subdomains of multiple domains simultaneously | Overkill and more expensive when simpler options suffice |
The 200-Day Validity Limit and SAN Planning
The CA/B Forum reduced the maximum TLS certificate validity period to 200 days effective March 2026. This affects multi-domain certificate planning in a specific way: because reissuance is more frequent, the SAN planning conversation happens more often.
Previously, with two-year certificates, organizations tolerated a somewhat stale SAN list: domains that had been decommissioned were still on the certificate because getting a reissuance was an effort worth deferring. At 200-day validity, the certificate renewal cycle naturally creates opportunities to review and update the SAN list more frequently.
The operational implication: maintaining a documented inventory of all hostnames covered under each multi-domain certificate becomes more important. At renewal time, the SAN list should be reviewed: remove decommissioned hostnames (which reduces unnecessary certificate scope), add newly required hostnames, and confirm domain validation credentials are current for all entries. Automated certificate management platforms that integrate with DNS and ACME make this process systematic rather than manual.
Frequently Asked Questions
What is the difference between a multi-domain SSL certificate, a SAN certificate, and a UCC?
They are the same type of certificate described by different names. Multi-domain SSL is the plain-English marketing term. SAN certificate is the technically accurate name, referring to the Subject Alternative Name extension in X.509 that lists all the covered hostnames. UCC (Unified Communications Certificate) is Microsoft’s term for this certificate type, coined for Exchange and Office Communications Server deployments that require multiple hostnames on one certificate. All three names describe a certificate that covers multiple FQDNs, IP addresses, or subdomain patterns in a single certificate.
How many domains can a multi-domain SSL certificate cover?
Commercially available multi-domain certificates typically start at 3 to 5 domain slots at base price, with additional slots purchasable in increments. The maximum varies by CA: many offer up to 100 or 250 SANs per certificate; SSL.com’s UCC/SAN supports up to 500 SANs. For practical deployments, most organizations use between 3 and 20 SANs. There is no browser or OS limitation on SAN count; the limit is set by the CA’s product configuration.
Do I need a UCC certificate for Microsoft Exchange?
Yes, Exchange Server requires a single certificate covering all the hostnames Exchange uses: at minimum the external mail hostname (mail.domain.com) and the Autodiscover hostname (autodiscover.domain.com), plus the internal server FQDN. Exchange’s certificate management expects all relevant hostnames to be on one certificate. The specific SANs required depend on your Exchange version and which services (OWA, ActiveSync, Lync/SfB) are configured. A single OV multi-domain certificate covering all Exchange hostnames is the standard approach.
Can a multi-domain certificate include wildcard entries?
Yes. A multi-domain certificate can include dNSName SAN entries that use the wildcard pattern (*.example.com) alongside specific hostname entries. This is the multi-domain wildcard certificate type: one certificate might include *.example.com (covering all example.com subdomains), *.example.net (covering all example.net subdomains), and specific.otherdomain.org (an explicit entry for a different domain). Mixing explicit and wildcard SANs in one certificate is supported and useful for organizations with multiple domains each requiring subdomain coverage.
Can I add domains to a multi-domain certificate after purchase?
Yes, most commercial CAs allow adding SANs to a multi-domain certificate and reissuing it within the same validity period. You submit a reissuance request with the updated SAN list, complete domain validation for any new domains, and receive a new certificate with the updated list and the original expiry date. The ability to add domains mid-cycle is a key operational advantage of multi-domain certificates over buying separate single-domain certificates for each hostname.
