Active Directory Certificate Services - MCTS Guide to Microsoft Windows Server 2008 Active Directory Configuration - page 452

• Digital certificate —A digital document containing identifying information about a
person or system; it's a central component of a PKI. Information in the certificate typi-
cally includes a person's or organization's name or a system's URL and IP address as
well as the holder's public key, an expiration date, and the digital signature of the certi-
fication authority that issued the certificate. The certificate also defines the purpose for
which it's used.
• Digital signature —A numeric string created by a cryptographic algorithm, called a hash
(discussed later in “Installing the AD CS Role”), that's used to validate a message or docu-
ment's authenticity. The signature is verified by an algorithm that uses the stated owner of
the signature's public key to accept or reject the signature as authentic. In a PKI, a certifi-
cation authority's digital signature is used to verify the authenticity of digital certificates
and other documents.
• Certification authority (CA) —An entity that issues and manages digital certificates and
associated public keys and is an integral part of a PKI. Windows Server 2008, with the
Active Directory Certificate Services role installed, can be a CA for a corporate network.
Companies such as VeriSign, Comodo, and GlobalSign are examples of universally trusted
public CAs that issue certificates to people and systems needing to engage in secure com-
munication with the public.

Now that you have a few terms down, take another look at the online banking session dis-
cussed earlier. The following steps are general because an actual secure Web session involves
many variables, but these steps are the basic framework for most secure Web transactions
(see Figure 11-1):
1. The Web browser requests a secure transaction with www.mybank.com using HTTPS.
HTTPS is a secure form of HTTP using the Secure Socket Layer (SSL) or Transport Layer
Security (TLS) protocol, both of which use a PKI.
2. The Web server sends information about the encryption protocols it will use and its certifi-
cate containing its public key.
3. The Web client verifies the certificate and extracts the CA's public key to verify the digital
signature of the issuing CA. If the CA is trusted and the signature is verified, the Web client
sends additional parameters to the server that are encrypted with the server's public key. One
parameter is a session key, which is a shared secret key used to encrypt and decrypt data
transferred during the rest of the communication session.
4. The Web server decrypts the session key with its private key. The session key is now used to
encrypt and decrypt information communicated between the parties.

Request secure transaction
Here's my certificate
Certificate verified; here is the encrypted session key
Data can be transferred securely by using the session key

SSL client

SSL Web server

Figure 11-1

Steps of a secure Web transaction

Notice in the preceding steps that both asymmetric and symmetric encryption are used.
Asymmetric encryption is used in the beginning of the conversation to transmit several parame-
ters, including the session key. After that point, symmetric encryption is used. So why not use
asymmetric encryption throughout the conversation? Doing so requires both client and server to
have a public/private key pair, and assuming every client has one might be unreasonable. Also,
the additional processing asymmetric encryption requires slows communication. Because the
shared secret key (session key) is exchanged by using more secure asymmetric encryption, the
transaction remains highly secure.
The online banking transaction example was used because of its familiarity to most people.
A Windows network with Active Directory Certificate Services installed is typically used to add