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.
Most Subject Alternative Names (SANs) are supported in certificate objects.
The following SANs are supported:
- DNS
- Email address
- URI
- IP address
- OtherName (User Principal Name only)
Using a policy setting in Aperture, you can control what SANS are allowed for certificate enrollment.
For more on how to control SANS using policy settings in Aperture, see Setting policy on a folder.
-
In the Policy tree, open the certificate work object.
-
To add Subject Alt Names, click Add/Remove .
-
Select the SAN Type from the drop-down list.
- Enter the SAN value.
- Click Add.
In which situations can you add or remove SANs from a certificate or certificate work object?
How the CSR is generated |
Ability to add or remove |
---|---|
Select Service Generated CSR | SANs can be added and removed at any time. Fully manual way to create a certificate. Fill in the fields manually then issue the certificate when desired. |
Select Manual CSR, upload a CSR which contains no SANs | All SANs types can be added or removed at any time. However, DNS out-of-band SANs Any Subject Alt Name (SAN) that is added to a certificate object after uploading a CSR that contains no SANs.These SANs are transmitted to the issuing CA along with the CSR, then added to the certificate by the CA. is supported by only the Symantec . They are the only drivers that can issue certificates with out-of-band DNS SANs. |
Select Manual CSR, upload a CSR which contains SANs | SANs cannot be added or removed. |
Select Service Generated CSR, upload a certificate which contains no SANs | SANs can be added or removed at any time. Importing the certificate enables Trust Protection Platform's monitoring system. Importing the CSR does not enable monitoring. |
Select Service Generated CSR, upload a certificate which contains SANs | SANs can be added or removed at any time. You can also configure all of the other settings on the object. |