Red Hat CERTIFICATE SYSTEM 8 - DEPLOYMENT Quick reference guide

Red Hat Certificate
System 8
Deployment Guide
Ella Deon Lackey
Publication date: July 22, 2009, updated on September 24, 2009

Deployment Guide
Red Hat Certificate System 8 Deployment Guide
Author Ella Deon Lackey
Copyright © 2009 Red Hat, Inc.
Copyright © 2009 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons
Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available
at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this
document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert,
Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity
Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
All other trademarks are the property of their respective owners.
1801 Varsity Drive
Raleigh, NC 27606-2072 USA
Phone: [phone]
Phone: [phone]
Fax: [phone]
PO Box 13588
Research Triangle Park, NC 27709 USA

iii
About This Guide vii
1. Examples and Formatting .............................................................................................. vii
1.1. Formatting for Examples and Commands ............................................................. vii
1.2. Tool Locations .................................................................................................... viii
1.3. Guide Formatting ............................................................................................... viii
2. Additional Reading ........................................................................................................ viii
3. Giving Feedback ............................................................................................................ ix
4. Document History ............................................................................................................ x
1. Introduction to Public-Key Cryptography 1
1.1. Encryption and Decryption ............................................................................................ 1
1.1.1. Symmetric-Key Encryption ................................................................................. 2
1.1.2. Public-Key Encryption ........................................................................................ 2
1.1.3. Key Length and Encryption Strength ................................................................... 3
1.2. Digital Signatures ......................................................................................................... 4
1.3. Certificates and Authentication ...................................................................................... 5
1.3.1. A Certificate Identifies Someone or Something .................................................... 5
1.3.2. Authentication Confirms an Identity ..................................................................... 5
1.3.3. How Certificates Are Used ................................................................................. 9
1.3.4. Contents of a Certificate .................................................................................. 13
1.3.5. How CA Certificates Establish Trust .................................................................. 16
1.4. Managing Certificates ................................................................................................. 21
1.4.1. Issuing Certificates .......................................................................................... 21
1.4.2. Key Management ............................................................................................ 22
1.4.3. Renewing and Revoking Certificates ................................................................. 22
2. Overview of Red Hat Certificate System Subsystems 23
2.1. A Review of Certificate System Subsystems ................................................................ 23
2.1.1. About the Certificate Manager (CA) .................................................................. 24
2.1.2. About the Registration Manager (RA) ............................................................... 26
2.1.3. About OCSP Services ...................................................................................... 27
2.1.4. About the Data Recovery Manager (DRM) ........................................................ 29
2.1.5. About the Token Processing System (TPS) ....................................................... 32
2.1.6. About the Token Key Service (TKS) .................................................................. 33
2.2. Red Hat Certificate System Services ........................................................................... 33
2.2.1. Interfaces for Administrators ............................................................................. 33
2.2.2. Agent Interfaces .............................................................................................. 36
2.2.3. End User Pages .............................................................................................. 37
2.2.4. Enterprise Security Client ................................................................................. 38
3. Supported Standards and Protocols 41
3.1. PKCS #11 .................................................................................................................. 41
3.2. SSL/TLS, ECC, and RSA ........................................................................................... 42
3.2.1. Supported Cipher Suites for RSA ..................................................................... 43
3.2.2. Using ECC ...................................................................................................... 43
3.3. IPv4 and IPv6 Addresses ........................................................................................... 44
3.4. Supported PKIX Formats and Protocols ....................................................................... 45
3.5. Supported Security and Directory Protocols ................................................................. 46
4. Major Features in Certificate System 49
4.1. Certificate Issuance .................................................................................................... 49
4.2. Authentication for Certificate Enrollment ....................................................................... 49
4.3. Certificate Profiles ...................................................................................................... 49

