What is a Multi Domain SSL? SAN SSL Certificate Information

Last updated: Nov 1, 2025

A Multi-Domain SSL certificate, also known as a SAN SSL certificate or Subject Alternative Name certificate, is a type of digital certificate designed to secure multiple domains and subdomains using a single certificate. Instead of managing separate certificates for each domain, website administrators can protect all of them under one certificate using the SAN (Subject Alternative Name) extension field. This makes SAN SSL certificates particularly useful for organizations managing diverse domain portfolios, web hosting providers serving multiple client sites, or businesses using Microsoft Exchange or Office 365 servers where multiple DNS names are involved.

Unlike traditional SSL certificates that can secure only one domain (e.g., example.com), SAN SSL certificates include additional domain names in the certificate’s Subject Alternative Name field. These names can include:

• Primary domain (e.g., example.com)

• Additional domain names (e.g., example.net)

• Subdomains (e.g., blog.example.org)

• Related services (e.g., mail.example.com, autodiscover.example.com)

By placing all these hostnames into a single SAN certificate, site owners eliminate the need for separate renewal, installation, and management cycles for each domain. This ensures streamlined SSL certificate lifecycle management while enhancing compatibility on most major browsers including Google Chrome, Firefox, Safari, and Microsoft Edge.

SAN SSL vs. Traditional SSL

A traditional or single-domain SSL certificate protects only one fully qualified domain name (FQDN). On the other hand, a SAN or Multi-Domain SSL certificate supports securing multiple domain names, whether they are related or completely different. This flexibility makes SAN SSL a preferred choice for complex environments where each hostname represents a separate service, platform, or product.

Multi-domain certificates are often issued as UCC SSL certificates (Unified Communications Certificates) in environments like Microsoft Exchange or SharePoint servers, where multiple domain names must be secured under one certificate for features such as mail.example.com, autodiscover.example.com, and owa.example.com.

Why the SAN Field Matters

Historically, SSL certificates relied on the Common Name (CN) field to establish the primary domain being secured. Today, however, browser and server behavior has shifted toward relying on the SAN (Subject Alternative Name) extension as the canonical source of domain identity. This shift is due to security, flexibility, and scalability considerations. SSL certificates that include only the CN and do not properly configure a SAN field may trigger warnings or errors across major browsers.

As a result, the modern multi-domain SSL certificate must be configured properly with all intended domain names listed in the SAN field, even if one of the names also appears as the CN. This is one of the most important considerations in avoiding certificate name mismatch errors during deployment.

Multi-Domain SSL vs Wildcard SSL vs Single-Domain SSL: What’s the Difference?

Understanding the difference between Multi-Domain SSL, Wildcard SSL, and Single-Domain SSL certificates is critical for making the right decision when securing your website or server environment with HTTPS. Although they all offer TLS encryption, each certificate type works differently, protects a different scope of domains or subdomains, and has different management and cost implications.

Choosing the wrong one can result in operational overhead, increased security risks, or even certificate reissues during scaling or domain changes. Below is a detailed comparison to help you decide which SSL certificate type fits your use case.

Single-Domain SSL Certificate

A Single-Domain SSL Certificate is the most basic type of certificate. It secures only one fully-qualified domain name (FQDN), such as www.example.com.

• It does not cover subdomains like mail.example.com unless explicitly issued for that subdomain.

• It’s commonly used for small websites with a single hostname or landing page.

• If your website grows or requires additional domains, you will need to deploy more certificates or migrate to a wildcard or multi-domain certificate.

Best for: Individual websites, single online stores, small business sites with no subdomains.

Wildcard SSL Certificate

A Wildcard SSL Certificate secures one domain and all its first-level subdomains, using an asterisk (*) as a placeholder. For example, a wildcard certificate for *.example.com secures:

• blog.example.com

• shop.example.com

• mail.example.com

However, a wildcard SSL does not secure multiple different domains. It only works for subdomains belonging to a single base domain. Wildcard SSL is a great option for organizations hosting multiple subdomains under one primary domain, such as a SaaS company using region-based subdomains (us.example.com, eu.example.com).

Best for: Websites with many subdomains, SaaS platforms, multi-regional brands using subdomain-based routing.

Multi-Domain SSL Certificate (SAN SSL / UCC SSL)

A Multi-Domain SSL certificate, also known as a SAN SSL certificate, secures multiple domains and subdomains within a single certificate, regardless of whether they share the same base domain.

One SAN SSL certificate can secure:

• example.com

• example.net

• shop.example.org

• mail.brand.com

• portal.example.co.uk

Unlike wildcard certificates, multi-domain SSL is not limited to subdomains. It can secure completely different top-level domains, with or without subdomains. Many multi-domain certificates also allow wildcard entries in the SAN list, depending on the issuing CA, making this type the most flexible of all SSL options.

Best for: Organizations with several domain names, agencies managing multiple client websites, Microsoft Exchange Servers, hosting platforms, or businesses with different product/domain portfolios.

