Certificates

Article
06/29/2009

By Jan De Clercq

Introduction

This paper provides a technical introduction to digital certificates and how you can use them on the Windows platform. The paper starts off with a technical introduction to certificates, which covers topics such as the link between a certificate and the certification authority (CA), the certificate life cycle, certificate storage, and an overview of applications using certificates. In the following parts, we go into more detail as to how you can use certificates to provide secure Web communications, secure mail and code exchanges, and secure network access authentication. This document focuses on the Windows XP, Windows 2000, and Windows Server 2003 releases of the Windows OS.

Introducing Certificates

A public key certificate, usually just called a certificate, is a digitally signed statement that’s commonly used for authentication and to secure information on open networks. A certificate securely binds a public key to the entity that holds the corresponding private key. The issuing CA digitally signs the certificates, and they can be issued for a user, a computer, or a service.

Public key certificates are rooted on asymmetric or public key cryptography. Asymmetric ciphers are built on the unique mathematical relationship that exists between a public and a private key. The public key is the non-secret half of a cryptographic key pair that’s used with a public key algorithm. Public keys are typically used when encrypting a session key, verifying a digital signature, or encrypting data that can be decrypted with the corresponding private key. The private key is the secret half of a cryptographic key pair that’s used with a public key algorithm. Private keys are typically used to decrypt a symmetric session key, digitally sign data, or decrypt data that has been encrypted with the corresponding public key.

Most certificates in common use today are based on the X.509v3 certificate standard. X.509v3 stands for version 3 of the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) recommendation X.509 for certificate syntax and format. An X.509 certificate includes the public key and information about the person or entity to which the certificate is issued, information about the certificate, plus optional information about the CA issuing the certificate.

The entity that receives the certificate is the subject of the certificate. The issuer and signer of the certificate is a CA.

Typically, certificates contain the following information:

The subject’s public key value
The subject’s identifier information, such as the name and email address
The validity period (the length of time that the certificate is considered valid)
Issuer identifier information
The digital signature of the issuer, which attests to the validity of the binding between the subject’s public key and the subject’s identifier information

A digital signature is a means for originators of a message, file, or other digitally encoded information to bind their identity to the information. The process of digitally signing information entails transforming the information, as well as some secret information the sender holds, into a tag called a signature. Digital signatures are used in public key environments, and they provide non-repudiation and integrity services.

A certificate is valid only for the time period specified within it. Every certificate contains Valid From and Valid To dates, which set the boundaries of the validity period. Once a certificate’s validity period has passed, the subject of the now-expired certificate must request a new certificate.

In instances for which it becomes necessary to undo the binding that’s asserted in a certificate, the issuer can revoke a certificate. Each issuer (CA) maintains a certificate revocation list (CRL)—which lists certificates that have been revoked—that programs can use when checking the validity of any given certificate.

One of the main benefits of certificates is that hosts no longer need to maintain a set of passwords for individual subjects who need to be authenticated as a prerequisite to access. Instead, the host merely establishes trust in a certificate issuer.

When a host, such as a secure Web server, designates an issuer as a trusted root authority, the host implicitly trusts the policies that the issuer has used to establish the bindings of certificates it issues. In effect, the host trusts that the issuer has verified the identity of the certificate subject. A host designates an issuer as a trusted root authority by placing the issuer’s self-signed certificate, which contains the issuer’s public key, into the trusted root CA certificate store of the host computer. The certificate store is a permanent storage where a Windows public key infrastructure (PKI) user stores its certificates, CRLs, and certificate trust lists.

Intermediate or subordinate CAs are trusted only if they have a valid certification path from a trusted root CA. A certification path can be defined as an unbroken chain of trust, consisting of certificates from trusted CAs, from a specific certificate to the root CA in a certification hierarchy.

Certificates and Certification Authorities

When a certificate is presented to an entity as a means of identifying the certificate holder (the subject of the certificate), it’s useful only if the entity receiving the certificate trusts the issuer, which is often referred to as the CA.

When you trust a CA, that means you have confidence that the CA has the proper policies in place when evaluating certificate requests and will deny certificates to any entity that doesn’t meet those policies. In addition, you trust that the CA will revoke certificates that should no longer be considered valid by publishing an up-to-date CRL. CRLs are considered valid until they expire. So even if the CA publishes a new CRL with newly revoked certificates listed, all clients that have an old CRL will neither look for, nor retrieve, the new one until the old one expires or is deleted. Clients can use the CA Web pages to manually retrieve the most current CRL, if necessary.

