The Basics of Certificates | Designing Secure Web-Based Applications for Microsoft Windows 2000 with CDROM

[Previous] [Next]

The three previous topics—symmetric cryptography, digest functions, and asymmetric cryptography—are important building blocks of all PKI-based solutions. Symmetric key cryptography can provide data privacy, digests can provide data integrity, and asymmetric cryptography can help provide message authenticity and provide for key exchanges. Sort of. In fact, asymmetric cryptography doesn't guarantee message authenticity because you don't know that Alice's public key is actually Alice's. Hence, you cannot assert that the person with Alice's private key is indeed Alice. You also don't know that a message is valid because a message digest can be tampered with. Certificates and the technologies surrounding them can help address many of these issues.

A Look Inside a Certificate

A certificate is a binary structure containing information about the holder of a public key. In technical terms, a certificate binds a name to a public key. The most common form of certificate is the X.509 certificate, of which there are three versions—1, 2, and 3. We'll focus mainly on version 3 certificates, which contain, at a minimum, the following information:

Version number The number 0, 1, or 2, which represents certificate version 1, 2, or 3, respectively.

Serial number A unique identifier for the certificate determined by the certificate issuer.

Signature algorithm The algorithm used to derive the digital signature, represented using an object identifier (OID). OIDs are discussed a little later.

Issuer name The name of the certificate issuer. Often, the name is expressed as an X.500 name; we'll discuss X.500 names in a moment.

Validity period The period during which the certificate is valid. Like a credit card, a certificate becomes valid on a given date and time and expires on a given date and time.

Subject name The name of the subject (the owner of the private key associated with the public key held in the certificate). Like the issuer name, the subject name is often expressed as an X.500 name.

Subject public key information The algorithm used to define the public/private key pair (expressed as an OID) and the actual public key data.

Signed hash of the certificate data The hashed contents of the certificate, which are encrypted using the issuer's private key, resulting in a digital signature.

Version 3 certificates can also contain other optional data, called extensions, which are extensions to a certificate not defined in the X.509 specification. Common extensions include alternate subject name, key usage, and certificate revocation list (CRL) distribution points, or CDPs.

An alternate subject name is another name by which the subject is known. For example, the common name in a certificate might be CN=Cheryl, but Cheryl might also be known by another name, such as her e-mail name, in which case altSubjectName might be E=Cheryl@exair.com.

Key usage determines what the private key associated with the certificate can be used for—for example, code signing, e-mail, server authentication, and logon. We'll explain key usage later in this chapter.

CDPs are lists of locations where software can check to see whether the certificate has been revoked by the issuer. Certificate revocation is also discussed later in this chapter.

NOTE
The Internet industry standard certificate format is defined by the Internet Engineering Task Force (IETF) Public Key Infrastructure (PKIX) working group, details of which can be found at http://www.ietf.org/html.charters/pkix-charter.html. The most important document is RFC 2459, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile."

Figure 15-7 shows the composition of an X.509 certificate.

click to view at full size.

Figure 15-7. The structure of an X.509 certificate.

X.500 naming, X.509, DER, base64 encoding, OIDs, PKCS, and ASN.1 explained

We've already mentioned X.509, X.500 naming, and OIDs. When you use cryptographic and certificate-based solutions, you'll also hear about distinguished encoding rules (DER), base64 encoding, PKCS (Public Key Cryptography Standard) #5, PKCS #7, PKCS #10, PKCS #12, and Abstract Syntax Notation One (ASN.1). Let's take a moment to look at each term in more detail.

X.500 naming is a standard way to unambiguously name an entity, such as a user. Its usage derives from the hierarchical X.500 directory services. A unique X.500 name is known as a distinguished name (DN). The most common format you'll see is of the type C=US, O=ExAir, OU=Development, CN=Cheryl, where C is country, O is organization, OU is organizational unit, and CN is the common name of the entity being named. As you can see, the naming structure is hierarchical and fits well into directory systems based on or derived from X.500.

