Implementing and Administering Security in a Microsoft Windows 2000 Network (Exam 70-214) (MCSE Self-Paced Training Kit Series)
  • Implementing and Administering Security in a Microsoft Windows 2000 Network (Exam 70-214) (MCSE Self-Paced Training Kit Series)
  • Implementing and Administering Security in a Microsoft Windows 2000 Network (Exam 70-214) (MCSE Self-Paced Training Kit Series)

Implementing and Administering Security in a Microsoft Windows 2000 Network (Exam 70-214) (MCSE Self-Paced Training Kit Series)

by Microsoft Corporation, Matthew Strebe
     
 

Learn how to implement security services for a Windows® 2000 network—and prepare for the Microsoft® Certified Professional (MCP) Exam—with this official Microsoft study guide. Work at your own pace through the lessons and hands-on exercises. And use the testing tool on CD to measure what you know and where to focus your studies—before

See more details below

Overview

Learn how to implement security services for a Windows® 2000 network—and prepare for the Microsoft® Certified Professional (MCP) Exam—with this official Microsoft study guide. Work at your own pace through the lessons and hands-on exercises. And use the testing tool on CD to measure what you know and where to focus your studies—before taking the actual exam. As you develop the real-world expertise needed to help manage network security, you’re also preparing for MCP Exam 70-214—an elective for MCSA or MCSE certification.

BUILD THE SKILLS TO:

  • Help secure client computers with file system permissions, Group Policy, and other baseline security measures
  • Configure IPSec and SSL to help protect communication channels for both private and public servers
  • Manage user and network authentication, certificates, and public key encryption
  • Implement security measures for RAS, VPNs, and wireless networks
  • Help protect Microsoft Internet Information Services, Microsoft Exchange Server, and Microsoft SQL Server™ from unauthorized access
  • Maintain software integrity with service packs, security updates, and hot fixes
  • Monitor events, detect network intrusions, and implement prevention and recovery measures

YOUR KIT INCLUDES:

  • Comprehensive self-paced study guide that maps to MCP exam goals and objectives
  • Learn-by-doing exercises for skills you can apply to the job
  • Lesson summaries and review questions, including a complete Q&A summary
  • Testing tool that generates realistic practice exams with automated scoring and explanations for both correct and incorrect answers
  • 120-day evaluation version of Windows 2000 Server
  • Fully searchable eBook version of the study guide

A Note Regarding the CD or DVD

The print version of this book ships with a CD or DVD. For those customers purchasing one of the digital formats in which this book is available, we are pleased to offer the CD/DVD content as a free download via O'Reilly Media's Digital Distribution services. To download this content, please visit O'Reilly's web site, search for the title of this book to find its catalog page, and click on the link below the cover image (Examples, Companion Content, or Practice Files). Note that while we provide as much of the media content as we are able via free download, we are sometimes limited by licensing restrictions. Please direct any questions or concerns to booktech@oreilly.com.

Read More

Product Details

ISBN-13:
9780735618787
Publisher:
Microsoft Press
Publication date:
02/19/2003
Series:
Microsoft Press Training Kit Series
Edition description:
Book with CD
Pages:
704
Product dimensions:
7.46(w) x 9.40(h) x 2.04(d)

Read an Excerpt

Chapter 5.

Certificate Authorities

    • About This Chapter
    • Before You Begin
  • Lesson 1: Understanding Certificates
    • How Encryption Works
    • Secret Key Encryption
    • Lesson Review
  • Lesson 2: Installing Windows 2000 Certificate Services
    • Practice: Establishing a CA Hierarchy
    • Lesson Review
  • Lesson 3: Maintaining Certificate Authorities
    • Practice: Managing CAs
    • Lesson Review


Chapter 5   Certificate Authorities

About This Chapter

This chapter covers certificate authorities and Microsoft Certificate Services. A certificate authority (CA) is a service that accepts and completes or revokes certificate requests. Certificate Services is the Microsoft Windows 2000 tool that allows users to request and obtain encryption certificates for use by numerous security services of Windows 2000, such as smart card logon and e-mail encryption.

Chapter 6, "Managing a Public Key Infrastructure," covers the various ways that certificates can be used specifically, including detailed information about how to request certificates within a domain and outside a domain.:


EXAM TIP:
Be sure you understand the differences between a root CA and a subordinate CA, as well as the difference between an enterprise CA and a stand-alone CA. You should also know how to protect a root CA from hacking attempts.

Before You Begin

To complete this chapter, you must have

  • The dc01.domain.fabrikam.com Windows 2000 Server configured with Active Directory
  • Windows 2000 Server joined to the domain as a member server—Active Directory need not be installed on this server
  • Your original Windows 2000 Server installation CD-ROM

Lesson 1: Understanding Certificates

Before you can begin to use certificates and certificate authorities, you need to understand what certificates are and how they work. This lesson covers the core concepts of certificates, along with encryption, public key encryption, and digital signatures.


After completing this lesson, you will be able to

  • Understand encryption
  • Understand public key encryption
  • Explain the difference between secret keys, public keys, and private keys
  • Understand digital signatures
  • Understand certificates

Estimated lesson time: 20 minutes


How Encryption Works

Encryption is the technological basis behind certificates. While certificates use public key encryption, you must understand basic secret key encryption to understand public key encryption.

Secret Key Encryption

With secret key encryption, also called symmetric key encryption, you use a single key for both encrypting and decrypting data. In traditional secret key encryption systems, a document (called a plain text) is encoded by performing a mathematical operation (called an algorithm) on each character in the text using another number (called the key). For example, you might encrypt a locker combination of 21-17-42 using the algorithm "add" and a key of 21:

   21 + 21 = 42
   17 + 21 = 38
   42 + 21 = 63

The resulting encrypted combination is 42-38-63. Only users who know the algorithm ("add") and the key (21) can decrypt the combination, so you can publicize the encrypted value without fear that anyone will know the true combination.