For Windows .NET 2003 users, computers, and services, trust in a CA is established when you have a copy of the root certificate in the trusted root CAs store, as well as when you have a valid certification path, meaning that none of the certificates in the certification path has been revoked or has had its validity period expire. As Figure 1 shows, the certification path includes every certificate issued to each CA in the certification hierarchy, from a subordinate CA to the root CA. For example, for a root CA, the certification path is one certificate: its own self-signed certificate. For a subordinate CA, just below the root CA in the hierarchy, its certification path is two certificates: its own certificate and the root CA certificate.

Figure 1: The Concepts of a Certification Hierarchy: Certification Path, Root CA, Subordinate CA, and Certificate

Figure 1: The Concepts of a Certification Hierarchy: Certification Path, Root CA, Subordinate CA, and Certificate

If your organization is using Active Directory, then trust in your organization’s CAs typically will be established automatically, based on decisions and settings made by the systems administrator.

A related concept with which you should be familiar is certificate store inheritance. If you place a root CA certificate into the computer’s trusted root CAs store or enterprise trust store, then any user of the computer will see that certificate in their own user trusted root CAs store or enterprise trust store, even though the root certificate is actually in the computer’s store. Essentially, users will trust any CA that their computer trusts. Certificate store inheritance doesn’t work the other way around: The computer doesn’t inherit certificates in the user’s trusted root CAs store and enterprise trust store.

If your organization is using the version of Certificate Services installed with the Windows Server 2003 family to run its CA, the CA is one of two types: enterprise or stand-alone. The differences between the two standard types of Windows .NET CAs for certificate users and requesters are summarized below.

An enterprise CA depends on Active Directory being present. You can use the Certificate Request Wizard (which you start from within the Certificates snap-in), as well as CA Web pages, to request certificates from an enterprise CA. An enterprise CA offers different types of certificates to a requester based on the certificates it’s configured to issue as well as the security permissions of the requester. An enterprise CA uses information available in Active Directory to help verify the requester’s identity. An enterprise CA publishes its CRL to Active Directory, as well as to a shared directory.

A stand-alone CA is less automated for a user than an enterprise CA because it doesn’t depend on the use of Active Directory. By default, users can request certificates from a stand-alone CA only by using Web pages. Stand-alone CAs that don’t use Active Directory generally have to request that the certificate requester provide more complete identifying information. A stand-alone CA makes its CRL available from a shared folder, or from Active Directory, if it’s available.

The Certificate Life Cycle

The certificate life cycle includes the following events:

CAs installed and the certificates issued to them
Certificates issued by CAs
Certificates revoked (as necessary)
Certificates renewed or expired
CAs’ certificates renewed or expired

You normally define the certificate life cycle to require periodic renewal of issued certificates. Issued certificates expire at the end of their lifetime and can be renewed in a cycle until revoked or expired, or until an issuing CA is unavailable. Each CA can issue certificates through several certificate renewal cycles until the CA approaches the end of its lifetime. At that time, the CA would either be retired because its keys are no longer useful, or the CA would be renewed with a new key pair.

You should define certificate life cycles that meet your business goals and security requirements. The life cycles you choose depend on various considerations, such as the following:

Length of private keys for CAs and issued certificates. In general, longer keys support longer certificate lifetimes and key lifetimes.
Security provided by the Cryptographic Service Provider (CSP). Typically, a hardware-based CSP is more difficult to compromise than a software-based CSP, and thus can support longer certificate lifetimes and key lifetimes.
Strength of the technology used for cryptographic operations. Some cryptographic technologies provide stronger security as well as support for stronger cryptographic algorithms. You can also use FORTEZZA Crypto Cards to provide stronger security than standard smart cards. Generally, cryptographic technology that’s harder to break supports longer certificate lifetimes.
Security provided for CAs and their private keys. In general, the more physically secure the CA and its private key, the longer the CA lifetime.
Security provided for issued certificates and their private keys. For example, private keys stored on smart cards can be considered more secure than private keys stored as files on local hard disks because smart cards cannot be coerced to export the private key.
Risk of attack. The risk of attack depends on how secure your network is, how valuable the network resources the CA trust chain protects are, and the cost of starting an attack.
How much trust you have for users of certificates. In general, lower trust requires shorter life cycles and shorter key lifetimes. For example, you might trust temporary users less than normal business users, so you might issue temporary users’ certificates with shorter lifetimes; you can also require stricter controls for renewal of temporary users’ certificates.
The amount of administrative effort you’re willing to devote to certificate renewal and CA renewal. For example, to reduce the administrative effort required to renew CAs, you can specify long, safe lifetimes for your certification trust hierarchies.

