Learn about wildcard and SAN Multi-Use SSL certificates and how you can simplify certificate management with reduced cost with digital certificates from Thawte.

Wildcard and SAN:

Understanding Multi-Use

SSL Certicates

LEVERAGING MULTI-USE DIGITAL CERTIFICATES TO SIMPLIFY CERTIFICATE

MANAGEMENT AND REDUCE COSTS

Wildcard and SAN: Understanding

Multi-Use SSL Certicates

hen you employ web-based services on the Internet, SSL

certicates are the industry standard for authentication

and security. Depending on how you plan to use SSL certicates,

multi-use certicates can provide greater exibility than traditional

certicates. Multi-use certicates protect multiple Fully Qualied

Domain Names (FQDNs) and subdomains, lowering your

administrative costs and simplifying certicate installation,

management, and deployment.

About Digital Certicates

The best way to prove your identity on the Internet is to use

a digital certicate. A digital certicate relies on a trusted

third-party authority, or Certicate Authority, to verify your identity

and then uses a chain of trust that begins with you and works up

to the trusted authority to validate your identity. This chain of

trust provides veriable security on the internet. Digital

certicates provide:

PROOF OF AUTHENTICITY

Digital certicates demonstrate and validate the authenticity of

the source of the web content.

INTEGRITY

Digital certicates make it difcult to modify content in transit

because the content is encrypted.

AVAILABILITY

Digital certicates enable the availability of secure information

exchange online. By providing a constant verication service,

Certicate Authorities identify bad risks for certicates and

mitigate those risks through a series of lists and checks.

CONFIDENTIALITY

SSL encrypts data both in the content itself and in the transport

mechanism that is used to send the data to a destination on the

Internet, ensuring condentiality.

A SSL trust mark or site seal lets your customers know

that a Certicate Authority has authenticated and

veried your organization.

Using SSL to Move HTTPS

Organizations that process transactions on the Internet, or offer

Internet-based services, rely on digital certicates to validate that

they are who they claim to be, ensuring trust in their services.

Most organizations add certicates to their Internet-facing servers

to ensure accurate proof of their identity.

2005-00-00

SECURED

2012-00-00

When a customer accesses a web page that is hosted on a

server with a digital certicate, their web browser automatically

detects the certicate and modies the session. The session

moves from an “open” session that uses Hypertext Transfer

Protocol (HTTP) to a secure HTTP (HTTPS). HTTPS allows for

the encryption of all the data sent between the user’s computer

and the server.

Secure Sockets Layer

Secure Socket Layer (SSL) provides HTTPS data encryption.

SSL creates an encryption tunnel between the client and the

server that protects the transfer of data from one point to the

other during the communication exchange. You know you are

using SSL when the web address starts with https:, and your

browser displays a closed padlock in its status bar, and/or you

see a green background in the address bar. Note that the green

background in the address bar and the padlock are hallmarks of

an Extended Validation (EV) SSL certicate. Extended Validation

certicates provides the highest level of authentication available

for a SSL certicate. Because EV SSL authentication standards

require strict issuance and management processes established

by the CA/Browser Forum, EV SSL Certicates provide an extra

layer of protection for online businesses and their customers.

Protecting Servers and Services with

SSL Certicates

To enable SSL on an externally facing server, an organization

must purchase a certicate from a trusted Certication Authority

(CA). The organization purchases one certicate for each service

that it plans to protect (e.g. email, instant messaging, mobile

device management, and web-based interactions).

An SSL certicate contains the service’s Fully Qualied Domain

Name (FQDN) and ties a service’s domain name to the server.

This combination makes it possible for a browser (or another

agent) to compare the domain name that the service accesses

with the domain name of the certicate.

Maintaining SSL Certicates

Certicates last for a nite period of time: typically one, two,

or three year periods. To avoid maintenance every year, it

is recommended you purchase certicates that are valid for

extended periods of time.

It’s also convenient to select static service names because each

time a service name changes, the certicate must change on

each server that provides the service. These strategies reduce

the workload associated with periodic renewal and installation of

certicates on your servers.