To decrypt the encrypted text, the reverse function must be used. In this example, "add" was used to encrypt the text, so "subtract" must be used to decrypt the encrypted value. However, the same key is used to perform the decryption. Because the same key value is used for encryption and decryption, secret key algorithms are referred to as symmetrical algorithms.


NOTE:
While this example is simple, all secret key cryptosystems work this way. Only the complexity of the algorithm and the length of the key changes.

There�s a problem with secret key algorithms, though: while you can transmit the encrypted text to any party without fear of it being decrypted, you cannot transmit the key to the party that should decrypt it because, if the key is intercepted during transmission, it can be used to decrypt the text. The inability to transmit a secret key to remote parties makes pure secret key systems inappropriate for transmitting information over public venues like the Internet.

Public Key Encryption

The solution to the key transfer problem was discovered in 1975 by cryptographic researchers. They arrived at a class of mathematical functions that have two different keys: one key to encrypt data, and a different key to decrypt the data. Because they use different keys for encryption and decryption, these algorithms are referred to as asymmetrical algorithms.

You still can�t transmit the decryption key across a public medium because it could be intercepted and used to decrypt the encrypted data. But you can transfer the encryption key across a public medium without compromise because it cannot be used to decrypt the message.

To transmit a message securely, the sender asks the receiver for its encryption key. Because the encryption key can�t be used to decrypt the message, this transfer is safe no matter how it�s sent. The sender then uses the encryption key to encrypt the message, and sends the encrypted text to the receiver. The encrypted text is indecipherable without the decryption key, so this transfer is also safe. Finally, the receiver uses the decryption key to decode the message. The decryption key has never left the receiver�s possession, so it has remained secure throughout the process, as shown in Figure 5.1.

Figure 5.1 The public key exchange process (Image unavailable)

Because the encoding key is sent over a public medium, it is referred to as the public key. The decryption key cannot be revealed, so it is referred to as the private key.


NOTE:
Anyone can encrypt a message to a receiver using an intercepted public key. Public key encryption cannot be used to verify identity because the ability to transmit messages to the receiver is open to anyone. However, once encrypted, the messages cannot be decrypted by anyone but the intended receiver.

Verifying Identities with Digital Signatures

Digital signatures are used to verify identities by encrypting identity information, such as contact information, in such a way that anyone can decrypt the information to verify it, but only the originator can encrypt the information. This is similar to the concept of a traditional signature: anyone can read and verify it, but only the person who developed the signature can sign a valid copy of it.

Digital signatures work by using the concept of public key encryption in reverse. Using the same type of algorithms as public encryption (in many cases, the same algorithms), digital signatures reverse the role of the encryption and decryption keys.

  • In a public key cryptosystem, the encrypting key is the public key and the decrypting key is the private key.
  • In a digital signature system, the encrypting key is the private key and the decrypting key is the public key.

By holding the encryption key privately and publicizing the decryption key, digital signatures allow transmitters to prove that they are undoubtedly the same security principal that encrypted the message using the original encryption key that they hold private.

By appending a digital signature to any plain text document, the receiver of the document can prove the document�s validity by decrypting the digital signature using the decryption key. Of course, that proves only that the digital signature is valid—the remainder of the plain text is unprotected.

To extend this protection to the entire document, the plain text portion of the document is processed through a checksum algorithm, one that can be as simple as adding all the data in the document into a single, large number, and including the resultant number inside the encrypted digital signature. The receiver can verify the entire contents of the document by running the same checksum algorithm on the document and ensuring that its calculated checksum equals the stored checksum inside the encrypted portion of the digital signature.

To summarize, digital signatures can guarantee that the entity that created a certain digital signature key is the same entity that later used it to transmit various documents. But no algorithm can tie the identity of an individual or organization to a specific pair of keys.

Combining Encryption and Certificates

Certificates combine numerous features of public key encryption and digital signatures to create a complete encryption and proof-of-identity solution.

Certificates are data structures that can contain numerous public keys, private keys, secret keys, and digital signatures. Primarily, certificates are used to perform trusted third-party authentication. Trusted third-party authentication allows trust to exist between parties who have no trust relationship, but who both trust a third-party service, called a certificate authority (CA), to process certificate requests. Both parties trust that the certificate authority has verified the identity of the other party.

To create a certificate:

  1. The user generates a pair of encryption keys for use in public key encryption, and optionally another pair for use in digitally signing documents. These keys, along with identity information like the user�s name, taxpayer ID, and e-mail address, are then encoded into a certificate request.
  2. The certificate request is sent to a CA for certification.
  3. The CA applies its own standards for verifying the identity of the requester and either rejects the request, if it�s determined to be invalid, or signs the request.

At this point, the certificate contains the digital signature decryption key of the user, which has been validated by the digital signature of the CA. That signature contains a checksum that validates the user�s digital signature decryption key. This signature key can be used to validate any remaining information in the certificate, such as a separately generated public key that can be used to encrypt documents going to the user who generated the certificate.

Because the transmitter�s digital signature decryption key was decryptable using the CA�s decryption key, the CA has vouched for the identity of the transmitter. The receiver can add the user�s digital signature decryption key to its cache of trusted entities and can use it to validate documents from the user in the future. By this mechanism, trust in the CA has been conferred upon the user whose signature was signed by the CA. When a CA vouches for an entity by signing its digital signature, it is certified.


NOTE:
Signing with a digital signature means that the CA first uses some physical means to verify the user�s identity, such as an administrator identifying the person by sight, then performs a checksum operation on the user�s digital signature, and finally includes that checksum in an additional digital signature that is appended to the certificate.

Certificate Hierarchies

A hierarchy of CA certification can go on indefinitely—any CA can be certified by any other CA, ad infinitum. For example, engineers at Fabrikam can have their certificates signed by the engineering CA at Fabrikam. This means that any two engineers at Fabrikam can trust each other because their identities have been verified by the engineering CA. The engineering CA can in turn be certified by the Fabrikam enterprise CA, which certifies all the subordinate CAs in the enterprise. With this certification, an engineer can present his certificate to any other user at the company, and that receiver can extend trust because they can decrypt the Fabrikam enterprise CA digital signature, which allows them to trust the engineering CA digital signature, which allows them to trust the engineer�s digital signature.