Give careful consideration to how long you want CAs and issued certificates and keys to be trusted. The longer the certificates and private keys are valid, the greater the risk and potential for a security compromise.

You should define certificate life cycles that realistically balance your business goals with your security requirements. Unrealistically short life cycles can result in excessive administrative efforts required to maintain the life cycles. Unrealistically long life cycles increase the risk of security compromises.

After you define a life cycle, you can change it later by renewing CAs, certificates, or keys at different periods than you originally specified. For example, if you later decide that the lifetime of the root CA places the CA at greater risk of compromise than you originally estimated, you can renew the CA chain and adjust the life cycle as necessary to mitigate risks.

Windows Certificate Storage

Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition store a certificate locally on the computer or device that requested it or, in the case of a user, on the computer or device that the user used to request it. The storage location is called the certificate store. A certificate store often has numerous certificates, possibly issued from a number of a different CAs.

Using the Certificates snap-in, you can display the certificate store for a user, a computer, or a service according to the purpose for which the certificates were issued or by using their logical storage categories. When you display certificates according to their storage categories, you can also choose to display the physical stores, showing the certificate storage hierarchy. (This is recommended for advanced users only.)

If you have the user rights to do so, you can import or export certificates from any of the folders in the certificate store. Additionally, if the private key associated with a certificate is marked as available for export, you can export both into a Public Key Cryptography Standards (PKCS) #12 file.

Windows can also publish certificates to Active Directory. Publishing a certificate in Active Directory enables all users or computers with adequate permissions to retrieve the certificate as needed.

You can display certificates by purpose or by logical store, as Table 1 below shows. Displaying certificates by logical store is the Certificates default. (Note that the list of certificate purpose stores doesn’t include all the possible purpose stores.)

Table 1 Windows Certificate Logical Store and Purpose Containers

Display By	Folder Name	Contents
Logical Store	Personal	Certificates associated with private keys to which you have access. These are the certificates that have been issued to you, or to the computer or service for which you’re managing certificates.
	Trusted Root Certification Authorities	Implicitly trusted CAs. Includes all of the certificates in the Third-Party Root CAs store plus root certificates from your organization and Microsoft. If you’re an administrator and want to add third-party CA certificates to this store for all computers in a Windows .NET Active Directory domain, you can use Group Policy to distribute trusted root certificates to your organization.
	Enterprise Trust	A container for certificate trust lists. A certificate trust list provides a mechanism for trusting self-signed root certificates from other organizations and limiting the purposes for which these certificates are trusted.
	Intermediate Certification Authorities	Certificates issued to subordinate CAs.
	Trusted People	Certificates issued to people or end entities that are explicitly trusted. Most often these are self-signed certificates or certificates explicitly trusted in an application such as Microsoft Outlook.
	Other People	Certificates issued to people or end entities that are implicitly trusted. These certificates must be part of a trusted certification hierarchy. Most often these are cached certificates for services like Encrypting File System (EFS), where certificates are used for creating authorization for decrypting an encrypted file.
	Trusted Publishers	Certificates from CAs that are trusted by Software Restriction policies.
	Disallowed Certificates	These are certificates that you’ve explicitly decided not to trust using either Software Restriction policies or by clicking Do not trust this certificate when the decision is presented to you in mail or a Web browser.
	Third-Party Root Certification Authorities	Trusted root certificates from CAs other than Microsoft and your organization.
	Certificate Enrollment Requests	Pending or rejected certificate requests.
	Active Directory User Object	Certificates associated with your user object and published in Active Directory.
Purpose	Server Authentication	Certificates that server programs use to authenticate themselves to clients.
	Client Authentication	Certificates that client programs use to authenticate themselves to servers.
	Code Signing	Certificates associated with key pairs used to sign active content.
	Secure Email	Certificates associated with key pairs used to sign email messages.
	Encrypting File System	Certificates associated with key pairs that encrypt and decrypt the symmetric key used for encrypting and decrypting data by EFS.
	File Recovery	Certificates associated with key pairs that encrypt and decrypt the symmetric key used for recovering encrypted data by EFS.