Table 15-2 lists the typical DN components.

Table 15-2. X.500 DN components.

Component	Name	Example
C	Country	US
SP	State/Province	WA (Washington)
S	State	WA (Washington)
L	Locality	Redmond
O	Organization	ExAir
OU	Organizational Unit	Development
CN	Common Name	Cheryl
E	E-Mail	cheryl@exair.com

Note that version 3 certificates do not mandate X.500 naming for the subject or issuer names. Other possibilities include e-mail name, IP address, electronic data interchange (EDI) name, or URL.

X.509 is the industry-standard certificate type. Microsoft Windows 95, Windows 98, Windows NT, and Windows 2000 all natively support X.509 certificates. You can find more information about X.509 certificates in the RSA Security Crypto FAQ at http://www.rsasecurity.com/rsalabs/faq and the official X.509 certificate specification at ftp://ftp.isi.edu/in-notes/rfc2459.txt.

DER is a binary encoding format for certificates. For more information, go to ftp://ftp.rsa.com/pub/pkcs/doc/layman.doc. Windows 95, Windows 98, Windows NT, and Windows 2000 support DER-encoded certificates.

Base64 encoding is a text-based encoding system for binary data. It's the same coding scheme used by basic HTTP 1.0 authentication and is defined in RFC 1521 at ftp://ftp.isi.edu/in-notes/rfc1521.txt. Base64 encoding is often used to transfer certificates and certificate requests in e-mail because the data is textual rather than binary and many older e-mail clients and e-mail servers cannot process binary data correctly. Windows 95, Windows 98, Windows NT, and Windows 2000 support base64-encoded certificates.

OIDs are a way to identify algorithms and attributes (such as parts of a distinguished name). OIDs are based on a hierarchical dot notation. For example, 1.2.840.113549.1.1.4 refers to the MD5/RSA digital signature algorithm. The parts of this OID are identified in Figure 15-8.

Figure 15-8. An MD5/RSA OID in detail.

You'll also come across OIDs if you use Active Directory. All identifiers in Active Directory, such as userPrincipalName (1.2.840.113556.1.6.655) and cn (common name; 2.5.4.3) are represented by OIDs.

To find out what an OID means, visit the invaluable Web site at http://www.alvestrand.no/harald/objectid/top.html. At the time of this writing, this site doesn't list security-related OIDs under 1.3.6.1.5, but it does list RSA-related OIDs under 1.2.840.113549.

PKCS #5, often referred to as passphrase-based encryption, is a standard and secure way of deriving a private key from a password and using the key to encrypt confidential data. For more information, go to http://www.rsasecurity.com/rsalabs/pkcs/pkcs-5/index.html. PKCS #7 is a binary format for defining encrypted and signed data such as certificates. For more information, go to http://www.rsasecurity.com/rsalabs/pkcs/pkcs-7/index.html. PKCS #10 is a binary format for creating certificate requests. For more information, take a look at http://www.rsasecurity.com/rsalabs/pkcs/pkcs-10/index.html. PKCS #12 is a binary format for storing certificates and their keys. The .pfx file format in Windows is a PKCS #12 blob. For more information, go to http://www.rsasecurity.com/rsalabs/pkcs/pkcs-12/index.html.

ASN.1 is a method and syntax for describing data precisely. For example, the data format of an X.509 certificate is defined using ASN.1 syntax. ASN.1 is somewhat similar in principle to BNF notation, which is familiar to those who know about the science of programming languages. The following is abbreviated ASN.1 syntax for an X.509 certificate taken from RFC 2459:

 Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } TBSCertificate ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version shall be v2 or v3. subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version shall be v2 or v3. extensions [3] EXPLICIT Extensions OPTIONAL -- If present, version shall be v3. }

Finally, in the interest of building a sentence containing the most certificate-related acronyms possible: an X.509 certificate is defined using ASN.1 notation, the entities of which are identified using OIDs, and is usually stored as a PKCS #7 data structure in either base64 or DER encoding.