When certificates are used pervasively throughout an enterprise and the CAs that have issued these certificates have the same root CA, the collection of CAs and certificate-based services is referred to as a public key infrastructure (PKI).

If users at Fabrikam need to trust engineers at Microsoft, both companies can have their enterprise root certificates signed by a third party that they both trust, such as VeriSign, Inc. When both companies have their enterprise root certificates signed by the same trusted third party, trust can be extended across corporate boundaries, with the parties secure in the knowledge that all are who they say they are. Figure 5.2 shows a list of some of the CAs that are, by default, trusted by Microsoft Internet Explorer.

Figure 5.2 Certificate authorities in Internet Explorer (Image unavailable)

Root Certification Authorities

Ultimately, users and companies have to trust some authority to act as a root certifying authority. In an ideal world, there would be one single root certifying authority that everyone trusts, but because trust cannot be legislated, this single authority might never exist.

Currently, users and companies choose a certifying authority that they reasonably believe will authenticate the identities of everyone that they certify. There are numerous companies that perform this function for a fee. When two independent organizations need to establish a trust relationship, they must agree on a third party to certify each of them. The other option is to sign each other�s root certificates and agree to trust one another without a third party.

In the United States, the National Institute of Standards and Technology (NIST) is establishing a government-run root certifying authority for purposes of authenticating communications among government agencies. However, the government lags far behind commercial certifying authorities, which are currently available world wide to perform validation services and to provide certificates rooted in their trust hierarchies.


PLANNING:
Anyone can create a root CA by setting up a CA that does not have its certificate signed by another CA. To establish a trust hierarchy, this root CA can sign the certificates of other CAs. It is not necessary to have a CA�s certificates signed by anyone if all parties involved in the certified transaction trust the CA. For most businesses, this means that certificates used entirely within the company, such as to perform logon authentication or encrypt internal e-mail, can be self-certified by the company without relying on external trust providers. In fact, it�s safer, because trust won�t be conferred on anyone who has managed to forge a certificate from a popular certifier.

Certificate Expiration

Certificates have a built-in expiration date included in their identity information that tells recipients when the certificate should no longer be trusted. Expiration is important in digital certificates to prevent factoring, or brute force, attacks against the certificate.

In a brute force or factoring attack, a hacker attempts to determine the private key by signing a document using all possible values until the digital signatures match. With a single computer, this would take an extraordinarily long time, but with the Internet�s ability to pool the resources of millions of computers in a single attack, it would become possible to factor all possible values of an extremely important digital signature—for example, a digital signature used by Microsoft to prove the validity of an update or a root certificate used by a popular CA like VeriSign or Thawte. If the private keys for these digital signatures could be factored, the hackers could forge certificates using their identities and convince any party that trusted the exploited party to trust them. Once these single certificates have been factored, trust in the CA would evaporate. Therefore, root certificates for public certifiers are a likely target for massive factoring efforts by large groups of hackers.

Certificate expiration thwarts this attack by telling certificate receivers to distrust the certificate after a reasonably short period of time, such as two years. Because no factoring attack could take less time using means available before the expiration date, factoring attacks will not succeed in time for them to be useful. If computing methods become available that make decryption easier, future certificates can use shorter expiration times or change the algorithm to a stronger mechanism.

Figure 5.3 shows the Certificate dialog box for a selected certificate. This information includes the certificate�s expiration date.

Figure 5.3 The Certificate dialog box (Image unavailable)

Before a certificate expires, most CA implementations negotiate with the trusted CA to which the certificate applies to receive an updated certificate with new keys (and potentially, specifying a new and stronger encryption algorithm). If the expiration date goes by without a new certificate exchange, both parties must manually establish trust using the same method that was used to establish trust originally.

Certificate Revocation Lists

Brute force attacks are only one possible reason why certificates should be periodically invalidated. The most important reason to invalidate a certificate is that the association between the CA and the certified entity has changed. For example, an employee might change positions within a company or leave the company. This means that the company should no longer certify that employee�s certificates.

It�s also possible that a hacker might have obtained access to a user�s computer and extracted the private keys for that user�s certificate. This would enable the hacker to impersonate the user by signing documents.

In these and many other cases, it�s important for a CA to be able to revoke certificates before their expiration date. The mechanism for revoking specific certificates is simple: the CA publishes a list of certificates that are no longer valid. This list is called a certificate revocation list (CRL). When a certificate is received, the receiver can check the CA�s published CRL to ensure that the certificate has not been revoked. Figure 5.4 shows an example of a CRL.

Figure 5.4 A CA�s certificate revocation list (Image unavailable)

The actual mechanism of publishing a CRL is not standardized. Some PKI systems publish their CRL using HTTP; others publish text files on FTP sites. Microsoft uses two methods: publishing a text file using Internet Information Services (IIS), and publishing the CRL in Active Directory. All Microsoft services use the Active Directory-integrated CRL, while third-party services that are not Active Directory-integrated can use the text file published by IIS to determine whether certificates have been revoked.

Uses for Certificates

Because certificates validate identity and can contain other useful information, they are used primarily in situations where verifying identity is critical, such as logon authentication and computer authentication. For example, Windows 2000 can be configured to use certificates stored on smart cards for log on rather than storing them in the registry and asking users for a user name and password.


MORE INFO:
Chapter 6, "Managing a Public Key Infrastructure," details the issuance and use of encrypted certificates.

Because certificates can contain information in addition to the digital signature keys, they are often used to transport public keys for encryption. The certificate simultaneously validates the identity of the person publishing the public key and delivers the key, so that the receiver can send encrypted texts to the publisher.