When you look at the contents of a certificate store in Logical Store mode, you’ll occasionally see what appear to be two copies of the same certificate in the store. This situation occurs because the same certificate is stored in separate physical stores under a logical store. When the contents of the physical certificates stores are combined into one logical store view, both instances of the same certificate are displayed.

You can verify this by setting the View option to show the physical certificate stores and then noting that the certificate is stored in separate physical stores under the same logical store. You can verify that it’s the same certificate by comparing the serial numbers.

Certificate Usage

Certificates can be issued for a variety of functions, such as Web user authentication, Web server authentication, secure email (using Secure/Multipurpose Internet Mail Extensions—S/MIME), Internet Protocol Security (IPSec), Transport Layer Security (TLS), and code signing. Microsoft has a wide range of applications that support certificates: examples are Outlook and Outlook Express, Internet Information Services (IIS), and Internet Explorer (IE). Table 2 gives an overview of the most common applications for certificates.

Table 2 Applications for Digital Certificates

Application	Uses
Secure email	Secure email clients use certificates to ensure the integrity of email and to encrypt email messages for confidentiality.
Secure Web communications	Web servers can authenticate clients for Web communications (using client certificates) and provide confidential, encrypted Web communications (using server certificates).
Secure Web sites	IIS Web sites can map client certificates to authenticate users to control their rights and permissions for Web site resources.
Digital signing of software files	Code-signing tools use certificates to digitally sign software files to provide proof of file origin and to ensure the integrity of data.
Local network smart card authentication	The Kerberos logon protocol can use certificates and the private key stored on smart cards to authenticate network users when they log on to the network.
Remote access smart card authentication	Servers that are running the Routing and Remote Access service can use certificates and the private key stored on smart cards to authenticate network users when they log on to the network.
IPSec authentication	IPSec can use certificates to authenticate clients for IPSec communications.
EFS recovery agent	Recovery agent certificates enable recovery of EFS files that other users encrypt.

Certificates are also issued from one CA to another in order to establish a certification hierarchy. A CA is an entity responsible for establishing and vouching for the authenticity of public keys belonging to subjects (usually users or computers) or other CAs. Activities of a CA can include binding public keys to distinguished names through signed certificates, managing certificate serial numbers, and certificate revocation. A certification hierarchy is a model of trust for certificates in which certification paths are created when parent-child relationships are established between CAs. The most trusted CA, which is at the top of a certification hierarchy and has a self-signed certificate, is called the root authority.

Because certificates are generally used to establish identity and create trusts for the secure exchange of information, CAs can issue certificates to people, to devices (such as computers), and to services running on computers (such as IPSec).

In circumstances where two entities—such as devices, persons, or applications or services—attempt to establish identity and trust, the fact that both entities trust the same CA allows them to establish a bond of identity and trust between them. Once a certificate subject has presented a certificate that a trusted CA has issued, the entity attempting to establish trust can proceed with an information exchange by storing the certificate subject’s certificate in its own certificate store, and, where applicable, using the public key contained in the certificate to encrypt a session key so that all subsequent communications to the certificate subject are secure.

Certificate Usage in Organizations

Many organizations install their own CAs and issue certificates to internal devices, services, and employees to create a more secure computing environment. Large organizations might have multiple CAs, set up in a hierarchy that leads to a root CA. Thus, an employee of an organization might have a multitude of certificates in their certificate store that a variety of internal CAs have issued, all of whom share a trust connection via the certification path to the root CA.

Certificates Issued to Individual Persons

Individual persons can purchase a certificate from a commercial CA, such as VeriSign, to send personal email messages that are encrypted for security or digitally signed to prove authenticity.

Once you’ve purchased a certificate and you use it to digitally sign an email message, the message recipient can verify that the message hasn’t been altered during transit and that the message came from you—assuming, of course, that the message recipient trusts the CA that issued your certificate.

Using Certificates for Secure Web Communications

Secure Sockets Layer (SSL) and TLS are protocols that are used to provide secure Web communications on the Internet or intranets. TLS is the standardized (on the Internet Engineering Task Force—IETF—level) version of SSL. TLS is also referred to as SSL version 3.1, whereas the most commonly used SSL version is 3.0. Both protocols can provide the following basic security services:

Mutual authentication. Verifies the identities of both the server and client through exchange and validation of their digital certificates.
Communication privacy. Encrypts information exchanged between secure servers and secure clients using a secure channel.
Communication integrity. Verifies the integrity of the contents of messages exchanged between client and server, which ensures that messages haven’t been altered en route.

Sample Scenario

Here’s an example of an environment using SSL/TLS. When you use the Internet for online banking, it’s important to know that your Web browser is communicating directly and securely with your bank’s Web server. Your Web browser must be able to achieve Web server authentication before a safe transaction can occur. That is, the Web server must be able to prove its identity to your Web browser before the transaction can proceed. Microsoft IE uses SSL to encrypt messages and transmit them securely across the Internet, as do most other modern Web browsers and Web servers.

When you connect using an SSL-enabled browser to an online banking Web server that has a server certificate from a CA such as VeriSign, the following events occur:

You access your bank’s secured online banking login Web page by using your Web browser. If you use IE, a locked-padlock icon appears in the lower right corner of the browser status bar to indicate that the browser is connected to a secure Web site. Other browsers depict secure connections in other ways.
The bank’s Web server automatically sends a server certificate to your Web browser.
To authenticate the Web server, your Web browser checks the certificate store on your computer. If the CA that issued the certificate to your bank is trusted, the transaction can proceed, and the bank certificate is stored in your certificate store.
To encrypt all communications with the bank Web server, your Web browser creates a unique session key. Your Web browser encrypts the session key with the bank Web server certificate so that only the bank Web server can read messages that your browser sends. (Some of these messages contain your login name and password and other sensitive information, so this level of security is necessary.)
The secure session is established, and sensitive information can be sent between your Web browser and the bank’s Web server in a secure manner.

SSL Certificates

Two kinds of certificates are used in HTTPS (HTTP over SSL) authentication:

Server certificates. This certificate contains information about the server that allows a client to identify the server before sharing sensitive information.
Client certificates. This certificate contains personal information about the user and identifies the SSL client (the sender) to the server.

Server Certificates

Before an SSL connection can be established for sending messages, the recipient computer requires a server certificate that resides in the Personal store under Certificates (Local Computer) in the Certificates snap-in on the recipient computer.

A server certificate obtained from a CA can be issued to the NetBIOS name or full DNS name of a computer. When HTTPS messages are sent, the destination specified in messages must be identical to the computer name in the recipient’s server certificate.

IIS on the recipient side must send the recipient’s server certificate to the sender for authentication. This server certificate, which contains the signature of the CA, the recipient’s public key, additional information on the recipient, and an expiration date, must be from a CA that the sender trusts. To authenticate the recipient computer, the sender verifies that it trusts the CA and validates the signature in the recipient’s server certificate.

When a sender computer trusts a CA, such as VeriSign or Microsoft Certificate Services, it has a certificate from that CA containing the CA’s signature and public key in the Trusted Root Certification Authorities store under Certificates (Local Computer) in the Certificates snap-in.

Client Certificates

An additional optional security component can be required for SSL sessions if IIS on the recipient side also requests the sender’s client certificate for authentication. Client certificates are also obtained from a trusted CA and are stored in the client’s Personal certificate store. The latter is accessible from the Certificates MMC snap-in on the sending computer.

Client Certificate Mapping

After client certificates are enabled, you can further protect content by creating mappings that relate the information contained in a client certificate to a Windows user account. Mapping is flexible, with one-to-one mapping to map individual client certificates to accounts, or many-to-one mapping to accept a wide range of certificates that meet specific criteria.

When all the conditions imposed by IIS are satisfied, the sender (SSL client) and recipient (SSL server) create and exchange SSL session keys, which are used to encrypt all packets sent over the SSL connection.

Using Certificates for Code Signing

Certificates can also be used to verify the authenticity of software code that you download from the Internet, install from your company intranet, or purchase on CD-ROM and install on your computer. Unsigned software—software that doesn’t have a valid software publisher’s certificate—can pose a risk to your computer and the information you store on your computer.

