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.
  • User principal name (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.

  • Custom OtherName. A flexible Subject Alternative Name (SAN) option that allows you to specify a custom Object Identifier (OID) and a friendly name.

    To use this SAN type, an administrator must first configure the custom OID within the root policy folder of the Policy Tree. This is done by selecting the Policy folder, navigating to the Certificate tab, and accessing the Subject Alt Name Definitions section.

    Like the User Principal Name (UPN) SAN, the Custom OtherName SAN enables the configuration of OtherName types on individual certificates, allowing them to be recognized as a Subject Alt Name during certificate issuance

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