IMPORTANT:
By including public keys for encryption inside certificates, both parties to a secure exchange can be certain of each other�s identity. In this way, certificates are used to assure identity in a way that public key encryption alone cannot.

Public key encryption is primarily used to send encrypted e-mail and to establish Secure Sockets Layer (SSL) encrypted Web sessions between a Web browser and a Web server.

Finally, the PKI system uses certificates to validate the identities of CAs to create a hierarchy of trust.

Lesson Review

The following questions are intended to reinforce key information in this lesson. If you are unable to answer a question, review the lesson and try the question again. Answers to the questions can be found in the appendix.

  1. What is the difference between a symmetrical algorithm and an asymmetrical algorithm?
  2. How does a digital signature system differ from a public key cryptosystem?
  3. How does a certificate authority sign a document?
  4. How does a CA certify another CA?

Lesson Summary

  • Secret key encryption allows two parties to exchange documents securely over a public medium by encrypting the documents using an algorithm and a secret key known to both parties. There is no way to transmit the secret key without risking interception, however.
  • Public key encryption solves the key transmission problem by using asymmetrical algorithms that use a public key to encrypt data and a separate private key to decrypt data. The public key can be sent over a public medium because it cannot be used to decrypt the encrypted text.
  • Digital signatures reverse the purpose of the keys used in public key encryption to allow any recipient to decrypt a text that can be encrypted only by the holder of the secret key. As long as the original digital signature public key is trusted, any document sent by the signer can be trusted.
  • Certificates are digital signatures that have themselves been signed by one or more CAs.
  • CAs vouch for the identity of the entities whose certificates they�ve signed. CAs themselves are verified by superior CAs up to a root CA that is self-certified. As long as all participants trust the root CA, the identities of all participants in the trust hierarchy can be trusted.

Lesson 2: Installing Windows 2000 Certificate Services

Windows 2000 creates a public key infrastructure (PKI) through the use of Microsoft Certificate Services, which establishes a CA on a server. In this lesson, you will learn how to install and configure a CA for use in Windows 2000 and for use with third-party PKI products.


After completing this lesson, you will be able to

  • Install Certificate Services for use in a Windows 2000 domain
  • Install Certificate Services for use in third-party PKI systems
  • Install Certificate Services as a root CA
  • Install Certificate Services as a subordinate CA

Estimated lesson time: 20 minutes


Installing Certificate Authorities

To use certificates in your organization, you must either have your own CA or request certificates from an organization that does. Because there is usually a charge associated with each certificate request from a commercial certifier, it is almost always advantageous to generate certificates locally. Furthermore, to use the advanced authentication features like smart card authentication allowed by Windows 2000 enterprise CAs, you must create your own CA.

Creating a CA in Windows 2000 is simple: install Certificate Services and answer a few questions about the type of CA you want to install. Windows 2000 supports two types of CAs:

  • Enterprise CAs are part of an enterprise-wide security infrastructure and require Active Directory.
  • Stand-alone CAs are separate from Active Directory and can issue certificates for extranet or intranet use.
When you install Certificate Services, you must determine which type of CA you intend to install. In addition, you need to determine whether you are installing a root CA, which is the topmost CA in the certification hierarchy, or a subordinate CA, which requires a CA certificate from the root CA. Your final installation decision is about which cryptographic service providers (CSPs) you will use to perform the cryptographic operations for the programming interfaces provided with Certificate Services.

Enterprise CAs

Enterprise CAs are stored in a CA object in Active Directory. Certificates are published in Active Directory, and the CA can be used to generate certificates for specific Windows 2000 purposes such as logging on using smart cards, as well as all purposes for which a stand-alone CA can be used.

Installing an enterprise CA requires the following:

  • The installing user must be a member of the Enterprise Admins group.
  • A fully-functioning, Active Directory�integrated DNS infrastructure must be available.


NOTE:
Although enterprise CA objects are stored in the Active Directory database, the CA need not be installed on a domain controller.

Users requesting a certificate from an enterprise CA must have an Active Directory account. Certificate requests can be made through Active Directory services by applications that require them.


MORE INFO:
Requesting certificates is discussed in Chapter 6, "Managing a Public Key Infrastructure."

Stand-Alone CAs

Installing a stand-alone CA requires administrative privilege on the server. Active Directory is not required, but a stand-alone CA can make use of Active Directory if it is available. Stand-alone CAs are primarily used in situations where Active Directory services are not available, such as for public Web or e-mail services.

Stand-alone CAs can generate certificates for such purposes as exchanging public keys for SSL secure Internet connections and Secure/Multipurpose Internet Mail Extensions (S/MIME) encrypted e-mail. Certificates for stand-alone CAs can be issued and managed through a Web site that is installed during the Certificate Services installation process. This Web site is located on all machines with both Certificate Services and IIS installed. IIS must be installed for this functionality to work.


NOTE:
Replace localhost with the DNS name or IP address of the CA if you are not requesting the certificate from a Web browser on the local machine.

Figure 5.5 The stand-alone CA certificate management Web site

Stand-alone CAs cannot issue certificates that can be used to log on to a Windows 2000 domain.

Root and Subordinate Certificate Authorities

In addition to choosing between the two primary types of CAs, you must also determine whether your CA will be a self-certified root CA or a subordinate CA. Most organizations initially install a root CA and then use that CA to certify all other CAs in the organization. However, you might have multiple root CAs in an organization if you have multiple purposes for which transitive trust is not necessary. For example, you might have an enterprise CA used to create certificates for smart card log on, and a separate root CA for generating S/MIME e-mail encryption certificates for business partners that should not receive the same level of trust as employees.

If you choose to create a subordinate CA, you have to configure the new CA to contact an existing CA to receive its certification. Alternatively, you can finish the installation without certification and later activate the CA by installing a certificate from a parent CA. In Figure 5.6, a certificate is being requested for a subordinate CA during Certificate Services installation.

Figure 5.6 Requesting a subordinate CA certificate (Image unavailable)

Cryptographic Service Providers