---

Comparison Table: Single-Domain SSL vs Wildcard SSL vs Multi-Domain SSL

---

How to Choose the Right SSL Option

Deciding between a multi-domain SSL, wildcard SSL, or single-domain SSL certificate depends on your website architecture, internal infrastructure, and long-term management plans.

• If you’re securing just one domain, a single-domain certificate is the simplest and cheapest option.

• If you’re using a single domain but need to support any number of first-level subdomains, wildcard SSL is a better match.

• If you need to secure multiple domains and subdomains, a multi-domain SSL certificate with SAN support offers the most flexibility and future-proofing.

In mainline enterprise environments such as Microsoft Exchange, Office 365, and unified communications servers, the multi-domain SAN SSL certificate is commonly used, often referred to as a UCC SSL certificate (Unified Communications Certificate). This allows administrators to secure a wide array of hostnames, including mail.domain.com, autodiscover.domain.com, and additional aliases, all under one certificate.

Common Use Cases for Multi-Domain SSL Certificates (SAN / UCC)

A Multi-Domain SSL certificate—often referred to as a SAN SSL certificate or UCC SSL certificate—is specifically designed to secure several hostnames within a single SSL installation. This makes it a powerful, flexible choice for organizations or platforms that need to protect multiple domains, subdomains, or services simultaneously.

While single-domain and wildcard certificates are effective for simpler site structures, the multi-domain SSL is ideal for more dynamic and complex environments. It is frequently deployed across enterprise-grade infrastructure, SaaS platforms, hosting providers, and Microsoft Exchange-based communication systems.

Below are some of the most common and practical use cases where a SAN SSL certificate offers clear advantages over traditional alternatives.

1. Microsoft Exchange, Office 365, and Unified Communications Environments

The SAN SSL certificate is widely adopted for securing Microsoft Exchange services due to the number of different domain names and services involved in a modern Exchange deployment. These may include:

• mail.example.com

• autodiscover.example.com

• owa.example.com

• lyncdiscover.example.com (for Skype for Business or Lync)

Unified Communications Certificates (UCCs) are essentially SAN SSL certificates designed to work seamlessly with Microsoft products such as Exchange Server, Skype for Business, Microsoft 365 Hybrid environment, or Outlook Web Access (OWA). Instead of installing separate certificates for each hostname, administrators can secure all endpoints within a single SAN certificate, simplifying installation, renewal, and ongoing domain management.

This is also beneficial for Outlook and mobile clients, which perform strict certificate name checks for encrypted communication. A missing SAN entry on Exchange often results in name mismatch or trust errors, interrupting email and calendaring connectivity.

2. SaaS Platforms and Multi-Tenant Architecture

Many SaaS companies host multiple custom domains or user-facing portals under different top-level domain names. For example, a CRM provider may allow each customer to use their own branded subdomain or domain, such as:

• client1-software.com

• portal.client2.net

• dashboard.client3.org

Instead of issuing individual certificates for each customer domain—a costly and technically burdensome approach—SaaS providers can use a SAN SSL certificate to secure all these address variations in one deployment, while still enforcing HTTPS everywhere.

This is especially useful when the architecture uses a shared backend or load balancer with SNI (Server Name Indication), allowing the server to present the correct certificate based on the domain requested by the user.

3. Multi-Brand or Multi-Product Companies

Businesses that operate multiple brands or web properties often host sites on entirely different domains. For example:

• brand-a.com

• brand-b.com

• brand-c.net

If these are managed by the same internal team or under a centralized hosting platform, a Multi-Domain SSL certificate offers an efficient way to secure them altogether, rather than purchasing and managing multiple certificates with staggered expiration and validation cycles.

This approach reduces certificate sprawl, simplifies renewals, and ensures that final users see consistent HTTPS trust indicators across all digital assets of the company.

4. Hosting Providers and Web Development Agencies

Agencies and hosting providers often manage websites and online services for multiple clients. Since each client may require their own domain name (or even multiple domains for staging, production, development, etc.), a SAN SSL certificate can improve efficiency when securing shared server environments.

Providers can enroll multiple client domains under a single SAN certificate—often used in managed VPS hosting or shared cloud orchestration—with the added ability to include or remove SAN entries as sites launch, rebrand, or retire.

This is especially true for platforms that support multi-tenant IIS, Nginx, or Apache configurations using SNI. It eliminates the need for one certificate per client while maintaining individual domain isolation and encryption.

5. Web Apps and Multi-Region Deployments

Some applications use distinct domains to serve regional or country-specific content (e.g., us.example.com, uk.example.com, de.example.com) or serve multiple brands or product lines across different domains under the same infrastructure. A SAN SSL certificate can unify these domains under one certificate deployment, reducing the need to configure SSL per region or subservice.

This multi-domain functionality becomes especially valuable in auto-scaling environments where new regions or endpoints may be added on-demand. With the right validation and certificate issuing process, SAN updates can be rolled out quickly without replacing the full infrastructure or certificate chain.

