Understanding SAN in X.509 SSL Certificates

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 Common Name (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 Subject Alternative Name (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 Subject Alternative Name (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: 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 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 Certificate Authorities (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—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 Certificate Authority (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 Subject Alternative Name 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 Common Name (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 Common Name field. 

Client Validates the SAN List 

Modern browsers rely on SAN list instead and ignore the common name. 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 which seek scalability as well as simplicity. 

 Securing Multiple Websites Under a Single Organization 

Use Case

A company have 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 Certificate Authority (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. 
• Follows all the guidelines set by CA/Browser Forum standards. 
• Knows 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 support flexible reissuance (add/remove domains easily) 

Why it matters: Efficient and simplified management reduces overhead and helps in cert expiration issue. 

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 Certificate Authorities (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 Certificate Authority (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. 

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—from discovery and issuance to 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 

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, Azure Key Vault. 

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

Conclusion 

Subject Alternative Name (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.