The final decision you must make when installing a CA is to determine which CSP you want to use. CSPs determine which algorithms are used to generate keys, encrypt data, and digitally sign documents. The primary difference between them is the strength of their encryption algorithms.

The following list identifies the primary encryption algorithms provided by default CSPs in Windows:

  • RC2 is a secret key algorithm used for block encryption of files stored on disk.
  • RC4 is a secret key algorithm used for stream encryption of Internet connections such as SSL.
  • DES (Data Encryption Standard) is a secret key algorithm used for TCP/IP packet encryption and numerous other uses.
  • SHA-1 is used for public key encryption.
  • MD5 is used for message signing, password encryption, and digital signatures.

The length of the encryption key directly affects how long it will take to factor all possible values. Each bit of additional key length doubles the length of time (or the number of computers) required to factor the key. Currently, 64 bits is the minimum required length to remain secure for the two-year default period of a certificate if the key is being factored by a single powerful machine (defined as an Intel Pentium 4 running at 2 GHz). Currently, 1 million PC-grade computers connected by the Internet could factor an 80-bit key within two years. A 112-bit double-key DES could be factored by 4 billion PCs in the space of 130,000 years. As you can see, increasing the key length by trivial amounts dramatically improves the security of an encrypted key.

Microsoft provides three primary CSPs:

  • Base CSP provides 40-bit RC2, RC4, and 56-bit DES, with 512-bit public keys for signatures and exchanges. Base CSP was originally developed to provide a CSP that could be exported.
  • Strong CSP provides 128-bit RC2, RC4, 112-bit double key DES or 168-bit Triple DES.
  • Enhanced CSP is the same as Strong CSP with improved encryption of keys.

  • WARNING:
    The Base CSP is weak and should not be used unless backward compatibility is more important than security. On standard computers, 40-bit keys can be factored in just a few days. Base CSP is also the default CSP if you do not select Advanced Options when you install Certificate Services.
    NOTE:
    Strong and Enhanced cannot generate 40-bit keys, but they are backward compatible with the Base CSP and can import 40-bit keys.

Windows 2000 is also distributed with third-party CSPs developed by other software developers for use with their security products. When you install Certificate Services, select Advanced Options in the Certification Authority Type page to see the Public And Private Key Pair page (Figure 5.7), in which you can select the CSPs.

Figure 5.7 Assigning a CSP (Image unavailable)

Best Practices

Determining how to create your CA hierarchy is not difficult. The first question is whether to install as a root CA or as a subordinate to a third-party trust provider. The simple answer to this question is that, because you can always configure your root CA to trust a third party CA later, there�s no reason not to install as a root CA.

The next question is whether your root CA should be a Windows 2000 Active Directory�integrated enterprise CA or a stand-alone CA. Because it is easier to create a certificate hierarchy using enterprise CAs that are Active Directory integrated, your root CA should be an enterprise CA. You can always create stand-alone CAs that are subordinate to your enterprise CA, and you can always root your enterprise CA to an external stand-alone CA later if you need to.

Larger enterprises that plan to issue certificates to other business organizations may want to initially begin with a stand-alone root CA and have that CA certify an enterprise root CA. This will allow the organization to create certificates for external parties that are not trusted for enterprise use. By starting with a stand-alone CA, you can easily shut down the CA after it has certified the enterprise CA to ensure that no hacker can forge a request to the root CA to gain wide trust.


TIP:
For maximum security, create a stand-alone root CA that certifies a subordinate enterprise CA that will actually be used for certificate issuance, and then turn off and store the root CA until it is needed to refresh the certificate issuer�s certification or affirm certificate requests from new CAs. This methodology prevents hackers or malicious users from exploiting an administrator�s account to certify their own CAs.

Finally, you need to determine how many CAs you need to install. In organizations with more than one CA, your first CA should be used only to certify other CAs. In general, your CA architecture should be somewhat analogous to your Active Directory structure, so it�s common practice to install the enterprise root CA on the same machine as was used to create the Active Directory forest. Because this CA certifies only other CAs, Certificate Services does not generate much load.

Once you have an enterprise root CA, you can create CAs as necessary to keep up with the demand for certificates. By creating a first tier of CAs in the first domain level below the top of your Active Directory tree, you can determine whether the CA infrastructure is large enough to keep up easily with demand. If it cannot, you can deploy another tier of CAs at the domain level below, and continue expanding your hierarchy until you have enough CAs to keep up with the demand placed upon them.


TIP:
You should always use the Microsoft Enhanced CSP unless you have a specific reason for using another CSP, such as instructions from a third-party cryptographic provider. The Enhanced CSP provides the strongest security of the Microsoft standard CSPs and is backward compatible with both the Base CSP and the Strong CSP.

Practice: Establishing a CA Hierarchy

In this practice, you create a CA hierarchy by first creating the enterprise root CA. You then install IIS so that you can create a stand-alone subordinate CA. For larger enterprises or those with strong security requirements, you would first create a stand-alone CA, use that CA to certify the enterprise CA, and then shut down the stand-alone root CA and continue as shown in this practice.

Exercise 1: Installing Certificate Services for an Enterprise Root CA

In this exercise, you establish an enterprise root CA. To complete this exercise, you must log on to the dc01.domain.Fabrikam.com server as a member of the Enterprise Admins group. The default Administrator account for the domain is a member of this group and can be used to complete this exercise.