How SAN Certificates Work Technically (X.509, SAN, CN, and Browser Trust)

To truly understand what makes a Multi-Domain SSL certificate (SAN certificate) different from other SSL types, it’s important to look at how they work internally. SAN certificates rely on the X.509 certificate format, which is the standard structure for SSL/TLS certificates used across the internet. They contain various fields that define the certificate’s identity, validity, signature, and issuer information — but the most important field for multi-domain support is the Subject Alternative Name (SAN) extension.

The X.509 Certificate Structure

An X.509 certificate includes several key fields, such as:

• Subject (Distinguished Name): The organization or individual to whom the certificate was issued.

• Issuer: The Certificate Authority (CA) that issued the certificate.

• Public Key: Used for encryption and authentication.

• Validity (Not Before / Not After): The certificate’s active time window.

• Signature Algorithm and Signature: Used to verify certificate authenticity.

• Extensions: Additional fields that provide metadata or functionality, such as key usage, policies, and SAN.

The SAN extension is part of the X.509 v3 certificate specification, and it allows the certificate to list additional hostnames that it should be considered valid for. This is what enables the single certificate to secure multiple DNS names and domains.

SAN vs. CN: Why the SAN Field Matters

Historically, SSL certificates relied primarily on the Common Name (CN) field inside the Subject field to specify the hostname being secured. For example, if you requested a certificate for www.example.com, the CN would be set to that domain. However, modern browsers such as Google Chrome, Mozilla Firefox, Microsoft Edge, and Apple Safari no longer rely solely on the CN to match hostnames.

Instead, they prioritize the SAN extension, which explicitly lists all secured identities. This is why a properly issued SAN SSL certificate will have each additional domain listed uniquely in the SAN field, even if one of the names is also used in the CN.

A SAN field may include multiple identifiers, such as:

The browser will validate the requested domain (e.g., client.portal.com) against this list during the SSL handshake. If the domain appears anywhere in the SAN extension, the browser will accept the certificate as valid for that hostname; if not, it will display a name mismatch or invalid certificate error.

How Browsers Validate SAN Certificates

During an HTTPS connection, the browser performs several checks before establishing trust:

1. Does the certificate come from a trusted Certificate Authority?

2. Is the certificate within its validity period?

3. Do the cryptographic signatures and chain of trust validate properly?

4. Is the requested hostname present in the SAN field?

If any of these checks fail, the browser will not establish a secure connection, and the user may see warnings like:

• NET::ERR_CERT_COMMON_NAME_INVALID

• SSL_ERROR_BAD_CERT_DOMAIN

• Name mismatch or untrusted certificate errors

For multi-domain SSL certificates, the fourth step is crucial. If a hostname is missing from the SAN field — even if it’s part of the same site or app — the certificate will not be considered valid for that name. This is why certificate planning and SAN inventory are critical during deployment.

Can SAN Certificates Include Wildcards?

While not all Certificate Authorities support it, many allow wildcard entries in the SAN field. This hybrid approach lets administrators mix specific hostnames with wildcard entries in the same SSL certificate, such as:

This makes the SAN SSL certificate extremely flexible, combining the breadth of wildcard certificates with the multi-domain protection of a SAN certificate. However, wildcard support varies by CA and validation level (DV, OV, EV), and not all multi-domain certificates allow wildcard entries in the SAN list.

Chain of Trust and Browser Trust Stores

A SAN certificate is only as good as the Certificate Authority that issued it. Trust is established through the certificate chain, which includes:

1. Leaf certificate — the actual SAN SSL certificate

2. Intermediate certificates — issued by the CA

3. Root certificate — trusted root present in the browser’s or OS’s trust store

If the certificate chain is incomplete or misconfigured, browsers may fail to validate the certificate and produce warnings such as “certificate not trusted” or “incomplete certificate chain.” This applies to SAN SSL certificates the same way it applies to single-domain or wildcard certificates.

Planning Your SAN Set: Naming Strategy, Limits, and Cost Considerations

Before purchasing or generating a Multi-Domain SSL certificate (SAN certificate), careful planning of the domain names you include in the SAN field is essential. Unlike single-domain or wildcard SSL certificates, a SAN SSL certificate explicitly lists every domain and subdomain it protects. This makes correct domain planning essential, not just for securing the intended sites, but also for controlling operational risk, renewal workflow, and long-term cost.

Whether you’re managing a SaaS platform, multi-brand enterprise, hosting environment, or Exchange server, this section will guide you through preparing your SAN inventory and anticipating the lifecycle implications.

Start with a Domain Inventory

The first step in preparing a SAN certificate is building a complete inventory of every domain and subdomain that needs to be secured under the certificate. This may include:

• Primary marketing domains (e.g., example.com)

• Service endpoints (e.g., login.example.com)

• Support or portal sites (e.g., portal.example.net)

• API hostnames (api.example.org)

• Country-level or brand variants (example.co.uk, brand2.com)

