Understanding SAN in X.509 SSL Certificates

Every SSL/TLS certificate has to tell a browser exactly which domains it is allowed to protect. For years, that job fell to a single field, the Common Name, until the Subject Alternative Name extension made it possible to secure many domains, subdomains, and IP addresses under one certificate. This guide explains what SAN is, how it is validated during the TLS handshake, where enterprises use it, and what to check before choosing a certificate authority for a SAN deployment.

Quick answer: The Subject Alternative Name (SAN) is an X.509 certificate extension, defined in RFC 5280, that lists every domain, subdomain, IP address, or email address a certificate covers. Modern browsers validate hostnames against the SAN list only, not the legacy Common Name field, which makes SAN a mandatory part of every publicly trusted SSL/TLS certificate issued today.

Executive Summary

Manual certificate handling remains a leading cause of outages across the industry. DigiCert’s Trust Pulse Survey (July 2, 2025) found that 45% of organizations experienced certificate-related downtime in the past year, and 37.5% traced an outage directly to an expired certificate (source). A SAN certificate that quietly covers dozens of domains raises the stakes further, since one missed renewal or one misconfigured entry can take down every service listed in it at once.

As an illustrative estimate, an enterprise tracking 2,000 SAN entries across its multi-domain certificates today would need roughly four times as many renewal cycles once maximum public TLS validity drops to 47-day TLS certificates by March 2029 (200 days from March 2026, 100 days from March 2027, per the April 14, 2025 ballot). What is currently a quarterly SAN audit becomes, at that cadence, a continuous process that a spreadsheet cannot keep up with.

Quick Checklist

• Confirm every certificate secures its domains through SAN entries, not a bare Common Name.
• List every domain, subdomain, and IP address that should be covered before requesting or reissuing a SAN certificate.
• Verify your chosen CA supports the validation level (DV, OV, or EV) your use case actually needs.
• Group SAN entries by risk and environment instead of combining unrelated services under one certificate.
• Confirm wildcard entries, if used, are supported by the CA and match only the intended subdomain level.

Owner and Action Matrix

A SAN certificate is rarely owned by a single team once it secures more than one service. The table below maps the primary responsibility and the first concrete action for each team.

Team	Primary Responsibility	First Action
PKI / Certificate team	Owns the SAN entry list, validation level, and CA relationship	Audit existing SAN certificates for entries that no longer map to an active service
Security team	Owns the blast radius if a shared SAN certificate is compromised or misconfigured	Confirm no unrelated high-risk and low-risk services share the same SAN certificate
Platform / DevOps team	Owns SAN entries for cloud, microservice, and multi-subdomain deployments	Add automation so new subdomains request SAN inclusion instead of a separate certificate
Compliance / vendor risk	Owns audit evidence for domain and organization validation records	Confirm validation-level documentation is retained for every SAN entry, not just the primary domain

What Is Subject Alternative Name (SAN) in SSL/TLS Certificates?

The Subject Alternative Name (SAN) is an important extension to the X.509 certificate standard, defined in RFC 5280. It allows SSL/TLS certificates to include multiple identities beyond just the Common Name (CN) field. These identities can include domain names, subdomains, IP addresses, email addresses, and more, enabling secure communication across a wide variety of endpoints.

By using the SAN extension, organizations can significantly enhance the flexibility, scalability, and security of their SSL certificates. Instead of managing separate certificates for each domain or service, one SAN-enabled certificate can secure all required identities under a single certificate, simplifying certificate management and reducing operational overhead.

Before SAN: The Common Name (CN) Limitation

In earlier SSL certificates, the domain name secured by the certificate was identified mainly through the CN field.

Example:

If the CN was:

CN = www.example.com

The certificate would only be valid for:

• www.example.com

If a user visited:

• example.com
• blog.example.com
• www.example.net

They would receive a security warning because the certificate does not align with the requested domain. Modern browsers no longer rely on the CN field for domain validation; they validate only against entries in the SAN field for better security and consistency, as per current industry standards.

Drawbacks of Relying Solely on CN

• Only a single fully qualified domain name (FQDN) could be secured.

• No flexibility to include subdomains or alternate domains.

• Multiple services/domains required separate certificates.

• Deprecated practice: Relying solely on CN is discouraged due to security risks and compatibility issues, as many modern browsers ignore the CN and trust only the SAN list for domain validation.

After SAN: Multiple Domains, One Certificate

By using the SAN extension, a single SSL/TLS certificate can secure multiple identities across different services. These identities can include:

• Subdomains (e.g., blog.example.com)
• Entirely different domains (e.g., example.net)

