Subject Alternative Name Certificates

The Shortcut Guide ToThe Shortcut Guide Totmtm

Subject Alternative Name Certificates

Mike Danseglio

Introduction

i

Introduction to Realtime Publishers by Don Jones, Series Editor For several years now, Realtime has produced dozens and dozens of high‐quality books that just happen to be delivered in electronic format—at no cost to you, the reader. We’ve made this unique publishing model work through the generous support and cooperation of our sponsors, who agree to bear each book’s production expenses for the benefit of our readers.

Although we’ve always offered our publications to you for free, don’t think for a moment that quality is anything less than our top priority. My job is to make sure that our books are as good as—and in most cases better than—any printed book that would cost you $40 or more. Our electronic publishing model offers several advantages over printed books: You receive chapters literally as fast as our authors produce them (hence the “realtime” aspect of our model), and we can update chapters to reflect the latest changes in technology.

I want to point out that our books are by no means paid advertisements or white papers. We’re an independent publishing company, and an important aspect of my job is to make sure that our authors are free to voice their expertise and opinions without reservation or restriction. We maintain complete editorial control of our publications, and I’m proud that we’ve produced so many quality books over the past years.

I want to extend an invitation to visit us at http://nexus.realtimepublishers.com, especially if you’ve received this publication from a friend or colleague. We have a wide variety of additional books on a range of topics, and you’re sure to find something that’s of interest to you—and it won’t cost you a thing. We hope you’ll continue to come to Realtime for your

far into the future. educational needs

enjoy. Until then,

Don Jones

http://nexus.realtimepublishers.com/

Table of Contents

ii

Introduction to Realtime Publishers ................................................................................................................. i

Ch

apter 1: Introduction to Certificates ........................................................................................................... 1

Intended Audience .............................................................................................................................................. 2

How to Use This Guide ...................................................................................................................................... 3

W hat Are Certificates? ....................................................................................................................................... 4

What Do Certificates Do? ............................................................................................................................. 5

What Is Trust? ....................................................................................................................................................... 6

Summary .............................................................................................................................................................. 12

Glossary ................................................................................................................................................................ 13

Ch apter 2: SAN Certificates In‐Depth ........................................................................................................... 16

W hat Is a SAN Certificate? ............................................................................................................................ 16

Overview ......................................................................................................................................................... 16

Te chnical Details .......................................................................................................................................... 17

Examining Certificate Details ............................................................................................................ 17

Us es For SAN Certificates ......................................................................................................................... 22

Email ............................................................................................................................................................. 22

Instant Messaging ................................................................................................................................... 23

Secure Sockets Layer ............................................................................................................................. 25

Re questing and Receiving a SAN Certificate ......................................................................................... 25

Identifying Resources and Uses ............................................................................................................ 25

Ob taining the Certificate ........................................................................................................................... 26

Outsourced PKI ........................................................................................................................................ 26

Internally Managed PKI........................................................................................................................ 27

Wildcard Certificates....................................................................................................................................... 30

Summary .............................................................................................................................................................. 30

Ch apter 3: The Business Value of SAN Certificates ................................................................................. 32

The Business Value .......................................................................................................................................... 32

Table of Contents

iii

Us ing Existing Resources .............................................................................................................................. 33

Ce rtificate Request ...................................................................................................................................... 33

Common Tasks ......................................................................................................................................... 34

Cost of Tasks ............................................................................................................................................. 36

SAN Certificate vs. Standard Certificate ........................................................................................ 37

Ce rtificate Issuance ..................................................................................................................................... 37

Common Tasks ......................................................................................................................................... 37

Cost of Tasks ............................................................................................................................................. 38


Ce rtificate Deployment ............................................................................................................................. 41

Common Tasks ......................................................................................................................................... 42

Cost of Tasks ............................................................................................................................................. 42


Ce rtificate Maintenance ............................................................................................................................ 42

Common Tasks ......................................................................................................................................... 42

Cost of Tasks ............................................................................................................................................. 44


Certification as a Business Driver.............................................................................................................. 45

Summary .............................................................................................................................................................. 46

Ch apter 4: Planning and Implementing a SAN‐Enabled Certificate Strategy .............................. 47

Pla nning for SAN Certificates ...................................................................................................................... 48

Planning PKI Applications ....................................................................................................................... 52

How to Determine Whether an Application Supports SAN Certificates .............................. 52

Using SAN Certificates in Your Environment .................................................................................. 54

SAN Operation and Maintenance ............................................................................................................... 59

Summary .............................................................................................................................................................. 60

Copyright Statement

iv

Copyright Statement © 2009 Realtime Publishers, Inc. All rights reserved. This site contains materials that have been created, developed, or commissioned by, and published with the permission of, Realtime Publishers, Inc. (the “Materials”) and this site and any such Materials are protected by international copyright and trademark laws.

THE MATERIALS ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. The Materials are subject to change without notice and do not represent a commitment on the part of Realtime Publishers, Inc or its web site sponsors. In no event shall Realtime Publishers, Inc. or its web site sponsors be held liable for technical or editorial errors or omissions contained in the Materials, including without limitation, for any direct, indirect, incidental, special, exemplary or consequential damages whatsoever resulting from the use of any information contained in the Materials.

The Materials (including but not limited to the text, images, audio, and/or video) may not be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any way, in whole or in part, except that one copy may be downloaded for your personal, non-commercial use on a single computer. In connection with such use, you may not modify or obscure any copyright or other proprietary notice.

The Materials may contain trademarks, services marks and logos that are the property of third parties. You are not permitted to use these trademarks, services marks or logos without prior written consent of such third parties.

Realtime Publishers and the Realtime Publishers logo are registered in the US Patent & Trademark Office. All other product or service names are the property of their respective owners.

If you have any questions about these terms, or if you would like information about licensing materials from Realtime Publishers, please contact us via e-mail at [email protected].

This sponsored eBook is valid until August 31, 2011.

c) 2009 VeriSign, Inc. All rights reserved. VeriSign, the VeriSign logo, and other VeriSign trademarks, service marks, and designs are registered or unregistered trademarks of VeriSign, Inc. and its subsidiaries in the United States and in foreign countries. All other trademarks are property of their respective owners.

mailto:[email protected]

Chapter 1

1