Certificates and the role of trust

Earlier we mentioned that a certificate binds a public key to a subject such as a computer or a user—in other words, a principal. But how do we know that the certificate is really the principal's certificate and not someone else's? It's all a matter of trust. Certificates are issued by issuers or authorities. An example of a well-known certificate authority (CA) is VeriSign. Thawte Consulting, based in South Africa, is another. At the time of this writing, Thawte was in the process of being purchased by VeriSign. Windows 2000 includes Microsoft Certificate Services, so in theory you can be a CA, too, but it's not quite as simple as that.

When a CA issues a certificate to a principal, it takes the following steps:

It performs background checks to verify that the principal (called a subject) is who it says it is. For example, for a user's certificate this might be a simple physical address check or perhaps a simple verification that the CA can receive the e-mail that the subject sent during the enrollment process. However, because certificates are often used for important and sensitive tasks, more stringent background checks are advisable.

It creates and signs a certificate using its private key.

It issues the certificate to the subject.

The CA (or the subject) makes the certificate known to all interested users.

How Do You Access Another User's Certificate?
Certificates are public, so accessing another user's certificate is actually quite easy. You can ask the user to send it to you via e-mail or on a floppy disk. In fact, if the e-mail is a digitally signed Secure Multipurpose Internet Mail Extensions (S/MIME) message, the certificate is already available to you in the e-mail. The certificate might reside in an Lightweight Directory Access Protocol (LDAP)-enabled directory, such as Active Directory in Windows 2000.

Windows 2000 also enables you to find a VeriSign customer's certificate right from the shell. You simply take the following steps:

Choose Search from the Start menu.

Select For People.

In the Find People dialog box (Figure 15-9), select VeriSign Internet Directory Service in the Look In drop-down list box.

Enter the name or e-mail address of the user you want to find.

Click Find Now.

If the user exists, you'll see details about the user, including the user's certificate or certificates.

Figure 15-9. The VeriSign Internet Directory Service in Windows 2000.

So, how does Bob know that a message was sent by Alice? As you can probably guess, it's a trust issue. Let's look at an example:

Alice creates an e-mail message using Microsoft Outlook Express 5 and digitally signs it using the private key associated with the public key contained in a certificate she possesses. The certificate containing her public key is already publicly available.

Alice sends the e-mail message to Bob over an insecure medium such as the Internet.

Bob's e-mail software, Microsoft Outlook 2000, receives the message and verifies that the certificate is correct. It does this as follows:

It verifies that the issuer of Alice's certificate is trusted. If the certificate is trusted, Outlook knows that the certificate of the issuer is stored on your computer.

It verifies that the document hasn't been tampered with by hashing the original document and decrypting the signature on Alice's e-mail using Alice's public key from her certificate. If the two resulting hashes are valid, the message is valid.

It verifies that the certificate hasn't expired.

It verifies that the certificate hasn't been revoked.

It verifies that the subject name in the certificate (Alice) matches the name of the e-mail sender (also Alice).

Here's what this process achieves: Bob's software determines that the message came from Alice and wasn't tampered with because Bob trusts the issuer of Alice's certificate and the digital signature is valid. Because Bob trusts the issuer, he trusts the issuer's public key and this public key is used to verify the signature on Alice's certificate.

Figure 15-10 shows the steps involved in checking that the certificate associated with the message is valid.

click to view at full size.

Figure 15-10. Determining whether a certificate is valid.

A Healthy Dose of Paranoia
During a presentation that Michael gave on cryptography and certificates at Microsoft Web Tech·Ed in Palm Springs, California, in early 1998, an audience member raised his hand and asked, "How do I know that the VeriSign root certificates included with Windows really came from VeriSign?" Michael jokingly responded, "Trust me!"

Of course, the audience laughed and Michael quickly responded, "Seriously, though, that's a great question and it's these kinds of security assumptions you should constantly examine. However, if you don't believe or trust that the root certificates are really VeriSign's, then go to the VeriSign Web site and download them."