• Email and authentication hostnames (autodiscover.example.com, mail.example.com)

If you are securing a Microsoft Exchange or Office 365 hybrid environment, you’ll also need to include hostnames such as:

• owa.example.com

• lyncdiscover.example.com

• smtp.example.com

Any hostname not listed in the SAN extension will be rejected by modern browsers with errors like “certificate not valid for this name.” This means domain omissions can result in unexpected production outages or client errors.

Understand SAN Certificate Limits

The X.509 certificate standard does not set a strict limit on the number of SAN entries, but Certificate Authorities (CAs) do. Depending on the provider and product tier, SAN SSL certificates typically support:

• 5–25 domains (low-tier SAN SSL)

• 50–100 domains (mid-tier multi-domain SSL)

• 250+ domains (enterprise/UCC SAN)

Some high-volume certificates support up to 2,000 SANs, depending on validation type and customer requirements, but these are rare and costly.

Since many CAs charge per additional SAN, planning the SAN list ahead of time can help control cost and avoid unplanned expansion fees.

Domain Change Management: Adding or Removing SANs

One additional consideration that is often overlooked is how SAN updates are handled after issuance. Unlike wildcard certificates—which cover any subdomain without modification—SAN SSL certificates require the certificate to be reissued whenever domains are added or removed.

This reissue process:

1. Requires validation checks again (DNS, email, HTTP challenge, etc.)

2. May introduce service downtime if the certificate must be replaced mid-cycle

3. Can affect caching layers, CDNs, or certificate pinning policies

4. Requires careful scheduling to avoid service disruptions

5. May result in additional certificate fees from the CA

Because changes to the SAN field require the entire certificate to be re-issued, it’s best to anticipate future domain needs rather than planning reactively.

Pricing Considerations for SAN SSL Certificates

SAN SSL certificates usually follow a base price covering the first domain or the common name, plus a per-domain or per-SAN cost. For example:

• Base certificate cost: $99/year (includes 1 primary domain)

• Additional SAN entries: $20 each per year

• Wildcard SAN entries: often cost 2–3x as much per SAN

If you’re managing 20+ domains, it may be more cost-efficient to bundle them into a single SAN SSL certificate rather than purchasing multiple individual or wildcard certificates. But if you have many subdomains under one base domain, a wildcard SSL may be cheaper and easier to manage.

Pricing also varies based on:

• Validation level (DV, OV, EV)

• Warranty coverage and insurance

• Brand reputation of the CA (Sectigo, DigiCert, GlobalSign, etc.)

• Whether wildcard SANs are included or not

Future-Proofing the SAN List

Because certificate issuance and reissue cycles are sensitive and time-consuming, it is best practice to:

• Include not just current domains, but ones that may be required in the next 12-24 months

• Plan SANs based on product roadmaps, brand rollouts, or expansion territories

• Avoid adding domains purely for short-term needs that could complicate future reissues

• Use naming consistency across services to reduce confusion (e.g., api.brand.com, login.brand.com, support.brand.com)

Where possible, minimize domain churn and internal rebranding after certificate issuance, since every change to the SAN list requires a cert reissue and redeployment.

Final Consideration: Governance and Access

Because multi-domain certificates protect multiple sites with a single private key, access control is critical. The administrator who manages the certificate effectively has influence over all SAN domains.

To protect against shared-risk security problems, many enterprises choose to:

• Separate unrelated client domains into different cert pools

• Avoid placing regulated and public domains on the same certificate

• Use distinct certificates for PCI-DSS or HIPAA-scoped infrastructure

If a SAN certificate is compromised or revoked, every domain listed is immediately affected. This “blast radius” consideration is why correct SAN planning and certificate access governance matter as much as the encryption itself.

Validation Levels for Multi-Domain SSL Certificates (DV, OV, EV) and What They Change

While the structural difference between a Single-Domain SSL, Wildcard SSL, and Multi-Domain SSL lies in the number and type of domains that a certificate can secure, another critical distinction exists beyond domain scope: the validation level. Multi-Domain SSL certificates are offered in three validation types — DV (Domain Validation), OV (Organization Validation), and EV (Extended Validation) — all of which influence the verification process, browser trust indicators, issuance speed, and real-world use cases.

Because multi-domain certificates often protect business-critical infrastructure, SaaS customer portals, payment pages, internal applications, and corporate digital assets, choosing the right validation level matters not only for security but also for compliance, public trust, and the overall user experience.

Domain Validation (DV) Multi-Domain SSL

A DV multi-domain SSL certificate is the fastest, simplest, and lowest-cost way to secure multiple domains under a SAN certificate. It only requires proof that the requester controls each domain included in the SAN list. This is typically done using:

• DNS TXT record verification

• Email approval to domain admin addresses

• HTTP/HTTPS file validation

The CA does not verify any organization identity, legal entity, physical address, or brand legitimacy. Security is technically equivalent to OV/EV in terms of encryption strength, but trust level is lower from an end-user perspective.

Best for:

• Internal tools

• Dev/QA environments

• Low-risk public websites

• SaaS platforms where user identity doesn’t depend on org validation

Pros: Fast issuance (minutes to hours), inexpensive, ideal for automating SAN renewals and ACME workflows.

Cons: Does not display company information in certificate details; weaker public trust signal.

Organization Validation (OV) Multi-Domain SSL

An OV multi-domain SSL certificate performs domain verification and validates the legal existence of the organization requesting the certificate. This includes checks such as:

• Registered organization name

• Location and phone verification

• Government business registry validation

• Proof of operational existence

The details of the organization are embedded in the certificate and visible to users in the certificate viewer. For multi-domain enterprise environments, OV is often the baseline required for compliance or vendor security policies.

Best for:

• Business websites, apps, and portals

• Enterprise communication infrastructure (Exchange, SharePoint)

• Multi-brand organizations with public trust concerns

• Environments requiring certificate-based identity assurance

Pros: Displays verified organization identity; builds business trust; helps satisfy vendor and corporate security policies.

Cons: Slower issuance (1–3 days); requires business paperwork; higher cost than DV.

Extended Validation (EV) Multi-Domain SSL

An EV multi-domain SSL certificate performs the highest level of identity verification before issuing the certificate. The validation process is far more extensive than OV, requiring:

• Legal entity verification

• Operational existence and physical address confirmation

• Proof of exclusive rights to use the domains listed

• Third-party identity verification

EV SSL certificates historically displayed a “green bar” in browsers, but most modern browsers have removed that visual cue. However, EV certificates still provide the highest level of certificate-based identity assurance and are often required for high-risk environments such as financial services, government portals, regulated industries, and eCommerce gateways.

Best for:

• Banking, insurance, fintech applications

• Customer login and authentication systems

• Healthcare and government portals

• Multi-brand public companies with compliance needs

Pros: Highest validation standard, full legal identity embedded, ideal for sensitive multi-domain applications.

Cons: Longest issuance time (up to 10 days), highest cost, not supported by all CAs for wildcard SANs.

---

Key Differences Between DV, OV, and EV in Multi-Domain SSL

A common mistake when choosing SAN SSL certificates is assuming that they only differ in the number of hostnames they support. In reality, the validation level directly affects the type of customers who trust the website or service you’re protecting.

• A SaaS onboarding portal securing portal.clientsite.com or clientdomain.net may need OV or EV for brand-sensitive clients.

• An Exchange server that handles corporate email may use OV SAN to ensure secure communications across all associated hostnames.

• A small business site hosting a few separate domains may prefer DV SAN for cost efficiency.

How to Create a SAN CSR (OpenSSL, IIS, Exchange) with Examples

Before a Certificate Authority (CA) can issue a Multi-Domain SSL certificate (SAN SSL / UCC SSL), it requires a CSR — Certificate Signing Request. The CSR contains the public key and metadata (including the Common Name and Subject Alternative Name field entries) that tells the CA what domains you want secured.

Unlike a traditional single-domain CSR, a SAN CSR must explicitly include all the domain names you want to secure under a single certificate. Any domain not included in the CSR’s SAN list will not be covered in the final certificate, leading to “name mismatch” SSL errors.

Below are the most common ways to create a SAN CSR: using OpenSSL, Microsoft IIS, and Exchange Management Shell for Microsoft Exchange or Skype/Lync deployments.

---

Generate a SAN CSR with OpenSSL (Linux/macOS/Unix)

OpenSSL is the most widely used tool for generating CSRs in Linux, Unix, and macOS environments. To include SAN entries in an SSL certificate request, you need a custom configuration file that lists the domains.

Step 1: Create a custom OpenSSL config file (e.g., san.cnf)

In the example above:

• The CN field (example.com) is the primary domain

• Each additional domain is added under [alt_names] as a separate DNS entry

• You may include up to the number of SANs supported by your CA or product tier

Step 2: Generate the CSR and private key

Run this command:

This generates two files:

• san.csr — the certificate signing request you will submit to your CA

• san-key.pem — the private key needed later for SSL installation

You can verify the SAN entries using:

---

Generate a SAN CSR in Microsoft IIS (Windows Server)

On Windows Server, the built-in IIS Manager provides a point-and-click wizard to generate CSRs, including those for multi-domain/SAN SSL.

Steps:

1. Open IIS Manager

2. Select the server name in the Connections pane

3. Open the Server Certificates feature

4. Click Create Certificate Request

5. In the wizard, enter the key fields like Common Name, Organization, etc.

6. On the final page, click “Details”, then click “Properties”

7. Add your SAN entries under Alternative Names, this may appear as “Subject Alternative Name”

Depending on your version of IIS or Windows Server, the SAN field may not appear natively in the UI — in that case, many admins instead use OpenSSL or PowerShell to generate SAN CSRs and then complete the certificate request in IIS during installation.

Once the CSR file is created, you will submit it to the CA and receive a .cer or .p7b certificate that can be imported using IIS’s Complete Certificate Request wizard.

