About Subject Alternative Names (SANs)

In X.509 certificates, a Subject Alternative Name extension allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record. Values can include:

  • DNS names. This SAN type is the successor to the common name for server certificates. They provide the set of DNS resolvable host names that are valid server endpoints for the certificate. TLS requires that one of the DNS SANs match the host portion of the URL in order to be trusted.
  • Email address. This SAN type is applicable to user certificates that are used for signing and encrypting emails. The format of email SAN values follows RFC822 (standard Internet email address format) hence the reason this type of SAN is sometimes referred to as an RFC822 SAN.
  • URI. This SAN type allows to you embed a URL like https://example.com into a certificate.
  • IP address. This SAN type is an alternative to DNS SANs for server certificates. Rather than a DNS resolvable host name, an IPv4 or IPv6 address specified can be used in the URL and as long as there is a corresponding IP SAN in the certificate it would be trusted for a TLS connection.
  • UPN. This SAN type is applicable to user and device certificates that are used for TLS client authentication. The UPN SAN provides the identity (user principal name) of the client to the server. The format of UPN SANs is the same as for email SANs (user@domain) and often UPNs for users are the same as their email address but there isn't a requirement for them to be the same.

    UPN SANs are different from the first four SAN types in this list in that they're not defined by RFC5280. They're a special type of SAN that makes use of the "OtherName" SAN type which identifies it as a UPN SAN by a unique OID 1.3.6.1.4.1.311.20.2.3.

    Smartcards are a case of TLS client authentication certificates which make use of UPN SANs.

  • Other objects. A registered Object identifier followed by a value.

Detail in about SANS in certificates can be found in RFC 5280 section 4.2.1.6.