When software is signed with a valid certificate from a trusted CA, you know that the software code hasn’t been tampered with and can be safely installed on your computer. During software installation, you’re prompted to verify that you trust the software manufacturer (for example, Microsoft Corporation). You might also be offered the option to always trust software content from that particular software manufacturer. If you choose to trust content from the manufacturer, its certificate goes into your certificate store and other software installations of its products can occur with a circumstance of predefined trust. In the circumstance of predefined trust, you can install software from the manufacturer without being prompted to indicate whether it’s trusted; the certificate on your computer states that you trust the manufacturer of the software.

Authenticode Technology

The Microsoft technology for code signing is called Authenticode. Authenticode is client-side software that watches for the downloading of ActiveX controls, .cab files, Java applets, or executable files, and then displays warnings to the user about possible security issues. In addition to these warnings, Authenticode displays certificate information, such as the name included in the digital signature, whether it’s a commercial or personal certificate, and the date the certificate expires. Authenticode presents this information so that users can make a more informed decision before continuing with the download.

Authenticode works by looking for digital certificates (or the lack thereof) in the files being downloaded. The digital certificate is incorporated in a .cab or .ocx file at the time it’s compiled. Part of a certificate is the digital signature—the name of the independent software vendor (ISV). A file containing a digital signature is referred to as signed.

If a piece of software has been digitally signed, IE can verify that the software originated from the named software publisher and that it hasn’t been tampered with. IE displays a verification certificate if the software passes the test.

A valid digital signature, though, doesn’t necessarily mean that the software is without problems. It just means that the software originated from a traceable source that you may choose to trust and that the software hasn’t been tampered with since publication. Likewise, an invalid signature doesn’t prove the software is bad or dangerous, but just alerts users to potential dangers and problems.

When a digital signature fails the verification process, IE reports the failure, reports why the signature is invalid, and queries users to choose whether to proceed with the download.

You can configure IE to take different actions, depending on the status of digital signatures. A signature can be unsigned, signed using valid certificates, or signed using invalid certificates.

For signed or unsigned software, you can configure IE to

Prevent downloading or running the software from a zone
Download and run the software without user intervention from a zone
Query users to make a choice whether to download or run the software from a zone

How you configure IE to respond to certificates depends on various factors, such as the level of trust you have for the security zone where the content originated. If you’re deploying IE in an organization, you’ll also want to consider the level of trust you have for the intended user group and the level of technical expertise the users have. For example, you might trust unsigned software from your intranet, but not trust unsigned active content from the Internet. In that case, you would configure IE to automatically download unsigned active content from the intranet without user intervention and prevent the download of unsigned active content from the Internet.

Using Certificates for Secure Mail

S/MIME is an extension of MIME that supports secure mail. It enables message originators to digitally sign email messages to provide proof of message origin and data integrity. It also enables messages to be transmitted in encrypted format to provide confidential communications.

The fundamental building blocks for establishing a secure email environment include the Windows platform, Exchange, and email clients.

S/MIME Technology

Both S/MIME message encryption and digital signatures are based on encryption technologies. This section explains how the S/MIME encryption and signing processes work.

Message body encryption creates a completely unreadable message body and digital signature. Figure 2 shows how the encryption process generates a one-time symmetric key (also called a session key) that encrypts the message body. The symmetric key is then encrypted with each recipient’s public key so that only the recipient can decrypt the symmetric key. The message is then sent. On the recipient end, the private key is used to decrypt the symmetric key, which is then used to decrypt the message. This process is transparent to the user and is performed with no interaction between clients. Aside from a directory query to obtain the recipient’s public key, there’s no additional interaction with network services. Symmetric encryption is much faster than asymmetric encryption. The reason is because symmetric encryption encrypts the data (message body) in bulk.

Figure 2: S/MIME Message Encryption and Decryption Process

Figure 2 illustrates the message encryption and decryption process. The four main steps detailed in the illustration are as follows:

Message is encrypted with session key.
Session key is encrypted with recipient’s public key.
After encrypted message is received, recipient decrypts session key with the recipient’s private key.
Message is decrypted with session key.

When you add a digital signature to a message, a hash value of the message contents is computed. User keys aren’t used to compute the hash value, and the hash doesn’t identify anyone. The hash is only a small, unique digital fingerprint of the message. This hash value is then encrypted with the sender’s private key, and can be decrypted with the public key found in the sender’s certificate. The recipient decrypts the original hash value with the sender’s public key, which might be sent with the signed message or can be found in the sender’s certificate. You can obtain the sender’s certificate from a directory you trust, such as Active Directory.