• IP addresses (e.g., 203.0.113.5). Note that IP addresses in SANs must match exactly; there is no support for subnets or partial matches.
• Internal hostnames (e.g., intranet.local)
• Wildcard domains (e.g., *.example.com). Wildcard entries in SAN fields come with limitations: they only match one level of subdomain (e.g., *.example.com matches blog.example.com but not dev.blog.example.com), and not all Certificate Authorities (CAs) support wildcard entries in SANs. Always verify CA support and policies before using them.

Example:

A SAN-enabled certificate could have:

CN = www.example.com

SAN:

DNS.1 = www.example.com

DNS.2 = example.com

DNS.3 = blog.example.com

DNS.4 = www.example.net

IP.1 = 203.0.113.5

This certificate is valid for all the listed DNS and IP entries.

Benefits:

• A single certificate can safeguard multiple services.
• Simplifies management: one renewal, one installation.
• It is cost-effective as it eliminates the need to purchase individual certificates.
• Supports modern web infrastructure like microservices, APIs, and multi-domain platforms.
• SAN is now a mandatory component in all publicly trusted
• SSL certificates, as per the CA/Browser Forum Baseline Requirements, modern browsers rely solely on the SAN field for domain validation.

Why Use a SAN SSL Certificate?

• Secure Multiple Domains with One Certificate
  Secure all domains under a single SSL certificate, making it easier for organizations to manage multiple websites.
  However, it’s important to note that each SAN entry must be individually validated during certificate issuance. Most CAs require DNS-based or HTTP-based domain validation for each domain included in the SAN list to ensure ownership and security compliance.
• Simplified Certificate Management
  Reduces complexity and human errors by managing, renewing, and deploying just one certificate instead of multiple certificates.
• Cost Efficiency
  Cuts expenses by not purchasing multiple certificates, since many SAN certificates support up to 100 domains.
• Supports Complex Infrastructures
  Perfect for modern setups like microservices, APIs, and cloud platforms using different subdomains or domains.
• Required for Browser Compatibility
  Modern browsers use the SAN field, making SAN a mandatory part of public SSL certificates.
• Scalable for Future Expansion
  Adding domains to the certificate during renewal or reissue is easy, which is great for growing businesses.
• Boosts Trust and SEO
  HTTPS on all domains builds user trust, protects data, and improves Google search rankings.

How a SAN Certificate Works?

Certificate Creation with SANs

During the generation of a certificate signing request (CSR), the administrator specifies a list of SAN entries. These can be:

• Fully qualified domain names (FQDNs)
• Subdomains
• IP addresses
• Email addresses
• URIs (for specialized applications)

To include these SAN values, the administrator must define them in the subjectAltName field within the CSR configuration file (typically openssl.cnf or equivalent).
Once the CSR is created and submitted to a CA, the CA verifies the ownership or control of each SAN entry. After successful validation, the CA issues a certificate with the SAN entries encoded in the SAN extension.

Browser/Client Makes a Secure Request

When a client (like a browser or app) connects to a secure website via HTTPS:

• During the TLS handshake, the server presents its SSL certificate to the client.
• The certificate includes:
  1. The public key
  2. The CN (legacy field)
  3. The SAN extension with all valid identities

As part of the handshake, the client performs hostname verification, where it checks whether the requested domain matches any of the entries in the SAN field. This verification step is critical to establishing trust; modern clients rely exclusively on the SAN extension for this check, ignoring the CN field.

Client Validates the SAN List

Modern browsers rely on the SAN list instead and ignore the CN. The client looks for a match between:

• The domain name, it’s trying to connect to.
• Any of the names listed in the SAN field.

The connection proceeds securely only if an exact or valid wildcard match is found.

• Wildcard behavior: Browsers support SAN entries with wildcard domains (e.g., *.example.com), but the wildcard can only match one level of subdomain. For example, *.example.com matches blog.example.com but not shop.dev.example.com.
• Internal names: Modern browsers and CAs no longer accept internal names (like localhost or server.local) in public certificates. Including such names will cause the certificate to be considered invalid or untrusted.

If no match is found, the browser displays a security warning, such as “Your connection is not private” or “Invalid certificate”.

One Certificate, Many Domains

Since the SAN list includes several identities, one certificate can be used across:

• Multiple websites (e.g., example.com, example.net)
• Multiple subdomains (e.g., shop.example.com, blog.example.com)
• Different services (e.g., Exchange Server, mail server, API gateway)

This makes the management easy and simple, as now there is no need to install and manage separate certificates for each domain.

Common Use Cases for SAN (Subject Alternative Name) Certificates

SAN certificates are used across many industries and infrastructures because of their multi-domain support. They help you to protect multiple domains, subdomains, and IP addresses using a single certificate, which makes it ideal for organisations that seek scalability as well as simplicity.