Deployment Guide
iv
4.4. CRLs ......................................................................................................................... 50
4.5. Publishing .................................................................................................................. 50
4.6. Notifications ............................................................................................................... 50
4.7. Jobs .......................................................................................................................... 50
4.8. Dual Key Pairs ........................................................................................................... 50
4.9. Cross-Pair Certificates ................................................................................................ 50
4.10. Logging .................................................................................................................... 50
4.11. Auditing .................................................................................................................... 51
4.12. Self-Tests ................................................................................................................. 51
4.13. Access Controls ....................................................................................................... 51
4.14. Security-Enhanced Linux Support .............................................................................. 51
5. Planning the Certificate System 55
5.1. Deciding on the Required Subsystems ........................................................................ 55
5.1.1. Single Certificate Manager ............................................................................... 55
5.1.2. Planning for Lost Keys: Key Archival and Recovery ........................................... 57
5.1.3. Balancing Certificate Request Processing ......................................................... 57
5.1.4. Balancing Client OCSP Requests ..................................................................... 58
5.1.5. Planning for Smart Cards ................................................................................. 59
5.2. Defining the Certificate Authority Hierarchy .................................................................. 61
5.2.1. Subordination to a Public CA ........................................................................... 62
5.2.2. Subordination to a Certificate System CA .......................................................... 62
5.2.3. Linked CA ....................................................................................................... 62
5.2.4. CA Cloning ...................................................................................................... 62
5.3. Planning Security Domains and Trust Relationships ..................................................... 63
5.3.1. Understanding Security Domains ...................................................................... 63
5.3.2. Using Trusted Managers .................................................................................. 65
5.4. Determining the Requirements for Subsystem Certificates ............................................. 65
5.4.1. Determining Which Certificates to Install ........................................................... 65
5.4.2. CA Distinguished Name ................................................................................... 67
5.4.3. CA Signing Certificate Validity Period ................................................................ 67
5.4.4. Signing Key Type and Length .......................................................................... 67
5.4.5. Using Certificate Extensions ............................................................................. 68
5.4.6. Using and Customizing Certificate Profiles ........................................................ 70
5.4.7. Planning Authentication Methods ...................................................................... 72
5.4.8. Publishing Certificates and CRLs ...................................................................... 73
5.4.9. Renewing or Reissuing CA Signing Certificates ................................................. 74
5.5. Planning for Network and Physical Security ................................................................. 74
5.5.1. Considering Firewalls ....................................................................................... 74
5.5.2. Considering Physical Security and Location ...................................................... 75
5.5.3. Port Considerations ......................................................................................... 75
5.6. Tokens for Storing Certificate System Subsystem Keys and Certificates ......................... 76
5.7. Questions for Planning the Certificate System .............................................................. 78
6. Setting up a Common Criteria Environment 79
6.1. About Common Criteria .............................................................................................. 79
6.2. Required Configuration for the Server or Network ......................................................... 79
6.3. Required Features and Configurations for the Certificate System Subsystems ................ 80
6.4. Users, Roles, and Access Control for Common Criteria ................................................ 81
6.4.1. Certificate System User Types .......................................................................... 82
6.4.2. Access Controls for Common Criteria ............................................................... 83
6.5. Security Objectives for the Common Criteria Environment for Certificate System ............. 83