Your client verifies signatures. For encrypted messages, it decrypts the message first. The client computes a new hash value based on the text received and compared to the original hash value. If they match, you can trust the content’s integrity and the sender’s identity.

Using Certificates for Network Access Authentication

Administrators use certificates for network access authentication because they provide strong security for authenticating users and computers and eliminate the need for less secure password-based authentication methods. This section describes how Internet Authentication Service (IAS) and virtual private network (VPN) servers use Extensible Authentication Protocol-Transport Layer Security (EAP-TLS), Protected Extensible Authentication Protocol (PEAP), or IPSec to perform certificate-based authentication for many types of network access, including VPN and wireless connections. Additionally, this topic describes certificate enrollment methods to help you determine the best certificate enrollment method for your use.

When discussing authentication, a server is defined as a VPN or IAS server that’s a TLS endpoint. You can configure VPN servers to perform network access authentication without IAS, or you can use IAS for authentication when you have multiple Remote Authentication Dial-In User Service (RADIUS) clients (such as VPN servers and wireless access points) on your network.

Two authentication methods use certificates: EAP-TLS and PEAP. Both methods always use certificates for server authentication. Depending on the authentication type configured with the authentication method, certificates might be used for user authentication and client authentication.

The following are some example certificate deployments for network access authentication:

Remote access VPN connections: Layer 2 Tunneling Protocol (L2TP)/IPSec or Point-to-Point Tunneling Protocol (PPTP) connections between VPN server and VPN client with EAP-TLS used as the authentication method. IPSec uses computer certificates between the client and the server for authentication, and EAP-TLS uses a certificate (from a smart card or the user’s local certificate store) for user authentication. The IAS or VPN server certificate must contain the Server Authentication purpose, and the client computer or user certificate must contain the Client Authentication purpose in the Enhanced Key Usage (EKU) extensions of the certificate.
Router-to-router VPN connections: L2TP/IPSec connections for dedicated or dial-on-demand connections between servers with EAP-TLS as the authentication method. Both servers must have certificates that contain the Server Authentication and Client Authentication purposes in EKU extensions.
IEEE 802.1X wireless or switch clients: PEAP-EAP-MS-CHAPv2 is configured as the authentication method, and the Validate Server Certificate option is enabled on the client computers. The IAS server certificate EKU extensions contain the Server Authentication purpose, and the certificate is used to identify the server to the client. User authentication is accomplished with username and password.
IEEE 802.1X wireless or switch clients: L2TP/IPSec is used, and EAP-TLS with certificates is configured as the authentication method. The IAS server certificate contains the Server Authentication purpose in EKU extensions to identify itself to the client, and the client uses a certificate (from a smart card or the user’s local certificate store) to identify itself to the IAS server. (The wireless access points are configured as RADIUS clients on the IAS server, which is the EAP authenticator.)

Computer Authentication in VPNs

The use of certificates for authentication of VPN connections is the strongest form of authentication available with the Windows Server 2003 family. You must use certificate-based authentication for VPN connections based on L2TP over IPSec (L2TP/IPSec). PPTP connections don’t require certificates, although you can configure PPTP connections to use certificates for computer authentication when you use EAP-TLS as the authentication method.

Sample Scenario

Here’s a short example of the use of certificates in a VPN scenario. When an employee logs in to the organization’s network from home using a VPN, the VPN server can present a server certificate to establish its identity. Because the corporate root authority is trusted and the corporate root CA issued the certificate of the VPN server, the client computer can proceed with the connection and the employee knows their computer is actually connected to their organization’s VPN server.

The VPN server must also be able to authenticate the VPN client before data can be exchanged over the VPN connection. Either computer-level authentication occurs with the exchange of computer certificates or user-level authentication occurs though the use of a Point-to-Point Protocol (PPP) authentication method. For L2TP/IPSec connections, computer certificates are required for both the client and server.

The client computer certificate can serve multiple purposes, most of which are based in authentication, allowing the client to use many organizational resources without needing individual certificates for each resource. For example, the client certificate might allow clients VPN connectivity, as well as access to the company store intranet site, product servers, and the human resources database where employee data is stored.

Using Certificates for L2TP/IPSec Authentication

In L2TP/IPSec, computer authentication is first performed during L2TP/IPSec connection attempts between remote access client and server. When a secure channel is established between the client and the server, the user authentication and authorization attempt proceeds.