---

Generate a SAN CSR Using Exchange Management Shell (PowerShell)

For Microsoft Exchange environments, the Exchange Management Shell (EMS) is the preferred tool for creating SAN certificate signing requests because:

• It automatically assigns the necessary hostnames for services like SMTP, IMAP, Autodiscover, OWA, etc.

• It produces a CSR in the correct format and naming pattern for the installation workflow

• It is built into the Exchange Server role, with no need for OpenSSL or IIS UI interaction

Step-by-step example:

Run the following PowerShell command inside Exchange Management Shell:

Key details:

• -SubjectName defines the primary domain (CN)

• -DomainName list holds all SAN entries, including mail and autodiscover records

• The output .csr file can be submitted directly to the Certificate Authority

After the certificate is issued, complete the request using:

This binds the new certificate to the Exchange services and replaces the prior TLS certificate automatically.

---

SAN CSR Best Practices

When creating a SAN CSR:

• Always list every domain that will be served via HTTPS, including subdomains and service-specific hostnames.

• Double-check for typos — incorrect SAN entries cannot be fixed without reissuing the certificate.

• Use fully-qualified domain names (FQDNs) such as portal.example.com — do not use shorthand hostnames like portal.

• Avoid adding internal IPs and private hostnames as they are no longer allowed under public SSL certificate policies.

• Make sure the SAN list is complete before submitting the CSR — adding SANs later requires a reissue.

Installation and Configuration of SAN SSL Certificates (Apache, Nginx, IIS, CDN)

Once your Multi-Domain SSL certificate (SAN SSL) has been issued by the Certificate Authority (CA), the next step is to install and configure it on your web server or content delivery platform. While the core SSL installation process is similar across server types, SAN certificates require a bit more attention due to the number of domains they support.

Whether you’re running a Linux web stack with Apache or Nginx, a Windows Server with IIS, or using a CDN like Cloudflare or AWS CloudFront, this section provides specific instructions and considerations for configuring multi-domain SSL certificates.

Before You Begin: What You Need

You must have the following files ready before installation:

• Certificate file (e.g., certificate.crt, server.crt)

• Private key file (e.g., server.key) — generated during the CSR creation

• Intermediate certificate / CA bundle (e.g., ca-bundle.crt, intermediate.pem)

• Full certificate chain (optional, if your CA provided fullchain.pem)

Ensure that all certificate files match the SAN certificate you purchased and that you have not mixed keys or certificates from different CSRs. Always install certificates and keys with strict permission settings (e.g., chmod 600 for .key files in Linux).

---

Installing a SAN SSL Certificate on Apache (Linux)

Apache HTTP Server remains one of the most popular web servers for handling HTTPS transport. To install a SAN SSL certificate on Apache, follow these steps:

Step 1: Copy Certificate and Key Files

Place your certificate, private key, and CA bundle into your SSL directory (e.g., /etc/ssl/certs/ and /etc/ssl/private/).

Step 2: Edit the Apache Virtual Host Configuration

Open your SSL virtual host file. This is often located at:

or for Ubuntu/Debian:

Add or update the following lines:

Step 3: Enable SSL Module and Restart Apache

Run the following commands (Ubuntu/Debian):

Verify installation by running:

---

Installing a SAN SSL Certificate on Nginx (Linux)

Nginx does not have a separate chain file directive; instead, it requires a combined certificate and chain PEM file. Follow these steps:

Step 1: Combine Certificate Files (if needed)

Run:

Step 2: Edit Nginx Server Block

Open your SSL-enabled server block file:

Configure SSL directives:

Step 3: Test and Reload Nginx

Use curl -Iv https://example.com to verify SSL header and certificate chain.

---

Installing a SAN SSL Certificate in IIS (Windows Server)

On Windows Server running IIS, the process is driven through the IIS Management Console.

Step-by-Step:

1. Open IIS Manager and select the server name.

2. Go to Server Certificates.

3. Click Complete Certificate Request in the right-hand panel.

4. Select your .cer or .p7b file, provide a friendly name, and finish the import wizard.

5. Go to Sites > Bindings and select the https binding.

6. Click Edit and choose your new SAN certificate from the SSL Certificate dropdown.

7. Click OK and restart IIS:

To verify, right-click the site, click Browse, and inspect the certificate in the browser.

---

SAN SSL on CDN/Cloud Platforms (Cloudflare, AWS CloudFront, etc.)

Most modern CDNs allow you to upload custom SSL certificates for edge delivery, or they may offer managed SAN certificates through automated issuance. Here are the two common scenarios:

Uploading a Custom SAN Certificate:

• In Cloudflare: Go to SSL/TLS > Edge Certificates > Upload Custom Certificate

• In AWS CloudFront: Use ACM or upload a certificate via the IAM Certificate Store

Automatic SAN Management:

Some CDNs include tools for automatically issuing multi-domain SSL for edge deployments, especially when domains are validated through DNS. This is ideal for dynamic SaaS or onboarding applications.