To install Certificate Services

  1. Click Start, point to Settings, and click Control Panel.
  2. In Control Panel, double-click Add/Remove Programs.
  3. In the Add/Remove Programs dialog box, click Add/Remove Windows Components. This launches the Windows Components Wizard.
  4. In the Windows Components Wizard, select the check box for Certificate Services. A Microsoft Certificate Services message box appears.
  5. Click Yes to acknowledge the warning that the computer cannot be renamed or have its domain affiliation changed once Certificate Services is installed.
  6. Click Next.

  7. NOTE:
    If you have Terminal Services installed, the Terminal Services Setup page will appear in the wizard. Click Next to accept the default Terminal Services remote administration mode and continue.

  8. The Certificate Authority Type page (Figure 5.8) appears. Select Enterprise Root CA, select Advanced Options, and click Next.
  9. Figure 5.8 Selecting the CA type (Image unavailable)


    NOTE:
    You can use this procedure to create a stand-alone root CA by selecting Stand-alone Root CA in this page. All other options are the same.

  10. The Public And Private Key Pair page (Figure 5.7) appears. Select Microsoft Enhanced Cryptographic Provider as the CSP, and click Next.
  11. In the CA Identifying Information page (Figure 5.9), Type Fabrikam Enterprise Root Certifier in the CA Name box.
  12. Figure 5.9 The CA Identifying Information page (Image unavailable)

  13. Type Fabrikam, Inc. in the Organization box.
  14. Type Redmond in the City box.
  15. Type WA in the State box.
  16. Type US in the Country/Region box.
  17. Type in the E-mail box.
  18. Type Fabrikam Root Certifier in the CA Description box.
  19. Leave the 2 year default duration, and click Next. The Data Storage Location page appears.
  20. Ensure that you have placed the Windows 2000 Server installation CD in your CD-ROM drive. To identify where the CA�s files will be stored, leave the default setting for the Certificate Database and Certificate Database Log, and click Next.
  21. If IIS is running, a message box appears stating that the service must be stopped before proceeding. Click OK to stop IIS and continue.
  22. The service will now generate cryptographic certificates and copy the files necessary for the certificate service from your CD-ROM drive.


    IMPORTANT:
    Make sure you use a storage location that is backed up on a regular basis.

  23. Click Finish. Certificate Services is now installed on your server.
  24. Click Close to close the Add/Remove Programs window.
  25. Close Control Panel.

Exercise 2: Installing Certificate Services for a Stand-alone Subordinate CA

In this exercise, you install a stand-alone CA that is subordinate to the previously installed enterprise CA. For this functionality to work, you must install IIS. You must then install the CA on a member server in the domain.Fabrikam.com domain. The procedure for installing a stand-alone CA is very similar to installing an enterprise CA. If IIS is already installed, you can skip this procedure.

To install a stand-alone subordinate CA

  1. Click Start, point to Settings, and then click Control Panel.
  2. Double-click Add/Remove Programs.
  3. In the Add/Remove Programs window, click Add/Remove Windows Components. This launches the Windows Components Wizard.
  4. In the Windows Components Wizard, select Certificate Services. A Microsoft Certificate Services message box appears.
  5. Click Yes to acknowledge the warning that the computer cannot be renamed or have its domain affiliation changed once Certificate Services is installed.
  6. Click Next.

  7. NOTE:
    If you have Terminal Services installed, the Terminal Services Setup page will appear. Click Next to accept the default Terminal Services remote administration mode and continue.

  8. In the Certificate Authority Type page (Figure 5.8), select Stand-alone Subordinate CA, select Advanced Options, and click Next.
  9. In the Public And Private Key Pair page (Figure 5.7), select Microsoft Enhanced Cryptographic Provider as the CSP, and click Next.
  10. In the CA Identifying Information page (Figure 5.10), type Fabrikam Web SSL and S/MIME Extranet Certifier in the CA Name box.
  11. Figure 5.10 Certificate Identity Information is embedded in the certificate (Image unavailable)

  12. Type Fabrikam, Inc. in the Organization box.
  13. Type Redmond in the City box.
  14. Type WA in the State box.
  15. Type US in the Country/Region box.
  16. Type in the E-mail box.
  17. Type Issues SSL and S/MIME certificates for extranet in the CA Description box, and click Next.
  18. Leave the default certificate database and log settings as they are. The Data Storage Location page appears.
  19. Select Store Configuration Information In A Shared Folder to identify where the CA�s files will be stored.
  20. Type C:\CAConfig as the name of the shared folder, and click Next.
  21. The Root CA selection dialog box appears. Click Browse, select Fabrikam Enterprise Root Certifier, and click OK. The Root CA selection dialog box now appears as shown in Figure 5.11.
  22. Figure 5.11 The Root CA selection dialog box (Image unavailable)

  23. In the Root CA selection dialog box, click Next. A message box appears asking whether you want to stop IIS. Ensure that you have placed the Windows 2000 Server installation CD in your CD-ROM drive. Click OK to stop IIS.
  24. The service generates cryptographic certificates and copies the files necessary for the Certificate Service from your CD-ROM drive.

  25. Click Finish. Certificate Services is now installed on your server.
  26. Click Close to close the Add/Remove Programs dialog box.
  27. Close Control Panel.

Lesson Review

The following questions are intended to reinforce key information in this lesson. If you are unable to answer a question, review the lesson and try the question again. Answers to the questions can be found in the appendix.

  1. What is the strongest standard CSP provided by Microsoft?
  2. How are certificates normally requested from a stand-alone CA?
  3. What is the primary difference between an enterprise CA and a stand-alone CA?
  4. How many certificate authorities can a single server host?

Lesson Summary

  • Stand-alone CAs can be used to generate SSL, S/MIME, and other types of Internet standard certificates. Certificates from stand-alone CAs are requested through the certificate services Web site on the server that hosts the CA.
  • Enterprise CAs have all the functionality of stand-alone CAs and can also generate certificates for use within a Windows 2000 domain for purposes such as logging on using a smart card. Active Directory account holders can request certificates through enterprise CAs.
  • CAs can be either self-certifying, stand-alone CAs, or subordinate to another CA. The top CA in any organization�s CA hierarchy can be configured as a subordinate to a third-party trust provider. To configure a CA as a subordinate CA, you can select the parent CA from the Active Directory list if the server is a member of the domain, or request and install the CA certificate manually.
  • CAs can use different CSPs to change the algorithms and key lengths used for the various certificate encryption functions. The Microsoft Enhanced CSP provides the best quality of encryption for most purposes and is backward compatible with the Base CSP and the Strong CSP.