Use Case	Recommendation	Operational Owner	Expected Outcome
Multiple websites or brand domains	Consolidate under one SAN certificate instead of a separate certificate per domain	PKI / Certificate team	Centralized management with fewer renewal cycles
Multi-subdomain application (login, API, dashboard, CDN)	Add each subdomain as an explicit SAN entry unless a wildcard is clearly justified	Platform / DevOps team	Simplified deployment on a unified expiration cycle
Cloud or microservices spanning regions and TLDs	Group services by risk and environment before combining them into one certificate	Security team	No single point of failure across unrelated services
Development, staging, and testing environments	Use an internal CA or a self-signed SAN certificate for .local names	Platform / DevOps team	Realistic HTTPS testing without public CA restrictions
Microsoft Exchange or Office 365	Use a Unified Communications Certificate sized for every Exchange and Skype endpoint	PKI / Certificate team	One certificate secures mail, autodiscover, and hybrid O365 services

 Securing Multiple Websites Under a Single Organization

Use Case

A company has the ownership of multiple websites or brand domains:

• example.com
• example.net
• example.org
• product.example.com
• support.example.net

Buying and managing separate SSL certificates for each is not at all necessary, as a company can now use a single SAN certificate to protect all domains and subdomains.

Note: Each subdomain must be explicitly listed in the SAN field unless a wildcard entry (e.g., *.example.com) is included. Without a wildcard, subdomain matching is exact, and unlisted subdomains will not be covered by the certificate.

Benefits

• Centralised management
• Cost savings
• Easier renewals and installations

Securing Multi-Subdomain Applications

Use Case

A web application operates across various subdomains:

• login.example.com (authentication)
• api.example.com (backend API)
• dashboard.example.com (user portal)
• cdn.example.com (static content delivery)

All subdomains are added as SAN entries in one certificate.

Benefits

• Simplifies deployment
• Reduces certificate sprawl
• Unified expiration and renewal cycle

Cloud-Based and Micro-services Architectures

Use Case

Modern applications, those using micro-services or cloud platforms, operate across:

• Different subdomains
• Separate regions or instances
• Different top-level domains (TLDs)

Example:

• us.api.example.com
• eu.api.example.net
• static.cdnexample.org

A SAN certificate can be used to protect all these services, even if they are geographically distributed or span multiple domains.

Consideration: While SAN certificates simplify management, tying too many services to a single certificate can create a single point of failure. If the certificate expires, is compromised, or needs to be reissued, all services relying on it are affected simultaneously. To mitigate this, organizations should carefully group services by risk and environment, and use separate SAN certificates when appropriate.

Benefits

• Easier cert automation (e.g., via CI/CD)
• Fewer certs to renew, fewer misconfigurations
• Secure service communication in hybrid cloud setups

Development, Staging, and Testing Environments

Use Case

Developers want to use HTTPS on local or staging domains:

• dev.example.local
• staging.example.com
• test-api.example.org

All environments are secured by using SAN certificates, and there is no need for multiple certs.

For internal environments like .local domains (e.g., dev.example.local), it’s recommended to use an internal CA or a self-signed SAN certificate. Public CAs no longer issue certificates for internal names due to security restrictions imposed by the CA/Browser Forum.

Benefits

• Enable accurate and safer testing under real-world HTTPS conditions.
• Faster CI/CD testing pipelines.
• The burden of manual certificate management is reduced.

Microsoft Exchange Server and Office 365

Use Case

Microsoft Exchange and Skype for Business require SAN certificates, so that they function correctly with multiple internal and external services, like:

• mail.example.com
• autodiscover.example.com
• smtp.example.net
• Internal.exchange.local

To simplify deployment, Microsoft recommends certificates that support multiple SAN entries.

A Unified Communications Certificate (UCC) is often used in these scenarios. While UCC is commonly referred to as a special certificate, it’s essentially a marketing term for a multi-SAN certificate that’s optimized for Microsoft applications like Exchange, Skype for Business, and Office 365.

Benefits

• Fully supports Microsoft’s trusted framework for certificate management.
• No need for multiple certs, one cert can secure all services (email, calendar, auto discover, etc.)
• Easy setup for hybrid Office 365 deployments

What to Consider When Choosing a CA for SAN Certificates

Reputation and Trust Level

Choose a globally trusted CA that is:

• Recognised by all leading browsers and operating systems.
• Following all the guidelines set by CA/Browser Forum standards.
• Known for implementing high security standards.

Popular Trusted CAs:

• DigiCert
• Sectigo (formerly Comodo)
• Entrust
• GlobalSign
• GoDaddy
• Let’s Encrypt (for limited use cases, supports SAN)

Note: While Let’s Encrypt is widely trusted and ideal for short-term, automated deployments, it may not be suitable for longer certificate lifespans or complex enterprise needs that require extended validation (EV), organization validation (OV), or advanced support and reporting features.

Why it matters: With public trust, users don’t see the warnings about “Untrusted Certificate”

Pricing and Licensing