Services that use subdomain names (names that use the

same root, or domain name, but have a different prex, or

subdomain name) have an additional maintenance overhead.

Because subdomain names are embedded into SSL certicates,

organizations usually buy one certicate per service. If the

organization protects numerous services with unique certicates,

this can become expensive and timeconsuming to manage.

Types of Multi-Use SSL Certicates

Two types of multi-use SSL certicates can greatly reduce the

complexity of managing SSL for services and subdomains.

• A Wildcard Certicate allows you to secure multiple

subdomains under a single unique FQDN. Using

one wildcard certicate not only simplies certicate

management, but also lowers your administrative costs

while providing immediate protection to current and

future subdomains.

• A single Subject Alternative Name (SAN) Certicate can

secure multiple FQDNs. SAN certicates provide exibility

when your websites do not share the same domain name.

Unlike Wildcard Certicates, SAN certicates have the

additional benet of being able to support deployments that

require Extended Validation (EV) certicates.

Wildcard Certicates

Wildcard certicates are regular SSL Certicates that support

the wildcard character “

” as a prex to the FQDN, allowing it

to secure multiple services. Wildcard certicates do not include

specic service names and always contain a wildcard character

that prexes the domain name.

A wildcard certicate can be more exible than using multiple

single purpose certicates because you can apply the wildcard

certicate to a number of different services. You can also add,

change, or replace services without needing to update the

certicate or purchase new certicates.

A single wildcard certicate–like *.thawte.com–can

secure the following domains:

www.thawte.com

nance.thawte.com

mail.thawte.com

sip.thawte.com

However, it cannot secure:

www.thawte.ca

mail.test.thawte.com

For example, suppose you want to protect servers that run an

instant communication protocol like Session Initiation Protocol

(SIP) and an email service. With single-use certicates, you

need two certicates because you have to embed the name of

each service into each certicate. As long as the domain is the

same, however, you can secure both domains with one wildcard

certicate. So the wildcard *.thawte.com can secure both sip.

thawte.com and mail.thawte. com with just one certicate.

Using a wildcard character as a placeholder in the domain

name embedded into the certicate makes the certicate more

exible. You can also apply it to any number of services since

the wildcard character can represent any subdomain name,

simplifying the certicate management process.

Because wildcard certicates manage multiple subdomains and

the services names they support, they can be less secure than

SAN certicates. We do not recommend their use as the primary

certicate solution for enterprises. When you deploy a wildcard

certicate, always make sure that you implement strong logical

and physical policies to protect your assets.

Subject Alternative Name (SAN) Certicates

Subject Alternative Name (SAN) certicates enable you to include

multiple FQDNs in one certicate. Unlike wildcard certicates that

can support an unlimited number of prex or subdomain names

as long as the domain name remains the same, SAN certicates

only support the FQDNs entered into the certicate. Depending

on the issuing Certicate Authority, SAN certicates can support

100 or more different FQDNs in one certicate.

A SAN certicate includes the standard Subject Name eld,

which supports a single primary web-based service name. The

subject name is what the certicate secures, as listed in the

example below in the component elds. It consists of a Common

Name, Organization, Organizational Unit, Locality, State, and

Country. It has an additional eld–the Subject Alternative Name

(SAN) eld–for additional service names. You can install a SAN

certicate on several servers, where it supports internal and

external service delivery.

SAN EXAMPLE

One SAN certicate can protect:

yourbusiness.co.uk

mybusiness.com

yourbusiness.net

products.yourbusiness.com

support.products

yourbusiness.com

Subject Alternative Name (SAN) certicates are also called Unied

Communications Certicates (UCC) because they were primarily

designed to support real-time communications infrastructures.

SAN certicates, or UCCs, are useful when organizations want to

use different root or domain names to run Internet-facing services.

For example, an organization that provides internal (sip.thawte.

net) and external domain (sip.thawte.com) unied communications

services can use a single SAN certicate to secure both FQDNs.

The organization would need two wildcard certicates because

thawte.net and thawte.com are different domains.

Another way to use a SAN certicate is when you validate secure

internal and external services.

You might have both an internal and external SIP service for

instant messaging: internal sip.thawte.com and external sip.

