What is SAN Certificate and How Does it Work?
A SAN Certificate is an X.509 certificate which contains one or more names used to identify a computer by hostname or a user by their email address.
This guide will cover everything you need to know about SAN Certificates including:
- What is a SAN Certificate?
- What is a Subject Alternative Name (SAN)?
- What is a Wild Card SAN Certificate?
- What common use cases are there for a SAN Certificate?
- What are SAN Restrictions?
What is a SAN Certificate?
When organizations create X.509 certificates to represent a machine identity or a person (user) identity they include one or more Subject Alternative Name (SAN) entries in the X.509 certificate which identifies the machine or person the certificate represents. The SAN fields in a certificate are in a standardized format so that the certificate consumer (browser, authentication applications, etc) can easily determine the identity provided in the digital certificate.
A typical X.509 certificate used for machine identity or person identity validation has a Subject field which provides a simplified representation of the identity in X.500 format. For example a typical machine identity certificate will have a Subject of form "CN=hostname.domain" (e.g. "CN=finance.contoso.com") though this format is not standardized or required. A person identity certificate will have a Subject of form "CN=First Last" (e.g. "CN=John Smith") and this format also is not required. As you can see it would be up to the certificate consumer to determine if the certificate represents a person or a machine. In order to remove the ambiguity of the Subject field, the Subject Alternative Name (SAN) was created and standardized as part of the X.509 v3 extensions.
An X.509 certificate can have between zero and an unlimited number of SAN entries. In practice a typical digital certificate contains one or two SAN entries, though it's not uncommon to have ten SANs in a certificate.
A typical X.509 digital certificate for a machine identity for a hostname of "finance.contoso.com" might have the following SANs:
SAN[0] = DnsName: finance.contoso.com SAN[1] = DnsName: fin.contoso.com SAN[2] = DnsName: finweb.contoso.com
A typical person certificate might have the following SANs:
SAN[0] = Rfc822Name: [email protected]
While you can mix different SAN types in the same certificate you would typically not have DnsName and Rfc822Name SAN entries in the same certificate since each of these represents a different type of entity. A more typical scenario might be a machine certificate with a URI:
SAN[0] = DnsName: finance.contoso.com SAN[1] = DnsName: fin.contoso.com SAN[2] = DnsName: finweb.contoso.com SAN[3] = UniformResourceIdentifier: https://finweb.contoso.com
SAN certificates are sometimes referred to as multi-domain SSL certificates because they allow multiple hostnames to be represented in a single SSL/TLS certificate.
The next section describes in more detail what is a Subject Alternative Name (SAN).
What is a Subject Alternative Name (SAN)?
A Subject Alternative Name (SAN) is a name in a specific, standardized format typically found in an X.509 digital certificate. It is an X.509 Extension consisting of a SAN Type and a Value as specified in the RFC5280 standard. There are specific Types that may be used and are shown in the table below. The Value of a SAN is required to be in the format required by the Type. For example a SAN of type DnsName must have a string value of form "hostname" with the typically value being "hostname.domain".
The most commonly used SAN types are DnsName for hostnames and Rfc822Name for email addresses.
| SAN Type | Description | Format | Example |
|---|---|---|---|
| DnsName | DNS hostname with domain | host.domain | finance.contoso.com |
| Rfc822Name | RFC822 Name otherwise known as an email address | [email protected] | [email protected] |
| x400Address | X.400 Address | ||
| DirectoryName | Directory Name | ||
| EdiPartyName | EDI Party Name | ||
| UniformResourceIdentifier | A Uniform Resource Identifier aka URL. | https://host.domain | https://finance.contoso.com/sales |
| IpAddress | IP Address | X.X.X.X | 10.1.2.3 |
| RegisteredID | Registered Identifier | ||
| Other | Any other data in a custom format | Any | "The answer is always 42" |
What is a Wild Card SAN Certificate?
A Wild Card SAN is a DnsName SAN which contains an asterick (*) for a portion of the name value. For example
DnsName: *.test.contoso.com
In this example the SAN represents all hosts which end with "test.contoso.com". A certificate which contains a Wild Card SAN can be used on any matching hostname. In the above case a certificate with DnsName:*.test.contoso.com could be used on any host which is in the test.contoso.com domain.
Typically Wild Card SANs are used in place of multi hostnames. Let's say you have these hosts:
qa1.test.contoso.com qa2.test.contoso.com ... qa100.test.contoso.com
You could create a certificate which has a SAN for each hostname:
SAN[0]: DnsName: qa1.test.contoso.com SAN[1]: DnsName: qa2.test.contoso.com ... SAN[99]: DnsName: qa100.test.contoso.com
It can be quite tedious and burdonsome to create 100 SAN entries especially if there is frequent churn of the systems. The alternative is to use a Wild Card SAN:
SAN[0]: DnsName: *.test.contoso.com
This is actually an example of a very dangerous Wild Card because a single certificate can be moved to any host in test.contoso.com and re-used for nefarious purposes. It's important to understand that Wild Card SANs can be very dangerous if not used sparingly and with great thought.
What Common Use Cases are there for a SAN Certificate?
A SAN certificate is typically used to identify a machine or identify a person/user.
The most common use cases for SAN certificates are as follows:
- SSL/TLS Certificates. All applications which provide service over HTTPS (SSL/TLS over HTTP) require an X.509 certificate. These certificates are required by nearly every application to have a SAN DnsName entry which matches the hostname used to connect over SSL/TLS.
- Applications which require Client Authentication certificates. These include VPN clients, 802.1x EAP-TLS servers, and many enterprise application services.
- Certificate Signing Request (CSR). When submitting a CSR to a Certificate Authority you can also include SANs in the CSR. The purpose of this is to request the CA to include those exact SANs in the issued certificate. It is up to the CA to decide if it will honor any or all of the SANs in the CSR.
What Are SAN Certificate Restrictions?
There are a number of restrictions to SANs in certificates that you should be aware of.
- Maximum number of SANs in a certificate: There is no limit specified by RFC5280 but instead the limits are imposed by Certificate Authorities. Microsoft ADCS has no limit. Commercial CAs often have limits of 10 or even 100.
- The SAN types you can use are controlled by the issuing Certificate Authority. In the case of Microsoft ADCS it is controlled by the ADCS Template. Commercial CAs typically only support DnsName SAN types.
- Wild card SANs are typically not allowed by Commercial CAs.
Automate SAN Certificates and More
CertAccord Enterprise automates the creation and renewal of X.509 SAN certificates on Linux, Mac, and Windows. It can quickly create SAN certificates safely, securely, and deploy at scale.