The same gentleman raised his hand again and said, "But how do I know it's the VeriSign Web site and not a rogue server acting as VeriSign and I'm being sent to the rogue site because someone has "poisoned" a DNS server?" Michael replied, "Phone up VeriSign and ask them to send you the root certificates on a floppy."

Obviously, the man wasn't happy with the answer and inquired, "How can I be sure that no one at the postal service changed the root certificates on the floppy to that of a rogue CA pretending to be VeriSign?"

Michael was impressed, but he had a quick answer. "Okay, when you install the root certificates from the floppy, you'll be given two thumbprints by Windows, an MD5 thumbprint and an SHA-1 thumbprint, both in hexadecimal. Telephone VeriSign and ask them to confirm the thumbprints." At this point, Michael showed the audience what the dialog box in question looked like (Figure 15-11).

Figure 15-11. Adding a new root certificate. (Note the two thumbprints, or hashes.)

The man cleared his throat and said, "How can I be assured that no one at the telephone exchange is redirecting my call to a rogue CA? I'm still not convinced that the roots are from VeriSign."

At this point, Michael dryly commented, "Sir, are you sure you should be putting anything on the Web?" The audience erupted into laughter and Michael continued, with a big grin: "May I suggest you fly to VeriSign's offices and personally ask an engineer to load the root certificates onto a floppy and hand them to you. And by the way, if you ask me how do you know it's VeriSign's offices and not those of an imposter, I will personally escort you out of the hall!"

Of course, the man wasn't trying to be difficult, nor was he particularly concerned about the authenticity of the roots included with Windows. He was merely thinking through a series of trust decisions that have to be made and wondering at what point a person should be convinced that something is what it says it is and is trustworthy.

As you can see, trust in the root CA certificate is paramount. All parties must trust the root CA; otherwise, the system won't work. A common analogy is that of issuing a driver's license. Many businesses accept a driver's license as proof of identity and date of birth because they trust that the issuer performed appropriate checks on the person.

An Important Note on Root CA Certificate Trust
Windows 2000 ships with over 100 root CA certificates "baked in." In other words, if your software encounters a certificate issued by any of these companies, it will trust them. However, some of the companies you might not know, so you shouldn't trust them. Period. You should go through the list of trusted root certificates and remove the root certificates of all the companies you do not know or do not trust. Do not remove any Microsoft or VeriSign root certificates, however, because many components included with Windows 2000 are signed by Microsoft or VeriSign, and removing them might make the system unreliable.

In Windows 2000, you can enforce this certificate removal through policy. Also note that you must not remove the roots from the computer store because these are used by some applications, such as Microsoft SQL Server and Internet Information Services.

Certificate chains and hierarchies

Often, a series of certificates (often called leaf certificates) leads from the principal's certificate up to the root certificate; this is referred to as a chain or a hierarchy. The topmost certificate, the root, is also called a self-signed certificate because it's not issued by any other CA, it's issued by itself to itself.

It's quite normal to have more than one subordinate certificate issued by the root (or a high-level subordinate) because the subordinates might issue certificates based on differing organizational units, geographical location, or certificate usage. This has significant benefits, including

Flexible configuration For example, the root CA might store its private key in expensive but very secure cryptographic hardware for maximum protection, while subordinate CAs store their private keys in software.

Reduced impact of CA key revocation You can disable parts of the CA hierarchy without affecting the entire public key infrastructure. For example, if the private key of the Client certificate subordinate CA is compromised, only its key is revoked, not all CA keys in the hierarchy.

A common way to set up a subordinate CA is to base the configuration on key usage. For example, Figure 15-12 shows Exploration Air's CA hierarchy, which is based on certificate usage.

click to view at full size.

Figure 15-12. Certificate hierarchy at Exploration Air.

There is one root. The four subordinates are for

Server authentication for use in Secure Sockets Layer/Transport Layer Security (SSL/TLS) (ExAir Server CA)