---

Post-Installation Checks

After installation:

• Visit each domain secured under the SAN certificate in a browser: https://example.com, https://api.example.net, etc.

• Use SSL testing tools like SSL Labs to verify:

  • SAN field correctness

  • Full certificate chain

  • No weak ciphers or protocol fallback (e.g., TLS 1.0)

• Monitor server logs for any handshake failures or SNI misconfiguration

• Ensure certificate auto-renew workflows (if any) support SAN reissue

Managing SAN Certificate Changes: Adding, Removing, Renewing, and Automating

Once a Multi-Domain SSL certificate (SAN SSL or UCC SSL) is deployed, management becomes an ongoing process—not a one-time setup. Multi-domain certificates introduce unique operational considerations because every domain or subdomain included in the SAN list must remain consistent during the certificate’s lifespan. This means that additions, removals, or corrections to the SAN list can only be accomplished by reissuing or renewing the certificate.

If not managed properly, SAN certificate lifecycle events can trigger unexpected downtime, validation failures, trust warnings, and disruptions to HTTPS services across multiple domains at once. In this section, we outline best practices and real-world workflows for maintaining multi-domain SSL certificates efficiently and securely.

---

Adding New SANs (Additional Domains or Subdomains)

When a new domain or hostname needs to be added to the SAN certificate—for example, when launching a new service or regional product—the process typically involves:

1. Generating a new CSR that includes the updated SAN list (all existing domains plus the new ones).

2. Submitting a reissue request to the Certificate Authority.

3. Completing validation for the new domains (DNS, email, or HTTP-based, depending on DV/OV/EV).

4. Installing the reissued certificate on the server or load balancer.

5. Updating CDN or reverse proxy configurations if necessary.

Important: You cannot append SANs to an existing SSL certificate without reissuing it. Any missing domain after reissue will be dropped from the certificate, which can break HTTPS for that domain.

---

Removing SAN Entries (Retired Domains or Decommissioned Services)

Similar to adding SANs, removing domains also requires a certificate reissue.

Reasons to remove SAN entries include:

• A domain being decommissioned or redirected permanently.

• Compliance requirements (e.g., removing domains that shouldn’t share a cert).

• Certificate size/complexity reduction.

• Reduction in certificate renewal cost.

Key caution: Once removed, the old domain will no longer be covered. If you forget to replace it with a new SSL certificate or redirect the domain properly, users will see trust errors or security blocks.

---

SAN Certificate Renewal

Renewing a SAN SSL certificate is similar to renewing any SSL certificate, but with an extra precaution: you must ensure the SAN list is still accurate and complete.

Before renewing, assess:

• Whether any of the domains in the SAN field have changed, expired, or been replaced.

• Whether any additional hostnames will be included in the next deployment cycle.

• That validation methods still work (such as DNS TXT ownership records).

• Whether the certificate private key will be rotated (recommended during renewal).

Most CAs allow SAN SSL renewal as early as 60–90 days before expiration. If your SAN list is large, start the renewal early to avoid last-minute issues with validation or certificate chain propagation.

---

ACME Automation for Multi-Domain SSL Certificates

While ACME clients like Certbot are well-known for automating single-domain and wildcard SSL certificates through Let’s Encrypt, multi-domain automation is also possible — but requires dynamic SAN support and DNS-based validation.

Tools like:

• Certbot with DNS plugins

• Posh-ACME for Windows/PowerShell ACME automation

• ACME.sh for Linux servers and Kubernetes ingress

• Native integrations in hosting or cloud platforms (e.g., Caddy server, Traefik, or Cloudflare API-driven certs)

These workflows let you automatically renew SAN certificates and update server installations, but they require:

• Programmatic control of DNS (API-based)

• Central certificate management and deployment automation

• Careful planning to support reissue (not just renewal)

Note: Let’s Encrypt supports up to 100 domains per SAN certificate, but EV and wildcard SANs are not supported. Commercial CAs are better suited for regulated or enterprise SAN certs.

---

Risks and Limitations of Managing SAN Certificates

Shared key risk: All domains secured by the SAN certificate share the same private key. If the key is compromised for one domain, all domains are affected.

Validation complexity: DV SAN certificates require ownership validation for every SAN domain — a challenge if DNS or email changes.

Propagation latency: After reissue, SSL caches at CDNs, browsers, and proxies may take several hours to fully clear, especially if HSTS headers are enabled.

Change window timing: Since reissues require replacing the certificate on every server instance, plan SAN list changes during maintenance windows or in coordination with application deployments.

---

Best Practices for SAN Certificate Lifecycle Management

• Track SAN domains in a central inventory file or certificate management platform.

• Always reissue SAN certificates in staging before deploying to production.

• Use automation (ACME, Ansible, CI/CD) when managing many SAN hosts.

• Rotate private keys at least annually to reduce long-term key exposure.

• Monitor expiration, OCSP status, and revocation logs using SSL scanning tools.

