Hostname SAN-dwich in TLS Certs
2022-03-11 | 7 min read
What is SAN?
TLS certificates are essentially digital certificates which are issued by a trusted third-party certificate authority. Used in the TLS handshake process, it authenticates the website (or hostname) that it is issued to and ensures that the user is communicating to a legitimate entity.
SAN, or Subject Alternative Name, is an extension that is part of the X.509 TLS certificate specification (RFC5280, section 126.96.36.199), which allows a certificate to authenticate multiple hostnames at once.
Multi-domain certificates that leverage the use of SAN are also often referred to as SAN Certificates.
The Need for SAN
So why do we need yet another technology with an acronym in an industry overwhelmed with tech acronyms?
The answer, as it often does, lies in efficiency.
In the past, the TLS certificate was only able to authenticate the one hostname mentioned in its
subject-Id-at-common-name field. The certificate is only valid if the common name is the same as the hostname requested by the user.
It could, however, authenticate subdomains of a hostname using a ‘wildcard’ hostnames. These are the hostnames that start with a star character (e.g.,
*.facebook.com) and indicated that hostnames like
login.facebook.com were also covered by the certificate.
But the common name field could not cover hostnames that were completely different yet belonged to the same parent organization (e.g.,
That is where SAN comes in, it allows the certificate to cover and authenticate multiple hostnames. It is a cost-effective solution that benefits organizations who otherwise needed to acquire multiple certificates for their different services. There is also the reduction in overheads that are associated with maintenance and renewal of multiple certificates.
Bringing flexibility, SAN allows the certificate to provide coverage for E-mail addresses, IP addresses and Uniform Resource Identifiers (URIs) among others as well.
SAN is one of many extensions that the X.509 (RFC5280, section 188.8.131.52) specifications enable. It lives within the ‘extensions’ field within the certificate. Here is what it looks like when seen in Wireshark:
Or alternatively (pun intended), we can see the extension in the browsers as well.
As we can see, there are multiple entries to the DNS Name field, where the hostnames are mentioned. According to the RFC5280, there are no limits yet as to how many SAN hostnames we can mention in a single certificate, though the certificate authorities may impose their own restrictions on it.
Adding SAN to the certificate is not that complicated as well. With OpenSSL 1.0.2l, we just add the following block to the /etc/ssl/openssl.conf file (on Linux systems) before generating the CSR (Certificate Signing Request).
[ SAN ]
Then use the
-extfile argument in the OpenSSL command to pass the same string (written on a temp file) while generating the .crt file.
After these steps, you will have generated a certificate with SAN extension that is ready to be used at your disposal.
Acceptance from the Internet
We fetched the Top 1000 websites (as per Alexa) and investigated the logged certificates for the SAN field. For every certificate that was found and analyzed, SAN was found in each of them. This small survey confirmed that there is almost complete integration of SAN in the server side within top 1000 websites of the internet.
On the client side, the CA/Browser Forum in its Baseline Requirements (Section 9.2.1) has required SAN certificates since 2012. Without SAN, a certificate is considered non-standard and would get flagged by popular browsers. Browsers have also started to ignore the common name field in the presence of the SAN field. Which is why popular certificate vendors now repeat the common name as the first SAN in their certificates.
Popular browsers have also stopped falling back to the common name in the absence of SAN for new certificates, citing the baseline requirements.
What's Next for SAN?
SAN has been around since 1997, After its introduction, certificates have had at least two methods to disclose its ties to a domain name.
Since RFC2818 (solidified in 2000), the common name has been deprecated. Along with the limitations of the common name, it is also ambiguous or untyped, so it is unclear whether the value stored in it is an IP or a host. RFC6125 (Section 6.4.4) mandates to not even seek the common name field if SAN or any other application-specific identifier type is present.
The writing on the wall is clear: SAN is the future. Going forward, it might exist as the sole trusted and reliable source of domain binding information within a certificate.
SAN in ATI
Since the ATI2022-02 release, BreakingPoint Systems have completely committed to use SAN certificates. Most of the web-based application protocols that have been released in the past without SAN in their TLS certificates now are updated to include it.