Client authentication when using SSL/TLS and secure e-mail using S/MIME (ExAir User CA)

Client authentication when using SSL/TLS and secure e-mail using S/MIME for extranet business partners (ExAir Extranet CA)

Client logon using smartcards and Windows 2000 (ExAir Logon CA)

Arguably, the third is for more than key usage; it's for key usage for specific customers. Exploration Air issues certificates to its business partners using this CA.

Key usage

Certificates and their associated private keys are used for a number of things, but ultimately they're all about verifying identity. For example, a certificate might be used to verify the sender of an e-mail message or assert ownership of a piece of code. However, the most common scenario is verifying the authenticity of a Web site. It's important that the private key associated with the certificate be used only as intended.

As another example, take a look at Table 15-3, which lists Michael's certificates.

Table 15-3. Michael's certificates.

Subject	Issuer	Purposes
Michael Howard	Personal Freemail RSA 1999.9.16 (Thawte)	Client authentication E-mail protection
Michael Howard	Windows 2000 Development Team	Encryption of data on the disk
Michael Howard	Windows 2000 Development User Enrollment	Client authentication E-mail protection Smartcard logon
http://mike-security	Michael's CA	Server authentication

Each certificate has an intended purpose for its associated private key. For example, the first three certificates are used to authenticate a user, and the fourth is used to authenticate a Web server called http://mike-security.

The first certificate can be used to authenticate the owner when the client is using SSL/TLS and the Web server requires that the user identify himself with a client authentication certificate. The certificate can also be used when the client sends secure electronic mail, such as S/MIME.

The second certificate, issued to members of the Windows 2000 development team, is used to encrypt and decrypt data on the disk using the Windows 2000 Encrypting File System.

The third, also issued to members of the Windows 2000 development team, can be used for SSL/TLS, e-mail (such as S/MIME), and logon to Windows 2000 using a smartcard rather than a password.

The fourth certificate was issued by the author's CA using Microsoft Certificate Services (included with Windows 2000) to his own intranet Web server. This is a purely experimental setup because no one has inherent trust in a personal CA.

As already discussed, it's common to have multiple certificate chains based on key usage. For example, the two Windows 2000 certificates in Table 15-3 have different issuers but they share the same root. (This isn't obvious from the table because the table includes only the issuers, not the full certificate chain.)

The full chains for each certificate are shown in Table 15-4.

Table 15-4. Certificates and their certificate chains.

Subject	Certificate Chain
Michael Howard	Thawte Personal Freemail CA (root) Personal Freemail RSA 1999.9.16 (Thawte)
Michael Howard	Windows 2000 Dev CA Root Windows 2000 End-User Windows 2000 Development Team
Michael Howard	Windows 2000 Dev CA Root Windows 2000 End-User Windows 2000 Development User Enrollment
http://mike-security	Michael's CA

Certificate trust

Notice the decreasing trust in the certificates listed in Table 15-4—the first certificate from Thawte carries more authority than the last certificate issued to Michael by Michael (which is a little like issuing a passport to yourself). Most people trust Thawte as a respected CA that issues certificates after performing some degree of due diligence. But few people will trust a certificate issued by an individual unless they know the individual personally. Think of it as a sphere of trust issue: how much trust is inherent in the issuer and to what degree is the issuer trusted? Thawte certificates have global trust, the internal Microsoft CA certificates are trusted within Microsoft, and Michael's CA is trusted only by Michael and those who know him.

Another implied aspect of trust is that CAs manage the certificates they issue—that is, they renew certificates when they expire and revoke certificates when required.

Certification revocation lists

A certification revocation list (CRL) is a data structure that maintains a list of certificates that have been revoked or invalidated before their expiration date. A CA might revoke a certificate for such reasons as these:

The associated private key has been compromised.

The user has left the organization or changed positions.

It's been discovered that the certificate was obtained through falsified means.