[Editor's Note: This eBook was downloaded from Realtime Nexus—The Digital Library for IT Professionals. All leading technology eBooks and guides from Realtime Publishers can be ound at f http://nexus.realtimepublishers.com.]

Chapter 1: Introduction to Certificates

There are numerous ways to apply public key infrastructure (PKI). There are probably as many unique solutions available as there are companies to apply them to. A one‐size‐fits‐all PKI simply does not exist. And in a similar vein, there is no perfect PKI; there is almost always a tradeoff made during the process of PKI implementation.

For example, deploying an externally managed PKI may cut costs, such as internal headcount or the deployment of intranet infrastructure servers, while incurring other costs, including monthly maintenance fees. Another, more esoteric example is key size. Many cryptographic algorithms allow an administrator to select the size of the public key used for the PKI. As you may already know, the rule is that for any cryptography, the larger you make the key, the more secure the data becomes. So many executives and IT professionals will initially decide to use the largest key possible. And if there were no downsides, that would be a great choice. However, the drawback is that intense calculations must be made every time the key is used, and particularly when the key is generated. As a result, the system becomes far more secure but far slower.

Because there is no PKI solution, you need to be familiar with as many available options as possible. This familiarity helps you determine the best way to address the stated needs. For example, let’s say you need a new car. Once you’ve defined the intended uses (for example, commute to work, drive the kids to band practice) you can begin to identify cars that will fulfill those uses. Most people will not simply decide, “I’ll buy a Ford because it’s a car.” They will review many brands, models, dealerships, and price points until they narrow their search. People often test drive several cars, sometimes for long enough to use the vehicle for its actual intended use. And almost invariably, the selected vehicle is a compromise. How often have you heard, “I went with the VW because even though the VW is too small, the Mazda was too expensive, and the Toyota didn’t have the options I wanted.” This person is making a compromise.


Chapter 1

2

Selecting a PKI and approach is very much the same. You work with a broad representation of business stakeholders to identify the various business and security needs that this system will address; you then seek to meet the needs in the best possible way, as defined by your selection criteria (for example, budget, timeline, security requirements). You will most likely try out a sample implementation as a “test drive” of the PKI solution before committing to it. And then your selection will be a compromise between your driving factors. You will almost certainly have some amount of compromise in your decision because, frankly, you do not have infinite resources at your disposal.

This reality requires explanation because some readers might wonder why this guide does not provide an end‐to‐end usage architecture and instructions for specific use of Subject Alternative Name (SAN) certificates within a PKI. There is no way to accurately state that one solution is better than the other for a specific need without in‐depth research. However, there are numerous common techniques and methods that, over time, have proven to be effective. These are the techniques that this guide will explore and recommend.

Intended Audience A common practice for guides like this is to clearly define the intended audience. In this case, the definition is broken down by role within an IT organization. This guide is written with a few key roles in mind:

• IT generalist—IT departments are frequently small and do not allow personnel to specialize in a particular area. Every person performs tasks from multiple disciplines. These generalists work on different systems, so they need to be familiar with the basics of many technologies. This guide serves to introduce them to SAN certificates as well as provide a reference when they are performing PKI‐related tasks.

• PKI specialist—This person is part of a larger IT infrastructure or a consultant who specializes in PKI and digital certificates. They do not have the broad knowledge of the generalist but instead deeply understand the mechanics and inner workings of PKI. Someone in this role can read this guide in its entirety or use pieces to meet specific needs. They can also refer other IT personnel to this guide for clarification or instruction.

• IT architect—In most organizations, an architect assesses a need and plans a solution in collaboration with many others. This person needs to be aware of virtually every possible solution to a problem in order to properly assess the problem and determine the best possible solution.

Chapter 1

3

• Business Decision Maker (BDM)—There are two decision‐making roles in many organizations. The first, the BDM, takes into account business drivers, budget, user and organizational needs, and IT requirements when making strategic decisions. A person in this role may, for example, decide whether to implement an internal PKI or outsource the infrastructure. This person will not, by contrast, decide to use one technology or the other. They will communicate their strategic decision and requirements to a Technical Decision Maker.

• Technical Decision Maker (TDM)—This person is complementary to the BDM. The TDM decides what specific technologies or processes are appropriate to meet the needs that are defined by the BDM and works closely with the architect to plan and the generalist and specialist to implement the plans. The TDM is often at the center of a project and, in many frameworks, is akin to the project manager.

• Hybrid—You might hold more than one of these roles or none at all. Because every IT organization is different, I cannot accurately describe 100% of the roles. As a result, this section does not define the only people who can find value in the guide. It merely explains the audience defined as part of the writing process.

How to Use This Guide This guide is provided in four chapters. Each chapter focuses on a different aspect of the concepts and practical use of SAN certificates:

• Chapter 1: Introduction to Certificates—This chapter introduces broad PKI terms that are used throughout the guide. It provides a framework for the in‐depth concepts and application of SAN certificates in later chapters. Although this chapter may be considered review material for some readers, it is important to understand this information to ensure that later chapters are effective.

• Chapter 2: SAN Certificates In Depth—This chapter is dedicated to getting down into the details of a SAN certificate. It will examine the certificate structures and metadata and will compare data between SAN and non‐SAN certificates. It will also compare SAN certificates to wildcard certificates to understand the distinction between two somewhat similar products.

Chapter 1

4

• Chapter 3: The Business Value of SAN Certificates—Written primarily for the BDM and TDM readers, this chapter discusses the business aspect of SAN certificates. It will examine the business costs and return on investment (ROI) drivers that apply to both SAN and other similar certification strategies. This chapter supports the business and organizational elements of the solutions discussed in Chapter 2.

• Chapter 4: Planning and Implementing a SANEnabled Certificate Strategy—This chapter discuss the details of actually implementing a SAN‐enabled certificate strategy. Topics include analyzing existing systems and properly planning for a SAN certificate deployment. Ongoing operations‐based tasks are also explored. This chapter is useful for the implementers in an organization, such as the IT generalist or specialist, and the planning elements apply to architects as well.

What Are Certificates? In the past, a certificate has been an official document asserting facts in a trustworthy manner. For many of us, the first example we encounter is our birth certificate. It contains information such as our date of birth and name. It is signed and usually stamped by the issuing authority, usually by the hospital or local government. Later in life, we can use this certificate to assert our identity when we enroll in school or secure a loan.

Modern certificates are much the same. They assert some detailed information in a trustworthy manner, vouched for by an issuing authority. But nowadays, certificates convey different detailed data.

Within the context of this guide, consider the term “certificates” to be digital certificates unless otherwise noted.

Certificates contain a great deal of data that can be used for a variety of purposes. Let’s take a closer look at the data inside the certificate and how it gets used in a variety of ways.

Chapter 1

5

What Do Certificates Do? Although you are probably already familiar with digital certificates (referred to as simply “certificates” from here on), it is worth defining them clearly. A certificate is a data structure that provides a digitally secure representation of the holder’s identity. This data includes keys that make the certificate extremely difficult to modify or spoof without detection.

Certificates, by themselves, have limited use. A certificate is made up of data that provides the following information at minimum:

• Certificate holder

• issuer Certificate

• Public key

• Intended use This is the bare minimum information that a certificate contains. Most certificates have a great deal more information to make them useful to a wide variety of services and applications.

This information allows a computer (the certificate holder) to assert its identity in a trustworthy manner and initialize secure communication. An important distinction here is that although the certificate supports and enables a number of critical security functions including authentication and encryption, the certificate does not act on those functions. For example, a certificate is normally used when two computers establish a secure communications channel. The certificate and the associated PKI provide the data and identity support necessary to initialize that process. But the secure communication itself must be performed by a service or application designed to do so, such as the use of Secure

ers and Web servers. Sockets Layer (SSL) in Internet brows

Common uses of certificates include:

• Data encryption using common protection technologies such as Windows Encrypting File System (EFS)

• Email signing and encryption

• IP Security (IPSec) to establish authenticated and encrypted communication between multiple computers or isolate portions of a network

• SSL for authenticated and encrypted communication between Web servers and clients

There are many other uses that are less common. If they are central to your business operations, they may be critical. This list is just a brief sampling.

Chapter 1

6

Software is readily available on the Internet for generating digital certificates. Anyone—from the US government to major corporations to a lone malware developer—can generate digital certificates. This is analogous to anyone being able to issue drivers licenses. You can imagine how much credibility a police officer would give to someone driving with a license issued from “Acme Mail Order Licenses” or some other fly‐by‐night outfit. The value of a digital certificate does not lie just with the certificate itself but with the credibility and reputation of the institution that issued it. In a word, it is all about trust.

What Is Trust? A central theme for PKI and certificates is trust. Trust is itself somewhat difficult to describe, as there are both technical and perception components that combine to form what we define as trust.

Consider your decision about which bank to use. When you were trying to select a bank, a number of factors entered your mind. Will the bank be in business for a long time? Is my money safe? Does the bank have a good reputation with other customers? Does the bank have a great deal of assets to ensure its long‐term viability? These are all great questions and you probably had many more. But in the end, no matter how much research you did, you had to trust your money with your bank and trust that the bank will not go out of business or steal your money.

Now consider an example from ecommerce. Ten years ago you might not have heard of a new company called eBay and therefore would have been hesitant to do business with it. How can a startup or small company offer proof to potential customers that it is a legitimate business? After all, as Peter Steiner’s famed New Yorker cartoon captured so well, “On the Internet, nobody knows you’re a dog” (Source: http://www.unc.edu/depts/jomc/academics/dri/idog.html). What kind of due diligence can you expect when picking an online vendor? It is simply not reasonable to assess each vendor’s trustworthiness. A better option is to find a business you trust that will perform

. the due diligence work to evaluate vendors. That’s where digital certificate issuers come in

When you examine a certificate, you can always determine what company or entity issued the certificate. The issuer trusted the certificate subject in order to actually sign and issue the certificate. Therefore, you are also trusting the subject and the issuer when you accept and use a certificate.

Let’s look at a very common example. Figure 1.1 shows a Web site, PayPal, that uses certificates and SSL for authentication and communication.

http://www.unc.edu/depts/jomc/academics/dri/idog.html

Chapter 1

7

Figure 1.1: PayPal’s Web site—notice the green address bar and the padlock

identifying the Web site.

PayPal obviously wants the users to trust its Web site, as the company handles financial transactions and the site is linked to bank accounts. In fact, the site is using an Extended Validation (EV) SSL Certificate that suggests an additional level of trust.

Cross Reference For more information about EV SSL Certificates, see http://nexus.realtimepublishers.com/SGEVSC.htm.

To help facilitate that trust, the Web site uses certificates that chain to a well‐known root Certification Authority (CA). To show this clearly, let’s look at Figures 1.2 and 1.3.

Chapter 1

8

Figure 1.2: The PayPal Web site certificate showing the intended use for the

certificate.

Figure 1.2 is the default certificate view in Windows. It shows a great deal of information that is often considered when a client decides whether to trust the Web site. The information on this screen is explained in Table 1.1.

Certificate Field Description

Intended purposes A list that describes what the certificate can be used for

Issued by The CA that issued the certificate Issued to The party that requested, received, and is now

using the certificate Valid from Date range for which the certificate is valid

Table 1.1: Basic information listed for a certificate.

Chapter 1

9

When you select the Certification Path tab in this dialog box, you can examine the chain of trust. This chain includes all certificates from the one being examined to the trusted root certificate.

Figure 1.3: Detail of the PayPal Web site certificate showing its chain to the trusted

VeriSign root certificate.

Is this information sufficient to decide whether to trust the certificate or the subject? There is no cut‐and‐dry answer to that question. Someone in an IT group may believe that this certificate is not trustworthy enough because of past issues with the root certificate. A client seeing this certificate in their Web browser may not be familiar with the root CA. Others might recognize the name or do research and decide that they want to trust the certificate and, by proxy, the information protected by the certificate.

Chapter 1

10

Levels of Trust Different certificates can provide different levels of trust. In a perfect world, every certificate would be entirely trustworthy. And for a while, many people in the IT field believed that. But as we’ve discussed, anyone can get a digital certificate, whether from a less‐than‐ideal public PKI or by creating his or her own PKI and issuing a certificate there (there are free PKI software packages available today for this purpose). Thus, the usefulness of a digital certificate relies entirely on whether it is trusted when presented. For example, there are dozens of certificates—issued by recognizable companies including VeriSign, GTE, Entrust, Thawte, and Microsoft itself—built‐in to and trusted by a standard Windows installation. These certificates have gone through a specific trust process with Microsoft before being included. That process provides a specific level of trustworthiness. By contrast, certificates from individual companies that offer no assurance of trustworthiness or identification are not included by default. Acme Corporation may create a PKI and issue itself a self‐signed certificate that I encounter when using their ordering process. Acme may be trustworthy, but their certificate is still not trusted by default and requires me to explicitly trust it before use. Figure 1.4 offers a great example of a Web site that is using an untrusted, self‐signed certificate. This page is only shown after clicking through a warning that the certificate is not trusted and should be scrutinized.

Figure 1.4: A Web site using an untrusted, selfsigned certificate. Notice

the red address bar and red security shield.

Chapter 1

11

There is another portion of the certificate that hasn’t yet been illustrated. Figure 1.5 shows the Details tab of the certificate, which includes a great deal of technical information about the contents of the certificate.

Figure 1.5: The details of the certificate.

In this case, the Subject field was selected to show the details of the certificate subject. This certificate was issued to PayPal, so the company’s information is displayed at the bottom in the details window. You can also see information that is more useful to applications and computer systems, such as the RSA public key, the object identifiers (OIDs) for the basic and enhanced key usage of the certificate, and so on. Although most users (and even many experienced IT professionals) do not understand all the information in a certificate, it is always available. This availability reflects a core concept of certificates that was explored earlier—namely, that certificates do not contain any data that you do not want to provide to the public. The only data kept secret is the private key (also called the secret key) and it is not part of the certificate.

Chapter 1

12

Note If we examined the same certificate on the PayPal Web server, it would indicate that there is a stored private key associated with this certificate. Do not misinterpret that the certificate contains the private key. The certificate itself contains only the public key. The private key is stored in the computer but not in the certificate.

Summary This chapter provides a basic refresher and introduction to PKI and digital certificates. It also defines a number of terms and concepts that we’ll be exploring in more detail in later chapters. In addition, we’ve taken an in‐depth look at the contents of certificates and how trust is built from this data. Remember that trust is relative—you might trust certificate x, but your peers or family members might not. Trust is made partially of empirical data and partially of personal perception and emotion.

The next chapter will explore how trust is applied when the PKI requires multiple subjects to be trusted, and how that trust can be inefficient if set up incorrectly. We will begin to explore the topic of SAN certificates in some depth and see how they can solve a number of PKI problems with little or no additional investment.

Chapter 1

13

Glossary Most series should have a glossary—including it with Chapter 1 makes it more accessible throughout the series and defines the terms in advance.

Asymmetric Cryptography

A cryptography method where the data is encrypted and decrypted with different keys that are mathematically related; also called public key cryptography.

Certificate

A digitally signed collection of data that asserts and, in some cases, proves an identity.

Certificate Chain

A set of two or more certificates where each certificate trusts another and one certificate (the root certificate) is self‐signed.

Certificate Revocation List (CRL)

A collection of certificates that have been revoked by the issuing certification authority (CA).

Certific oint (CDP) ate Revocation List Distribution P

A location where a CRL is published.

Certification Authority (CA)

A computer that issues certificates to entities and other CAs and vouches for the authenticity of certificates that it issues.

Digital Signature

A combination of a data hash to prove data integrity and public key encryption to prove the identity of the entity vouching for the data; most certificates contain digital signatures.

Hash

A small, unique cryptographic derivative of a message that is often used to prove the authenticity of the message; common hash functions include MD5 and SHA‐1.

Issuer

The CA that digitally signs a certificate.

Chapter 1

14

Key

A number that is used in cryptographic functions to encrypt, sign, decrypt, or validate the signature of a message.

Key Usage

A portion of a certificate that specifies which tasks the certificate is authorized to enable.

Message Digest 5 (MD5)

A 128‐bit one‐way hash function.

Object Identifier (OID)

A long, unique number often used in digital certificates.

Private Key

A cryptographic key that is kept secret and not shared with other parties.

Private Key Cryptography

See symmetric cryptography.

Public Key

A cryptographic key that is not compromised from being well‐known to unauthorized parties.

Public Key Cryptography

See asymmetric cryptography.

Public Key Infrastructure (PKI)

A system of clients and certification authorities (CAs) that form a complete trust.

Requestor

The entity that presents a certificate request to an issuing certification authority (CA).

RSA (Algorithm)

A cryptographic algorithm that uses symmetric cryptography to protect and sign data.

Chapter 1

15

Root Certificate

A self‐signed certificate at the top of a chain of trust.

Secure Hash Algorithm 1 (SHA1)

A 160‐bit one‐way hash function.

Secure Sockets Layer (SSL)

A security protocol that uses asymmetric cryptography to provide authentication, confidentiality, and data integrity; SSL is often used in Web applications.

Symmetric Cryptography

A cryptography method where the data is encrypted and decrypted with the same key; also called private key cryptography.

Trust

A state where a valid certificate is accepted as adequate proof of identity.

Trusted Root

A root certificate that is accepted as trustworthy; when a certificate is presented that chains to a trusted root, that certificate is considered trustworthy.

Validity Period

The time interval during which a certificate is effective.

Chapter 2

16

Chapter 2: SAN Certificates In‐Depth

Chapter 1 reviewed the basics of certificates. We established definitions for certificates and related technologies and processes. Although this information was a review for most readers, it is important to establish that common foundation before we press on to the more technical and complex topic of Subject Alternative Name (SAN) certificates.

This chapter will delve into the details of a SAN certificate. We’ll examine the appropriate public key cryptography standards (PKCS), specifically the PKCS #10 and #7 certificate structures and meta data that apply to this technology. We’ll compare data between SAN and non‐SAN certificates. We will also compare SAN certificates to wildcard certificates to understand the distinction between two similar objects.

Note Flip back to Chapter 1—particularly the Glossary—periodically as you read through this chapter, especially if you encounter a term that you’re not familiar with (for example, CRL Distribution Point). Going back to Chapter 1 is also useful for recalling processes such as Secure Sockets Layer (SSL) cryptography.

What Is a SAN Certificate? Why write a four‐chapter guide about one very specific aspect of public key certificates? To put it in very simple terms, SAN certificates are amazingly powerful tools that you can use to solve important business problems inexpensively and efficiently. However, they must be used properly to realize the benefits and avoid potential drawbacks. We'll show you how to do both in this guide.

Overview A SAN certificate is like most other certificates. It is requested with a PKCS #10 and supplied as a PKCS #7. But it has one important attribute that sets it apart from other, standard certificates. A SAN certificate has a field that specifies other domain names that can use the certificate.

Take, for example, a company that has a Web presence at Example.com. Most Internet users will open a browser and type http://www.example.com and land on the company’s home Web page. But what happens when the company wants to switch to an SSL‐restricted Web site? The company will probably redirect all requests from http://www.example.com to https://www.example.com and obtain an SSL‐enabled certificate for that Web server. So far, so good.

Chapter 2

17

But what happens when a user types https://example.com and presses Enter? Well, to SSL, the sites www.example.com and example.com are not the same. They have separate DNS namespaces. Or consider the impact a domain name purchase of Example.net or Example.org. The company will almost certainly want to use one Web site and simply provide the same content, including secure content, through the .net and .org domains. But the same problem as encountered earlier crops up because those are separate DNS namespaces. Thus, the same SSL certificate will not work on those Web sites.

The administrator could obtain a separate SSL certificate for each domain. But SSL certificates can be expensive to purchase individually. And unless a centralized system for automated certificate management and deployment is used, they are also more difficult to manage when there are a large number of them. In some cases, a more efficient deployment includes fewer, more flexible certificates.

SAN certificates fit this situation nicely. They allow Web servers in multiple DNS namespaces to share the same certificate. Let’s take a look at how that happens.

Technical Details Most certificates are actually pretty basic. As we saw in Chapter 1, they contain the basic information that allows them to establish their identity in a secure manner and then set up secure communication.

The purpose of a SAN certificate is the same as that of any other certificate. It provides a means for the server to establish its identity and then set up secure communication. It is really only different in one way: A SAN certificate contains a Subject Alternative Name field. This field specifies the DNS namespaces that can use the certificate. In basic certificates, the Subject field is the one that contains a fully qualified domain name (FQDN) and that FQDN is the only field that establishes the namespace where the certificate is valid. You can think of the Subject Alternative Name field as extending that namespace by including one or more additional namespaces.

Examining Certificate Details To best understand the differences in these certificates, we can show actual certificates taken from live Web sites at the time of this writing. Note that by the time you read this chapter, the certificates may have changed. However, the information is still applicable.

Chapter 2

18

Viewing Certificates with GUI vs. Text You will probably notice that the certificates in this guide are displayed as screenshots from Microsoft Windows, specifically from the graphical user interface (GUI) of Windows Vista. There are important reasons to display them this way. The most important is that certificates are displayed in a very understandable and user‐friendly manner in Windows. The various fields and values are parsed and presented in a tabbed dialog box. In addition, each certificate in the chain can be viewed and validated. Other operating systems (OSs) have similar presentation methods, parsing and displaying the data nicely. If we chose to display the certificates in raw‐text form, the usability would be quite different. For example, the following content is the actual data from the first certificate that we show in its native BASE64 format (a small amount has been deleted for space considerations): ‐‐‐‐‐BEGIN CERTIFICATE‐‐‐‐‐

MIIGvDCCBaSgAwIBAgIQB/3VFUtFQg6Qmkdyo+BLfTANBgkqhkiG9w0BAQUFADBp

MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3

d3cuZGlnaWNlcnQuY29tMSgwJgYDVQQDEx9EaWdpQ2VydCBIaWdoIEFzc3VyYW5j

ZSBFViBDQS0xMB4XDTA4MDExNTAwMDAwMFoXDTEwMDMxNDIzNTk1OVowgf8xGzAZ

BgNVBA8MElYxLjAsIENsYXVzZSA1LihkKTETMBEGCysGAQQBgjc8AgEDEwJVUzEV

MBMGCysGAQQBgjc8AgECEwRVdGFoMRUwEwYDVQQFEww1Mjk5NTM3LTAxNDIxGzAZ

BgNVBAkTEjMzMyBTb3V0aCA1MjAgV2VzdDEOMAwGA1UEERMFODQwNDIxCzAJBgNV

BAYTAlVTMQ0wCwYDVQQIEwRVdGFoMQ8wDQYDVQQHEwZMaW5kb24xFTATBgNVBAoT

DERpZ2lDZXJ0IEluYzERMA8GA1UECxMIRGlnaUNlcnQxGTAXBgNVBAMTEHd3dy5k

aWdpY2VydC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALXUnCJkdTU+

wc18EI7iSOad7mkbOyg5l18a8ThUFMUsZWPces5HZPrtlSjaQ+GI2QFDT9cBjqgA

msQzmouX4UYue4a0IuPjW7LigeqD53VEfcpb/Tm4xR7StDSNT0q3zXWb9g1rAO2K

N9sjGSckYS1IpADUxbqXcpGHZHeRQL+fAgMBAAGjggNLMIIDRzAfBgNVHSMEGDAW

gBRMWMsl8EFPUvQoyIFDm6aooOaS5TAdBgNVHQ4EFgQUaq4xHFUGsTaJb7Inzqb5

QRWrgrQwKQYDVR0RBCIwIIIQd3d3LmRpZ2ljZXJ0LmNvbYIMZGlnaWNlcnQuY29t

MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNl

cnQuY29tMBEGCWCGSAGG+EIBAQQEAwIGwDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T

AQH/BAIwADCBiwYDVR0fBIGDMIGAMD6gPKA6hjhodHRwOi8vY3JsMy5kaWdpY2Vy

dC5jb20vRGlnaUNlcnRIaWdoQXNzdXJhbmNlRVZDQS0xLmNybDA+oDygOoY4aHR0

cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0SGlnaEFzc3VyYW5jZUVWQ0Et

‐‐‐‐‐END CERTIFICATE‐‐‐‐‐

Chapter 2

19

If you think that’s unusable, other formats are even worse. However, some programs, such as OpenSSL, have parsers that can read the encoded formats and present a more understandable description of a certificate. The following example is an older certificate from the University of Illinois at Urbana‐Champaign: Data:

Version: 3 (0x2)

Serial Number:

fc:e7:90:e6:be:cd:e7:8b

Signature Algorithm: sha1WithRSAEncryption

Issuer: C=US, ST=Illinois, L=Urbana, O=NCSA, OU=Security Research Division,

CN=www.ncsa.uiuc.edu/[email protected]

Validity

Not Before: Mar 1 19:30:31 2006 GMT

Not After : Mar 1 19:30:31 2007 GMT

Subject: C=US, ST=Illinois, L=Urbana, O=NCSA, OU=Security Research Division,


Subject Public Key Info:

Public Key Algorithm: rsaEncryption

RSA Public Key: (1024 bit)

Modulus (1024 bit):

00:b2:f3:ff:40:7e:29:78:0b:ec:2f:15:d9:b6:a7:

bc:3a:b1:0b:19:a2:55:c9:43:52:74:ed:50:f2:48:

2a:20:b9:70:a2:ea:c0:91:fc:0c:89:12:bf:44:ea:

33:f7:e7:41:6c:80:5a:0c:9f:87:74:aa:19:01:6f:

a2:70:73:32:6d:25:13:e9:85:92:2f:5d:38:b4:ae:

b3:b3:66:97:b4:c9:31:75:ec:d5:9c:73:95:d7:9f:

d3:3c:31:b4:76:8d:2f:7b:a6:32:76:03:27:25:bc:

e8:06:37:f9:d8:21:d1:29:05:f1:8a:27:47:0b:42:

be:74:ac:11:00:bb:e1:92:71

Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 Subject Key Identifier:

0F:54:DA:9E:36:1D:1E:B8:C4:82:B7:B8:AF:53:AA:CB:81:62:4A:2B

X509v3 Authority Key Identifier:

keyid:0F:54:DA:9E:36:1D:1E:B8:C4:82:B7:B8:AF:53:AA:CB:81:62:4A:2B

Chapter 2

20

DirName:/C=US/ST=Illinois/L=Urbana/O=NCSA/OU=Security Research Division/


serial:FC:E7:90:E6:BE:CD:E7:8B X509v3 Basic Constraints:

CA:TRUE

Signature Algorithm: sha1WithRSAEncryption

07:ea:e7:68:38:a0:c5:45:b7:3a:79:da:93:19:7a:fc:68:bf:

d1:f2:24:da:6e:58:73:8f:ef:2e:d6:1e:6b:98:ce:28:03:cb:

9b:ce:a8:98:0f:92:2d:f0:de:19:1d:a6:b2:0a:28:86:f9:ed:

43:f0:7c:46:71:ad:6e:16:c2:49:56:96:57:18:57:6f:f4:d3:

2b:59:f6:d7:f9:1a:b7:86:84:cf:80:18:a3:99:ce:ff:9f:0d:

00:6d:cc:ba:f8:4f:84:ce:8e:94:0e:1e:d7:1e:89:1d:49:78:

d3:55:1c:bf:98:e7:77:17:6c:fe:aa:2a:1d:13:62:7f:31:55:

01:f7

I recommend that you stick to GUI‐based certificate management as a rule, using text‐based command‐line tools only when necessary to closely examine or manipulate granular data.

Figure 2.1 shows a certificate with only one valid namespace, taken from a well‐known US financial site.

Figure 2.1: A commonname certificate without the Subject Alternative Name field.

Chapter 2

21

This certificate is valid and provides the required security and authentication. However, it protects only the namespace defined in the Common Name (CN) portion of the Subject field. Figure 2.2 shows a SAN certificate.

Figure 2.2: A certificate that includes a Subject Alternative Name field.

The SAN field is simply a list of extra DNS namespaces. When the client receives the certificate from the server, it checks both the Subject and SAN fields to verify that the certificate is in use on the correct server. If any matches exist—that is, if the server matches any of the DNS paths listed—the certificate is valid.

Chapter 2

22

Uses For SAN Certificates You now have a pretty good idea of what SAN certificates do and how they do it. But how is it directly applicable to your existing PKI or server infrastructure?

The most interesting uses of SAN certificates today are in the areas of email and instant messaging (IM). With the release of new software that utilizes the full potential of SAN certificates, administrators can use them much more easily and optimize the use of every certificate even further. The use of SAN certificates in SSL configurations has been only briefly covered, so we’ll discuss that more thoroughly as well.

Note This section will describe the scenarios that make good use of SAN certificates. However, we will not be listing step‐by‐step instructions about how to implement SAN certificates. Chapter 3 will provide more specific details on exactly how to operate with these certificates.

Email Using PKI certificates that chain to a trusted root is very important in any email infrastructure. To prevent attackers from spoofing a valid system, the email clients must know that the server is authentic and trustworthy before they transmit or receive sensitive data. Similarly, email servers must know that their peers (other email servers) are authentic to avoid including rogue servers in their email distribution channel. Failure of these security measures could easily allow an attacker to send false email or intercept others’ email, often without detection.

Many large organizations segment their email and authentication into manageable portions. This division is often done along geographic boundaries, but the segmentation can be along any lines that make business sense, such as departmental.

With our favorite example organization, Example.com, let’s assume that there are tens of thousands of users. Putting all users in one database could easily choke most systems, degrading performance and making administration difficult. For that reason, Example.com divides its user base into geographic groupings. A user from France, for example, will login to the France.Example.com domain and has an email address of [email protected]. A user from the US would be [email protected], and so forth. This setup makes sense from an administrative viewpoint.

From the PKI viewpoint, this division is a nightmare. Each subdomain is a different namespace. Thus, each requires a different certificate. Worse yet, depending on the certification authority (CA), different validation and application may be required for each certificate. For example, some vendors have different requirements depending on whether the certificate applies to a .com, .org, or .net domain name.

Chapter 2

23

Using a SAN certificate in this situation is perfect. A single SAN certificate can, for example, contain a field that allows servers in the following domains to provide authentication:

Example.com *.Example.com *.US.Example.com *.Japan.Example.com *.France.Example.com

Thus, all the email servers for Example.com can share one SAN certificate.

Proper Use of SAN Certificates Prior to the release of Microsoft Exchange 2007, SAN certificates were not properly processed by most email servers. Although the SAN field has been a part of the PKI standards for many years, few software vendors originally took advantage of this feature. As a result, few SAN certificates were used to their full potential. Other alternatives were used, including wildcard certificates (discussed later). Starting with Microsoft Exchange 2007 and continuing to other products, proper use of SAN certificates has begun to drive the popularity of this deployment technique. In fact, other messaging technologies have begun to take advantage of the flexibility and power of SAN certificates. Today, many software packages use it, and in fact, some (Microsoft Office Live Communications Server in particular) require this type of certificate for operation.

Instant Messaging Similar to the email paradigm explored in the previous section, IM requires certificates for server‐to‐client and server‐to‐server authentication and secure communication establishment. However, this paradigm is relatively new in corporate computing. Let’s take a bit of a closer look at it.

Industry and social trends are moving towards smaller, frequent, and more informal communications. Consider the type of text messaging that virtually all modern cell phones support. The messages are short—less than 160 characters per message with no attachments. This type of communication has branched into several technologies, one of the more popular being IM.

Because IM gained most of its exposure with informal, leisure‐oriented communication, many business decision makers (BDM) have overlooked IM as a component of business communications. But over the past several years, IM has been gaining popularity and more widespread use in business environments. As a result, business‐oriented IM solutions have begun to surface. These are led by Microsoft’s Office Communications Server 2007 (OCS) product.

Chapter 2

24

OCS offers a great deal of communications technologies including integration with email and Voice over IP (VoIP) telephony services. One of the more interesting offerings is an IM server and client. Because OCS allows an enterprise to host its own IM infrastructure, administrators can apply security and usage policies and manage the infrastructure in compliance of company policy. Users no longer have to resort to using public (and likely less secure) technologies such as Skype or Yahoo Instant Messenger to communicate.

There are often many very similar OCS servers configured in groups to handle the heavy load sometimes experienced during busy times or events. For example, Monday morning is a very busy time for any IM infrastructure. People are beginning their work week, catching up on weekend experiences, planning their week, and so on. Often, these communications are most appropriate for IM‐style communication. Communications servers can also reach peak load during important events, such as a company laying off employees or announcing a merger. As a result of this type of load, some companies can have hundreds of IM servers running OCS spread out over the infrastructure to disperse load and ensure that they are near the clients for optimal bandwidth and performance. These servers must be configured in a near‐identical faction.

As you may have surmised, OCS uses public key certificates. One important function of OCS is its use of SAN certificates to authenticate and establish secure communications channels. If each has a unique certificate, it greatly increases the workload of renewing and replacing certificates and decreases the security of the infrastructure by exposing more systems if a key is compromised. That is, if a certificate is compromised, an attacker has broken the “chain of trust” and all systems that trust that certificate are also vulnerable as they now trust a compromised certificate.

Note Whenever a private key is exposed or broken, regardless of the PKI design, the infrastructure is at risk to some degree. Different designs can help to minimize this exposure, but they may be suboptimal in other areas. This concern is one you most likely considered when deciding on your PKI design.

OCS does not support wildcard certificates for the common name in a certificate. A SAN certificate must be used for this solution.

Chapter 2

25

Secure Sockets Layer Probably the most common use of certificates in a PKI environment is for serving up SSL communications. You already know the basics of SSL from Chapter 1 and from connecting to secure Web sites. Virtually all secure Web sites (and many services) use SSL in one capacity or another.

What you might not have encountered yet is how difficult certificate management can be in an SSL environment. If each server uses a separate certificate, the user experience must be carefully tested (to ensure trust works properly), and the administration is a nightmare without an automated certificate management platform (frequently called managed PKI) in place. A wildcard certificate can be useful but has some limitations (described later), especially when you have multiple DNS namespaces. A SAN certificate can be useful in this configuration with its ability to provide SSL for multiple namespaces.

Now that we’ve established the business and technical uses for a SAN certificate and the details of what distinguishes a SAN certificate, let’s take a look at how to actually obtain one.

Requesting and Receiving a SAN Certificate The process of requesting and receiving a SAN certificate can be either very simple or very complex. It almost entirely depends on your PKI. There are a few key elements of this process that will apply regardless of your specific topology. First, you need to identify your resources to determine whether you really need a SAN certificate. Then, you’ll need to determine what DNS names need to be included in the Subject Alternative Name field and what uses your certificate will have. Once you’ve acquired that data, you can request the certificate and install it once issued. Let’s briefly look at each part of this process.

Identifying Resources and Uses We’ve seen the main purposes for SAN certificates. They’re very useful in environments that use Microsoft OCS or Exchange 2007 products where multiple DNS namespaces are part of the corporate infrastructure. They’re also useful in some SSL‐enabled environments with multiple DNS namespaces.

If you have this software in your environment, you most likely need a SAN certificate (or a large number of standard certificates, which is both expensive and inefficient). Although having a Subject Alternative Name field in a certificate that is not used for one of these purposes does not hurt anything, it may not be the best security practice. Most security practitioners tend to minimize and simplify configurations, keeping to the “less is more” axiom. Because the SAN field in the certificate may be extraneous data, you should weigh whether that field would impact your security posture.

You must identify the specific applications and servers that will use the new certificate. This identification is absolutely critical to ensuring that you obtain the appropriate certificate. If you’re using an outsourced PKI that charges per certificate, you already know that requesting an improper certificate is a costly mistake. It can be even more costly if the mistake is discovered after the certificate is deployed.

Chapter 2

26

Consider gathering the following information:

• Applications that will use the SAN certificate, especially OCS and Exchange—The list of applications will ensure that you specify both the proper domain names and the proper Key Usage and Extended Key Usage fields in the certificate.

• Servers that will run the software that uses the SAN certificate, and their DNS names—This information is critical to ensuring that your Subject Alternative Name field is complete and correct.

• Other PKI‐enabled servers that may benefit from using this certificate, and their DNS names—You may find that you want to use a single SAN‐enabled certificate more broadly than first thought as you continue to gather information. Note You might already have this information. Most well‐run networks already have a complete network map and inventory of systems and their functions. If you have that data, congratulations! This task will be quick and easy. However, if you don’t have this data, you should consider gathering it and keeping it up‐to‐date for a variety of reasons, not the least of which is for PKI planning. There are dozens of software tools and process guidance packages that will help you accomplish this task, ranging from enterprise‐class fully automated software to simple, free utilities that can gather the information for you in a matter of moments.

Once you have this data, you should have enough information to obtain a SAN certificate. Of course, the certificate request will differ depending on whether you manage your own PKI or use a managed or external system. So let’s take a look at these in more detail.

Obtaining the Certificate How do you obtain a SAN certificate? The simple answer is: the same way you obtain any other certificate. You already have some PKI integration with your network. Obtaining a SAN certificate is done the same way as acquiring a Web Server or Recovery Agent certificate.

In very general terms, there are two approaches to PKI. Each has its own approach to requesting and retrieving a certificate. You either manage your own PKI or you use an outsourced commercial PKI. The two are very different and require individual explanation.

Outsourced PKI Not very long ago, there were only a small handful of PKI vendors that offered truly useful certificates (certificates that chained to an already trusted public root CA) at a reasonable price. But times have changed. There are hundreds of PKI vendors in the world today. Many of them offer amazing products and very reasonable prices. Virtually all of them chain to a trusted root. And most of them offer a variety of levels of assurance, such as Extended Validation (see Chapter 1) and chaining to different root certificates depending on the level of trust required.

Chapter 2

27

One important selling point for PKI vendors has been the ease of use of their products. Because, let’s face it, PKI deployment and operation is difficult. Having a commercial offering that is just as difficult as an internal deployment makes no sense. Thus, PKI vendors have gone to great lengths to make their products simple to use. Many have simplified the certificate request process to a basic Web‐based form or a browser plug‐in, reducing the entire process to less than a minute’s work. Often a Web‐based certificate enrollment process is accompanied by a phone call to Customer Service or interactive online assistance. Honestly, they couldn’t make it much easier to get a certificate.

The key element in successfully obtaining a SAN certificate from an outsourced PKI vendor is communicating the information that you gathered in the previous step. The vendor cannot read your mind and determine that you need a SAN certificate with x domains or y key usage fields. Consider creating a complete document of the information that you gathered and providing it to the vendor along with the certificate request to avoid any confusion. Although it might seem like overkill, it is certainly better to err on the side of completeness and redundancy than risk a useless $5000 certificate (as an example—not all certificates cost $5000).

The certificate is normally issued through a safe means. Some vendors send a CD or USB drive to the address provided during enrollment as an additional security verification. Others use an SSL Web site or even secure email to provide the certificate. Regardless of the method of issuance, you should immediately examine the certificate to verify that the required data, especially the Subject Alternative Name field, is correct.

Internally Managed PKI Managing your own PKI used to be a daunting task. You needed to hire or become a PKI guru. You needed to read at least one book on the topic. You had to become an expert on the OS that supported the PKI and the client systems and applications that used certificates. All that before you even decided on whether to use an internal or external PKI solution and have deployed the PKI!

Times have changed. PKI is much more approachable and easy to deploy and operate. Some OSs, such as Windows Server 2003 and Windows Server 2008, have a CA software package built right in. With a basic knowledge of PKI and the client requirements, you can have a self‐signed PKI up and running in less than an hour, and a CA that chains to an external trusted root in only a little more time than that. And most of these software packages make certificate requests extremely simple.

For example, let’s take a look at Windows Server 2008. Assuming you’ve got a CA installed and configured (a wizard‐driven task that takes just a few moments), how do you request a SAN certificate? By default, Windows Server 2008 installs its own Web‐based certificate management Web site on the CA at http://servername/certsrv. The default Web page isn’t glamorous or colorful, but it is both highly functional and customizable (see Figure 2.3).

Chapter 2

28

Figure 2.3: The default Windows Server 2008 CA home page.

You can see in Figure 2.3 that the key elements of certificate enrollment are available: request a certificate and view the status of a certificate (or retrieve an issued certificate). Clicking Request a certificate results in a fairly complete form that you can use to either fill out and specify the request or submit a binary‐encoded request that comes from your software package (Figure 2.4).

Chapter 2

29

Figure 2.4: The Certificate request page. Not shown at the bottom (for space

concerns) is a text field where you can simply paste in a binaryencoded certificate request from your favorite application.

For most certificate requests, you will create a CMC or PKCS #10 request with your favorite application and then paste it in to this form. Doing so ensures that the desired fields, especially the Subject Alternative Name field, are complete and correct. In Windows Server 2008, the command‐line tools Certreq.exe and Certutil.exe can be used to create the request and submit it directly to the CA.

Chapter 2

30

More Information For complete documentation of the PKCS #10 format, see http://www.rsa.com/rsalabs/node.asp?id=2132 and http://www.ietf.org/rfc/rfc2986.txt. For a very readable example, see http://msdn.microsoft.com/en‐us/library/aa379078(VS.85).aspx. For a lengthy article on using Certreq.exe and Certutil.exe to create and submit a SAN certificate request, see http://support.microsoft.com/kb/931351.

Wildcard Certificates By now, you’ve seen the strengths and weaknesses of SAN certificates. You might already be familiar with another certificate type that fills a similar role—wildcard certificates are simply certificates that allow you to secure multiple first‐level child domains based on one root domain. For example, if you have a *.Example.com wildcard certificate, you can secure mail.Example.com and www.Example.com with that same wildcard certificate.

However, you cannot secure second‐level child domains or disjointed domains (for example, Example.com and Example.org) with wildcard certificates. That is where the flexibility of SAN certificates comes in. Although wildcard certificates have uses, they are not as flexible and powerful as SAN certificates. In addition, many small browsers (such as those found on phones or ultraportable devices) and other portable applications do not understand how to process wildcard certificates properly. These same applications often work well with SAN certificates. If you intend to support portable clients on your network, determine whether wildcard certificates work and ensure that your PKI supports whatever certificates are required. However, you should note that wildcard certificates can be considered somewhat of a security risk due to their unrestricted nature. Even if they will meet the technical needs of your deployment, they may present more security exposure than acceptable.

Summary This chapter provides a deeper look into SAN certificates. We examined exactly what distinguishes this type of certificate—the Subject Alternative Name field. We also saw what that field looks like in real certificates.

This chapter also showed the Windows Server 2008 CA in more depth, including how to obtain a SAN certificate. Although you might not be using Windows Server 2008 in your PKI, the information in this chapter applies to most PKI software. If you’re using an outsourced PKI, the tasks are almost always easier because of the customization and extensive customer service that they provide.

http://www.rsa.com/rsalabs/node.asp?id=2132

http://www.ietf.org/rfc/rfc2986.txt

http://msdn.microsoft.com/en-us/library/aa379078(VS.85).aspx

http://support.microsoft.com/kb/931351

Chapter 2

31

Throughout the chapter, we also looked at wildcard certificates. You shouldn’t come away from this chapter believing that SAN certificates are superior to wildcard certificates. Each has their own role in an organization. You may, depending on your network and PKI architecture, decide to use one or the other, or both. The only “wrong” way to use these certificates is if the way they’re being used prevents applications from working correctly.

We focused on the technical side of certification in this chapter. In the next chapter, we will explore the business side of SAN certificates. We’ll examine how they make sense, where they make sense, and what business functions they support. Because all certificates have a real cost to an organization, we’ll look at the return on investment side of things to help you ake the most cost‐effective choices possible. m

Chapter 3

32

Chapter 3: The Business Value of SAN Certificates

Chapter 1 reviewed the basics of certificates. We established definitions for certificates and related technologies and processes. Although this chapter might have been a review for most readers, it is important to set up a common foundation before pressing on to the more technical and complex subject of SAN certificates, as we did in Chapter 2.

Chapter 2 explored the details of a SAN certificate. This exploration included examining the appropriate public key cryptography standards (PKCS) and comparing data between SAN and non‐SAN certificates. We wrapped up by comparing SAN certificates to wildcard certificates to show the distinction between two somewhat similar objects.

Chapter 3 offers a look at a different aspect of certification—the business aspect.

Cross Reference You should feel comfortable flipping back to Chapter 1 periodically as you read through this chapter, especially the glossary. Nobody memorizes every PKI‐related definition, and you’re certainly not expected to. But if you see a term that you’re not very familiar with (for example, CRL Distribution Point), the glossary is there for you. Flipping back to Chapter 1 is also useful for recalling processes such as secure sockets layer (SSL) cryptography.

The Business Value This chapter focuses almost exclusively on non‐technical concerns. The business value of PKI is fairly well understood. However, the options that SAN certificates offer to the PKI business proposition are not always clear. They are extremely powerful options that can make a significant difference in this infrastructure investment.

One of the most important business values that SAN certificates offer is in the area of certificate reuse. Simply put, you can use a single SAN certificate in a number of systems for several different tasks. Although that certificate might require a bit more of an initial investment, in the long run, the SAN certificate can usually save time and money by simplifying your IT investments and getting more mileage out of that single certificate.

Chapter 3

33

Using Existing Resources One of the best ways to examine the business resources expended on PKI certificates is to examine the various phases of certification. There are a number of ways to describe these phases. We’ll use one that works from both a business and technical perspective, based on the cer e phases we’ll examine are: tificate life cycle. Th

• Certificate request

• Certificate issuance

• Certificate deployment

• Certificate maintenance For each of these phases, we’ll first look at the common tasks normally completed in the phase using common, non‐SAN certificates. Once we list the tasks, we’ll begin to assign detailed statistics around how much of an investment the phase might be in terms of both money and time. Finally, for each phase, we’ll compare using a SAN certificate and what difference the certificate would make in terms of time and cost.

The Difference Between Public and Private Certification Authorities The one enormous differentiator in this process is whether your organization uses a public or private certification authority (CA) for certificates. This makes a difference in virtually every task and, therefore, in virtually every component of the cost and the business decisions. In today’s IT landscape, many organizations use a combination of both public and private CAs to cover their security needs. Often, private authorities are used for lower‐value transactions and authentication, while public‐facing services and higher‐value or higher‐risk data will require a public CA’s validation. For this section, we will assume that you’re using a public CA; in cases where there is a significant difference that might impact a business decision, we’ll compare both.

Certificate Request Certificate request seems to many people like the easiest part of certification. You simply login to a secure Web site, provide a credit card or other payment option, and you get a certificate. Right?

Well, it’s not quite that simple.

A certificate request is, technically, a set of data that is presented to a CA. The data—including a public portion of a public‐private key pair, a list of object identifiers specifying key use, and other cryptographic details—is not very important for this section. What is important, however, is how those details are created. They are created by an administrator. Often the technical details are created individually without an automated or documented process. This requires a significant amount of work to do correctly.

Chapter 3

34

Common Tasks The first part of the certificate request process is very important in business value: justifying the need for a certificate. Each certificate has a significant value associated with it. Thus, before any certificate request process is begun, care must be taken to analyze whether the certificate is even required. The common terminology for this process and decision is return on investment (ROI).

When determining the ROI, the entire certificate life cycle is examined. A certificate is valid for months or years, and there is a certain amount of expenditure required to keep the certificate both valid and secure. For example, let’s assume that you request a Web server end‐entity certificate that contains pointers to two certificate revocation lists (CRLs) and chains to a trusted root. For the certificate to remain valid, at least two servers must always be available: one of the two CRL servers (preferably both) and the root CA. As we know, keeping a server up and functioning is a significant cost, and this setup requires the maintenance of two servers in addition to the end‐entity server.

Some questions you should ask when making an ROI decision around certificate requests include:

• Is there already a certificate that you can use for this task? If so, use it! Get more bang for your PKI buck by reusing certificates where it makes sense and is within your established security policy.

• Can you obtain a multiuse certificate? If you need a new certificate, it may be cost‐effective to purchase a more expensive one that can be used for many purposes in addition to the immediate one. There really are such things as Swiss Army certificates, and though they may cost a bit more, they are sometimes worth it. Just make sure that this is, again, within your established security policy.

• What level of trust will this certificate provide? You might need an ultra‐trustworthy certificate, for example, if you’re handing high‐value financial transactions over the Internet. In contrast, a self‐signed certificate might very well suffice for internal‐only, low‐impact trust situations. In general, the more trustworthy the certificate, the more it costs both initially and over time. So you should avoid using the same level of trust for all certificates unless that’s a documented requirement.

• How difficult will the issuance process be? If you are requesting a highly trusted certificate, you might be required to provide a great deal of information during the issuance process to validate your identity. This can be a resource drain, especially in a smaller IT department where the issuance process can consume days or weeks of time and require cooperation with other departments. Carefully examine the issuance requirements for your CA and determine how much effort the process will take before you make a decision. This will also help you properly prepare for the application and issuance, which may significantly streamline the process.

Chapter 3

35

Once the decision is made to obtain the certificate, the details of the certificate must be determined. That’s because PKI certificates are issued when the CA digitally signs the request presented by the end‐entity. Most of the information in the certificate request cannot be changed by the issuer. Thus, if it isn’t correct or complete, the request must be denied so that the requestor can correct the issue and re‐request the certificate.

The actual gathering of details isn’t difficult. It mostly requires planning. But the planning is critical. If an inappropriate or unusable certificate is issued, you might wind up paying for it anyway.

The result of all this decision making and information gathering is a certificate request. During the creation of a certificate request, the technologists perform detailed tasks such as generate public/private key pairs, define required Key Usage parameters as numerical representations, verify connection to the CRL distribution point (CDP), and so on.

Figure 3.1 shows an example certificate request process grouped into a basic workflow.

Figure 3.1: The process to obtain and deploy a new certificate.

Chapter 3

36

As you can see from this workflow, the process is fairly linear. One task completes and the next begins. Very little work can be done in parallel.

The tasks that must be completed are a direct result of the business decisions made earlier. Thus, once the decision is made to create the request, there should no longer be any decisions being made.

Cost of Tasks The cost of the certificate request process really breaks down into two main parts: making decisions and gathering information. Both of these functions can be very manpower‐intensi a number of tasks including: ve. The costs will come in the form of

• Meetings with internal stakeholders

• Documentation creation and review

• l vendors and consultants Discussions with externa

• ignoffs Decision maker s

• Budget planning

• Data gathering and verification

• Preparing the data for presentation to the CA There is not much in the way of money movement at this stage. The real cost is the time of your employees to get the request correct.

Analysis Paralysis There is the notion in the business world of completely overanalyzing something to the point that no work gets done. This is often referred to as analysis paralysis— s conducting so much analysis that the process becomeparalyzed. During the certificate request phase, you might think that the process is encountering analysis paralysis. Do not fear. The first time this task is done properly, there is a necessary but significant time and energy investment. For example, educating decision makers on the value of PKI or examining your existing infrastructure to ensure compatibility with the certificate may require a great deal of time. However, you will see the phase become shorter and more efficient as it is used more often. Many organizations find that by the third or fourth time through this process, it is short and effective. That’s because many of these tasks need to occur only once. The best advice is to expect the first run through this process to be a bit sluggish. But you’ll see a tremendous difference in even the second run.

Chapter 3

37

SAN Certificate vs. Standard Certificate In this phase of the certificate process, there’s one big difference between a SAN certificate and standard certificate: cost. The cost of a SAN certificate from an external vendor is, in today’s market, significantly higher than the cost of a standard single‐namespace certificate. The reason is pretty apparent: you will need fewer SAN certificates because you can use them in a variety of ways compared with the traditional certificate. But it may well be worth the investment. That’s why we emphasize the ROI process so strongly here.

The cost and number of additional namespaces per certificate do vary widely between vendors and over time. So part of this initial phase is to look at the cost difference between a SAN and non‐SAN certificate. For example, at the time of this writing, one large PKI vendor charges an extra $500USD for a SAN certificate that supports up to 20 additional namespaces. If you used that certificate in just one additional application, you might recoup the $500 right there. And then you’re free to reuse it over and over, each use driving up the return on your investment. Of course, if you have your own internally‐managed PKI, there may be no cost at all to that extra SAN field.

Certificate Issuance Once all the details of the certificate request are nailed down, it’s time to get that certificate issued. This phase has less to do with technology and more to do with trust.

Common Tasks The most obvious tasks during the certificate issuance phase are presenting the certificate request to the issuing CA and retrieving the issued certificate. Let’s take a closer look at both of them, and the important piece that comes between them.

The data created in the request phase must be delivered via some secure method to the issuing CA. There are numerous methods. Secure online enrollment is the most common method today, with more rigid security methods such as overnight couriers, trusted Web sites, and physical travel being reserved for only the most critical enrollment requests. As the level of trust for the certificate request goes up, usually the method of delivering the request also becomes more secure. The reason for all this security is that if the request is intercepted between creation and presentation, it can potentially be modified to enable security compromise.

At the end of this phase, the issuing CA delivers a signed certificate to the requestor. The method for that delivery is almost always identical to the delivery method of the request itself, but because the certificate is now public, it could be delivered in a variety of ways.

Between the presentation of the request and the delivery of the response is where a great deal of process takes place. Because the issuing CA is responsible for the level of trust of every certificate it issues, it must take steps to ensure the validity of the request. That means that virtually any well‐trusted CA will thoroughly analyze all certificate requests and require proof of authenticity before the certificate is issued.

Chapter 3

38

Improperly Issued Certificates Can Be a Nightmare The scrutiny that a well‐trusted CA applies to certificate requests is often misunderstood by both IT professionals and business decision makers. It is seen as an unnecessary hindrance or delaying tactic. Because many businesses need immediate results from vendors, having to wait days or weeks for a certificate seems unacceptable. But this caution before issuance is very justified. Not long ago, a large and well‐trusted CA issued a new software‐signing certificate to a large software publisher. The certificate was trusted by the most trustworthy certificate available. However, a few days later, the issuer noticed a discrepancy in the process. It turned out that the certificate request was bogus. It was made by someone who had no legitimate connection to the software publisher. Even worse was that this particular certificate chain did not specify a CDP, making certificate revocation exceedingly difficult and expensive. The names have been omitted from this story, but the details are accurate. So when a well‐known CA requests details about your organization or asks you to wait while they perform research prior to issuance, there is a reason they’re taking so long.

One of the biggest mistakes is not building enough time into a project plan for this phase. Some issuers can take days or weeks to validate identity before the request meets the necessary requirements for issuance. There is also some cost associated with this set of events, which we’ll cover in the next session.

Cost of Tasks Writing a check or sending credit card payment to the CA is usually done at the beginning of this phase or the end of the previous one. That is a fixed and well‐defined cost. Almost any PKI vendor will have the cost prominently displayed on its Web site. Their sales staff will also be happy to discuss various ways to save money, so you may wind up buying a block of certificates, some other services, etc. Because this is such a well‐defined cost and it is so easy to comparison shop between vendors, we won’t spend a lot of time discussing it. It would be best to spend time discussing the less obvious costs.

One cost that you will not hear about often is the cost of supporting the issuance process. As you learned in the previous section, the vendor will conform to whatever validation process they’ve established for the type of certificate you request. As we also discussed, the more trustworthy certificates require more thorough and exhaustive validation processes.

Chapter 3

39

This is very similar to when you prove your personal identity. For example, when you go to the store to buy a bottle of wine, you’re probably asked for some basic identification to ensure that you are old enough to make the purchase. The clerk just wants to see a piece of relatively trustworthy identification that shows your birth date. That’s pretty much it. Compare that to when you want to obtain a passport. A passport is considered a very reliable piece of identification. As a result, the validation process is much more stringent. You might be required to provide multiple forms of trustworthy identification. The passport authority may take several days to validate the identification and might even ask you to provide further proof before the request meets their issuance requirements. Both the wine and passport requests require identification, but they have very different levels of trust associated with them.

During the validation process, a vendor may ask for a number of things that help ensure the authen stworthiness of the request. They might include: ticity and tru

• Tax records

• s Bank account record

• Real estate records

• Lists of executive employees

• sually IT personnel and executives) Interviews with personnel (u

• Inspection of the IT facilities While responding to these requests might be a time and money investment, you should consider that they conform to the process that you agreed to during the first phase of the certification process.

Chapter 3

40

OnSite Inspections If you’re using a well‐known and trustworthy PKI vendor and requesting a highly‐valued certificate, you may expect an on‐site visit from one of their representatives at some point during the issuance phase. This isn’t because they don’t like you. They simply need proof of everything you’ve stated before they trust you with one of their certificates. The on‐site visit can be daunting for some IT personnel. They’re not used to being questioned. They might see the process as harassment or a thinly‐veiled insult. For example, if your operations staff shows the inspector your Web server and the inspector remarks that it is not in a secure configuration, the operations staff will likely be unhappy. You should consider the on‐site inspection as a form of audit. The inspector will almost always provide their criteria well in advance of the inspection so that your staff can prepare for the inspector and ensure a smooth visit. If there are any criteria that are not clear or unacceptable, work it out before the inspector shows up. That will help keep morale up and streamline the issuance process as well as prevent the cost of re‐inspection and reconfiguration.

Another cost consideration for certificate issuance is in the actual receipt of the certificate. If your certificate vendor requires in‐person delivery of an issued certificate to protect the trustworthiness of that certificate, the cost can be considerable.

You might notice a common theme throughout the details for this process: trust. Each step along this process is there to help ensure the trustworthiness of the process and the resulting certificate. Thus, while the process might seem a bit cumbersome and lengthy, when seen within the context of trust, the steps are both useful and necessary.

At the end of the certification issuance phase, you receive a signed and valid certificate. You already have the private key from the request, so the next step will be to deploy it and get it into use.

Chapter 3

41

SAN Certificate vs. Standard Certificate If you’ve requested a SAN certificate, the validation process might be a bit more complex. This entirely depends on the issuer and their validation requirements. For higher‐value certificates, the certificate is almost always kept in a hardware security module (HSM) to provide the best level of protection and reliability. Because an HSM is a complex and highly‐secure piece of technology, configuration and certificate implementation can take a significant amount of time.

When you request a SAN certificate, you probably want to store that certificate on more than one HSM to provide functionality to more than one system. Thus, you must configure each HSM individually. So, for example, if you’ve requested a SAN certificate with an extra four namespaces, you will probably spend time on all five of the HSMs (the one primary system and the four extra).

The math is very easy for this situation: multiply the amount of system configuration and deployment time by the number of SAN fields you’ve requested. The time should be a bit less as you or your staff repeat the process, but you should err on the high side.

Private Key Compromise Whether you use SAN or standard certificates, when an attacker compromises the private key associated with a certificate, that certificate must be replaced. This means repeating the request, issuance, and deployment all over again. If you’re using SAN certificates, you’re probably using a single certificate in several places, so a single key compromise could be quite a bit of work to replace. Thus, when using SAN certificates, consider using HSMs to help protect the private key or a PKI management platform to expedite your recovery from key compromise. Also consider using multiple standard certificates to help minimize the impact of a single key breach.

Certificate Deployment So far you’ve selected a CA and certificate usage, created and submitted a formal certificate request, paid some money, successfully endured a validation process, and received a signed certificate in return. Now you get to put the certificate into production!

Interestingly, deploying the certificate is one of the easiest parts of this process and, therefore, one of the least expensive. It requires relatively little investment from the business management viewpoint. There are a number of highly technical tasks to certificate deployment, but that will be covered in the next chapter.

Chapter 3

42

Common Tasks The certificate and its associated private key must be made accessible to each computer or server that will use it. In PKI‐based server scenarios (for example, Web server, messaging server) that means the data must be copied to the server or installed on that server’s HSM. This is usually a simple task that most IT staff is familiar with and is well documented.

The system must then be configured to use the certificate. Again, this is a relatively low‐cost work item due to its simplicity and well‐documented nature.

Finally, the system must be tested before it is put into production. Note that testing the proper functioning of the certificate itself is not the same as testing the entire system. The software and devices that are part of the system should be tested before the high‐value certificate is loaded and used. That means that the system should be ready for the certificate to be installed so that basic tests to ensure that the new certificate works properly with the system can then be conducted. Because the system has already been tested, this phase is usually quick and easy.

Cost of Tasks The cost of certificate deployment is very small compared with the previous two phases. Most of the investment in this phase is the time of your IT group to follow the proper (and hopefully well‐documented) procedures for certificate handling. You might want to engage an outside company to test the proper operation of your systems with the new certificate or audit the proper configuration of your systems. Even this cost is relatively low, because at the time of this writing, the test and auditing functions are relatively inexpensive.

SAN Certificate vs. Standard Certificate By definition, a SAN certificate is capable of being used on multiple domains. Thus, the cost of deploying a SAN certificate will depend on the number of systems that use the certificate. However, this should not be a significant concern because of the inexpensive nature of these tasks.

Certificate Maintenance Once a certificate is requested, issued, and deployed, it must be maintained. This sustained‐operations phase is overlooked by many IT departments. So you should understand what this phase entails and how much it costs. Although the cost may not have a huge impact on your plans, it is important nonetheless.

Common Tasks The most important task in this phase is, ironically, the one that happens the least. Someone, or something, must keep an eye on the certificate expiration date. As you’ve learned in previous chapters and in other PKI‐related materials, every certificate has a valid lifetime—both a beginning and ending date and time where the certificate can be trusted. The certificate lifetime is specified in the certificate request and is signed by the CA, so this window is well known to both parties. If you’re using a well‐trusted public CA, you will likely pay more for a certificate with a longer lifetime. But the benefit to the longer lifetime is that you can use the existing certificate for longer before it must be renewed or replaced.

Chapter 3

43

If you’ve ever visited a Web site and gotten the following security error, you’ve seen an expired certificate in action:

The security certificate has expired or is not yet valid.

Figure 3.2 shows what a user might see if they’re using Microsoft Internet Explorer as their browser.

Figure 3.2: An expired but otherwise valid certificate.

This is a horrible user experience and often causes users to leave a site or close down an application in fear of violating security. Even worse is that most applications do not handle invalid certificates as gracefully as Web browsers. Many simply display a generic error message or, worse, do not check the validity period at all and continue to use an invalid certificate.

Certificate renewal is very simply the CA issuing a replacement certificate with a new lifetime. This is usually done with the same key pair and often uses the existing customer verification information, making it a fast process. The process is relatively simple as it is nearly the same as the deployment process.

The oth d include: er operational tasks that must be conducted after a certificate is deploye

• perly Periodic verification that the system is still using the certificate pro

• nt computers Regular verification that the CDP is accessible by clie

• Maintenance of the key storage device (HSM), if any

• Maintenance of the security mechanisms protecting the private key Each of these is relatively simple and low‐cost but necessary to ensure proper ongoing use of the certificate.

Chapter 3

44

Cost of Tasks The cost of certificate maintenance is, as described in the previous section, relatively low. The biggest cost is when a certificate expires and needs to be replaced. This is usually a far lower cost than requesting a new certificate, and in fact, the renewal price should be specified when the original certificate price is determined.

SAN Certificate vs. Standard Certificate There is a tremendous benefit realized in the maintenance phase when an organization is using SAN certificates. This is best illustrated in the following example.

Too Many Certificates on the Systems A company I recently worked with was concerned about their PKI deployment. Because they did not have an accurate network or systems diagram, I created one. I was alarmed when I got to the point of documenting which PKI certificates were loaded in which systems. Apparently for redundancy, the IT staff had loaded every certificate, with its associated private key, in every system at the datacenter, regardless of whether the system even had the capacity to use the certificate (for example, Web server certificates loaded onto secure messaging servers and vice versa). Each system had 23 certificates. On the surface, there may not appear to be much wrong with this situation. The data is less than 10Kb per certificate and private key, so there is no storage issue. And all the systems were well‐patched and kept in a very secure data center, so there was little concern for security compromise. But what happened when a certificate expired? Every system in the data center needed to have the expired certificate removed or replaced. That required a substantial investment for virtually no return. Because the certificates were issued at different times, and with different levels of trust, each renewal required individual planning and execution. Although there was an appearance of effectiveness for this configuration, there was no practical need for this redundancy. Of course, the flip side of this point is that using a single certificate can present a single point of failure. For example, when the certificate expires, it expires on all computers simultaneously. Therefore, more care must be given to properly maintain the certificate’s life cycle and security, or an automated PKI management platform must be implemented. An improperly managed SAN certificate deployment could be expensive and difficult to repair if it is allowed to fail.

If this company had used a single SAN certificate with the appropriate key usages specified in the request (via proper planning), there would not be an issue at all. That type of configuration would be far more efficient and just as, if not more, secure as a result of reduced complexity and improved efficiency. The redundancy aspect can easily be addressed with consistent, verified backups or the use of a managed HSM to ensure data protection.

Chapter 3

45

Certification as a Business Driver Why is all this work necessary? What is the value of the process and of certification in general? In a word, it’s all about trust. Let’s look at a brief example of how trust has changed over the years.

A hundred years ago, trust was very different. A person asserted their identity almost completely by a statement of “My name is Mike Danseglio.” The process for validating that identity was simply asking neighbors and friends, “Is that person’s name Mike Danseglio?” A great deal of trust came from appearance as well—if Mike asserted that he was a wealthy businessman, you might look at his clothes, his manner of speech, and his cleanliness to determine whether you trusted his assertion. In some cases, you might write a letter to a trusted authority in businessmen, but the response might comes months or years later and be as simple as “Yes, I know Mike. He’s a great guy.” This is certainly a great endorsement of Mike’s reputation and honor, but it doesn’t answer key questions that are part of any business decision.

There are many flaws to the historical trust process: Is this person really Mike Danseglio? Is the letter genuine? Does he have a good reputation with all business associates or just this one? Does his reputation mean he’s a reliable partner? And again, because this is probably the most important question: Is this person really Mike Danseglio?

The most common way to solve these problems was for Mike to carry some form of proof of both his identity and his business reputation. For example, he might carry letters of credit from banks and wax‐sealed envelopes from government officials proclaiming his identity. But because of the delayed communication of the time, verification of the data could take a very long time and the delay could often jeopardize or invalidate the business deal entirely. But this level of uncertainty was part of all business transactions. In short, trust was hard to come by and little or no trust was considered an acceptable risk in some cases.

The business world today is very different. You may have business relationships with people all over the world, many of which you never meet. Contracts and transactions execute in minutes compared with the years they took in the past. Any effective business decision maker recognizes this difference between historical trust and modern trust. It is this modern trust that we support with certification.

In today’s world, trust is an essential component of all business transactions. Consider what your CEO would say if you suggested dealing with a previously unfamiliar partner based entirely on the unverifiable assertions of a single person. You’d be out of a job! Verified reputations, financial statements, and personal and company histories are all standard elements that go into modern trust. All of these elements are increasingly represented by digital data. But this data is still susceptible to modification or forgery unless some protection is provided. That’s where the concept of certification comes in.

Chapter 3

46

Certification provides the technology and infrastructure necessary to provide reliable proof of information. It allows us to securely communicate, providing authenticity, data integrity, and data non‐repudiation in addition to the better‐known data security benefit. These four elements are often defined in the context of certification, but the business value is not often described. In short, the values map as:

• Authenticity—The value of knowing that the person or company you’re communicating with is the person or company that you believe them to be. They have proved their identity to a trusted third party, and because you trust the third party, you trust the person or company to be authentic.

• Data integrity—You can trust that when the person or company (entity) sends you data, it has not been modified or replaced en route. The data they send is the same as the data you receive.

• Data non‐repudiation—There is tremendous value in proving that an entity made a specific statement or sent certain data. Non‐repudiation ensures that the recipient of data can prove that the sender sent the data, usually at a specific time, to provide accountability in case the sender later claims ignorance or inaccuracy.

• Data security—The information that you exchange with the entity is secure from eavesdropping by third parties. All data between you is kept secret.

As you can see, certification is a very important element of today’s business landscape. The services it provides are not optional—they are critical elements of nearly every business transaction.

Summary The previous two chapters covered PKI and certificates in some technical detail. This chapter departed from that type of content by focusing on the business aspects of certificates, and SAN certificates in particular.

The SAN certificate can be a powerful business tool. It can save a great deal of money during the request and issuance phases, which is where the initial PKI investment is most closely scrutinized. We looked at the ROI and showed how SAN certificates have a tremendous value, especially where required for specific applications or scenarios. We also saw that the use of a SAN certificate can be efficient over time, as it is relatively easy to maintain.

In the next chapter, we will get back to the technical details by going through some typical SAN‐specific PKI scenarios. Many of the sections explored in this chapter, especially planning, will be expanded upon in the next chapter so that you can take direct action to start using SAN certificates.

Chapter 3

47

Chapter 4: Planning and Implementing a SAN‐Enabled Certificate Strategy

Chapter 1 reviewed the basics of certificates, establishing definitions for certificates and related technologies and processes. With this foundation, we explored the more technical and complex topic of subject alternative name (SAN) certificates. Chapter 2 pressed on to discuss the details of a SAN certificate. This discussion included examining the appropriate public key cryptography standards (PKCS) and comparing data between SAN and non‐SAN certificates. That chapter wrapped up by comparing SAN certificates to wildcard certificates to show the distinction between two somewhat similar objects.

Chapter 3 focused on the business aspects of certificates, and SAN certificates in particular. We saw how the proper use of a SAN certificate can be a powerful business tool. It can save a great deal of money during the request and issuance phases, which is where the initial PKI investment is most closely scrutinized. We looked at the ROI and showed how SAN certificates are clearly advantageous to single‐purpose certificates in many organizations. We also saw that the use of a SAN certificate is highly efficient over time, as it is easier to maintain than a large number of specialized certificates.

In this final chapter, we will get back to the technical details by going through typical SAN‐specific public key infrastructure (PKI) scenarios in detail. Many of the sections in this chapter will enable you to take direct action to start using SAN certificates.

Chapter 3

48

Quick Reminder About SAN Certificate Use We’ve thoroughly examined the flexibility of the SAN certificate in previous chapters. As a quick reminder, a SAN certificate is a single PKI certificate that allows multiple DNS namespaces to use it for authentication and secure communications. It does so by listing the DNS namespaces in the subject alternative name field. For example, a company might own the following namespaces: www.example.com www.example.net .com www.new‐example www.example.org www.newyork.example.org Normally, a PKI certificate specifies a single namespace where it is valid. By using the subject alternative name field, a SAN certificate can be valid for all of the listed namespaces. Aside from the subject alternative name field, a SAN certificate is identical to any other PKI certificate. It still contains the same information all other certificates contain, including public key, root certification authority (CA), key usage, and so on. Many applications that properly use PKI certificates can use a SAN certificate without any problem. However, as we’ll see, an application that is specifically designed to exploit the power of SAN certificates can be very effective and efficient.

Planning for SAN Certificates Planning a certificate strategy using SAN certificates differs significantly from a single‐use certificate strategy. Before we begin to look at implementation details, we should take a brief look at how the certificate planning differs. As you’ll see, the result is that plans can be greatly simplified. Because SAN certificates are more flexible than single‐instance certificates, in general, we can plan to obtain fewer certificates and use those certificates in multiple locations. For example, we can show how a company might secure its Internet‐facing servers with a series of certificates in a typical PKI deployment (see Figure 4.1).

Chapter 3

49

Email server

E-commerce server

Web server

Real-time Communications

server

InternetFirewall

Certificate #1

Certificate #2

Certificate #3

Certificate #4

Figure 4.1: A typical Internetfacing PKI deployment.

As we can see, this deployment has four servers, one of each, that will serve as our server archetypes:

• Email server

• server E‐commerce

• Web server

• Real‐time Communications (RTC) server

Chapter 3

50

You can see from the certificates that there are four specific certificates deployed. There is a different certificate on each system, and that certificate is unique to that server’s identity and key usage. Note that for space and clarity, I have not listed each system’s DNS name in the diagram; as an example, the names might conform to Table 4.1.

Server Role Server DNS Names

Email server Example.com Autodiscover.example.com Owa.example.com

E-commerce server payments.example.com Web server www.example.com

www.example.net www.example.org www.acquisition.com (an acquired company)

RTC server Olm.example.com Rtc.example.com

Table 4.1: Example DNS names by server role.

Now let’s look at the same deployment using a SAN certificate; you’ll quickly see the difference.

Chapter 3

51

Figure 4.2: Using a single SAN certificate on multiple servers.

We’re using the same certificate on all four systems. We examined the benefits of using the same certificate in multiple locations in Chapters 2 and 3, so you should recall that there are a number of reasons that this configuration is desirable.

To make this simplified configuration happen, we have to properly plan the PKI deployment. Most of the existing best practices for PKI planning apply to the use of SAN certificates. This actually makes the proper use of SAN certificates much easier. The most significant difference comes in the use of applications that either require or provide additional functionality when using a SAN certificate. Let’s take a look at that planning element.

Private Key Compromise Whether you use SAN or standard certificates, when an attacker compromises the private key associated with a certificate, that certificate must be replaced. This means repeating the request, issuance, and deployment all over again. If you’re using SAN certificates, you’re probably using a single certificate in several places, so a single key compromise could be quite a bit of work to replace. Thus, when using SAN certificates, consider using HSMs to help protect the private key or a PKI management platform to expedite your recovery from key compromise. Also consider using multiple standard certificates to help minimize the impact of a single key breach.

Chapter 3

52

Planning PKI Applications There are dozens of categories of PKI‐enabled applications, and easily hundreds of individual applications within those categories. So how do we know the best way to plan for each of them? The important aspect of planning PKI applications for SAN certificates is in understanding how each application uses PKI.

For example, let’s take a look at email. Email volume, message complexity, security, reliability, and improved services and features have significantly increased over time. As a result, the load on email servers has increased. Today, very few organizations have a single email server. And most email servers and clients support PKI‐centric encryption based on long‐established standards and practices, such as secure sockets layer (SSL) for secure Web communications and IP Security (IPSec) for secure networking. In fact, in many

s. organizations, the majority of certificates are usually deployed for secure communication

More specifically, Microsoft’s Exchange 2007 messaging server and Office Outlook 2007 client support SAN certificates to enable the deployment of a single, multi‐use certificate in several locations. We’ll look at these in more depth later in this chapter.

The crux of this section is that you need to examine each service in your organization that supports PKI and determine whether it supports SAN certificates. At the time of this writing, only a few newer applications support them despite the fact that the subject alternative name field has been defined for years. For example, no version of Microsoft Exchange prior to 2007 supports SAN certificates. The older versions of Exchange only looked at the common name portion of the subject field. No matter what the subject alternative name field contained, it was ignored. Thus, although you could theoretically use a SAN certificate for that application, it would certainly not work as you would expect it to.

In general, the applications that support SAN certificates are the ones where it makes good sense. As I mentioned earlier, the applications that use distributed services over a number of servers and locations are the most likely to support SAN certificates. Single‐instance applications that utilize only one server for their service, such as phone switching applications or network gateways, are less likely to support multiple DNS namespaces per certificate simply because they have no need to do so.

How to Determine Whether an Application Supports SAN Certificates You need to understand how to determine whether a given application will work properly with SAN certificates. It makes no sense to pursue a SAN certificate infrastructure if your applications will not support it. In fact, there is even the potential (albeit small) for a SAN certificate to break your existing services.

Chapter 3

53

In general, there are three possible ways that an application will deal with a SAN certificate:

• The application will honor the subject alternative name and consider all names within the field valid. Thus, SAN certificates will work as expected on this application.

• The application will ignore the subject alternative name field and examine only the common name portion of the subject field to determine the valid subject name. Although a SAN certificate will work with this application, the alternative names will not work. You will still need separate certificates for separate namespaces.

• The application will consider the certificate invalid because it cannot understand or process the subject alternative name field. You will have to obtain and use a standard certificate without the SAN field.

The fastest and most authoritative method for determining which of these three ways the application will deal with a SAN certificate is to ask the software manufacturer. Check their Web site, read their documentation, or talk to a sales or technical support representative. If their application supports PKI (and if it doesn’t, you’re already barking up the wrong tree), they will probably understand your question and have a ready answer for you.

If the software manufacturer is unable to provide an authoritative answer, you will probably have to test it yourself. Assuming you already have the software deployed in your organization, you may be able to test the certificate in your live systems during downtime or on a hot‐swap server. However, that isn’t always a good approach. As a general rule, functional and compatibility tests like this should be done with offline systems to prevent any issues from affecting the production network.

A common software testing and verification method is to obtain an evaluation copy of the intended software and try out a SAN certificate on a test installation. Most large software vendors are more than happy to provide evaluation or test copies for this exact purpose. For example, Microsoft provides 120‐day evaluation copies of most of its server technologies including Windows Server 2003, Windows Server 2008, Exchange Server 2007, and Office Live Communications Server.

Chapter 3

54

Virtualized Testing Most organizations are trying to do more with less these days. As a result, many dedicated test environments are being scaled back or eliminated. However, technology advances have made testing much easier with limited resources. You’ve undoubtedly heard of solutions such as VMware Workstation and Microsoft’s Virtual PC or Virtual Server products. These products allow you to run a virtual environment within another system at reasonable performance and system resource investments. If you’re doing basic PKI testing, such as testing to ensure proper SAN certificate support, there is probably no reason to set up a large test architecture. You should be able to obtain evaluation copies of both the operating system (OS) and application, install them in a virtual environment, and test away. If you also use managed PKI or a third‐party CA, you can often obtain a limited‐lifetime test certificate to validate the technology before you buy the actual certificate. Although virtual environment testing does not replace the need for full‐scale testing prior to enterprise‐wide deployment, it can very handily serve the purpose of validating behavior and applicability of SAN certificates.

Once you’ve got the test environment up and running, you should use the SAN certificate extensively to ensure that the same level of functionality exists with both a regular and a SAN certificate. Because this chapter focuses on PKI and not software testing, I will not provide an exhaustive testing methodology. There are numerous books and articles on the subject. You should use whatever methodology you find most effective for your software and your situation.

Using SAN Certificates in Your Environment Once you’ve determined that your application supports the subject alternative name field of certificates, you are ready to begin planning for deployment. This process can be lengthy or short, expensive or cheap, simple or difficult. It will all depend on the plan developed prior to the deployment.

Based on my experience, few organizations will consider taking a rip‐and‐replace approach of replacing all existing certificates with the new SAN certificate. Unless there is a massive redeployment or some other event that requires certificate reinstallation across the systems, the new certificate will most likely be deployed to replace existing certificates as they expire. This will gradually put the single SAN certificate into use throughout the system.

Chapter 3

55

The gra benefits: dual replacement of certificates has several

• Making the most use of existing certificates

• Limiting exposure of the new certificate in case of compatibility issues

ing a single reengineering event • Conserving IT resource expenditure by avoidThere are also several drawbacks of this approach:

• rtificate configuration Continuing to support the complex multiple‐ce

• Losing validity time of the new SAN certificate

• Missing out on potential SAN‐enabled functionality of the applications In general, you should consider the rip‐and‐replace strategy to replace existing certificates with the new SAN certificate if there are other factors that contribute to the need to perform operations on all servers. The factors that might cause you to conduct a rip‐and‐replace operation include:

• Extended server maintenance on all servers

• Broad server hardware or software upgrades

• Additional functionality added by deploying the SAN certificate

• Application intolerance of a mixed certificate environment (in other words, the application will not work unless all certificates are consistent)

If one or more of these factors applies to your environment, consider the rip‐and‐replace strategy. Otherwise, I recommend that you plan to replace existing certificates as they expire or as maintenance is conducted on each server.

The Danger of a Massive Certificate Deployment On the surface, the rip‐and‐replace massive deployment of a new certificate seems like a great idea. Get it all over with at one time. But it can also be a dangerous venture. If your testing was not thorough, there might be deployment or compatibility issues with the new certificate. It may not work in the production systems. And without a fallback plan, you might find yourself unable to provide core services such as email and messaging. So before performing this type of deployment, ensure that you have thoroughly researched and tested the configuration and have a fallback plan of some type in case of disaster.

Chapter 3

56

Example: Using SAN Certificates with Microsoft Exchange 2007 Microso KI certificates for a variety of purposes: ft Exchange 2007 supports P

• Secure email communication

• ) over hypertext transfer protocol (HTTP) Remote procedure call (RPC

• Outlook Web Access (OWA)

• Various email transport protocols including SMTP and POP3 Many of these services will work with a standard certificate (assuming it is properly configured). As we’ve discussed, the use of multiple DNS namespaces with a single certificate is the principle benefit of a SAN certificate. With email systems in general, they are often deployed to serve more than one namespace, such as example.com, example.org, and exchange.example.com. Wildcard certificates might suffice for some of the convergent namespaces, but for a combination of .org and .com addresses, a SAN certificate is required. A wildcard certificate cannot span multiple root domain names. There is a useful new feature in Microsoft Exchange 2007 called Autodiscover. This feature encapsulates new functionality of Exchange. It also provides a great deal of existing functionality that relies on Autodiscover. The features that require Autodiscover to work properly are:

• Auto Account Setup (a new service that provides automatic account detection and profile creation)

• rvice) Availability (the free/busy se

• ss Book (OAB) Offline Addre

• Out of Office

• Exchange Unified Messaging Microsoft Exchange 2007’s Autodiscover feature requires a SAN certificate to work properly. Because Exchange uses certificates for several reasons already, the only change from the PKI side is that the certificate can no longer be a standalone certificate. It must be a SAN certificate. By default, Microsoft Exchange 2007 deploys a self‐signed certificate when it is installed. The self‐signed certificate can provide basic functionality for limited organizations, but it is not flexible enough for most organizations. In fact, it will not be trusted by clients by default. Adding a self‐signed certificate to each client’s Trusted Root Certification Authorities container can be very difficult to deploy and manage (and will not work for many types of clients). It is simply not realistic to try to do so. As a result, you will want to remove that self‐signed Exchange certificate and install a CA‐issued SAN certificate that chains to a trusted root. In this configuration, you have to manage only the server‐side certificate and not worry about the client configuration in most cases.

Chapter 3

57

Previous Versions of Microsoft Exchange It is worth calling out that the support for SAN certificates is new for Microsoft Exchange 2007. Previous versions did not cleanly support or require this certificate type like the current version does. Although it is possible to use SAN certificates in previous versions, it is tricky and less than optimal to do so. Thus, this section is specific in mentioning the version of Exchange repeatedly. If you’re using a previous version of Exchange, this guidance does not apply.

Let’s take a look at how to request a certificate from Microsoft Exchange 2007.

Requesting a SAN Certificate from Microsoft Exchange 2007 This process assumes that you already have Exchange 2007 installed. We will use functionality from the Exchange software to generate the certificate request, as other software may not properly form a SAN‐enabled certificate request. We’ll use the Exchange Management Shell to create a certificate request at the command line. Although a bit cumbersome, it is the only way to ensure that the certificate request is complete and properly configured. As of the time of this writing, there is no user interface (UI) method for requesting a SAN certificate because there is no interface for adding the domain names that go in the subject alternative name field.

For this example, we will use the details provided in Table 4.2.

Field Data

Certificate friendly name Microsoft Exchange SAN Certificate Primary domain name (CN) Example.com Secondary domain names Autodiscover.example.com

www.example.com PKI key size 2048 bits Subject name C=com

O=requestor CN=example.com

Mail services for certificate IIS, POP3, SMTP Certificate request path and file name C:\ExchangeSANCert.txt Issued certificate path and file name C:\IssuedExchangeSANCert.p7b

Table 4.2: Microsoft Exchange 2007 SAN certificate request example details.

Chapter 3

58

To c a llow these steps on the server running Exchange 2007re te the request, fo :

1. Click Start, then All Programs, next Microsoft Exchange Server 2007, and then click Exchange Management Shell. The Exchange Management Shell command‐line window will open.

2. Type the following command: New-ExchangeCertificate -DomainName example.com, autodiscover.example.com, www.example.com -FriendlyName "Microsoft Exchange SAN Certificate" -GenerateRequest:$True -Keysize 2048 -path c:\ExchangeSANCert.txt -PrivateKeyExportable:$true -SubjectName "c=com, o=Requestor, CN=example.com"

This two‐step process will result in a certificate request saved in the file C:\ExchangeSANCert.txt.

Installing an Issued SAN Certificate in Microsoft Exchange 2007 The next step is having the certificate issued. This is normally done by sending the saved request file to a CA (internal or external) and completing the certification process as described in Chapter 3. At the end of the process, the CA will sign and issue the certificate and most likely send a copy to you in a p7b file. Once you have the certificate, it is a simple process to install it. Just follow these steps on the r ange 2007: se ver running Exch

1. Click Start, then All Programs, next Microsoft Exchange Server 2007, and then click Exchange Management Shell. The Exchange Management Shell command‐

n. line window will ope2. Type this command: Import-ExchangeCertificate –Path c:\IssuedExchangeSANCert.p7b | Enable-ExchangeCertificate –Services IIS, POP, SMTP

This process will import the signed certificate from the p7b file back into the server. Because the server where this command is run is the same one where the certificate request was made, the private key for this certificate is already loaded and is automatically associated with the newly signed certificate. The result is a signed certificate and its associated private key both loaded into the computer.

Note If the exported p7b file was password‐protected, step 2 in the previous procedure would require the addition of the following parameter, where password is the password specified by the certificate issuer:

‐Password password

Chapter 3

59

Post‐Installation Tasks Once the certificate has been installed, the first thing you should do is conduct functional tests to ensure that the certificate works properly. For the example in this section, appropriate tests might include using PKI‐enabled features by performing these user‐focused ns: tasks for each of the subject alternative name domai

• Access a mailbox through OWA from a Web browser

• Configure a new email Microsoft Office Outlook 2007 client and confirm that Autodiscover populates the configuration

• Schedule a meeting to ensure that the Free/Busy Service is functioning Once these tests are successfully completed, you should back up the certificate and private key. Take care to ensure you make a complete backup by testing it on another system, then store the backup in a reliable and secure location. If the backup is compromised by an attacker, the attacker will have the private key for your messaging infrastructure (and possibly much more). If the backup is lost or damaged, and your original key is also lost, the cost and difficulty in having a new certificate issued and can be significant.

Example: Using SAN Certificates with Microsoft Office Communications Server 2007 SAN certificates are required for proper operation of Microsoft Office Communications

Server 2007. This isn’t a matter of convenience or best practice. It actually is a requirement.With SAN certificates, the Office Communications Server 2007 environment does not work. Compared with the Exchange processes, however, the operational processes for requesting and installing the certificates are amazingly simple. In fact, it’s a wizard that comes up by default when you run the management console. The wizard generates your SAN certificate request automatically. Your only task is to send the request to the issuing CA and then install the returned certificate by double‐clicking it. Really, that’s all there is to it!

SAN Operation and Maintenance SAN operation and maintenance is discussed extensively in Chapter 3. As a brief reminder, certificates require very little attention during their lifetime. For the most part, once you’ve installed and verified the configuration of a PKI‐enabled application, it will work until one of a small number of issues occurs:

• The private key is compromised on one of your servers

• The root issuing certificate’s private key is compromised

• on list (CRL) is compromised or is unreachable The certificate revocati

• The certificate expires

Chapter 3

60

When one of these issues occurs, you should quickly address it. The most common issue that you’ll face is certificate expiration. PKI vendors understand this, and today many of them are recommending 2‐ to 3‐year certificate validity periods to help minimize the impact of expiring certificates.

Summary The first two chapters covered PKI and certificates in technical detail. Chapter 3 departed from that type of content by focusing on the business aspects of certificates, and SAN certificates in particular. In this chapter, we looked at applied use of the SAN certificates. We discussed various planning techniques and details, and provided specific recommendations and guidelines for which approaches are appropriate for each situation. We then explored Microsoft Exchange 2007’s use of certificates in some depth and showed specifically how it can be configured with a SAN certificate.

Throughout this series, you have seen the benefits of SAN certificates. Not only are they required for a number of advanced PKI‐based applications, they also simplify your IT infrastructure and can lower the cost of certificate ownership and management. Although some managed PKI vendors do charge more for SAN certificates, you now understand their alue and how to calculate whether to make an investment. v

Download Additional eBooks from Realtime Nexus! Realtime Nexus—The Digital Library provides world‐class expert resources that IT professionals depend on to learn about the newest technologies. If you found this eBook to be informative, we encourage you to download more of our industry‐leading technology eBooks and video guides at Realtime Nexus. Please visit ttp://nexus.realtimepublishers.comh .


Date post:	27-Nov-2014
Category:	Documents
Upload:	davidlam0109
View:	154 times
Download:	0 times

Subject Alternative Name Certificates

Documents