v
6.5.1. Usage Assumptions ......................................................................................... 83
6.5.2. Organizational Policies ..................................................................................... 84
6.5.3. Potential Threats ............................................................................................. 84
6.5.4. Security Objectives .......................................................................................... 85
6.6. Features Not Covered by Common Criteria Evaluation` ................................................ 87
Glossary 89
Index 103

vi

vii
About This Guide
This guide explains how to install and configure Red Hat Certificate System subsystems.
This guide is intended for experienced system administrators planning to deploy the Certificate
System. Certificate System agents should refer to the Certificate System Agent's Guide for information
on how to perform agent tasks, such as handling certificate requests and revoking certificates. For
information on using Certificate System to manage smart cards and security tokens, see Managing
Smart Cards with the Enterprise Security Client.
Before using Certificate System, become familiar with the following concepts:
• Intranet, extranet, and Internet security and the role of digital certificates in a secure enterprise,
including the following topics:
• Encryption and decryption
• Public keys, private keys, and symmetric keys
• Significance of key lengths
• Digital signatures
• Digital certificates, including different types of digital certificates
• The role of digital certificates in a public-key infrastructure (PKI)
• Certificate hierarchies
• LDAP and Red Hat Directory Server
• Public-key cryptography and the Secure Sockets Layer (SSL) protocol, including the following:
• SSL cipher suites
• The purpose of and major steps in the SSL handshake
1. Examples and Formatting
1.1. Formatting for Examples and Commands
All of the examples for Red Hat Certificate System commands, file locations, and other usage are
given for Red Hat Enterprise Linux 5 (32-bit) systems. Be certain to use the appropriate commands
and files for your platform.
To start the Red Hat Certificate System:
service pki-ca start
Example 1. Example Command

About This Guide
viii
1.2. Tool Locations
All of the tools for Red Hat Certificate System are located in the /usr/bin directory. These tools can
be run from any location without specifying the tool location.
1.3. Guide Formatting
Certain words are represented in different fonts, styles, and weights. Different character formatting is
used to indicate the function or purpose of the phrase being highlighted.
Formatting Style Purpose
Monospace font Monospace is used for commands, package names, files and
directory paths, and any text displayed in a prompt.
Monospace
with a
background
This type of formatting is used for anything entered or returned
in a command prompt.
Italicized text Any text which is italicized is a variable, such as
instance_name or hostname. Occasionally, this is also used to
emphasize a new term or other phrase.
Bolded text Most phrases which are in bold are application names, such as
Cygwin, or are fields or options in a user interface, such as a
User Name Here: field or Save button.
Other formatting styles draw attention to important text.
NOTE
A note provides additional information that can help illustrate the behavior of the system or
provide more detail for a specific issue.
IMPORTANT
Important information is necessary, but possibly unexpected, such as a configuration
change that will not persist after a reboot.
WARNING
A warning indicates potential data loss, as may happen when tuning hardware for
maximum performance.
2. Additional Reading
The documentation for Certificate System includes the following guides:
•Certificate System Deployment Guide1 describes basic PKI concepts and gives an overview of the
planning process for setting up Certificate System.
This manual is intended for Certificate System administrators.

Giving Feedback
ix
•Certificate System Installation Guide2 covers the installation process for all Certificate System
subsystems.
This manual is intended for Certificate System administrators.
•Certificate System Administrator's Guide3 explains all administrative functions for the Certificate
System. Administrators maintain the subsystems themselves, so this manual details backend
configuration for certificate profiles, publishing, and issuing certificates and CRLs. It also covers
managing subsystem settings like port numbers, users, and subsystem certificates.
This manual is intended for Certificate System administrators.
•Certificate System Agent's Guide4 describes how agents — users responsible for processing
certificate requests and managing other aspects of certificate management — can use the
Certificate System subsystems web services pages to process certificate requests, key recovery,
OCSP requests and CRLs, and other functions.
This manual is intended for Certificate System agents.
•Managing Smart Cards with the Enterprise Security Client5 explains how to install, configure,
and use the Enterprise Security Client, the user client application for managing smart cards, user
certificates, and user keys.
This manual is intended for Certificate System administrators, agents, privileged users (such as
security officers), and regular end users.
•Using End User Services6 is a quick overview of the end-user services in Certificate System, a
simple way for users to learn how to access Certificate System services.
This manual is intended for regular end users.
•Certificate System Command-Line Tools Guide7 covers the command-line scripts supplied with Red
Hat Certificate System.
This manual is intended for Certificate System administrators.
•Certificate System Migration Guide8 covers version-specific procedures for migrating from older
versions of Certificate System to Red Hat Certificate System 8.0.
This manual is intended for Certificate System administrators.
•Release Notes9 contains important information on new features, fixed bugs, known issues and
workarounds, and other important deployment information for Red Hat Certificate System 8.0.
All of the latest information about Red Hat Certificate System and both current and archived
documentation is available at http://www.redhat.com/docs/manuals/cert-system/.
3. Giving Feedback
If there is any error in this Deployment Guide or there is any way to improve the documentation,
please let us know. Bugs can be filed against the documentation for Red Hat Certificate System
through Bugzilla, http://bugzilla.redhat.com/bugzilla. Make the bug report as specific as possible, so
we can be more effective in correcting any issues:
• Select the Red Hat Certificate System product.

About This Guide
x
• Set the component to Doc - deployment-guide.
• Set the version number to 8.0.
• For errors, give the page number (for the PDF) or URL (for the HTML), and give a succinct
description of the problem, such as incorrect procedure or typo.
For enhancements, put in what information needs to be added and why.
• Give a clear title for the bug. For example, "Incorrect command example for setup
script options" is better than "Bad example".
We appreciate receiving any feedback — requests for new sections, corrections, improvements,
enhancements, even new ways of delivering the documentation or new styles of docs. You are
welcome to contact Red Hat Content Services directly at [email protected].
4. Document History
Revision 8.0.4 September 24, 2009 Ella Deon Lackey
Tech edits to the subsystems overview chapter, per Bugzilla #510596. This completes the tech
reviews for this guide.
Revision 8.0.3 September 19, 2009 Ella Deon Lackey
Further edits to the key length and strength section in chapter 1, per feedback from Bob Relyea.
Revision 8.0.2 September 9, 2009 Ella Deon Lackey
Tech edits to chapter 1, per Bugzilla #510594.
Revision 8.0.1 August 5, 2009 Ella Deon Lackey [email protected]
Tech edits to chapters 3, 4, and 5, per Bugzilla #510598, #510599, #510597. The biggest changes
were to the SELinux feature overview.
Revision 8.0.0 July 22, 2009 Ella Deon Lackey [email protected]
Initial draft for Certificate System 8.0 Deployment Guide.

Chapter 1.
1
Introduction to Public-Key
Cryptography
Public-key cryptography and related standards underlie the security features of many products such
as signed and encrypted email, single sign-on, and Secure Sockets Layer (SSL) communications. This
chapter covers the basic concepts of public-key cryptography.
Internet traffic, which passes information through intermediate computers, can be intercepted by a
third party:
•Eavesdropping. Information remains intact, but its privacy is compromised. For example,
someone could gather credit card numbers, record a sensitive conversation, or intercept classified
information.
•Tampering. Information in transit is changed or replaced and then sent to the recipient. For example,
someone could alter an order for goods or change a person's resume.
•Impersonation. Information passes to a person who poses as the intended recipient. Impersonation
can take two forms:
•Spoofing. A person can pretend to be someone else. For example, a person can pretend to have
the email address [email protected] or a computer can falsely identify itself as a site called
www.example.net.
•Misrepresentation. A person or organization can misrepresent itself. For example, a site called
www.example.net can purport to be an on-line furniture store when it really receives credit-card
payments but never sends any goods.
Public-key cryptography provides protection against Internet-based attacks through:
•Encryption and decryption allow two communicating parties to disguise information they send to
each other. The sender encrypts, or scrambles, information before sending it. The receiver decrypts,
or unscrambles, the information after receiving it. While in transit, the encrypted information is
unintelligible to an intruder.
•Tamper detection allows the recipient of information to verify that it has not been modified in transit.
Any attempts to modify or substitute data are detected.
•Authentication allows the recipient of information to determine its origin by confirming the sender's
identity.
•Nonrepudiation prevents the sender of information from claiming at a later date that the information
was never sent.
1.1. Encryption and Decryption
Encryption is the process of transforming information so it is unintelligible to anyone but the intended
recipient. Decryption is the process of decoding encrypted information. A cryptographic algorithm,
also called a cipher, is a mathematical function used for encryption or decryption. Usually, two related
functions are used, one for encryption and the other for decryption.
With most modern cryptography, the ability to keep encrypted information secret is based not on
the cryptographic algorithm, which is widely known, but on a number called a key that must be used

Chapter 1. Introduction to Public-Key Cryptography
2
with the algorithm to produce an encrypted result or to decrypt previously encrypted information.
Decryption with the correct key is simple. Decryption without the correct key is very difficult, if not
impossible.
1.1.1. Symmetric-Key Encryption
With symmetric-key encryption, the encryption key can be calculated from the decryption key and vice
versa. With most symmetric algorithms, the same key is used for both encryption and decryption, as
shown in Figure 1.1, “Symmetric-Key Encryption”.
Figure 1.1. Symmetric-Key Encryption
Implementations of symmetric-key encryption can be highly efficient, so that users do not experience
any significant time delay as a result of the encryption and decryption. Symmetric-key encryption also
provides a degree of authentication, since information encrypted with one symmetric key cannot be
decrypted with any other symmetric key. Thus, as long as the symmetric key is kept secret by the two
parties using it to encrypt communications, each party can be sure that it is communicating with the
other as long as the decrypted messages continue to make sense.
Symmetric-key encryption is effective only if the symmetric key is kept secret by the two parties
involved. If anyone else discovers the key, it affects both confidentiality and authentication. A person
with an unauthorized symmetric key not only can decrypt messages sent with that key, but can encrypt
new messages and send them as if they came from one of the legitimate parties using the key.
Symmetric-key encryption plays an important role in SSL communication, which is widely used for
authentication, tamper detection, and encryption over TCP/IP networks. SSL also uses techniques of
public-key encryption, which is described in the next section.
1.1.2. Public-Key Encryption
Public-key encryption (also called asymmetric encryption) involves a pair of keys, a public key and
a private key, associated with an entity. Each public key is published, and the corresponding private
key is kept secret. (For more information about the way public keys are published, see Section 1.3,
“Certificates and Authentication”.) Data encrypted with a public key can be decrypted only with the
corresponding private key. Figure 1.2, “Public-Key Encryption” shows a simplified view of the way
public-key encryption works.
Figure 1.2. Public-Key Encryption

Key Length and Encryption Strength
3
The scheme shown in Figure 1.2, “Public-Key Encryption” allows public keys to be freely distributed,
while only authorized people are able to read data encrypted using this key. In general, to send
encrypted data, the data is encrypted with that person's public key, and the person receiving the
encrypted data decrypts it with the corresponding private key.
Compared with symmetric-key encryption, public-key encryption requires more processing and may
not be feasible for encrypting and decrypting large amounts of data. However, it is possible to use
public-key encryption to send a symmetric key, which can then be used to encrypt additional data. This
is the approach used by the SSL/TLS protocols.
The reverse of the scheme shown in Figure 1.2, “Public-Key Encryption” also works: data
encrypted with a private key can be decrypted only with the corresponding public key. This is not
a recommended practice to encrypt sensitive data, however, because it means that anyone with
the public key, which is by definition published, could decrypt the data. Nevertheless, private-key
encryption is useful because it means the private key can be used to sign data with a digital signature,
an important requirement for electronic commerce and other commercial applications of cryptography.
Client software such as Mozilla Firefox can then use the public key to confirm that the message was
signed with the appropriate private key and that it has not been tampered with since being signed.
Section 1.2, “Digital Signatures” illustrates how this confirmation process works.
1.1.3. Key Length and Encryption Strength
Breaking an encryption algorithm is basically finding the key to the access the encrypted data in plain
text. For symmetric algorithms, breaking the algorithm usually means trying to determine the key used
to encrypt the text. For a public key algorithm, breaking the algorithm usually means acquiring the
shared secret information between two recipients.
One method of breaking a symmetric algorithm is to simply try every key within the full algorithm
until the right key is found. For public key algorithms, since half of the key pair is publicly known, the
other half (private key) can be derived using published, though complex, mathematical calculations.
Manually finding the key to break an algorithm is called a brute force attack.
Breaking an algorithm introduces the risk of intercepting, or even impersonating and fraudulently
verifying, private information.
The key strength of an algorithm is determined by finding the fastest method to break the algorithm
and comparing it to a brute force attack.
For symmetric keys, encryption strength is often described in terms of the size or length of the keys
used to perform the encryption: longer keys generally provide stronger encryption. Key length is
measured in bits. For example, 128-bit keys with the RC4 symmetric-key cipher supported by SSL
provide significantly better cryptographic protection than 40-bit keys used with the same cipher. The
128-bit RC4 encryption is 3 x 1026 times stronger than 40-bit RC4 encryption.
An encryption key is considered full strength if the best known attack to break the key is no faster than
a brute force attempt to test every key possibility.
Different types of algorithms — particularly public key algorithms — may require different key lengths
to achieve the same level of encryption strength as a symmetric-key cipher. The RSA cipher can use
only a subset of all possible values for a key of a given length, due to the nature of the mathematical
problem on which it is based. Other ciphers, such as those used for symmetric-key encryption, can
use all possible values for a key of a given length. More possible matching options means more
security.

Chapter 1. Introduction to Public-Key Cryptography
4
Because it is relatively trivial to break an RSA key, an RSA public-key encryption cipher must have a
very long key — at least 1024 bits — to be considered cryptographically strong. On the other hand,
symmetric-key ciphers are reckoned to be equivalently strong using a much shorter key length, as little
as 80 bits for most algorithms.
1.2. Digital Signatures
Tamper detection relies on a mathematical function called a one-way hash (also called a message
digest). A one-way hash is a number of fixed length with the following characteristics:
• The value of the hash is unique for the hashed data. Any change in the data, even deleting or
altering a single character, results in a different value.
• The content of the hashed data cannot be deduced from the hash.
As mentioned in Section 1.1.2, “Public-Key Encryption”, it is possible to use a private key for
encryption and the corresponding public key for decryption. Although not recommended when
encrypting sensitive information, it is a crucial part of digitally signing any data. Instead of encrypting
the data itself, the signing software creates a one-way hash of the data, then uses the private key to
encrypt the hash. The encrypted hash, along with other information such as the hashing algorithm, is
known as a digital signature.
Figure 1.3, “Using a Digital Signature to Validate Data Integrity” illustrates the way a digital signature
can be used to validate the integrity of signed data.
Figure 1.3. Using a Digital Signature to Validate Data Integrity
Figure 1.3, “Using a Digital Signature to Validate Data Integrity” shows two items transferred to
the recipient of some signed data: the original data and the digital signature, which is a one-way
hash of the original data encrypted with the signer's private key. To validate the integrity of the data,
the receiving software first uses the public key to decrypt the hash. It then uses the same hashing
algorithm that generated the original hash to generate a new one-way hash of the same data.
(Information about the hashing algorithm used is sent with the digital signature.) Finally, the receiving
software compares the new hash against the original hash. If the two hashes match, the data has not
changed since it was signed. If they do not match, the data may have been tampered with since it was
signed, or the signature may have been created with a private key that does not correspond to the
public key presented by the signer.
If the two hashes match, the recipient can be certain that the public key used to decrypt the digital
signature corresponds to the private key used to create the digital signature. Confirming the identity of
the signer also requires some way of confirming that the public key belongs to a particular entity. For
more information on authenticating users, see Section 1.3, “Certificates and Authentication”.

Certificates and Authentication
5
A digital signature is similar to a handwritten signature. Once data have been signed, it is difficult
to deny doing so later, assuming the private key has not been compromised. This quality of digital
signatures provides a high degree of nonrepudiation; digital signatures make it difficult for the signer
to deny having signed the data. In some situations, a digital signature is as legally binding as a
handwritten signature.
1.3. Certificates and Authentication
•Section 1.3.1, “A Certificate Identifies Someone or Something”
•Section 1.3.2, “Authentication Confirms an Identity”
•Section 1.3.3, “How Certificates Are Used”
•Section 1.3.4, “Contents of a Certificate”
•Section 1.3.5, “How CA Certificates Establish Trust”
1.3.1. A Certificate Identifies Someone or Something
A certificate is an electronic document used to identify an individual, a server, a company, or other
entity and to associate that identity with a public key. Like a driver's license or passport, a certificate
provides generally recognized proof of a person's identity. Public-key cryptography uses certificates to
address the problem of impersonation.
To get personal ID such as a driver's license, a person has to present some other form of identification
which confirms that the person is who he claims to be. Certificates work much the same way.
Certificate authorities (CAs) validate identities and issue certificates. CAs can be either independent
third parties or organizations running their own certificate-issuing server software, such as Certificate
System. The methods used to validate an identity vary depending on the policies of a given CA for the
type of certificate being requested. Before issuing a certificate, a CA must confirm the user's identity
with its standard verification procedures.
The certificate issued by the CA binds a particular public key to the name of the entity the certificate
identifies, such as the name of an employee or a server. Certificates help prevent the use of fake
public keys for impersonation. Only the public key certified by the certificate will work with the
corresponding private key possessed by the entity identified by the certificate.
In addition to a public key, a certificate always includes the name of the entity it identifies, an expiration
date, the name of the CA that issued the certificate, and a serial number. Most importantly, a certificate
always includes the digital signature of the issuing CA. The CA's digital signature allows the certificate
to serve as a valid credential for users who know and trust the CA but do not know the entity identified
by the certificate.
For more information about the role of CAs, see Section 1.3.5, “How CA Certificates Establish Trust”.
1.3.2. Authentication Confirms an Identity
Authentication is the process of confirming an identity. For network interactions, authentication
involves the identification of one party by another party. There are many ways to use authentication
over networks. Certificates are one of those way.
Network interactions typically take place between a client, such as a web browser, and a server. Client
authentication refers to the identification of a client (the person assumed to be using the software) by

Chapter 1. Introduction to Public-Key Cryptography
6
a server. Server authentication refers to the identification of a server (the organization assumed to be
running the server at the network address) by a client.
Client and server authentication are not the only forms of authentication that certificates support. For
example, the digital signature on an email message, combined with the certificate that identifies the
sender, can authenticate the sender of the message. Similarly, a digital signature on an HTML form,
combined with a certificate that identifies the signer, can provide evidence that the person identified by
that certificate agreed to the contents of the form. In addition to authentication, the digital signature in
both cases ensures a degree of nonrepudiation; a digital signature makes it difficult for the signer to
claim later not to have sent the email or the form.
Client authentication is an essential element of network security within most intranets or extranets.
There are two main forms of client authentication:
•Password-based authentication . Almost all server software permits client authentication by
requiring a recognized name and password before granting access to the server.
•Certificate-based authentication . Client authentication based on certificates is part of the SSL
protocol. The client digitally signs a randomly generated piece of data and sends both the certificate
and the signed data across the network. The server validates the signature and confirms the validity
of the certificate.
1.3.2.1. Password-Based Authentication
Figure 1.4, “Using a Password to Authenticate a Client to a Server” shows the process of
authenticating a user using a username and password. This example assumes the following:
• The user has already trusted the server, either without authentication or on the basis of server
authentication over SSL.
• The user has requested a resource controlled by the server.
• The server requires client authentication before permitting access to the requested resource.
Figure 1.4. Using a Password to Authenticate a Client to a Server
These are the steps in this authentication process:
1. When the server requests authentication from the client, the client displays a dialog box requesting
the username and password for that server.

Authentication Confirms an Identity
7
2. The client sends the name and password across the network, either in plain text or over an
encrypted SSL connection.
3. The server looks up the name and password in its local password database and, if they match,
accepts them as evidence authenticating the user's identity.
4. The server determines whether the identified user is permitted to access the requested resource
and, if so, allows the client to access it.
With this arrangement, the user must supply a new password for each server accessed, and the
administrator must keep track of the name and password for each user.
1.3.2.2. Certificate-Based Authentication
One of the advantages of certificate-based authentication is that it can be used to replace the first
three steps in authentication with a mechanism that allows the user to supply one password, which is
not sent across the network, and allows the administrator to control user authentication centrally. This
is called single sign-on.
Figure 1.5, “Using a Certificate to Authenticate a Client to a Server” shows how client authentication
works using certificates and SSL. To authenticate a user to a server, a client digitally signs a randomly
generated piece of data and sends both the certificate and the signed data across the network. The
server authenticates the user's identity based on the data in the certificate and signed data.
Like Figure 1.4, “Using a Password to Authenticate a Client to a Server”, Figure 1.5, “Using a
Certificate to Authenticate a Client to a Server” assumes that the user has already trusted the server
and requested a resource and that the server has requested client authentication before granting
access to the requested resource.
Figure 1.5. Using a Certificate to Authenticate a Client to a Server
Unlike the authentication process in Figure 1.4, “Using a Password to Authenticate a Client to a
Server”, the authentication process in Figure 1.5, “Using a Certificate to Authenticate a Client to

Chapter 1. Introduction to Public-Key Cryptography
8
a Server” requires SSL. Figure 1.5, “Using a Certificate to Authenticate a Client to a Server” also
assumes that the client has a valid certificate that can be used to identify the client to the server.
Certificate-based authentication is preferred to password-based authentication because it is based on
the user both possessing the private key and knowing the password. However, these two assumptions
are true only if unauthorized personnel have not gained access to the user's machine or password,
the password for the client software's private key database has been set, and the software is set up to
request the password at reasonably frequent intervals.
NOTE
Neither password-based authentication nor certificate-based authentication address
security issues related to physical access to individual machines or passwords. Public-
key cryptography can only verify that a private key used to sign some data corresponds to
the public key in a certificate. It is the user's responsibility to protect a machine's physical
security and to keep the private-key password secret.
These are the authentication steps shown in Figure 1.5, “Using a Certificate to Authenticate a Client to
a Server”:
1. The client software maintains a database of the private keys that correspond to the public
keys published in any certificates issued for that client. The client asks for the password to this
database the first time the client needs to access it during a given session, such as the first
time the user attempts to access an SSL-enabled server that requires certificate-based client
authentication.
After entering this password once, the user does not need to enter it again for the rest of the
session, even when accessing other SSL-enabled servers.
2. The client unlocks the private-key database, retrieves the private key for the user's certificate,
and uses that private key to sign data randomly-generated from input from both the client and the
server. This data and the digital signature are evidence of the private key's validity. The digital
signature can be created only with that private key and can be validated with the corresponding
public key against the signed data, which is unique to the SSL session.
3. The client sends both the user's certificate and the randomly-generated data across the network.
4. The server uses the certificate and the signed data to authenticate the user's identity.
5. The server may perform other authentication tasks, such as checking that the certificate presented
by the client is stored in the user's entry in an LDAP directory. The server then evaluates whether
the identified user is permitted to access the requested resource. This evaluation process can
employ a variety of standard authorization mechanisms, potentially using additional information
in an LDAP directory or company databases. If the result of the evaluation is positive, the server
allows the client to access the requested resource.
Certificates replace the authentication portion of the interaction between the client and the server.
Instead of requiring a user to send passwords across the network continually, single sign-on requires
the user to enter the private-key database password once, without sending it across the network. For
the rest of the session, the client presents the user's certificate to authenticate the user to each new
server it encounters. Existing authorization mechanisms based on the authenticated user identity are
not affected.

How Certificates Are Used
9
1.3.3. How Certificates Are Used
Certificates have a purpose: to establish trust. Their usage varies depending on the kind of trust they
are used to ensure. Some kinds of certificates are used to verify the identity of the presenter; others
are used to verify that an object or item has not been tampered with.
1.3.3.1. Uses for Certificates
•Section 1.3.3.1.1, “SSL”
•Section 1.3.3.1.2, “Signed and Encrypted Email”
•Section 1.3.3.1.3, “Single Sign-on”
•Section 1.3.3.1.4, “Object Signing”
1.3.3.1.1. SSL
The Secure Sockets Layer (SSL) protocol governs server authentication, client authentication, and
encrypted communication between servers and clients. SSL is widely used on the Internet, especially
for interactions that involve exchanging confidential information such as credit card numbers.
SSL requires an SSL server certificate. As part of the initial SSL handshake, the server presents
its certificate to the client to authenticate the server's identity. The authentication uses public-key
encryption and digital signatures to confirm that the server is the server it claims to be. Once the
server has been authenticated, the client and server use symmetric-key encryption, which is very fast,
to encrypt all the information exchanged for the remainder of the session and to detect any tampering.
Servers may be configured to require client authentication as well as server authentication. In this
case, after server authentication is successfully completed, the client must also present its certificate
to the server to authenticate the client's identity before the encrypted SSL session can be established.
For an overview of client authentication over SSL and how it differs from password-based
authentication, see Section 1.3.2, “Authentication Confirms an Identity”.
1.3.3.1.2. Signed and Encrypted Email
Some email programs support digitally signed and encrypted email using a widely accepted protocol
known as Secure Multipurpose Internet Mail Extension (S/MIME). Using S/MIME to sign or encrypt
email messages requires the sender of the message to have an S/MIME certificate.
An email message that includes a digital signature provides some assurance that it was sent by the
person whose name appears in the message header, thus authenticating the sender. If the digital
signature cannot be validated by the email software, the user is alerted.
The digital signature is unique to the message it accompanies. If the message received differs in
any way from the message that was sent, even by adding or deleting a single character, the digital
signature cannot be validated. Therefore, signed email also provides assurance that the email has
not been tampered with. This kind of assurance is known as nonrepudiation, which makes it difficult
for the sender to deny having sent the message. This is important for business communication. For
information about the way digital signatures work, see Section 1.2, “Digital Signatures”.
S/MIME also makes it possible to encrypt email messages, which is important for some business
users. However, using encryption for email requires careful planning. If the recipient of encrypted email

Chapter 1. Introduction to Public-Key Cryptography
10
messages loses the private key and does not have access to a backup copy of the key, the encrypted
messages can never be decrypted.
1.3.3.1.3. Single Sign-on
Network users are frequently required to remember multiple passwords for the various services they
use. For example, a user might have to type a different password to log into the network, collect email,
use directory services, use the corporate calendar program, and access various servers. Multiple
passwords are an ongoing headache for both users and system administrators. Users have difficulty
keeping track of different passwords, tend to choose poor ones, and tend to write them down in
obvious places. Administrators must keep track of a separate password database on each server
and deal with potential security problems related to the fact that passwords are sent over the network
routinely and frequently.
Solving this problem requires some way for a user to log in once, using a single password, and get
authenticated access to all network resources that user is authorized to use-without sending any
passwords over the network. This capability is known as single sign-on.
Both client SSL certificates and S/MIME certificates can play a significant role in a comprehensive
single sign-on solution. For example, one form of single sign-on supported by Red Hat products
relies on SSL client authentication. A user can log in once, using a single password to the local
client's private-key database, and get authenticated access to all SSL-enabled servers that user is
authorized to use-without sending any passwords over the network. This approach simplifies access
for users, because they don't need to enter passwords for each new server. It also simplifies network
management, since administrators can control access by controlling lists of certificate authorities
(CAs) rather than much longer lists of users and passwords.
In addition to using certificates, a complete single-sign on solution must address the need to
interoperate with enterprise systems, such as the underlying operating system, that rely on passwords
or other forms of authentication.
1.3.3.1.4. Object Signing
Many software technologies support a set of tools called object signing. Object signing uses standard
techniques of public-key cryptography to let users get reliable information about code they download in
much the same way they can get reliable information about shrink-wrapped software.
Most important, object signing helps users and network administrators implement decisions about
software distributed over intranets or the Internet-for example, whether to allow Java applets signed by
a given entity to use specific computer capabilities on specific users' machines.
The objects signed with object signing technology can be applets or other Java code, JavaScript
scripts, plug-ins, or any kind of file. The signature is a digital signature. Signed objects and their
signatures are typically stored in a special file called a JAR file.
Software developers and others who wish to sign files using object-signing technology must first obtain
an object-signing certificate.
1.3.3.2. Types of Certificates
The Certificate System is capable of generating different types of certificates for different uses and in
different formats. Planning which certificates are required and planning how to manage them, including
determining what formats are needed and how to plan for renewal, are important to manage both the
PKI and the Certificate System instances.