SAN/UC technology

SAN (Subject Alternative Name) was created to extend SSL certificate functionality by securing more subjects/domains. SSL certificates with SAN support enable you to secure more domains and cut the costs of buing certificates as such. Saving IP addresses for encrypted communication is another advantage and last, but not least, they save administrators time installing them on the server. SAN SSL certificates are also used to secure Microsoft Exchange Server, Microsoft OfficeCommunication Server or MobileDevice Manager Unified Communications (UC) services.
You can find a wider range of SAN/UC certificates in SSLmarket portfolio.

SAN Certificates

Securing more domains and subjects

You can put domains and names which you can't generally put in the Common name (certificate domain) in the certificate that supports SAN technology. SAN certificates are described in RFC 3280 - Internet X.509 Public Key Infrastructure.

Usage examples

  • (FQDN - Fully Qualified Domain Name)
  • (FQDN - Fully Qualified Domain Name)
  • server.local (internal domain name)
  • (subdomain)
  • (subdomain)
  • (private IP address)
  • msexchange1 (netbios name)
  • (public IP address)
  • post01 (not valid name or domain)

For Fully Qualified Domain Names (FQDN), the certificate applicant authorization will be performed against the domain owner. If you don't own the domain but you want to enter it as SAN, you will need the domain owner's permission.
It is no longer possible to enter a non-qualified name and certificate containing non-qualified SANs will be cancelled (revoked) after 1 November 2016 (based on CA/Browser forum recommendation).

IP addresses:

It is no longer possible to enter an IP adress. All certificates containing IP adress will be cancelled (revoked) after 1 November 2016 (based on CA/Browser forum recommendation)

Notice: If you want to use SANs in your SSL certificate, you have to enter at least one SAN name during the order.
After issuing a certificate without SAN no other SAN names can be added.