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.
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.
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:
This guide is provided in four chapters. Each chapter focuses on a different aspect of the concepts and practical use of SAN 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.
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:
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 Sockets Layer (SSL) in Internet browsers and Web servers.
Common uses of certificates include:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Most series should have a glossary—including it with Chapter 1 makes it more accessible throughout the series and defines the terms in advance.