Lesson 3: Maintaining Certificate Authorities

CAs don�t require much in the way of specific maintenance. The most important administrative tasks in addition to regular backup are the revocation of certificates that should no longer be used and the maintenance of the CRL.


After this lesson, you will be able to

  • Revoke certificates
  • View and publish the CRL
  • Back up the CRL
  • Restore the CRL

Estimated lesson time: 20 minutes


Revoking Certificates

Certificate authorities are designed to issue certificates, but they can also take them back. Certificates are designed to be autonomous—once issued, they contain all the information necessary to validate themselves, so contacting the issuing server is not necessary.

But that doesn�t cover the case in which a certificate must be rescinded. There are numerous reasons why a certificate might be obsolete before it expires:

  • The business activity using the certificate has been discontinued.
  • The association between the organization and the employee represented by the certificate has changed.
  • The administrator suspects that the keys have been compromised.

The certificate protocol does not allow for any intrinsic mechanism to rescind a certificate other then expiration. For this reason, the X.509 protocol includes a procedure for listing certificates by serial number that the administrator wants to rescind. This list is called the certificate revocation list (CRL).

In Windows 2000, the CRL is stored in Active Directory for enterprise CAs and as a text file in a shared directory for stand-alone CAs. Because of the potential size of the CRL, it is not published to the Active Directory database or the CRL text file each time that a certificate is revoked. Rather, the CRL expires and is republished on a periodic basis that can be set by the administrator. The default period is one week, which is sufficient for most purposes.


NOTE:
It is up to the service receiving the certificate to check the issuing CA when the certificate is presented to determine if the CA has been revoked.

When a particularly important revocation occurs or a large number of certificates have been revoked by administrative action, an administrator can choose to immediately publish the CRL before the normal expiration period.

Issuing Certificates

When a user requests a certificate through Active Directory in an enterprise CA, the certificate is issued by the CA by default. This is automatic because the user�s identity is already certified; the user holds a user account in the Active Directory database.

For stand-alone certificates, an administrator must choose to issue each pending certificate request. The administrator must validate the identity of the user and verify that the user issued the request. For example, the administrator might telephone the requestor for verification.

Once the administrator has determined that the request is valid, the administrator can select the certificate in the Pending Requests folder within the CA management console and select Issue. The CA digitally signs the certificate and places it in the Issued Certificates folder so that the user can download it.


NOTE:
The Exchange 2000 Key Management Service (KMS) uses the Windows 2000 Certificate Authority service to automatically generate certificates for Exchange and Outlook users. KMS provides an easy method for recovering lost private keys for users: By right-clicking on the Key Manager and selecting All Tasks, and then clicking Recover Keys, you can select the users who require key recovery. Those users will receive an email from the KMS detailing the steps they need to follow to reinstall their private key. More information about KMS is provided with Exchange Server 2000 and the Microsoft Exchange Server 2000 Resource Kit.

Backing Up and Restoring CAs

As with all crucial enterprise data, certificates must be backed up to avoid losing them in the event of a hardware failure. If the CA database is lost, a new CA will have to be established. Existing issued certificates would not be revocable, and certificates previously on the CRL could no longer be revoked.

Routine CA Database Backups

Although the CA management console contains a facility for backing up and restoring the certificate database, your primary mechanism for backing up the CA should be the Windows 2000 Backup tool or your enterprise backup management software. The Certificate Database will be picked up as a part of any normal server backup process and can be retained along with your traditional full system backup.

As long as you perform regular full system backups, there is no need to use the backup and restore mechanism provided by the CA management console for the purpose of restoring a CA. The backup and restore mechanism provide by the CA management console is primarily used to transfer a CA from one server to another.

Backing Up the Certificate Database Using the CA Management Console

The Certificate Authority management console provides a mechanism for backing up the CA�s certificate as well as the database of issued, pending, and revoked certificates. You can use the CA Backup Wizard to manually back up the CA database, but there is no mechanism for performing automatic periodic backups.


TIP:
Treat the CA backup facility as a secondary, manual backup mechanism for such purposes as transferring an existing CA from one server to another or retaining a permanent record of CA certificates.

The CA Backup Wizard is capable of creating full backups or incremental backups. Making incremental backups of the certificate authority, while supported, is not recommended. The problem with incremental backups is that the entire body of backup files from the last full backup through the most recent incremental backup is required to restore the database. The sum total size of all of these backups is no larger than the size of a current full backup. Figure 5.12 provides an example of the contents of a CA Backup folder after a CA backup operation.

Figure 5.12 A CA Backup folder (Image unavailable)

Incremental backups are used in traditional backups so that many older sets of data can be retained in case a file is lost. But keeping old copies of a CA has no value. Previous backups of a CA do not contain the most recent CRL, so if you had to restore one, you would not know which certificates were no longer revoked. CA databases are not particularly large. Even very large CAs can be backed up to a file that would be less than a few gigabytes in size. Given the problems that incremental backups can cause and the lack of any real benefit to performing them for a CA, you should always run full backups.


TIP:
Consider backing up your CA to flash memory, and keeping a single CA backup on your flash memory device. USB flash memory devices are easy to mount in servers and come in sizes up to 1 GB, which is large enough to back up most CAs. Flash memory is the most reliable form of digital storage available.

Practice: Managing CAs

In this practice, you manage CAs by revoking a certificate, verifying the information in a CRL, updating a CRL, and then changing the CRL publication date. You�ll finish by backing up and then restoring a CA.

Exercise 1: Revoking a Certificate

In this exercise, you revoke a certificate that is being discontinued.

