Provide current and historical ownership information on domains / IPs. Identify all connections between domains, registrants, registrars, and DNS servers.
Most often, SSL/TLS certificates are issued for specific websites: one certificate for one hostname or website. But for larger organizations, this creates problems with certificate management — they pile up, they expire at different times, it becomes harder to spot rogue certificates, and so on.
This problem is solved by so-called SAN certificates, or multi-domain certificates, which can secure multiple domain names or hostnames with the help of the Subject Alternative Names (SAN) field. This post covers what a SAN certificate actually is, how it works, how to get one, and how security teams use SAN data for asset discovery.
What Is a SAN Certificate?
A SAN certificate is a TLS/SSL certificate that can secure more than one domain name or hostname through its SAN field. A certificate’s SAN field lists all the domain names and hostnames it is valid for. During each SSL/TLS connection, the browser checks whether the requested hostname matches one of those SAN entries.
Because there can be more than one domain name or hostname in the SAN field, SAN certificate and multi-domain certificate are used interchangeably in the industry. DigiCert, for example, sells them under the name “Multi-Domain Certificate.” Some other vendors call them “Unified Communications Certificates (UCC),” a naming holdover from their early use with Microsoft Exchange and Office Communications Server.
Technically, nowadays all publicly trusted TLS/SSL certificates are SAN certificates. The CA/Browser Forum’s Baseline Requirements mandate that every certificate include a Subject Alternative Name extension with at least one entry, even certificates that only cover one hostname.
A certificate authority can issue multi-domain certificates under all different levels of validation — Domain Validation (DV), Organization Validation (OV), or Extended Validation (EV), depending on how much identity checking the requester goes through.
- DV only confirms that the requester controls the domain. This is fast and automated, and issuing such a SAN certificate doesn’t require any paperwork.
- OV involves manual identity vetting that verifies your legally registered business name.
- EV involves a multi-step background check that verifies the organization’s legal, physical, and operational existence plus domain ownership.
Subject Alternative Name (SAN) Field
The SAN field is a section inside a TLS/SSL certificate where you list the hostnames and domain names you want the certificate to cover. It was introduced as part of the X.509 v3 certificate format, standardized by ISO/IEC, ITU-T, and ANSI X9 in 1996-97, and was later profiled for internet use by the IETF in RFC 2459 (1999), one of the early specifications applying X.509 v3 to the internet.
Since the SAN field lets a certificate identify its subject unambiguously by domain name or IP address, it addressed a gap in the older Common Name field, which had no such structure and became a common source of parsing bugs.
SAN entries are plain hostnames, technically called DNSName entries, such as example[.]com and shop.example[.]com. The extension can also hold IP addresses so that a certificate can secure a server by both its domain name and its numeric IP address. The SAN field can also contain email addresses when a certificate needs to secure a mailbox, even though that’s less common compared to domains or IP addresses.
Individual certificate authorities have added their own rules on top of the X.509 specifications that define the SAN extension. Some of the most common restrictions are:
- Only standard wildcard names are allowed (e.g., *.example[.]com): CAs don’t allow partial wildcards (b*.example[.]com or a*b*.example[.]com) and multi-level wildcards (*.*.example[.]com) as SAN entries, since the CA/Browser Forum’s Baseline Requirements only recognize a wildcard in the left-most label.
- Hostnames in a SAN list do not need to share a root domain name. An SSL certificate can legitimately cover unrelated domains at once.
- There is usually a cap on the number of names per certificate, often around 100.
How to Know What’s Written in an SSL/TLS Certificate’s SAN Field?
Some SSL Certificates Lookup tools return the contents of the SAN field (ours certainly does).
How Do SAN Certificates Work?
One certificate can have multiple hostnames in its SAN field. Any name on that list is considered protected by the certificate.
For example, one certificate can secure the following domain names all at once, even though they aren’t all subdomains of the same root domain.
- example[.]com
- www.example[.]com
- foo.bar.hello[.]com
- login.hello[.]com
- blog.domain[.]com
To get such a certificate, the requester has to prove that they control example[.]com, hello[.]com, and domain[.]com.
When a browser connects to a site, it checks whether the requested hostname appears in the SAN list of the certificate protecting this site. If there’s no match, the connection fails, and users will get a warning that says something like “your connection is not private”, which basically explains that the certificate used on the site does not seem to be issued for it.
It’s worth knowing that this wasn’t always how certificate checking worked. Older certificates relied on a separate common name (CN) field for the hostname, and some clients would fall back to checking the common name if no SAN was present.
That fallback is no longer available in modern browsers because the CA/Browser Forum’s Baseline Requirements made the SAN extension mandatory in 2012, and Chrome and Firefox dropped CN fallback afterward. So today, if a hostname isn’t in a certificate’s SAN list, the connection fails, no matter what the common name says.
Why Do People Use SAN Certificates?
The main benefit of a multi-domain SSL certificate is simpler certificate management, which provides several practical advantages:
- Fewer certificates to track: One multi-domain SSL certificate can replace several single-domain certificates, so there are fewer certificates to monitor and manage.
- Lower renewal overhead and cost: Having only one certificate to buy and later renew costs less than buying three or 10 single-domain certificates. At the time of writing, a Domain Validation (DV) level single-domain certificate on Sectigo, for example, costs $96 per year, while a multi-domain certificate that covers three domains costs $268 per year.
- Flexibility to add or remove domain names: Most CAs let you modify the domain list over the certificate’s lifetime rather than force a brand new certificate request every time your infrastructure changes. Using a wildcard entry, like *.yourdomain[.]com, instead of listing individual subdomain names, goes a step further. This way, you can spin up new subdomains freely without touching the certificate at all.
- Lower risk of outages from missed renewals: Fewer expiration dates to track means fewer chances that one gets missed and takes a site down unexpectedly.
How to Get a SAN Certificate?
- Decide which hostnames need coverage: List all domain names, subdomains (or add wildcards), or IP addresses the certificate needs to protect before you request it.
- Check the provider’s limits and requirements: Some platforms, like Let’s Encrypt, require all names on the certificate to belong to the same domain, which is stricter than what the X.509 specifications technically allow.
- Generate a Certificate Signing Request (CSR): The CSR is a base64-encoded file that contains all your desired names in the SAN extension as well as the public key that will be used for encryption. Most CAs can generate this automatically for you, but it typically looks like this:
-----BEGIN CERTIFICATE REQUEST-----
MIICWDCCAUACAQAwSDELMAkGA1UEBhMCVVMxFDASBgNVBAoTC0V4YW1wbGUgSW5j
MRcwFQYDVQQDEw5leGFtcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAK... (truncated, this is illustrative, not a real key)
-----END CERTIFICATE REQUEST------ Submit the certificate request to a certificate authority: The CA, such as Let’s Encrypt, Sectigo, or DigiCert for public sites, will validate the submitted information in the CSR and verify domain ownership.
It’s worth noting that not every certificate is publicly trusted. Organizations often run their own internal, or enterprise certificate authority to issue certificates for systems that won’t need to be exposed outside the company, and those internal certificates aren’t bound by the CA/Browser Forum rule described earlier, since that rule only applies to publicly trusted CAs.
For internal or enterprise certificates, administrators running a Microsoft CA through Active Directory Certificate Services can request SAN certificates using the built-in Web Server certificate template, though they need to explicitly add the SAN attribute to the request since it isn’t included by default.
SANs and Domain Expansion in Cybersecurity
Because SAN certificates secure traffic for multiple domains, the SAN field also doubles as a data source for mapping an organization’s real footprint, especially in cybersecurity processes involved in attack surface management (ASM) and continuous threat exposure management (CTEM).
1. Asset Discovery and Attribution
Publicly trusted certificates are logged publicly in Certificate Transparency (CT) logs, and ASM tools query either these logs or an SSL Certificates Lookup API (to get a single source of truth instead of a variety of CT logs) to pull SAN lists from certificates tied to known domains, and use that to find additional domains and subdomains without needing to guess or brute-force anything.
If a certificate is issued to an organization and its SAN field lists 20 hostnames, all of them are very likely to belong to that same organization. However, security teams would still need to cross-check with WHOIS data, autonomous system (AS) data, DNS intelligence, and other sources before confirming attribution.
The discovered domains, subdomains, and IP addresses from the SAN fields are then cross-referenced to known assets. If security teams already know a company owns example[.]com, and you find a certificate with example[.]com and internal-portal.another-domain[.]net in the same SAN list, that second domain is now a strong candidate for the same organization’s asset inventory, even though the name looks unrelated.
A shared SAN certificate across multiple sites is a stronger signal than, say, similar page content or shared hosting, since issuing a certificate usually requires some level of domain control validation. That makes it harder to spoof than other attribution signals.
It’s worth noting, though, that wildcard entries in a SAN list often limit how much subdomain detail this method can actually turn up, since a wildcard hides the exact subdomains it covers.
2. Penetration Testing
Penetration testers use a similar asset discovery technique to described above, but they often have just one starting point: a domain name.
Before checking anything, testers use tools like the SSL Certificates API to pull the certificate for that domain and read its SAN list. If it includes blog.example[.]com, staging.example[.]com, or internal.example[.]com, those are now candidate targets (unless, of course, something is explicitly excluded in the scope documents).
They then use OSINT tools to query CT logs directly, searching for all certificates ever issued for the given domain. This brings up historical SAN entries too, including subdomains from certificates that have already expired or been replaced, which can point to forgotten infrastructure that’s still running.
Once a new hostname turns up, the process repeats on that hostname specifically, by checking its own certificate history in CT logs. If blog.example[.]com shares a certificate with partner-portal.new-corp[.]com, that second domain gets pulled into scope for investigation too, even though it doesn’t share the same root domain as the original target.
Like in asset discovery, wildcard entries prevent pentesters from getting a complete list of exact subdomains, so testers typically use multiple reconnaissance methods.
3. M&A and Subsidiary Mapping
When a company acquires or merges with another, security teams cross-reference SAN entries to figure out what infrastructure the acquired company actually owns, which may be incomplete or outdated in due-diligence paperwork.
The same technique works for divestitures, where you check whether a spun-off business still shares SSL certificates (and therefore infrastructure) with the parent company after separation. If that’s the case, then the parent company would likely have to remove the divested entity’s hostnames from its SAN field, and the latter would need to get its own SSL certificates.
Conclusion
The SAN field’s value appears in two very different places. For site owners, it means fewer certificates to manage and less risk of an expired one taking down a site.
For security teams, that same list of hostnames doubles as a data source, used to map infrastructure, pull unrelated but connected domains into scope, and help with attribution along with DNS, WHOIS, and other intelligence sources, whether that’s for asset discovery, a pentest, or due diligence on an acquisition.
Frequently Asked Questions
Is a “SAN certificate” a distinct certificate type, or just a TLS/SSL certificate with a SAN field?
A SAN certificate isn’t a distinct product category. It’s an industry term for a TLS/SSL certificate that lists multiple names in its SAN field, which has become synonymous with multi-domain certificates.
Do all TLS/SSL certificates have SAN fields?
Yes. Current CA/Browser Forum rules require every publicly trusted certificate to include a SAN, even those that only cover one hostname. This has been the rule since 2012, when the CA/Browser Forum’s Baseline Requirements made the SAN extension mandatory, largely to remove the ambiguity and parsing bugs that came with matching hostnames against the older Common Name field instead.
What’s the difference between a SAN certificate and a wildcard certificate?
A SAN certificate covers a defined list of names, which can include different domains entirely (acme[.]co and example[.]com together) and can include wildcard entries too. A wildcard certificate, by contrast, only covers subdomains of one specific domain, like *.example.com.
SAN vs. Common Name: What’s the difference?
Common Name (CN) was the original field used to identify a certificate’s hostname, before the SAN extension existed. Modern browsers no longer check the CN for hostname matching at all. They rely on the SAN list exclusively, which is why the CA/Browser Forum requires the CN’s value to also be repeated in the SAN when a CN is present.
How to add a domain to an existing SAN certificate?
If you already have a multi-domain SSL certificate and want to add a domain to that certificate, the actual process may vary for different providers, but it usually involves the following steps:
- Generate a new CSR
- Log in to your CA or provider account
- Reissue or edit the certificate
- Verify ownership
- Download the new certificate files and replace the old files on your web server