thawte.net. In this situation, you must have a certicate on each

server in the internal and external service to allow your users

to work whether they are in the ofce or on the road. The same

scenario applies for instant messaging infrastructures where you

want to encrypt both internal and external messages. Note that

servers cannot include two certicates for the same purpose.

SAN certicates are also useful for Application Service Providers

(ASP) who host applications for multiple clients with each client

using their own domain name. By using a SAN certicate, ASPs

can use a single certicate to support multiple clients. Note that

the site seal and certicate are only for the primary domain name

entered in the certicate and do not include any of the other

domain names. The certicate includes all of the domain names

veried at the time of purchase.

SAN certicates have the same issues as single-purpose

certicates. When the actual service names are embedded into

the certicate, your services must always use the same name

otherwise you have to change the certicate. Because the

certicate is a multi-use certicate, you change it on each of the

servers that host the certicate-supported service. When you

want to add services to provide further functionality to your users,

you must update the SAN certicate with the new service names.

While SAN certicates are useful for supporting unied

communications deployments, keep these caveats in mind:

• SAN certicates do not support wildcard characters.

For this reason, you need to add subdomain names as

unique domain name entries in the certicate at the point

of purchase. Each time you want to add a new domain

name or you remove an old one, you need to update

and re-deploy the certicate to each host server.

• When hosting web sites for multiple clients, ASPs should

be aware that all domain names are visible in a SAN

certicate. If the ASP does not want one site to appear

connected to another, use a different kind of certicate.

Making the Selection

Multi-use certicates can secure multiple web services using

a single certicate. To accomplish this, these certicates either

add a subject alternate name eld to the common single-use

certicate or use a wildcard to replace the subdomain or prex

name in the certicate.

Multi-use certicates save money and simplify management by

including multiple names within the same certicate or replacing

service names with a wildcard. Use SAN certicates when you

need multiple domain names for each service.

WILDCARD CERTIFICATES

Use a wildcard certicate when you want:

• a single domain name for all services

• a single domain and multiple subdomains that cover

all services

SAN CERTIFICATES

Use a SAN certicate when you want:

• unique domain names for each service

• the option of providing Extended Validation protection

In Summary

Most organizations use a least one public domain name and one

private domain name to segregate their internal and external

name spaces. In this case, only SAN certicates work.

For organizations that only use one single public domain name

the wildcard certicate may be a good option.

Multi-use certicates make it much easier to deploy multiple

secure services both internally and externally and have distinct

advantages in lowering costs and reducing resources. This ease

of deployment is particularly useful in environments that include

several services such as mail, instant messaging, web, mobile

device management, and File Transfer Protocol. If this is the

situation that applies for your organization, then your best choice

is a multi-use certicate designed to t your needs.

Wildcard vs. SAN Certicates

The following table provides you with an overview of the differences between the SAN and wildcard certicates.

Certicate Feature Wildcard SAN Comment

Multiple secure domain

support

Yes Yes Both certicate types support multiple secure domain names. Wildcard

supports multiple sub domains to one domain, per certicate. SAN-

enabled certicates can support multiple domain names; the limitation is

the number of SANs per certicate established by the CA.

UCC or SAN support Yes Both certicate types support multiple uses.

Microsoft Exchange Server, Microsoft Ofce Communications Server and

Microsoft System Center Mobile Device Manager use SAN.

Number of Fully

Qualied Domain

Names (FQDNs)

1 Multiple Wildcard certicates only support one single domain name, but a

nearly unlimited number of subdomains. SAN-enabled Certicates can

support multiple domains, multiple host names, etc. The limitation is

the amount of SAN’s per certicate. This limitation is established by the

Certication Authority.

Domain name

ownership

1 Multiple An organization must own, or be authorized to use, any and all domains

in the certicate’s subject. The Wildcard product and SAN functionality are

subject to these basic requirements.

Domain name format *.name.com Multiple Wildcard certicates use a single name format (*.name.com). SAN

certicates can use any FQDN.

Name exibility Yes In a Wildcard certicate, only the subdomain can change. Additionally,

a subdomain must exist in place of the wildcard character; for example,