When a program requests a certificate from a principal, it can check the CRL to ensure that the certificate hasn't been revoked. It does this by checking the CDPs in the certificate, which might be a file stored on a file and print server, an FTP server, a Web server, or a server responding to LDAP requests such as Active Directory.

Data communication protocols that use certificates

Some of the common protocols that use certificates include

SSL/TLS, a protocol for securing a connection between a client application and a server application (such as a Web browser and Web server). SSL/TLS requires a certificate at the server and optionally a certificate for each client if the server requires a client authentication certificate. Internet Explorer 5, IIS 5, Microsoft Exchange Server 5.5, SQL Server 2000, SMTP Server, and LDAP support on Windows 2000 all support SSL/TLS.

S/MIME, a protocol for sending secure e-mail. If a user has a private key and an associated certificate, he can sign his e-mail to enable other users to verify the origin of the message. A user can send another user a private e-mail if he has access to the recipient's certificate. It's common to sign and encrypt e-mail. To do so, both parties must have a certificate and a private key. Outlook 2000 and Outlook Express 5 support S/MIME.

IPSec (Internet Protocol Security), a computer-to-computer protocol that supports privacy, authentication, and data integrity. IPSec does not require certificates, but it's a very secure means of authenticating hosts. Windows 2000 supports IPSec.

Some myths about certificates

We've seen numerous articles explaining, erroneously, how simply using certificates can render a Web site impervious to attack. Certificates are useful for building certain security solutions, but they're no panacea.

Myth #1: certificates provide encryption.

This myth originates from the fact that the most common protocol that uses certificates is SSL/TLS, and SSL/TLS provides encryption—hence the misconception that certificates provide encryption. SSL/TLS works by authenticating the server first; this is where the certificate is used. Once the client authenticates the server, the client and server determine a symmetric key to use for the rest of the conversation. The key is used to encrypt the communication channel.

Myth #2: certificates are a perfect authentication scheme.

Certificates are an excellent form of authentication, especially when used in conjunction with smartcards. However, certificates have two weaknesses:

Your software trusts all certificates issued by the CA if you trust the CA. However, if the CA does an inadequate background check on the principal, the system breaks down.

Managing keys is a complex task, especially for users. In order for the system to be secure, the keys must never leave the user's computer, but many users have access to more than one computer. Unlike passwords, which are portable because you keep them in your head, private keys usually reside on a computer. Moving the keys to another computer is a relatively complicated undertaking for users, and it's also a security risk because the private keys might be exposed as they're being transferred.

Myth #3: the CA has your private key.

Most of the time, this isn't true, especially in the case of public CAs. When you want a new certificate and private key, the key pair is created at the client computer and the private key is securely stored locally. The certificate request is made and contains only the public key that will eventually be returned to the user as a certificate containing the public key.

Myth #4: certificates provide as much authentication as Web cookies.

We were surprised to hear this comment coming from an industry consulting organization. Cookies are a common way to authenticate users when they access your Web site, but they're a very weak form of authentication compared to public key certificates. Here are some of the differences:

A certificate is a public document. There is nothing in a certificate to protect or secure data. Cookies must be secured because they're private data.

A certificate is tamper resistant. No one can change a certificate without making it invalid. Cookies provide no such security.

Only the person who holds the private key can use the certificate for authentication. Others can use the certificate to verify your identity. A cookie, however, is much less secure and can easily be replayed. (A replay or spoof attack is a third party using packets captured from a successful connection to play back the remote client's response in order to gain an authenticated connection.)

Certificates are issued only after some kind of verification of your identity. Cookies come with no such assurances.

Certificates and private keys can be stored on tamper-resistant devices such as smartcards; cookies are not stored on these devices.

Cookies can easily be stolen by sniffing the connection between the client and the server. Private keys are much harder to steal because they rarely leave the computer on which they were generated.

Private keys can be used to create digital signatures that assert that the possessor is the owner or producer of a piece of code or a document. Cookies cannot be used for such purposes.