Computer authentication by IPSec is performed by using preshared keys or computer certificates. The recommended method of authentication is the use of a PKI and certificates. If certificates are used, a computer certificate is required to establish IPSec trust during the Internet Key Exchange (IKE) negotiation in L2TP/IPSec-based VPN connections.

In order for a VPN server running Windows .NET and a VPN client running Windows 2000 or Windows XP to establish trust for an L2TP/IPSec VPN connection, both computers must have a computer certificate that the same trusted enterprise root CA issued. When both computers have and exchange certificates that the trusted root CA issued during IPSec negotiation, they extend trust to each other, and the security association is made.

When an L2TP/IPSec VPN connection is attempted between VPN client and server, computer authentication fails if the VPN client certificate (from a smart card or the certificate store on the local computer) isn’t configured with the Client Authentication purpose in EKU extensions, and the VPN server certificate isn’t configured with the Server Authentication purpose in EKU extensions. IPSec checks the EKU extensions for the client certificate to determine whether the Client Authentication purpose object identifier is present. When the EKU extension includes the Client Authentication purpose object identifier, IPSec can use the certificate for authentication. Similarly, the client checks the VPN server certificate for the Server Authentication purpose object identifier in EKU extensions.

Although VPN servers that end connections for remote users need a certificate configured with the Server Authentication purpose in EKU extensions only, a VPN servers that’s used as an endpoint for a VPN connection with another VPN server originates (as a client) and ends (as a server) VPN connections. For this reason, the certificate on these servers must contain both the Server Authentication purpose and the Client Authentication purpose in EKU extensions. In addition, due to the way in which automatic certificate selection functions, both purposes (Server Authentication and Client Authentication) must be contained in the same certificate.

Automatic certificate selection can provide IPSec with any certificate in the certificate store that chains to the trusted enterprise root CA, regardless of the purposes contained in the certificate. If two certificates are installed on the server—one that contains the Client Authentication purpose and one that contains the Server Authentication purpose—it’s possible that automatic certificate selection could use the wrong certificate for authentication. For example, the certificate with the Client Authentication purpose might be required, but the certificate provided through automatic certificate selection contains the Server Authentication purpose. In this and similar instances, computer authentication fails.

Certificate-based Authentication and Wireless Clients

For wireless clients (computing devices with wireless network adapters, such as your portable computer or PDA), PEAP with EAP-TLS and smart cards or certificates is the recommended authentication method.

IEEE 802.1X authentication provides authenticated access to 802.11 wireless networks and to wired Ethernet networks. 802.1X provides support for secure EAP types, such as TLS with smart cards or certificates. You can configure 802.1X with EAP-TLS in a variety of ways. If the Validate Server Certificate option is configured on the Windows XP Professional client, the client authenticates the server by using its certificate. Client computer and user authentication can be accomplished by using certificates from the client certificate store or a smart card, providing mutual authentication.

With wireless clients, PEAP-EAP-MS-CHAPv2 can be used as the authentication method. PEAP-EAP-MS-CHAPv2 is a password-based user authentication method that uses TLS with server certificates. During PEAP-EAP-MS-CHAPv2 authentication, the IAS or RADIUS server supplies a certificate to validate its identity to the client (if the Validate Server Certificate option is configured on the Windows XP Professional client). Client computer and user authentication is accomplished with passwords, which eliminates some of the difficulty of deploying certificates to wireless client computers.

802.1X wireless and switch clients can also use PEAP-EAP-TLS, which provides strong security. PEAP-EAP-TLS uses a PKI with certificates used for server authentication and either smart cards or certificates for client computer and user authentication.

Conclusion

Certificates are a key building block for providing strong security services to your users, applications, and IT infrastructure in general. This document illustrated how you can use certificates to provide secure Web communications, secure email and code exchanges, and provide strong network access authentication. The use of certificates in an enterprise environment usually requires the creation of an enterprise PKI—a very time-consuming, but critical process.

For More Information

For more information about on certificates and PKI in general, see the following Microsoft TechNet articles:

How PKI Works: https://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/deploy/dgch_pki_odbg.mspx?mfr=true

Microsoft Windows 2000 PKI Introduction: https://www.microsoft.com/technet/prodtechnol/windows2000serv/evaluate/featfunc/2000pk.mspx