To revoke a certificate

  1. Click Start, point to Programs, Administrative Tools, and choose Certificate Authority. The Certificate Authority console opens.
  2. In the console, expand Certification Authority, Fabrikam Enterprise Root Certifier, and select Issued Certificates.
  3. In the right pane of the console, right-click the certificate with the Issued Common Name of Fabrikam Web SSL And S/MIME Extranet Certifier, select All Tasks, and then choose Revoke Certificate (Figure 5.13).
  4. Figure 5.13 Revoking a certificate in the Certification Authority console (Image unavailable)

  5. The Certificate Revocation dialog box appears, as shown in Figure 5.14. In the Reason Code box, select Cease Of Operation, and click Yes. The certificate will disappear from the Issued Certificates list.
  6. Figure 5.14 Selecting a reason for revoking a certificate (Image unavailable)

  7. Click the Revoked Certificates folder. Note that the certificate now appears in this folder.

Exercise 2: Managing the CRL

This exercise walks you through the procedures for viewing and updating the CRL, and for updating the publication interval.

To view the CRL

  1. Click Start, point to Programs, Administrative Tools, and then click Certificate Authority. The Certificate Authority console opens.
  2. Expand Certification Authority and Fabrikam Enterprise Root Certifier.
  3. Right-click Revoked Certificates and choose Properties. The Revoked Certificates Properties dialog box appears.
  4. Click View Current CRL.
  5. When the Certificate Revocation List dialog box appears, click the Revocation List tab. Verify that the CRL is empty.
  6. Why does the CRL appear to be empty when certificates have been revoked?

  7. Click OK to close the Certificate Revocation List dialog box.
  8. Click OK to close the Revoked Certificates Properties dialog box.

To immediately update the CRL

  1. Right-click Revoked Certificates, point to All Tasks, and choose Publish.
  2. A message box appears informing you that the current CRL is still valid. Click Yes to publish a new CRL.
  3. Repeat the procedure for viewing the CRL to verify that the revoked certificates now appear in it.

To change the CRL publication interval

  1. Click Start, point to Programs, Administrative Tools, and click Certificate Authority.
  2. Expand Certification Authority and Fabrikam Enterprise Root Certifier.
  3. Right-click Revoked Certificates, and select Properties. The Revoked Certificates Properties dialog box appears, as shown in Figure 5.15.
  4. Figure 5.15 The CRL Publication Parameters (Image unavailable)

  5. For the Publication Interval, type 2 in the box, and select Days from the dropdown list box.
  6. Click OK. The CRL will now be published every two days.

Exercise 3: Backing Up a CA

In this exercise, you back up a CA to avoid losing the ability to issue, revoke or renew certificates for the CA.

To back up a CA

  1. Start the Certificate Authority management console.
  2. Right-click Fabrikam Enterprise Root Certifier, point to All Tasks, and choose Backup CA. The Certification Authority Backup Wizard appears.
  3. Click Next. The Items To Back Up page appears, as shown in Figure 5.16.
  4. Figure 5.16 Backing up items using the Certification Authority Backup Wizard (Image unavailable)

  5. In the Items To Backup page, select Private Key And CA Certificate, and select Issued Certificate Log And Pending Certificate Request Queue.
  6. Type C:\WINNT\Temp\CABackup in the Back Up To This Location box, and click Next.
  7. A dialog box appears asking if you want to create the directory. Click OK.
  8. Type the same random secure password in both the Password and Confirm Password boxes. Click Next.
  9. Click Finish. A progress bar will appear indicating backup progress. When it disappears, the backup is complete.
  10. In Windows Explorer, browse to C:\WINNT\Temp\CABackup. Notice that a file called Fabrikam Enterprise Root Certifier.p12 exists, along with a folder called Database, as shown in Figure 5.17. The .p12 file is an export of the CA�s certificate. The files inside the Database folder are Active Directory backup files containing all the certificates for the CA.
  11. Figure 5.17 A CA Backup certificate and database (Image unavailable)

Exercise 4: Restoring a CA

In this exercise, you use the Certification Authority Restore Wizard, which is very similar to the Certification Authority Backup Wizard. Using this wizard, you stop the Certificate Services and restore from the files you previously backed up.

To restore a CA

  1. Start the Certificate Authority management console.
  2. Right-click Fabrikam Enterprise Root Server, point to All Tasks, and click Restore CA.
  3. A message box appears asking if you want to stop Certificate Services. Click OK.
  4. When the Certification Authority Restore Wizard appears, click Next.
  5. In the Items To Restore page, select Private Key And CA Certificate, and select Issued Certificate Log And Pending Certificate Request Queue.
  6. Click Browse and browse to C:\WINNT\Temp\CABackup, select CABackup, and click OK. Click Next.
  7. The Provide Password page appears. Type the password you entered in the previous exercise, and click Next.
  8. Click Finish to restore the database.
  9. You might see a message box asking for additional incremental files. Click No to indicate that there are no additional files.
  10. You might see a message box asking if you would like to start Certificate Services. If so, click Yes. Otherwise, right-click Fabrikam Enterprise Root Certifier, select All Tasks, and click Start Service.

Lesson Review

The following questions are intended to reinforce key information in this lesson. If you are unable to answer a question, review the lesson and try the question again. Answers to the questions can be found in the appendix.

  1. What are the two mechanisms through which a certificate can be rendered invalid?
  2. What are the two methods by which the CRL is published in Windows 2000?
  3. What is the best way to back up a CA?

Lesson Summary

  • CAs require very little administration. Outside of normal server backup, administrators can choose to independently back up the CA�s certificate and the certificate database using the Certificate Authority management console.
  • Certificates can be revoked by the CA that issued them at any time. Reasons for revoking a certificate include no longer offering the service for which the certificate is required, suspected compromise of the certificate�s private keys, or a change in relationship between the issuing organization and the certified entity.
  • Certificates that have been revoked are listed in the server�s CRL, the list of certificate serial numbers that have been revoked. The CRL can be published by any network mechanism. In Windows 2000, the CRL is published in the Active Directory database or in a text file within a shared directory.
  • All certificate management functions are performed through the Certificate Authority management console.

Read More

Customer Reviews

Average Review:

Write a Review

and post it to your social network

     

Most Helpful Customer Reviews

See all customer reviews >