https://*.thawte.com cannot secure https://thawte.com. By contrast, a

certicate for https://www.thawte.com can support a SAN of https://thawte.

com or https://www.thawte.org.

Cost control Yes Wildcards allow for future-proong. You don’t need to buy additional

certicates later as long as you are securing subdomains under

one domain.

Secure private key Yes Yes Both certicate types include a secure private and public key pair.

However, if you use a single wildcard certicate on multiple servers and

one server is compromised, all servers become compromised. For this

reason, each server hosting a wildcard certicate should have its own

version of the certicate with its own private key. The same issue is

possible with SAN certicates. Make sure you keep the private key secure

at all times.

Best PKI practice: Multiple servers sharing one key pair are prone to a

single point of failure. We recommend unique key pairs in multi-server

scenarios, where possible.

Certicate Feature Wildcard SAN Comment

Simplicity of

management

Yes Yes Wildcard certicates are easier to manage than SAN certicates because

they support any subdomain. SAN certicates must be updated each time

a new domain is added or an old domain is dropped.

Note that due to the convenient nature of wildcard certicates, you have to

keep careful track of the subdomains that the certicate secures. Keeping

a close record of supported subdomains helps eliminate the chance that a

“rogue” subdomain exists.

Strong physical policy or access control measures to limit who can add/

change/remove host headers are also recommended to eliminate the

possibility of rogue subdomains.

Domain-only

authentication

Because the wildcard certicate supports unlimited subdomains, it is not

available in domain-only format. SAN certicates are also not available in

domain-only format because they include multiple domains.

SHA-1 Yes Yes SHA-1 (a secure hash algorithm) is supported on both types of certicate.

Organizational validated

authentication

Yes Yes Both types of certicate are only available in organizational validated

format, which is more trustworthy than domain-only certicates.

Organizational validated authentication certicates require both domain

validation and organization validation.

SSL encryption Yes Yes Both certicate types support 128-bit and better encryption.

Number of domains

secured

Unlimited

subdomains

Specied

FQDNs

Wildcard certicates validate virtually an unlimited number of subdomains

that are based on the same domain name (though for example, *.thawte.

com does not secure group.test.thawte.com). SAN certicates support

only the domain names entered in the certicate. The number of domains

supported in a SAN certicate depends on the certicate authority.

Extended validation Yes Extended Validation SSL Certicates (EV SSL) instill customer condence

by enabling web browsers to display the green address bar, one of the

most trusted and recognized security indicators available.

Site seal Yes Yes Wildcard site seals are assigned to the domain name. SAN site seals are

assigned to the primary domain name in the certicate.

Mobile device support Yes Yes Note that some older devices, for example, Windows Mobile version 5,

do not support the wildcard character. Check with your vendors to see if

updates are available to support wildcard certicates. All devices support

the SAN certicate.

of Thawte, Inc. and its subsidiaries and afliates in the United States and in foreign countries. All other trademarks are property of their respective owners.

Certicate Feature Wildcard SAN Comment

Browser compatibility 99+% 99+% All modern browsers support both types of certicates.

Validity duration Multi-Year Multi-Year Both certicate types are available for multi-year spans.

Warranty Yes Yes Certicate providers can provide warranties for both types of certicates.

Shared hosting usage Yes You can only use SAN certicates for shared hosting because they support

multiple domain names.

Quality assurance

testing usage

Yes Yes Wildcard certicates can only be used in QA testing environments that use

the same domain name. SAN certicates can be used in environments

that use either the same domain name or multiple domain names.

• Via phone

– US toll-free: +1 888 484 2983

– UK: +44 203 450 5486

– South Africa: +27 21 819 2800

– Germany: +49 69 3807 89081

– France: +33 1 57 32 42 68

• Email sales@thawte.com

• Visit our website at

https://www.thawte.com/log-in

To learn more, contact our sales advisors:

Protect your business and translate

trust to your customers with high-

assurance digital certicates from

Thawte, the world’s rst international

specialist in online security. Backed by

a 17-year track record of stability and

reliability, a proven infrastructure, and

world-class customer support, Thawte

is the international partner of choice

for businesses worldwide.