DESIGNING A PUBLIC KEY INFRASTRUCTURE

1. Chapter 9 DESIGNING A PUBLIC KEY INFRASTRUCTURE

2. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE OVERVIEW • Describe the elements and functions of a public key infrastructure (PKI). • Understand the functions of certificates and certification authorities (CAs). • Describe the structure of a CA hierarchy. • List the differences between enterprise and stand-alone CAs. • Install and configure a CA. • Understand the certificate enrollment process. • Publish certificate revocation lists.

3. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE INTRODUCING THE PUBLIC KEY INFRASTRUCTURE • A public key infrastructure is a collection of software components and operational policies that govern the distribution and use of public and private keys using digital certificates.

4. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE UNDERSTANDING SECRET KEY ENCRYPTION • Encryption is a system in which one character is substituted for another. • Encryption on a data network typically uses a form of public key encryption. • In public key encryption, every user has two keys, a public key and a private key. • Data encrypted with the public key can be decrypted using the private key, and vice versa.

5. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE ENCRYPTING DATA

6. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE DIGITALLY SIGNING DATA • Digital signing refers to the process of using your private key to encrypt all or part of a piece of data. • Digitally signed data, encrypted with your private key, can only be decrypted with your public key. • Digital signing prevents other users from impersonating you by sending data in your name.

7. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE VERIFYING DATA • Hash values, or checksums, are used to guarantee the data has not been modified since the checksum was created. • The receiving system verifies the checksum to determine whether or not the data has been altered.

8. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE USING CERTIFICATES • Digital certificates are documents that verifiably associate a public key with a particular person or organization. • Certificates are obtained from an administrative entity called a certification authority (CA). • The CA issues a public key and a private key as a matched pair. The private key is stored on the user’s computer, and the public key is issued as part of a certificate.

9. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE UNDERSTANDING CERTIFICATE CONTENTS • Digital certificates contain the public key for a particular entity plus information about the entity. • Almost all certificates conform to the ITU-T standard X.509 (03/00), “The Directory: Public-Key and Attribute Certificate Frameworks.” • Standardization of certificate format is important, otherwise exchange of certifications and keys would be difficult.

10. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE DOWNLOADING CERTIFICATES FROM THE INTERNET

11. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE USING INTERNAL AND EXTERNAL CAs • For a certificate to be useful, it must be issued by an authority that both parties trust to verify each other’s identities. • Within an organization, you can use Windows Server 2003 Certificate Services, a service that enables the computer to function as a CA. • When communicating with external entities, a trusted third-party certificate issuer can be used.

12. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE UNDERSTANDING PKI FUNCTIONS • Having a PKI in place provides additional security on a Windows Server 2003 network. • Using the management tools provided, administrators can publish, use, renew, and revoke certificates. They can also enroll clients in the PKI. • Users can use certificates to provide additional security.

13. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE DESIGNING A PUBLIC KEY INFRASTRUCTURE • Planning a PKI typically consists of the following basic steps: • Defining certificate requirements • Creating a CA infrastructure • Configuring certificates

14. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE DEFINING CERTIFICATE REQUIREMENTS • When designing a PKI, you must determine the client’s security needs and how certificates can help provide that security. • You must determine which users, computers, services, and applications will use certificates, and what kinds of certificates will be needed. • Best practice dictates that a small set of security definitions are created, and then applied to users and computers as needed.

15. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE CREATING A CA INFRASTRUCTURE • Planning the creation of certification authorities requires an understanding of CA hierarchy. • A CA hierarchy refers to a structure in which each CA is validated by a CA at a higher level. • The root CA is considered the ultimate authorityfor the organization.

16. A d v a n t a g e s D i s a d v a n t a g e s A d v a n t a g e s D i s a d v a n t a g e s I n t e r n a l C A I n t e r n a l C A Direct control over certificates Increased certificate management § § ove r head No per-certificate fees § Longer, more complex deployment § Can be integrated into Active § Dire c tory Organization must accept liability § for PKI failures Allows configuring and expanding § PKI for minimal cost Limited trust by external customers § E x t e r n a l C A Instills customers with greater High cost per certificate E x t e r n a l C A § § conf i dence in the organization No auto-enrollment possible § Provider liable for PKI failures § Less flexibility in configuring and § Expertise in the technical and legal ma n aging certificates § ramifications of certificate use Limited integration with the § Reduced management overhead organiz a tion’s infrastructure § Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE WHEN TO USE INTERNAL AND EXTERNAL CAs

17. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE HOW MANY CAs? • A single CA running on Windows Server 2003 can support as many as 35 million certificates and can issue two million or more a day depending on the system specifications. • System performance is a factor in determining how many CAs should be implemented. Issuing certificates can be disk and processor intensive. • Multiple CAs can be implemented for fault-tolerant or load-distribution reasons.

18. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE CREATING A CA HIERARCHY

19. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE UNDERSTANDING WINDOWS SERVER 2003 CA TYPES • Enterprise CAs: • Are integrated into Active Directory • Can only be used by Active Directory clients • Stand-Alone CAs: • Do not automatically respond to certificate enrollment requests • Are intended for users outside the enterprise that submit requests for certificates

20. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE CONFIGURING CERTIFICATES • Criteria to consider when configuring certificates include: • Certificate type • Encryption key length and algorithm • Certificate lifetime • Renewal policies

21. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE USING CERTIFICATE TEMPLATES • Certificate templates determine what attributes are available or required for a given type of certificate. • Windows Server 2003 includes a large number of certificate templates designed to satisfy most certificate requirements.

22. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE INSTALLING CERTIFICATE SERVICES • Install through Add/Remove Windows Components in Control Panel. • Can be installed on either a domain controller or a member server running Windows Server 2003. • When installing an enterprise CA, a DNS server must be available that supports service location (SRV) resource records. • During installation, the desired CSP can be selected.

23. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE PROTECTING A CA • CAs should be considered critical network services. • Protection measures and plans should include: • Physical protection • Key management • Restoration

24. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE CONFIGURING A CA

25. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE THE GENERAL TAB

26. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE THE POLICY MODULE TAB

27. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE THE EXIT MODULE TAB

28. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE THE EXTENSIONS TAB

29. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE THE STORAGE TAB

30. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE THE CERTIFICATE MANAGERSRESTRICTIONS TAB

31. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE THE AUDITING TAB

32. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE THE RECOVERY AGENTS TAB

33. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE THE SECURITY TAB

34. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE BACKING UP AND RESTORING A CA • The Certificate Services database is always open, making it difficult to back up. • Special software can be used to back up the files, or the Certification Authority console can provide a backup feature. • The backup CA function of the Certification Authority console causes the Certificate Services database to be momentarily closed while a copy of the database is made.

35. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE UNDERSTANDING CERTIFICATE ENROLLMENT AND RENEWAL • Auto-enrollment The CA determines whether or not a certificate request is valid and issues or denies a certificate accordingly. • Manual enrollment An administrator must monitor the CA for incoming requests and determine if a certificate should be issued on a request-by-request basis.

36. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE USING AUTO-ENROLLMENT

37. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE USING MANUAL ENROLLMENT • When using stand-alone CAs, the administrator must grant or deny requests for certificates. • Incoming certificate enrollment requests appear in the Pending Requests folder. • The administrator must check the folder on a regular basis.

38. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE MANUALLY REQUESTING CERTIFICATES • Applications can request certificates and receive them in the background. • Alternately, users can explicitly request certificates.

39. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE USING THE CERTIFICATES SNAP-IN

40. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE USING WEB ENROLLMENT

41. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE REVOKING CERTIFICATES

42. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE CHAPTER SUMMARY • Public key encryption uses two keys, a public key and a private key. Data encrypted with the public key can only be decrypted using the private key. Data encrypted using the private key can only be decrypted with the public key. • A PKI is a collection of software components and operational policies that governs the distribution and use of public and private keys. • Certificates are issued by a CA. You can run your own CA using Windows Server 2003 or obtain your certificates from a third-party commercial CA.

43. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE CHAPTER SUMMARY (continued) • The first step in planning a PKI is to review the security enhancements the certificates can provide and determine which of your organization’s security requirements you can satisfy with the certificates. • When running multiple CAs in an enterprise, you configure them in a hierarchy. • The configuration parameters of certificates themselves include the certificate type, the encryption algorithm and key length the certificates use, the certificate’s lifetime, and the renewal policies.

44. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE CHAPTER SUMMARY (continued) • Only enterprise CAs can use auto-enrollment, in which clients send certificate requests to a CAand the CA automatically issues or denies the certificate. • For a client to receive certificates using auto-enrollment, it must have permission to use the certificate template for the type of certificate it is requesting.

45. Chapter 9: DESIGNING A PUBLIC KEY INFRASTRUCTURE CHAPTER SUMMARY (continued) • Stand-alone CAs do not use certificates or auto-enrollment. Certificate requests are stored in a queue on the CA until an administrator approves or denies them. • CAs publish CRLs at regular intervals to inform authenticating computers of certificates they should no longer honor.