SAN certificates pricing can fluctuate, depending on:

• Number of SANs included (some include 2-5 SANs by default)
• Cost per additional SAN entry
• Validation level (DV, OV, EV)

Caution: Be aware of potential vendor lock-in and unexpected renewal costs. Some CAs offer low initial prices but charge significantly higher fees during renewal or when adding new SAN entries. Always review the full pricing model and renewal terms before committing.

Why it matters: Scalability can be affected by pricing, especially if many domains are managed simultaneously.

Certificate Validation Type

CAs offer three types of validation:

Validation Type	Verification Level	Trust Indicators	Best For
DV (Domain Validation)	Verifies domain ownership only	Padlock in browser	Internal sites, personal blogs, low-risk applications
OV (Organization Validation)	Verifies domain + organization identity	Padlock + organization details in certificate info	Business websites, APIs, public-facing apps
EV (Extended Validation)	Extensive vetting of business + legal existence	Padlock + organization name in browser address bar (in some browsers)	Financial services, eCommerce, regulated industries

For handling sensitive data, running public services, or aiming for high trust, you should choose OV or EV.

Ease of Certificate Management

Look for CAs offering:

• Management dashboards or APIs
• Certificate automation (e.g., via ACME protocol)
• Renewal reminders
• SAN supports flexible reissuance (add/remove domains easily)

Why it matters: Efficient and simplified management reduces overhead and helps with cert expiration issues.

Support for Custom Requirements

Consider:

• Wildcard SAN support (e.g., *.example.com)
• IP address inclusion
• Internal domain support (e.g., dev.local)
• Integration with your infrastructure (e.g., Microsoft Exchange, AWS, Kubernetes)

Note: Not all CAs support combining wildcard domains and SAN entries in the same certificate. Some impose restrictions or may require a different product tier. Be sure to verify this capability if your use case includes both.

Why it matters: Some CAs may need special configurations or offer limited support for internal names, IP addresses, or complex wildcard/SAN setups; understanding these limits helps avoid deployment issues.

Customer Support & SLAs

When evaluating a CA, prioritize those that offer:

• 24/7 support
• Fast issuance and reissue SLAs
• Dedicated enterprise support (for large deployments)

Time-to-issue matters: Some CAs can issue Domain Validation (DV) certs within minutes, while OV/EV may take hours or days, depending on verification processes.
Reissuance downtime should also be considered: delays in replacing expired or compromised certificates can lead to service disruptions or security warnings for users.

Why it matters: Timely support is essential when facing outages or renewals.

What to Do Next

Cleaning up SAN certificate sprawl does not require rebuilding your certificate inventory overnight. Each team has a specific, near-term action.

• PKI and certificate teams: audit existing SAN certificates for entries that no longer resolve to an active service.
• Security teams: confirm no unrelated high-risk and low-risk services are combined under the same SAN certificate.
• Platform and DevOps teams: automate SAN entry requests for new subdomains instead of provisioning a separate certificate each time.
• Compliance and vendor risk teams: confirm validation-level documentation is retained for every SAN entry, not only the primary domain.

How Encryption Consulting Can Help

Managing SAN certificates for multiple domains, subdomains, and IPs can quickly become a challenge, especially at scale. That’s where Encryption Consulting’s CertSecure Manager steps in.

Our Certificate Lifecycle Management (CLM) solution automates and streamlines the entire process, starting with certificate discovery across every domain, subdomain, and IP address in your SAN inventory, then applying the same certificate automation used for single-domain certificates to issuance, renewal, and revocation. Whether you’re securing internal services, cloud workloads, or complex multi-domain environments, CertSecure Manager offers:

• Centralized certificate inventory, including SAN entries
• Automated issuance and renewal using leading CAs
• Policy-driven controls and approval workflows
• Real-time alerts to prevent expirations or misconfigurations
• Detailed audit logs and compliance reporting
• Prepare for Crypto Agility: As certificate inventories grow and post-quantum migration approaches, we help you build crypto agility into your PKI, assess PQC readiness, and extend your SAN certificate inventory into a full CBOM for complete cryptographic visibility.

Integrations supported: CertSecure Manager seamlessly integrates with major CA platforms like DigiCert, Sectigo, and others via their APIs. It also supports ACME protocol-based clients (e.g., Let’s Encrypt) and can connect with infrastructure tools such as Microsoft CA, AWS, and Azure Key Vault.

With CertSecure Manager, organizations can confidently manage SAN SSL certificates with efficiency, visibility, and control, all from a single platform.

Conclusion

SAN certificates offer a smart, scalable solution for securing multiple domains, subdomains, and services with a single certificate. Whether you’re managing a complex infrastructure or just looking to simplify SSL management, SAN certificates provide flexibility, cost-efficiency, and strong security, making them essential for modern digital environments.