Hostname SAN-dwich in TLS Certs

PublishTime： 2022-03-18 Article Source：Keysight

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 4.1.2.6), 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, in an industry inundated by technical abbreviations, why do you need another technology with abbreviations? 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 api.facebook.com or 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., www.messenger.com).

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.

Implementation

SAN is one of many extensions that the X.509 (RFC5280, section 4.1.2.6) specifications enable. It lives within the 'extensions' field within the certificate. Here is what it looks like when seen in Wireshark:

SAN in Wireshark

Or alternatively (pun intended), you can see the extension in the browsers as well.

SAN in Chrome browser

As you 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 you 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, you just add the following block to the /etc/ssl/openssl.conf file (on Linux systems) before generating the CSR (Certificate Signing Request).

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

You 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.

+1 Like
Add to Favorites

Recommend

Selection Guide

More>

Technical Resources

More>

New Products & Solutions

More>

This document is provided by Sekorm Platform for VIP exclusive service. The copyright is owned by Sekorm. Without authorization, any medias, websites or individual are not allowed to reprint. When authorizing the reprint, the link of www.sekorm.com must be indicated.

Integrated Circuits