• Avoid unnecessary SAN additions — every new DNS name is a point of attack and validation failure.

• Don’t mix sensitive and publicly accessible services on the same SAN certificate.

Security and Performance Best Practices for Multi-Domain SSL Certificates

Deploying a Multi-Domain SSL certificate (SAN SSL certificate) introduces several operational and security considerations that go beyond typical single-domain or wildcard SSL setups. Since these certificates protect multiple domains, they also concentrate risk, centralize certificate management, and increase dependency on infrastructure consistency. To maximize security and stability across your SAN SSL deployment, the following best practices should be implemented.

These best practices are critical whether you’re running a SAN certificate on a traditional web server, a reverse proxy, API gateway, CDN, or cloud-native app front end.

---

Implement Strong Key Management Policies

Every SSL certificate relies on a private key that decrypts traffic and signs TLS negotiations. For a multi-domain certificate, this single private key protects traffic for all domains listed in the SAN extension. Therefore, key protection is an immediate priority.

Best practices include:

• Use 2048-bit RSA or higher, or consider ECC keys for better performance and stronger crypto.

• Store private keys under strict server permissions (e.g., chmod 600)

• Rotate private keys during certificate renewals or reissues to prevent long-term compromise

• Do not reuse the same private key across different certificates or environments

• Store private keys on secure hardware (e.g., HSM, cloud KMS) for high-security deployments

Failure to protect the private key of a SAN certificate introduces extreme blast radius: a single compromise affects every domain secured.

---

Enable OCSP Stapling

OCSP stapling is a performance and security enhancement that helps browsers validate whether a certificate has been revoked. Without OCSP stapling, client devices must independently check the certificate status with the Certificate Authority, which may result in:

• Slower page load times

• Temporary validation failures due to CA timeout

• Privacy concerns (browsers must contact a third-party server)

With OCSP stapling enabled, the server handles certificate status checks and provides the signed OCSP response to the client during the handshake.

Example (Nginx):

OCSP stapling is especially valuable when using SAN SSL certificates because it covers multiple domains at once, reducing validation overhead per domain.

---

Harden TLS Protocols and Cipher Suites

Today’s best practice SSL configuration requires supporting only modern TLS versions and secure cyphers. Legacy protocols (SSLv3, TLS 1.0/1.1) may expose your SAN certificate to downgrade and interception attacks.

Recommended configuration:

• Support only TLS 1.2 and TLS 1.3

• Disable weak ciphers like RC4, MD5, EXPORT, and DES

• Prefer ECDHE suites for forward secrecy

• Use Mozilla SSL Configuration Generator for up-to-date templates

For example, a high-security Nginx suite may include:

---

Use HSTS to Enforce HTTPS

HTTP Strict Transport Security (HSTS) makes your site safer by telling browsers they must always connect using HTTPS — no exceptions. This eliminates the risk of downgrade attacks and mixed content warnings. However, implementing HSTS across multiple SAN names requires planning, as it affects all subdomains and sites that share the certificate.

Sample HSTS header:

When using HSTS with SAN certificates:

• Confirm every domain in the SAN list supports HTTPS correctly

• Avoid preloading unless all hostnames meet HSTS requirements

• Review CDN or proxy influence before activating subdomain enforcement

---

Keep Certificate Chains Complete and Updated

SAN certificates depend on a valid certificate chain, which consists of:

1. Root certificate

2. Intermediate certificate(s)

3. Leaf certificate (your SAN SSL cert)

Servers must always return the full certificate chain, or clients may fail to validate the certificate.

To ensure proper chain behavior:

• Use the CA-provided bundle file instead of building manually.

• Confirm your server config includes both fullchain.pem and privkey.pem (for Nginx-based setups).

• Test chain completeness with tools like:

or public resources like SSL Labs.

---

Monitor Certificate Status and Renewal Deadlines

Because SAN SSL certificates service multiple domains at once, a single missed renewal can break HTTPS for an entire portfolio of sites.

Monitoring methods include:

• CRON-based OpenSSL checks

• ACME client dry-runs (for automation)

• Commercial monitoring tools (e.g., UptimeRobot, StatusCake, SSLMate)

• Certificate transparency log subscriptions

• API-based checks via Sectigo, Digicert, or custom dashboards

Look specifically for:

• Near-expiry warnings

• OCSP status changes (revoked, unknown)

• Hostname mismatches after reissue or vulnerability patching

---

Avoid Excessive Domain Consolidation

Although it is technically possible to include dozens or even hundreds of domains in a single SAN SSL certificate, doing so centralizes risk in a potentially dangerous way.

Consider splitting SAN certificates into:

• Functional scope (e.g., SaaS domains vs static websites)

• Security zones (i.e., public services vs internal services)

• Traffic tiers (high-volume vs low-traffic domains)

This reduces exposure if a certificate key is compromised, revoked, misconfigured, or incorrectly renewed.

---

Summary of SAN SSL Best Practices