Page 1 Administrator’s Guide Red Hat Certificate System Version 7.1 September 2005...
Page 2 All other trademarks referenced herein are the property of their respective owners. The GPG fingerprint of the security@redhat.com key is: CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E...
Page 3: Table Of Contents
Contents About This Guide ............... 23 Who Should Read This Guide .
Page 4 Java SDK Extension Mechanism for Customization ......... . 36 How Certificate System Works .
Page 5 Chapter 3 Certificate Manager ............77 Certificate Manager Deployment Considerations .
Page 6 Importing Cross-Pair Certificates ............126 Publishing Cross-Pair Certificates .
Page 7 OCSP Responses ..............159 CS OCSP Services .
Page 8 Tokens ................205 Internal Database .
Page 9 Configuring Logs in the CS.cfg File ........... . . 263 Monitoring Logs .
Page 10 Storing a User’s Certificate ............319 Setting up Agents Using the Automated Process .
Page 11 certServer.ee.crl ..............348 certServer.ee.profile .
Page 12 certServer.ra.requests ..............366 certServer.registry.configuration .
Page 13 Dual Key Generation Input ............426 Key Generation Input .
Page 14 Chapter 12 Policies ..............461 Introduction to Policy .
Page 15 PolicyMappingsExt ..............532 PrivateKeyUsagePeriodExt .
Page 16 Chapter 15 Revocation and CRLs ............569 Revocation .
Page 17 Publisher Plug-in Module Reference ........... . . 606 Mappers .
Page 18 Appendix A Common Criteria Environment: Security Requirements ......677 ..........Security Requirements for the IT Environment 677 .
Page 19 SSL Client Authentication with the Internal Database ........699 CS Administrative Console .
Page 20 Appendix F Certificate Download Specification ......... . . 721 Data Formats .
Page 21 A Certificate Identifies Someone or Something ..........774 Authentication Confirms an Identity .
Page 22 Red Hat Certificate System Administrator’s Guide • September 2005...
Page 23: About This Guide
About This Guide This Administrator’s Guide explains how to install, configure, and maintain Red Hat Certificate System (CS), and use it for issuing and managing certificates to various end entities, such as web browsers (users), servers, Virtual Private Network (VPN) clients, and Cisco™...
Page 24: What's In This Guide
What’s in This Guide Public keys, private keys, and symmetric keys ❍ Significance of key lengths ❍ Digital signatures ❍ Digital certificates, including various types of digital certificates ❍ The role of digital certificates in a public-key infrastructure (PKI) ❍ Certificate hierarchies ❍...
Page 25 What’s in This Guide Chapter 5, “OCSP Provides information about installing an Online Certificate Responder” Status Manager, step-by-step instructions for installing an Online Certificate Status Manager, and an overview of the configuration options for an Online Certificate Status Manager. Chapter 6, “Data Provides information about installing a Data Recovery Recovery Manager”...
Page 26: Conventions Used In This Guide
Conventions Used in This Guide Appendix A, “Common Provides security requirements for running CS in the Criteria Environment: Common Criteria Environment. Security Requirements” Appendix B, “Common Provides details on setting up CS in the Common Criteria Criteria Environment: Environment. Setup and Operations” Appendix C, Provides information about running CS in the Common “Understanding the...
Page 27 Conventions Used in This Guide Italic Italic type is used for emphasis, book titles, and glossary terms. Example: This control depends on the access permissions the super administrator has set up for you. Boldface Boldface type is used for various UI components such as captions and field names, and the terminology explained in the glossary.
Page 28: Documentation
Agent Services pages, click any help button. For the latest information about Certificate System, including current release notes, complete product documentation, technical notes, and deployment information, check this site: http://www.redhat.com/docs/manuals/cert-system/ Red Hat Certificate System Administrator’s Guide • September 2005...
Page 29: Chapter 1 Overview
Chapter 1 Overview This chapter provides an overview of Red Hat Certificate System (CS), a highly configurable set of software components and tools for creating, deploying, and managing certificates. Based on open standards for certificate management, Certificate System provides a complete, customizable, robust, scalable, and high-performance certificate management solution for your public-key infrastructure (PKI), extranets and intranets.
Page 30: Certificate Manager Flexibility And Scalability
Features • The Certificate Manager is the subsystem that provides Certificate Authority functionality for issuing, renewing, revoking, and publishing certificates and creating and publishing CRLs. See Chapter 3, “Certificate Manager” for complete details. • The Registration Manager is an optional subsystem that provides Registration Authority functionality.
Page 31: Interfaces
Features Root or Subordinate CA CS can function as a root CA; in this case, the server signs its own CA signing certificate as well as other CA signing certificates, enabling you to create your own CA hierarchy. You can also install the server to function as a subordinate CA; in this case, the server gets its CA signing key signed by another CA in an existing CA hierarchy.
Page 32: Auditing
Features Supports Signing of Logs CS allows you to sign log files digitally before archiving them or distributing them for audit purposes. This feature enables you to check whether the log files were tampered with after being signed. See “Signing Log Files,” on page 266 for complete details. Auditing CS can be configured to produce signed audit logs that record auditable events from the subsystem.
Page 33: Certificate Issuance
Features allowing a request signed by an agent to be automatically processed. A set of prebuilt authentication plug-ins are available to enable and configure. You can create additional Authentication plug-in modules using the CS SDK. See Chapter 10, “Authentication” for complete details.
Page 34: Policy
Features Policy The policy feature of CS allows you to set policies about certificate issuance, renewal, and revocation. You set policies that either define what is possible, for example the possible values of for the expiration date, and extensions that are used in a particular type of certificate.
Page 35: Jobs
Features Jobs The Jobs feature allows you to set up automated jobs that run at defined intervals.The jobs framework comes with default jobs that you can enable and configure. You can create additional jobs plug-in modules using the CS SDK. See Chapter 14, “Automated Jobs” for complete details Dual Key Pairs CS supports certificate generation for dual key pairs—separate key pairs for signing and...
Page 36: Java Sdk Extension Mechanism For Customization
Features • Supports signature key lengths of up to 1024 bits (DSA) and 4096 (RSA) on both hardware and software tokens. • Supports multiple message formats, such as KEYGEN/SPAC, CRMF/CMMF, CRS/CEP/SCEP, and PKCS #10 and CMC for certificate requests. All requests are delivered to CS over HTTP or HTTPS;...
Page 37: How Certificate System Works
How Certificate System Works How Certificate System Works CS allows you to manage certificates by providing a flexible, scalable system for issuing, renewing, and publishing certificates; creating and publishing CRLs; and providing key storage and retrieval capabilities. CS Basics CS is installed on each host running a CS subsystem. The subsystems that will be run on that host are then installed with a default configuration.
Page 38 How Certificate System Works • Administrative Interface—The administrative interface is a java application, called Red Hat Console, that provides a GUI interface for performing administrative tasks and configuring plug-in modules and instances of plug-in modules. The area of Red Hat Console that is specific to CS tasks is called the CS console.
Page 39 How Certificate System Works You can customize audit logs to include the information you want to include in the audit log. See “Signed Audit Log,” on page 268 for complete details. Internal Database Each subsystem has its own internal database where it stores such things as issued certificates, certificate requests, and so on.
Page 40: About The Certificate Manager
How Certificate System Works Jobs The Jobs feature allows you to set up automated jobs that run at defined intervals. See Chapter 14, “Automated Jobs” for complete details. About the Certificate Manager The Certificate Manager subsystem provides the capability of a Certificate Authority. It can issue, renew, revoke, and publish certificates as well as compiling and publishing CRLs.
Page 41: How The Certificate Manager Works
How Certificate System Works Types of Certificates That are Managed CS can issue and manage certificates for Certificate Authority signing certificates, cross-signed pair certificates (FBCA), SSL server certificates, router certificates, VPN client certificates, and end user certificates. Revocation and CRLs CS provides the framework for revoking certificates which can either be initiated by an agent or by the end user themselves.
Page 42 How Certificate System Works Authentication Methods CS provides authentication plug-ins that allow you to set up automated enrollment and configure the particular method(s) you set up; it provides agent-approved enrollment, where an agent must approve the request by default. Each end-entity form is associated with a particular authentication method, either one of the automated methods or the agent-approved method.
Page 43 How Certificate System Works Publishing of Certificates Certificates can be published to a file, an LDAP directory, or OCSP responder. You set up the publishing feature and set up rules that determine which certificates are published using which method, and where exactly they are published. The publishing system is flexible allowing you many options in configuring it.
Page 44: About The Registration Manager
How Certificate System Works CRLs Whenever a certificate is revoked, any CRLs that are set up are edited and updated in the internal database. It is also published to a file, an LDAP directory, or an OSCP responder, if you have set up these services. You can configure the Certificate Manager to issue CRLs, and also define CRL Issuing Points that define which certificates go into each CRL, such as CA signing certificates, or for a subset of a type of certificates, such as those certificates issued to west coast employees.
Page 45 How Certificate System Works Accepting Enrollment Requests Similar to the Certificate Manager, the Registration Manager contains an end-entity interface with various forms associated with various types of certificates and various types of users. This interface is fully customizable allowing you to only show the forms that are pertinent to your users, change the look and feel of the forms, or add and delete fields.
Page 46 How Certificate System Works Certificate Profiles are a new feature that bind an authentication method and certificate type to a set of constraints and certificate content and values for that content. It allows you to configure a single module for a type of certificate that binds to an authentication method and sets constraints for the certificate issued as well as defines the content and values for that content in the certificate.
Page 47: Data Recovery Manager
How Certificate System Works Storing Certificate Requests and Certificates When it issues a certificate, the Certificate Manager stores both the certificate and the certificate request in it internal database. See “The Internal Database,” on page 281 for complete details. Renewing Certificates A Registration Manager allows end-entities to renew certificates if the policies are set up to allow for renewal.
Page 48: Online Certificate Status Manager
Deployment Scenarios Key Archival If you have set up a Data Recovery Manager as part of your PKI, the private encryption key for an end-entity is requested and stored when the enrollment request is made. Key Retrieval If you have set up a Data Recovery Manager up as part of your PKI, you can retrieve the private encryption keys of your users to decrypt messages or other documents that have been encrypted with the private encryption key.
Page 49: Certificate Manager And Registration Manager
Deployment Scenarios Certificate Manager Figure 1-1 Single root Figure 1-1 shows the relationships among a single Certificate Manager, end entities, and a publishing directory. The Certificate Manager can publish both end-entity certificates and CRLs to a directory. Certificate Manager and Registration Manager Figure 1-2 shows a Registration Manager and its Certificate Manager in separate instances on separate machines.
Page 50 Deployment Scenarios Certificate Manager Figure 1-2 and Registration Manager in different instances Many organizations need to separate the role of the Registration Manager from the role of the Certificate Manager. This separation can be useful, for example, if different groups of end entities are subject to different authentication policies or work in different geographic locations.
Page 51: Certificate Manager And Data Recovery Manager
Deployment Scenarios In many organizations, it may be desirable to deploy multiple Registration Managers that all communicate with a single Certificate Manager. Each separate Registration Manager, for example, might handle all end-entity interactions in a particular geographic area or within an organizational group.
Page 52 Deployment Scenarios Figure 1-3 Certificate Manager and Data Recovery Manager in different instances The Data Recovery Manager is intended for archival and recovery of private encryption keys only. Therefore end entities must be using either a browser that supports dual-key generation or a browser that is using Red Hat Personal Security Manager, which supports dual keys.
Page 53: Certificate Manager, Data Recovery Manager, And Registration Manager
Deployment Scenarios Certificate Manager, Data Recovery Manager, and Registration Manager The three CS subsystems can be deployed in many different relationships. Figure 1-4 illustrates some of the issues involved in deploying all three subsystems by showing the relationships among a single Certificate Manager, a single Registration Manager, and a single Data Recovery Manager, each installed in a different CS instance on a different machine.
Page 54: Cloned Certificate Manager
Deployment Scenarios The Registration Manager handles all end-entity interactions and communicates with the Certificate Manager and the Data Recovery Manager over HTTPS. The Registration Manager is configured to request the end entity’s private encryption key (in encrypted form) and send it to the Data Recovery Manager during the enrollment process. Before the Registration Manager sends the certificate request to the Certificate Manager for processing, the Registration Manager must receive verification from the Data Recovery Manager that the private key has been received and stored and that it corresponds to the end...
Page 55: System Architecture
System Architecture files from the original Certificate Manager to the new Certificate Manager directory). If these databases are present, the Configuration <server_root>/alias Wizard will recognize that you are creating a clone and confirm that you want to reuse the CA’s signing key and certificate (if the clone is on the same server, you can also reuse the SSL server certificate).
Page 56: Cs Component
System Architecture Figure 1-5 CS Architecture CS Component The CS component is the main component in the CS product. CS is a set of pure Java classes. This component provides a secure application platform where subsystems (CA, RA, DRM, and OCSP) can be tightly integrated with a PKI infrastructure. Depending on the installation configuration selection, CS can be easily installed as a CA, RA, DRM, or OCSP Responder, where subsystem-specific HTTP servlets are registered at startup to provide subsystem-specific services.
Page 57: Http Engine
System Architecture Within the CS component, a set of common modules (all can be extended with customized JAVA plug-ins) are provided for all subsystems (although some may not be utilized by default setting, they are all available for further customization): •...
Page 58: Service Interfaces
System Architecture • Agent Entry Point—provides entry point for agent interface and inter-CIMC_Boundary interface. A set of customizable HTML forms are provided at this port for CA, RA, and DRM agent users to perform agent tasks. The client applications used to access this entry point must have the capability to act as an SSL client.
Page 59: Jss And The Java/Jni Layer
System Architecture Agent Services Interface The agent services interface provides JAVA servlets to process HTML form submissions coming from the agent entry-point. Based on the information given in each form submission, the agent servlets allow agents to perform agent tasks, such as editing and approving requests for certificate approval, certificate renewal, and certificate revocation, and approving certificate profiles.
Page 60: Nss
System Architecture Network Security Services (NSS) is a set of libraries designed to support cross-platform development of security-enabled communications applications. Applications built with the NSS libraries support the SSL protocol for authentication, tamper detection, and encryption as well as the PKCS #11 interface for cryptographic token interfaces. Red Hat uses NSS to support these features in a wide range of products, including CS.
Page 61: Management Tools
System Architecture • FIPS 140-1 module. This module complies with the FIPS 140-1 government standard for implementations of cryptographic modules. Many products sold to the US government must comply with one or more of the FIPS standards. The FIPS 140-1 module includes a single, built-in FIPS 140-1 Certificate DB token (as shown in Figure 1-5 on page 56), which handles both cryptographic operations and communication with the certX.db and keyX.db files.
Page 62: Internal Ldap Database
CS SDK Internal LDAP Database CS employs Red Hat Directory Server as its internal database for storing information such as certificates, requests, users, roles, ACLs, as well as other miscellaneous internal information. CS communicates with the internal LDAP database securely by means of SSL client authentication.
Page 63: Support For Open Standards
Support for Open Standards • Tutorials—“How To” tutorial to help demonstrate how you can create your own plug-in modules for CS. Each tutorial includes sample Java source code, environment and build script and a detailed “cookbook” describing how to build and install these plug-in modules.
Page 64: Security And Directory Protocols
Support for Open Standards • PKIX Certificate and CRL Profile (PKIX Part 1). The first part of the four-part standard under development by the IETF for a public-key infrastructure for the Internet. Part 1 deals with specifications for certificates and CRLs. CS will support the other PKIX parts as they are finalized.
Page 65: Chapter 2 Installation
Chapter 2 Installation This chapter explains how to install Red Hat Certificate System (CS). This chapter contains the following sections: • Installation and Configuration Overview • Installation Overview • Installing CS • Uninstalling CS Installation and Configuration Overview You install Red Hat Certificate System (CS) on each host on which you will be setting up a CS subsystem.
Page 66: Installation And Configuration Process
Installation Overview Installation and Configuration Process The following outlines the process for installing, setting up, and configuring CS: Run the installation program to install Administration Server, Directory Server, and CS on each host system that will be part of your deployment. See “Installing CS” on page 72 for complete instructions on installing CS.
Page 67: About The Installation Program
Installation Overview About the Installation Program The installation program installs Administration Server, Directory Server, Red Hat Console, and CS in the server root directory you specify. It creates one instance of Administration Server, one instance of Directory Server, and one instance of CS. The installation program automatically starts Administration Server and Directory Server.
Page 68 Installation Overview Choosing Ports for Directory and Administration Servers During installation, you choose port numbers for both the directory server used as the configuration directory, and the administration server. The port for the administration server is the port used to log into Red Hat Console. Port numbers can be any number from 1 to 65535.
Page 69 You should use a common group for all Red Hat Directory and Certificate servers, such as , to ensure that files can be shared between servers when necessary. redhat Before you can install Directory Server and Administration Server, you must make sure that the user and group accounts you will use exist on your system.
Page 70 Installation Overview • Administration Server User and password. You are prompted for this only during custom installations. The Administration Server user is the special user that has all privileges for the local Administration Server. Authentication as this person allows you to administer all the Red Hat servers stored in the local server root.
Page 71: Installation Worksheet
Installation Overview Installation Worksheet You can use the following worksheet to specify the information you will be prompted for during the installation. The default setting is indicated in square brackets. Install location [/usr/netscape/servers] ______________________________________ Computer name [myhost.mydomain.com] ______________________________________ System User [nobody] ______________________________________ System Group [nobody] ______________________________________...
Page 72: Installing Cs
Installing CS Installing CS To install CS: Log in to the host system as the user ID you will be running the servers as. Note that you must be logged into the host locally. Do not install remotely. See “Deciding the User and Group for Your Red Hat Servers,” on page 68 for more information.
Page 73 Installing CS Do you agree to the license terms? [No]: Type and press Enter. Select the component you would like to install [1]: Accept the default to install the Red Hat servers. Choose an installation type [2]: Accept the default for a typical installation. Install location [/usr/netscape/servers]: Enter the full path to the location in which you want to install the servers.
Page 74 Installing CS Do you want to use another directory to store your data? [No]: If you accept the default setting, the installation script either adds a user/group directory to the newly installed instance of Directory Server (if you accepted the default in step 17) or installs a new instance of Directory Server for use as a user/group directory.
Page 75 Installing CS Administration port [random #]: Accept the default port number, which is randomly generated, or enter any port number that is not and will not be used for another purpose. See “Choosing Ports for Directory and Administration Servers,” on page 68 for more information.
Page 76: Uninstalling Cs
Uninstalling CS Uninstalling CS To remove CS from a host system, run the uninstall program. To remove a specific CS instance, follow the instructions provided in “Removing an Instance From a System” on page 249. To uninstall CS: Log in as the user account under which the server is running. Go to the server root directory containing the installed software.
Page 77: Chapter 3 Certificate Manager
Chapter 3 Certificate Manager The Certificate Manager subsystem provides the services of a Certificate Authority (CA) in the PKI. It can issue, renew, and revoke certificates; create and issue CRLs; and publish certificates and CRLs. This chapter discusses the Certificate Manager subsystem. It provides an overview of the subsystem including the decisions you need to make before installing the subsystem, complete installation instructions, an overview of the Certificate Manager processes including information on configuring those processes, information about FBCA, and details...
Page 78: Self-Signed Root Vs. Subordinate Ca
Certificate Manager Deployment Considerations Self-Signed Root vs. Subordinate CA A Certificate Manager can be set up as a self-signing root CA. You set up a self-signing root CA by choosing this option when you install. A self-signing root CA issues and signs its own certificates.
Page 79: Cloned Ca
Certificate Manager Deployment Considerations with the certificates you issue. If you are using Netscape Communicator as your client, you can accomplish this task within an intranet by using tools such as Mission Control Desktop or with the aid of Personal Security Manager, but extranet deployments can be more complicated.
Page 80 Certificate Manager Deployment Considerations CA Signing Key Pair and Certificate Every Certificate Manager you install has a Certificate Manager CA signing certificate, whose public key corresponds to the private key the Certificate Manager uses to sign the X.509 certificates and CRLs it issues. This certificate is created and installed when you install the Certificate Manager.
Page 81 Certificate Manager Deployment Considerations The default nickname for the OCSP signing certificate is , where identifies the CS ocspSigningCert cert-<instance_id> <instance_id> instance in which the Certificate Manager is installed. The Certificate Manager uses the private key (that corresponds to the public key used to generate the OCSP signing certificate) to sign the OCSP responses it sends to the OCSP-compliant clients when queried about the revocation status of certificates.
Page 82 Certificate Manager Deployment Considerations CA’s Distinguished Name The core elements of a CA consist of a signing unit and the Certificate Manager’s own identity. The signing unit digitally signs certificates requested by end-entities that use a specified enrollment process to establish their identities. Regardless of how related Registration Managers or Data Recovery Managers are configured, any Certificate Manager must have its own distinguished name (DN), which is listed in every certificate it issues.
Page 83: Certificate Manager Interfaces
Certificate Manager Deployment Considerations Many people no longer consider an RSA key of length less than 1024 bits to be cryptographically strong. Export and other regulations permitting, it may be a good rule of thumb to start with 1024 bits and consider increasing the length to 4096 bits for certificates that provide access to highly sensitive data or services.
Page 84: Password Storage
Certificate Manager Deployment Considerations • An End-Entity interface that is accessible by anyone who can access that URL. The end-entity interface is an HTML interface accessible through either HTTPS or HTTP (there are two ports set up by default). The default interface provides forms for the various types of enrollment and other tasks an end entity can perform and is completely customizable.
Page 85: Installing A Certificate Manager
Installing a Certificate Manager If you are using an external token, you will need to install it before you run the Installation Wizard. In the wizard, you can select from a list of already installed and available tokens. For example, .
Page 86 Installing a Certificate Manager Administrator. Type the user ID, name, and password for the CS administrator. This user ID will be set up as the administrator who can access the CS window and control all CS settings. Allow Multiple Roles for Users. Select if you want to allow users to belong to more than one group, thus assuming more than one role.
Page 87 Installing a Certificate Manager Network Configuration. Type the port numbers for the ports used by this instance, or accept the defaults. See “Certificate Manager Interfaces,” on page 83 for more information. Click Next to continue. CA Signing Certificate. Select the “Create self-signed CA certificate” option. Click Next to continue.
Page 88 Installing a Certificate Manager Validity Period for Certificate Manager CA Signing Certificate. Select the validity period for the CA signing certificate. The default validity is two years. The validity period determines how soon you will have to renew the certificate, which can be a complex procedure.
Page 89 Installing a Certificate Manager Key Length. Available key sizes for RSA are 512, 768, 1024, 2048, 4096, or ❍ Custom. Available key sizes for DSA are 512, 1024, or Custom (which must be in increments of 64 bits only). See “Signing Key Type and Length” on page 82 for more information. Click Next to continue.
Page 90: Installing A Certificate Manager As A Subordinate Ca
Installing a Certificate Manager You now need to create the first agent user for the Certificate Manager. See “Agent Certificates,” on page 324 for details. Installing a Certificate Manager as a Subordinate CA To install the Certificate Manager as a subordinate CA: Log into Red Hat Console as the administrator, see “Red Hat Console”...
Page 91 Installing a Certificate Manager Subsystems. Choose a subsystem you want to install. Select Certificate Manager. Click Next to continue. Remote Data Recovery Manager. Select the appropriate options: Select No if you don’t want to connect the Certificate Manager to a remote Data ❍...
Page 92 Installing a Certificate Manager Key Type. Choose RSA or DSA. ❍ Key Length. Available key sizes for RSA are 512, 768, 1024, 2048, 4096, or ❍ Custom. Available key sizes for DSA are 512, 1024, or Custom (which must be in increments of 64 bits only).
Page 93 Installing a Certificate Manager For more information about extensions, see Appendix G, “Certificate and CRL Extensions.” Click Next to continue. Certificate Manager CA Signing Certificate Creation. This is an informational screen that tells you that the wizard has all the information required to generate the key pair and certificate request.
Page 94 Installing a Certificate Manager Select List Requests, then click Show Pending Requests and click Find. The pending request list is displayed. Locate your request, click Details to see it, and make any changes. Then, VII. scroll down to the bottom of the form and click Do It. After the certificate is generated, click Show Certificate.
Page 95 Installing a Certificate Manager In the pending request list, locate your request, click Details to see the VIII. request, and make any changes. Then, scroll down to the bottom of the form, and click Do It. After the certificate is generated, click Show Certificate. When the certificate is displayed, scroll down to the base-64 encoded version of the certificate, highlight all the text (including -----BEGIN...
Page 96 Installing a Certificate Manager If you selected Yes, the “Location of Certificate” screen appears (Step 21). ❍ Location of Certificate. Specify the location of the certificate. You can use any of these options: If you copied the encoded certificate to a file, select the “The certificate is located ❍...
Page 97 Installing a Certificate Manager If you want to submit the SSL server certificate request to another CA, for example ❍ to the CA that signed the subordinate CA’s signing certificate, select the “Create request for submission to another CA” option. Click Next to continue.
Page 98 Installing a Certificate Manager If you want the wizard to generate the certificate request in PKCS #10 format, ❍ select the “Generate PKCS10 request” option. If you want the wizard to generate the certificate request in CMC format, select the ❍...
Page 99 Installing a Certificate Manager In the pending request list, locate your request, click Details to see the request, VII. and make any changes. Then, scroll down to the bottom of the form, and click Do It. After the certificate is generated, click Show Certificate. VIII.
Page 100 Installing a Certificate Manager To approve the request, do the following: In the web browser window, enter the URL for the Certificate Manager’s Agent Services page. (You must have a valid agent’s certificate.) Select List Requests, then click Show Pending Requests and click Find. The pending request list is displayed.
Page 101 Installing a Certificate Manager Select Yes, only if you have the certificate ready in its base-64 encoded format. ❍ Click Next to continue. If you selected Yes, the “Location of Certificate” screen appears (Step 32). ❍ If you selected No, you will be presented with the “Create Single Sign-on ❍...
Page 102: Configuring The Certificate Manager
Configuring the Certificate Manager Paste the certificate chain into the text box. Click Next to continue. Single Sign-on Summary. Check the summary and select whether to retain or delete file. For details, see “Token Password Storage” on page 244. password.conf Click Next to continue.
Page 103: Managing Certificates And The Certificate Database
Configuring the Certificate Manager change the privileges of a user, group, or IP address. You can also create new groups and assign privileges to those groups by adding ACI entries for that group in the ACLs. For complete details about creating users, assigning users to groups, creating groups, and changing ACIs and ACLs, see Chapter 9, “Authorization.”...
Page 104 Configuring the Certificate Manager Trust Settings and CA Certificates The trusted database also contains the CA certificates for those CAs that the subsystem trusts. If your subsystem has certificates from a CA or accepts certificates that are issued by a CA, it must have a copy of those CA certificates in the trusted database, and they must be configured as trusted, see “Changing the Trust Settings of a CA Certificate,”...
Page 105 Configuring the Certificate Manager Once you have the certificate request ready, submit it to the Certificate Manager so that it can issue a certificate—in the request submission screen of the wizard, use the auto-submission feature by entering the Certificate Manager’s hostname and port number so that the request gets added to the Certificate Manager’s agent queue.
Page 106 Configuring the Certificate Manager Is the name of the token used for generating the token_name key pair and the certificate. If you used the internal/software token, use Internal Key as the value. Storage Token For example, your edited entries might look like this: ca.crl_signing.cacertnickname=crlSigningCert cert-demoCA ca.crl_signing.defaultSigningAlgorithm=MD5withRSA ca.crl_signing.tokenname=Internal Key Storage Token...
Page 107: Changing Ports And Ip Addresses
Configuring the Certificate Manager If you configure the Certificate Manager to function as a trusted manager to a Data Recovery Manager, the Certificate Manager also uses its SSL server certificate for SSL client authentication to the Data Recovery Manager. For details on trusted managers, see “Trusted Managers”...
Page 108: Changing Subsystem Security Setting
Configuring the Certificate Manager You can also change the IP address for the CS instance. You might do this if you have more than one IP address set up on your machine and want separate instances of CS to use different IP addresses.
Page 109: Configuring Self Test
Configuring the Certificate Manager Configuring Self Test Each subsystem provides self tests that are run on start up and can also be run on demand. This feature is configurable, see “Self Tests,” on page 272 for complete information. Setting Up a Mail Server If the subsystem will be sending out email notifications, you can configure the subsystem to use a mail server, see “Mail Server,”...
Page 110: Setting Up Authentication
Configuring the Certificate Manager Validity periods of certificates during enrollment is determined by the plug-in module, “ValidityConstraints,” on page 487. ValidityConstraints Similarly, validity periods of certificates during renewal is determined by the plug-in module, see “RenewalValidityConstraints,” RenewalValidityConstraints on page 481. Certificate Serial Number.
Page 111 Configuring the Certificate Manager For example, you might want to create an automated enrollment that requires LDAP authentication. You have two classes of employees, permanent and temporary. You want to issue both classes of employees certificates using LDAP authentication, but you want to issue each of these classes certificates with different validity periods and different extensions.
Page 112: Configuring Policies
Configuring the Certificate Manager • Portal Enrollment. End users are registered into an LDAP directory and issued a certificate. If user already has an entry in the directory, they are authenticated against the directory and then issued a certificate. See “Setting Up Portal Enrollment,” on page 382.
Page 113: Configuring Certificate Profiles
Configuring the Certificate Manager Configuring Certificate Profiles The Certificate Profile feature uses instances of certificate profile plug-ins that can be configured to issue a type of certificate. The certificate profile contains defaults that specify the contents and the value of that content for this type of certificate, constraints that constrain the content of this type of certificate, associate the certificate profile with a set up authentication method, and define the contents of the enrollment page and the output page when an automated authentication method is used.
Page 114: Configuring Ocsp Services
Configuring the Certificate Manager Configuring OCSP Services The Certificate Manager contains an internal OCSP responder which is installed by default. The OCSP responder receives standard OCSP requests via the non-SSL end-entity port. It checks the status of certificates in the internal database and then reports back on the status of the certificate.
Page 115: Setting Up Jobs
Configuring the Certificate Manager Setting Up Jobs The jobs feature that allows you to run automated jobs is disabled after installation. You need to enable and configure jobs in order to use this feature. For detailed information on setting up jobs, see Chapter 14, “Automated Jobs.” Customizing the End Entity Interface CS provides you with a set of forms that are available at the end entity interface and are preconfigured for various types of interaction with the end entity.
Page 116 This is a required parameter. Example: dbdir=/u/smith/db/ password. Password for , which stores the agent certificate. This is a required cert8.db parameter. Example: password=redhat format. Request format, either pkcs10 crmf Example: format=crmf The following parameters specify CMC control attributes: confirmCertAcceptance.enable. If , then the request will contain this control.
Page 117 Configuring the Certificate Manager confirmCertAcceptance.issuer. The issuer name for the confirmCertAcceptance control. Example: confirmCertAcceptance.issuer=cn=Certificate Manager,ou=102504a,o=102504a,c=us getCert.enable. If , then the request will contain this control attribute. Absence of this true parameter is interpreted as false Example: getCert.enable=false getCert.serial. The serial number for the control.
Page 118 Configuring the Certificate Manager Example: revRequest.nickname=newuser's 102504a ID revRequest.issuer. The issuer name for the certificate being revoked. Example: revRequest.issuer=cn=Certificate Manager,ou=102504a,o=102504a,c=us revRequest.serial. The serial number for the certificate being revoked. Example: revRequest.serial=75 revRequest.reason. The reason for revoking this certificate. Use one of these values: unspecified keyCompromise caCompromise...
Page 119 Example: dbdir=<server_root>/bin/cert/tools clientmode. for client authentication, for no client authentication. This true false parameter will be ignored if secure=false Example: clientmode=true password. Password for . This parameter will be ignored if cert8.db secure=false clientauth=false Example: password=redhat Chapter 3 Certificate Manager...
Page 120: Setting Up The Cmcauth Authentication Plug-In
Configuring the Certificate Manager nickname. Nickname for client certificate. This parameter will be ignored if clientmode=false Example: nickname=CS Agent-102504a's 102504a ID servlet. The URI of the servlet that processes full CMC requests. The default value is /ca/profileSubmitCMCFull Example: servlet=/ca/profileSubmitCMCFull CMC Response Utility The CMC Response Utility, , is used to parse a CMC response (received by CMCResponse...
Page 121: Setting Up The Server For Multiple Requests In A Full Cmc Request
Configuring the Certificate Manager In the CS window for the Certificate Manager issuing the certificates, select the Configuration tab. Select Authentication in the navigation tree. The right pane shows the Authentication Instance tab listing currently configured authentication instances. Click Add. The Select Authentication Plug-in Implementation window appears.
Page 122: How The Certificate Manager Works
How The Certificate Manager Works Restart the server. How The Certificate Manager Works This section provides detailed information on how the Certificate Manager works during Enrollment, Renewal, Revocation, and Publishing of certificates and CRLs to help you better understand what configuration you will need to perform for your PKI. Enrollment An end entity can enroll in your PKI by submitting an enrollment request via the end-entity interface.
Page 123 How The Certificate Manager Works • The end entity may have to provide some form of authentication before submitting the request. You can configure LDAP authentication, Pin-based authentication, or certificate-based authentication. • The request may be submitted using an agent-approved enrollment process or an automated process.
Page 124: Renewal
How The Certificate Manager Works In automated (for example, directory-based) enrollment, the certificate is delivered ❍ to the user immediately. Normally, the enrollment is via HTML page (the browser), the certificate is returned as a response (HTML page) to a HTTP submit (post).
Page 125: Revocation
Federal Bridge CA Revocation An end entity can request that their own certificate is revoked. When an end entity makes the request, they are asked to present their certificate. If they have the certificate and the key materials, the request is processed and sent to the Certificate Manager and the certificate is revoked.
Page 126: Issuing Cross-Pair Certificates
Federal Bridge CA Issuing Cross-Pair Certificates The policy feature allows you to configure the policy CertificatePoliciesExt provide as the predicate value, and then set up any HTTP_PARAMS.certType==fbca other necessary policies for this kind of certificate. You would then associate an end-entity enrollment page, customized to enroll for cross-pair certificates, providing the hidden value , thus activating policies associated with FBCA to this request.
Page 127: Cloning A Ca
Cloning a CA CS also provides a publishing mapper for CA certificates that can be used for publishing cross-pair certificates, , designating which LDAP entry should be used to store the LDAPCA . A publisher, , is also set up crossCertificatePair LDAPCrossPairPublisher specifying the attribute used to store the cross-pair certificate in the CA entry.
Page 128 Cloning a CA Red Hat Certificate System Administrator’s Guide • September 2005...
Page 129: Chapter 4 Registration Manager
Chapter 4 Registration Manager The Registration Manager is an optional subsystem that provides Registration Authority functionality. It establishes a trusted relationship with a Certificate Manager in which its requests are processed. This chapter details how to install and configure a Registration Manager and includes the following sections: •...
Page 130: Registration Manager Interfaces
Registration Manager Deployment Considerations When you get the certificates from a CS CA, you can set the Registration Manager up as a trusted manager of the Certificate Manager by specifying this on the agent approval form for the certificate request. Otherwise, you will need to manually set up the trusted relationship.
Page 131: Password Storage
Registration Manager Deployment Considerations • An Administrative interface that is accessible by default only to members of the Administrator and Auditor group. Administrators can configure any of the settings of the server. Most basic functionality and subsystem specific configuration to the subsystem can be done using the administrative interface.
Page 132: Internal Database
Registration Manager Deployment Considerations Internal Database Each Registration Manager instance contains an internal database that stores certificates, certificate requests and the like. During installation, you set up this database by either choosing to create a new database, or use an existing database, providing user IDs and associated passwords to the database, and the port the database will listen to requests on.
Page 133: Tokens
Installing a Registration Manager Tokens You choose either the token (if you plan to use the internal/software token) or an internal external token to store the signing certificate and key pair and the SSL signing certificate and key pair. If you are using an external token, you will need to install it before you run the Installation Wizard.
Page 134 Installing a Registration Manager Subsystems. Choose a subsystem you want to install. Select Registration Manager. Click Next to continue. Remote Certificate Manager. Type the host name and agent port number of the remote Certificate Manager to which you want to connect this Registration Manager. Click Next to continue.
Page 135 Installing a Registration Manager Subject Name for Registration Manager Signing Certificate. Type the values for the subject DN components; these values identify the Registration Manager’s signing certificate. A DN is a series of name-value pairs that in combination uniquely identify an entity. The subject DN identifies the Registration Manager signing certificate.
Page 136 Installing a Registration Manager To automatically submit the request to a remote Certificate Manager (or for ❍ automatic enrollment), follow these steps: Select the “Send the request to a remote CS now” option. Enter the host name and end-entity port number of the remote Certificate Manager, and specify whether the end-entity port is SSL enabled.
Page 137 Installing a Registration Manager Go to the end-entity URL of the remote Certificate Manager that will issue the Registration Manager’s signing certificate. For example, if you assigned the port number 17006 to the non-SSL end-entity port for your root CA, you would go to the URL to bring up the Certificate Manager page for http://<hostname>:17006 end entities.
Page 138 Installing a Registration Manager Be sure to not make any changes to the certificate. You’re required to paste the encoded certificate into the Installation Wizard next. So, once you’ve copied the certificate, go back to the wizard screen (Step 17). To submit your certificate request manually to a third-party CA, follow these ❍...
Page 139 Installing a Registration Manager If you copied the certificate to the clipboard, select the “The certificate is located ❍ in the text area below” option and then paste in a base-64 encoded certificate (including the header and footer) in the text area provided. If you noted the request ID of your request and know the host name and end-entity ❍...
Page 140 Installing a Registration Manager Key Length. Available key sizes for RSA are 512, 768, 1024, 2048, 4096, or ❍ Custom. Available key sizes for DSA are 512, 1024, or Custom (which must be in increments of 64 bits only). See “Signing Key Type and Length” on page 132 for more information. Click Next to continue.
Page 141 Installing a Registration Manager Enter the host name and end-entity port number of the remote Certificate Manager, and select whether the end-entity port is SSL enabled. Click Next to submit the request. III. The Certificate Request Result screen appears, confirming that the request has been submitted.
Page 142 Installing a Registration Manager Click Manual Server Certificate Enrollment, or click Agent-Based Server III. Certificate Enrollment if you have an agent certificate. If you choose Agent-Based Server Certificate Enrollment and you have an agent certificate, the certificate will be automatically issued once you submit the request. In the resulting form, choose the type of request from the pull down menu, paste the request in the request field, and fill in the other fields on the form.
Page 143 Installing a Registration Manager This action copies the certificate request to the clipboard. In addition to the copy on the clipboard, the screen informs you that the certificate request has been saved to a file. You can use either the copy on the clipboard or the copy in the file to transfer your request to the CA that will issue the Registration Manager’s SSL server certificate.
Page 144 Installing a Registration Manager Certificate Details. This is an informational screen that displays the certificate so you can inspect its contents. Notice the nickname assigned to the certificate and verify that you’re installing the correct certificate. Click Next to continue. Import Certificate Chain.
Page 145: Configuring A Registration Manager
Configuring a Registration Manager Configuring a Registration Manager This section details the areas that you can configure for the Registration Manager and points you to specific information on configuring those sets of features. Setting Up Trust With a CA You need to set up the Registration Manager as a trusted manager in the Certificate Manager that issues certificates for the Registration Manager.
Page 146: Managing Certificates And The Certificate Database
Configuring a Registration Manager Default ACL Configuration The configuration set up for the Certificate Manager gives the following privileges to members of the following groups: • Members of the Administrator group can perform any operations in the administrative interface including viewing configuration settings, changing configuration settings, adding or deleting plug-ins, creating or deleting instances or plug-ins, and viewing all logs except for the signed audit log—if you have the signed audit feature set up.
Page 147: Changing Ports And Ip Addresses
Configuring a Registration Manager Certificate Chain You also may need to install a certificate chain in the database to provide the chain of CAs to a trusted CA. You can install a certificate chain in the certificate database, see “Installing a CA Certificate Chain in the Certificate Database,”...
Page 148: Changing Subsystem Security Setting
Configuring a Registration Manager You can also change the IP address for the CS instance. You might do this if you have more than one IP address set up on your machine and want separate instances of CS to use different IP addresses.
Page 149: Configuring Self Test
Configuring a Registration Manager Configuring Self Test Each subsystem provides self tests that are run on start up and can also be run on demand. This feature is configurable, see “Self Tests,” on page 272 for complete information. Setting Up a Mail Server If the subsystem will be sending out email notifications, you can configure the subsystem to use a mail server, see “Mail Server,”...
Page 150 Configuring a Registration Manager Agent-Approved Enrollment The Registration Manager is enabled by default for agent-approved enrollment. The agent-approved enrollment form is used to enroll end entities whose request is sent to the agent services interface for processing. If you are using the certificate profile feature, an agent-approved enrollment is associated with any certificate profile that does not declare an authentication method.
Page 151: Configuring Policies
Configuring a Registration Manager Configuring Policies The Policy feature is a set of plug-ins that you create instances of and then configure. These instances define certificate content and the values for that content and constraints for the content that can either be associated with all certificates, or with a subset of certificates defined using predicates.
Page 152: Crls
Configuring a Registration Manager The default instances of certificate profiles are for particular types of certificates including a CA certificate, SSL server certificate, end-entity certificate, and so on. Each certificate profile is associated with the certificate profile form in the end entity interface that lists all of the available certificate profiles.
Page 153: Setting Up Notifications
How a Registration Manager Works Setting Up Notifications The notification feature that allows you to send automated notifications is disabled after installation. You need to enable and configure notifications in order to use this feature. For detailed information on setting up notifications, see Chapter 13, “Automated Notifications.” Setting Up Jobs The jobs feature that allows you to send automated jobs is disabled after installation.
Page 154: Enrollment
How a Registration Manager Works Enrollment An end entity can enroll in your PKI by submitting an enrollment request in the end-entity interface. You can create more than one type of enrollment that either uses a different enrollment method, has different certificate issuance policies, or requires a different method of authentication, or all three.
Page 155 How a Registration Manager Works The automated process allows the certificate to be processed upon successful ❍ authentication of the end entity. See Chapter 10, “Authentication.” • The form can collect information about the end entity from an LDAP directory when the form is submitting.
Page 156: Renewal
How a Registration Manager Works • You can set up publishing in the Certificate Manager, in which case the certificate will be published according to the rules set up in the Certificate Manager. • If the OCSP service of the Certificate Manager is enabled, requests for the status of this certificate can be made to the Certificate Manager through this service.
Page 157: Chapter 5 Ocsp Responder
Chapter 5 OCSP Responder This chapter provides an overview of an Online Certificate Status Protocol (OCSP) service, and explains how you can use the OCSP service built into the Certificate Manager for real-time verification of certificates issued by the Certificate Manager. The chapter also explains how to install and configure an Online Certificate Status Managers to publish CRLs.
Page 158: How Ocsp Services Work
About OCSP Services How OCSP Services Work An OCSP service works as follows: A CA is set up to issue certificates that include the Authority Information Access Extension whose value identifies an OCSP responder that can be queried for the status of the certificate.
Page 159: Ocsp Responses
CS OCSP Services CS has a built-in OCSP responder and allows you to request OCSP responder certificates. The end-entity interface of both Registration Manager and Certificate Manager includes a form that allows you to manually request a certificate for the OCSP responder.
Page 160 CS OCSP Services How Certificate Manager’s OCSP-Service Feature Works The Certificate Manager has a built-in OCSP-service feature, which when configured, can be used by OCSP-compliant clients to directly query the Certificate Manager about the revocation status of the certificate being validated. The OCSP service is installed and configured by default, and is one of the options during install.
Page 161: Setting Up A Certificate Manager With Ocsp Service
Setting Up a Certificate Manager with OCSP Service As explained earlier, the Online Certificate Status Manager stores each Certificate Manager’s CRL in its internal database and uses it as the default CRL store for verifying certificates. You can also configure the Online Certificate Status Manager to use the CRL published to an LDAP directory by a Certificate Manager.
Page 162: Online Certificate Status Manager Deployment Considerations
Online Certificate Status Manager Deployment Considerations Online Certificate Status Manager Deployment Considerations This section describes the decisions you make during installation that will apply to your initial configuration of the subsystem. Online Certificate Status Manager Certificates When you install the Online Certificate Status Manager, the keys for the OCSP signing certificate and SSL server certificate are created and a certificate request is made for the signing certificate and the SSL server certificate.
Page 163: Interfaces
Online Certificate Status Manager Deployment Considerations The Online Certificate Status Manager’s SSL server certificate was issued by the CA to which you submitted the certificate signing request. You might have submitted the request to an internally deployed CA or a public CA. The Online Certificate Status Manager uses its SSL server certificate to do SSL server-side authentication for the Online Certificate Status Manager Agent Services interface.
Page 164: Password Storage
Online Certificate Status Manager Deployment Considerations • An End-Entity interface that is accessible by anyone who can access that URL. The end-entity interface listens for requests on the SSL or Non-SSL End Entity Ports. It does not contain HTML forms, but is used for requests to the OCSP responder. Both are configured during installation.
Page 165: Signing Key Type And Length
Installing an Online Certificate Status Manager Signing Key Type and Length If you wish, you can import the signing key and certificate used in a previous version of CS installation rather than generating a new signing key pair. For information on how to do this, check the migration information in Step 6 of the section “Upgrading”...
Page 166 Installing an Online Certificate Status Manager Internal Database. Choose to either create a new internal database for this instance or to use an existing Directory Server instance as the internal database for this instance. Next, specify the information for that Directory Server instance. See “Internal Database,”...
Page 167 Installing an Online Certificate Status Manager Subject Name for Online Certificate Status Manager Signing Certificate. Type the values for the subject DN components; these values identify the Online Certificate Status Manager’s signing certificate. Click Next to continue. Online Certificate Status Manager Signing Certificate Request Creation. This informational screen tells you that the wizard has all the information required to generate the key pair and certificate request.
Page 168 Installing an Online Certificate Status Manager Locate your request, click Details to see it, and make any changes. Then, VII. scroll down to the bottom of the form and click Accep this request. After the certificate is generated, click Show Certificate. VIII.
Page 169 Installing an Online Certificate Status Manager Locate your request, click Details to see it. After checking the rest of the certificate request and making any changes, scroll to the bottom, and click Approve Request. When the certificate is displayed, scroll down to the base-64 encoded version of the certificate, highlight all the text (including -----BEGIN ), and copy it to...
Page 170 Installing an Online Certificate Status Manager If you selected Yes, the “Location of Certificate” screen appears (Step 14). ❍ If you selected No, you will be presented with the “Key-Pair Information for SSL ❍ Server Certificate” screen (Step 17). Location of Certificate. Specify the location of the certificate. You can use one of these options: If you noted the file path to the file that contains the certificate (in its base ❍...
Page 171 Installing an Online Certificate Status Manager Click Next to continue. If you closed the end-entity interface, you can get the CA certificate chain this way: Open a web browser window. Go to the end-entity URL for the Certificate Manager that issued the Online Certificate Status Manager’s signing certificate.
Page 172 Installing an Online Certificate Status Manager CS provides command-line tools for generating extensions to include in CA and other certificate requests. For details about these tools, check this directory: <server_root>/bin/cert/tools Note that the certificate extension text field accepts a single extension blob. If you want to add multiple extensions, you should use the program, which is also ExtJoiner...
Page 173 Installing an Online Certificate Status Manager In the web browser window, enter the URL for the Certificate Manager’s Agent Services page. (You must have a valid agent’s certificate.) Select List Requests, then click Show Pending Requests and click Find. The pending request list is displayed.
Page 174 Installing an Online Certificate Status Manager If you used the Manual Server Certificate Enrollment request, the request gets added to the agent queue of that Certificate Manager for approval by that Certificate Manager’s agent. If you’ve permission to access that Certificate Manager’s Agent interface, you can follow the instructions below to issue the certificate.
Page 175 Installing an Online Certificate Status Manager If you copied the encoded certificate to a file, select the “The certificate is located ❍ in this file” option and type the file path, including the filename, in the text field. If you copied the certificate to the clipboard, select the “The certificate is located ❍...
Page 176: Setting Up The Ocsp Responder
Setting Up the OCSP Responder Configuration Status. This screen should indicate that your configuration has been successful and that you need to create an agent for the Online Certificate Status Manager. Click Done to exit the Installation Wizard. You now need to create the first agent user for the Online Certificate Status Manager. See “Agent Certificates,”...
Page 177: Configuring The Online Certificate Status Manager
Configuring the Online Certificate Status Manager Identify every Certificate Manager that will publish to the OCSP Responder to the ❍ OCSP Responder. “Identifying the CA to the OCSP Responder,” on page 181 for complete details. You may need to configure trust settings depending on who signed the OCSP ❍...
Page 178: Managing Certificates And The Certificate Database
Configuring the Online Certificate Status Manager Default ACL Configuration The configuration set up for the Online Certificate Status Manager gives the following privileges to members of the following groups: • Administrators can perform any operations in the administrative interface which includes viewing configuration settings, changing configuration settings, adding or deleting plug-ins, creating or deleting instances or plug-ins, viewing all logs except for the signed audit log, if you have the signed audit feature set up.
Page 179: Ocsp Certificates
Configuring the Online Certificate Status Manager Certificate Chain You also may need to install a certificate chain in the database to provide the chain of CAs to a trusted CA. You can install a certificate chain in the certificate database, see “Installing a CA Certificate Chain in the Certificate Database,”...
Page 180: Changing Subsystem Security Setting
Configuring the Online Certificate Status Manager Changing Subsystem Security Setting You can configure the security of each subsystem by changing the SSL version used by the subsystem and enabling or disabling ciphers, see “Configuring the Server’s Security Preferences,” on page 309. Changing Passwords or Storage Settings Each subsystem stores passwords for its internal database, and for the tokens containing its keys and certificates.
Page 181: Setting Up Jobs
Configuring the Online Certificate Status Manager Setting Up Jobs The jobs feature that allows you to send automated jobs is disabled after installation. The Online Certificate Status Manager contains the framework for jobs, but does not contain any prebuilt jobs. You can build jobs using the CS SDK. For detailed information on setting up publishing, see Chapter 14, “Automated Jobs.”...
Page 182: Configure The Revocation Info Stores
Configuring the Online Certificate Status Manager Verify Certificate Manager and Online Certificate Status Manager Connection When you restart the Certificate Manager, it tries to connect to the Online Certificate Status Manager’s end-entity SSL port. To verify that the Certificate Manager did indeed communicate with the Online Certificate Status Manager: Enter the URL for the Online Certificate Status Manager’s Agent interface.
Page 183 Configuring the Online Certificate Status Manager In the navigation tree, select Online Certificate Status Manager, and then select Revocation Info Stores. The right pane shows the two repositories the Online Certificate Status Manager can use; by default, it uses the CRL in its internal database. Select the appropriate option: If you want to configure the Online Certificate Status Manager to use the CRLs in ❍...
Page 184: Testing Your Ocsp Setup
Testing Your OCSP Setup port<n>. Type the nonSSL port of the LDAP directory. For example, 389. baseDN<n>. Type the DN to start searching for the CRL. For example, O=example.com refreshInSec<n>. Type how often the connection is refreshed. The default is 86400 seconds (that is, refresh every day).
Page 185 Testing Your OCSP Setup Download the certificate to the browser or client. Make sure the CA is trusted by the browser or client. Check the Status of Certificate Manager’s OCSP Service (internal OCSP service). Go to the agent services interface for the Certificate Manager and then go to the OCSP Services page.
Page 186 Testing Your OCSP Setup The Online Certificate Status Manager sent an OCSP response to the browser. ❍ The browser used that response to validate the certificate and informed you of its status (that the certificate could not be verified) Red Hat Certificate System Administrator’s Guide • September 2005...
Page 187: Chapter 6 Data Recovery Manager
Chapter 6 Data Recovery Manager When data is stored in encrypted form, you must have the private key that corresponds to the public key that was used to encrypt the data in order to decrypt and read it. If the private key is lost, the data cannot be retrieved.
Page 188: Clients That Can Generate Dual Key Pairs
PKI Setup for Key Archival and Recovery • An installed and configured Data Recovery Manager • HTML forms with which end-entity’s can request dual certificates (based on dual keys) and key recovery agents can request key recovery The sections that follow explain these elements in detail. For step-by-step instructions on setting up your PKI environment for key archival and recovery, see “Installing a Standalone Data Recovery Manager”...
Page 189: Forms For Users And Key Recovery Agents
Key Archival Process Forms for Users and Key Recovery Agents End-entity’s encryption private keys are archived by the Data Recovery Manager when they are generated. So, for key archival to occur, the enrollment form that users fill out to request dual certificates must have the JavaScript code for activating the key archival option embedded in it, along with a valid copy of the Data Recovery Manager’s transport certificate.
Page 190: Where The Keys Are Stored
Key Archival Process • An employee leaves the company, and company officials need to perform an audit that requires gaining access to the employee's encrypted mail. Where the Keys are Stored If configured properly, the Data Recovery Manager, stores your end-entity’s encryption private keys automatically whenever the associated or connected Registration Manager or Certificate Manager issues certificates to your users.
Page 191 Key Archival Process Figure 6-1 illustrates how the key archival process occurs when an end-entity’s requests a certificate. The deployment scenario shown in this figure has a Registration Manager acting as the trusted enrollment authority to a Certificate Manager and Data Recovery Manager. Figure 6-1 How the key archival process works These are the steps shown in Figure 6-1:...
Page 192: Key Recovery Process
Key Recovery Process Upon receiving the encrypted key from the client, the Registration Manager sends it to the Data Recovery Manager for storage, along with some other information (including the end-entity’s public key). Then, the Registration Manager waits for verification from the Data Recovery Manager that the private key has been received and stored and that it corresponds to the end-entity’s public encryption key.
Page 193: Key Recovery Agents And Their Passwords
Key Recovery Process Key Recovery Agents and Their Passwords Key recovery agents have the authority to retrieve end-entity’s encryption private keys. The recovery agent’s role can be performed by any person in your organization. As system administrator, you can designate one or more individuals to be key recovery agents. These individuals need to do the following: •...
Page 194 Key Recovery Process The Data Recovery Manager splits the PIN for the token into n parts or pieces by using the Bloom/Shamir secret-sharing algorithm. It then encrypts these parts with the passwords that are provided by the authorized key recovery agents. During the key recovery procedure, the required number of key recovery agents (m) provide their identifiers and passwords.
Page 195: How Agent-Initiated Key Recovery Works
Key Recovery Process By default, key recovery authorization is local. Remote Key Recovery Authorization To authorize key recovery remotely, the required number of recovery agents access the Data Recovery Manager Agent Services interface at their own locations and use the Authorize Recovery button to enter each authorization separately.
Page 196 Key Recovery Process Figure 6-2 The agent-initiated key recovery process These are the steps shown in Figure 6-2: The Data Recovery Manager agent accesses the Key Recovery form using the appropriate client certificate, types the identification information pertaining to the person whose encryption private key needs to be recovered, and submits the request.
Page 197 Key Recovery Process The input section includes fields for entering the end-entity’s certificate ❍ corresponding to the key that needs to be recovered, the password for the PKCS #12 package, and key recovery agents’ passwords. The Data Recovery Manager uses the certificate to construct the PKCS #12 package (which includes the end-entity’s encryption private key and corresponding certificate), the PKCS #12 password to encrypt the PKCS #12 package, and key recovery agents’...
Page 198: Key Recovery Agent Scheme
Key Recovery Process Key Recovery Agent Scheme The key recovery agent scheme consists of configuring the Data Recovery Manager to recognize a fixed number of key recovery agents (a minimum of one) and specifying how many of these agents are required to authorize a key recovery request before the archived key is restored.
Page 199 Key Recovery Process In the navigation tree, select the Data Recovery Manager, and in the right pane, click the Scheme Management tab. The Scheme Management tab shows the current key recovery scheme. Chapter 6 Data Recovery Manager...
Page 200 Key Recovery Process Click Change scheme. The Change Recovery Key Scheme window appears. In the New Scheme section, make the appropriate changes: Number of recovery agents required. Type the number of agents required to authorize a key recovery process. The number cannot be zero and must be equal to or less than the total number of recovery agents.
Page 201 Key Recovery Process When you have entered all agent information, click Done. You are returned to the Scheme Management tab. Changing Key Recovery Agents’ Passwords As administrator, you have the responsibility of safeguarding the security of each Data Recovery Manager installed in your PKI setup. One of the safety measures you can implement is to ask your key recovery agents to change their passwords periodically.
Page 202 Key Recovery Process The tab shows current key recovery agents in the Available Agents list. Select the agent whose password needs to be changed, and click Change Password. The Change Password dialog box appears. Red Hat Certificate System Administrator’s Guide • September 2005...
Page 203: Installing A Standalone Data Recovery Manager
Installing a Standalone Data Recovery Manager Allow the agent to enter the appropriate information. During installation, the Data Recovery Manager prompts you to enter key recovery agent passwords (by default, they are set to , where can be 1, 2, and so agent<n>...
Page 204 Installing a Standalone Data Recovery Manager The first time you generated this certificate is when you installed the Data Recovery Manager. The default nickname for the certificate is , where identifies the CS kraTransportCert cert-<instance_id> <instance_id> instance in which the Data Recovery Manager is installed. The transport certificate was issued by the CA to which you submitted the certificate signing request.
Page 205: Tokens
Installing a Standalone Data Recovery Manager The Data Recovery Manager uses its SSL server certificate to do SSL server-side authentication to the following: • The end entity services interface (the HTTPS port) • The Data Recovery Manager Agent Services interface By default, the Data Recovery Manager uses a single SSL server certificate for authentication purposes.
Page 206: Key Type And Length
Installing a Standalone Data Recovery Manager Key Type and Length If you wish, you can import the signing key and certificate used in a previous version of CS installation rather than generating a new signing key pair. For information on how to do this, check the migration information.
Page 207 Installing a Standalone Data Recovery Manager Internal Database. Choose to either create a new internal database for this instance or to use an existing Directory Server instance as the internal database for this instance. Next, specify the information for that Directory Server instance. See “Internal Database,”...
Page 208 Installing a Standalone Data Recovery Manager Subject Name for Data Recovery Manager Transport Certificate. Type the values for the subject DN components; these values identify the transport certificate. Click Next to continue. Certificate Extensions for Data Recovery Manager Transport Certificate. Select the required extensions.
Page 209 Installing a Standalone Data Recovery Manager The Certificate Request Result screen appears, confirming that the request has been submitted. Note the request ID provided in the response message. (You can use it later to retrieve the certificate, once it has been issued, from the end-entity port.) Note that your request gets added to the agent queue of the remote Certificate Manager for approval by that Certificate Manager’s agent.
Page 210 Installing a Standalone Data Recovery Manager Click Submit. The request gets added to the agent queue of the remote Certificate Manager for approval by that Certificate Manager’s agent. If you’ve permission to access that Certificate Manager’s Agent interface, you can follow the instructions below to issue the certificate.
Page 211 Installing a Standalone Data Recovery Manager If you have submitted your request to a third-party CA or to a remote Certificate ❍ Manager for which you do not have agent privileges, you may have to wait days or weeks before you receive the certificate. In this case, you should click No, continue as far as you can with the configuration, and resume after you receive the certificate.
Page 212 Installing a Standalone Data Recovery Manager Select the Retrieval tab, and then in the left-hand frame, click Import CA Certificate Chain. In the resulting form, select the “Display the CA certificate chain in PKCS#7 for importing into a server” option, and click Submit. In the resulting page, locate the CA certificate chain in its base-64 encoded format, and copy it to the clipboard.
Page 213 Installing a Standalone Data Recovery Manager Message Digest Algorithm. Select the algorithm to use for computing the certificate signature. The choices are: SHA-1, MD2, or MD5. Click Next to continue. Subject Name for SSL Server Certificate. Type the values for the subject DN components;...
Page 214 Installing a Standalone Data Recovery Manager The Certificate Request Result screen appears, confirming that the request has been submitted. Note the request ID provided in the response message. (You can use it later to retrieve the certificate, once it has been issued, from the end-entity port.) Note that your request gets added to the agent queue of the remote Certificate Manager for approval by that Certificate Manager’s agent.
Page 215 Installing a Standalone Data Recovery Manager Click Manual Server Certificate Enrollment, or click Agent-Based Server III. Certificate Enrollment if you have an agent certificate. If you choose Agent-Based Server Certificate Enrollment and you have an agent certificate, the certificate will be automatically issued once you submit the request. In the resulting form, choose the type of request from the pull down menu, paste the request in the request field, and fill in the other fields on the form.
Page 216 Installing a Standalone Data Recovery Manager This action copies the certificate request to the clipboard. In addition to the copy on the clipboard, the screen informs you that the certificate request has been saved to a file. You can use either the copy on the clipboard or the copy in the file to transfer your request to the CA that will issue the subordinate CA’s signing certificate.
Page 217 Installing a Standalone Data Recovery Manager Certificate Details. This is an informational screen that displays the certificate so you can inspect its contents. Notice the nickname assigned to the certificate and verify that you’re installing the correct certificate. Click Next to continue. Import Certificate Chain.
Page 218: Configuring Key Archival And Recovery Process
Configuring Key Archival and Recovery Process Configuring Key Archival and Recovery Process By default, the Data Recovery Manager is not configured to archive or recover end-entity’s encryption private keys. This section explains how to set up key archival and recovery processes.
Page 219 Configuring Key Archival and Recovery Process Step B. Connect the Enrollment Authority and the Data Recovery Manager Key archival occurs when dual key pairs are generated by the client. The client generates the key pairs when a user requests a certificate by filling out the appropriate certificate enrollment form served by an enrollment authority, which can be either a Certificate Manager or a Registration Manager.
Page 220 Configuring Key Archival and Recovery Process • The algorithm, length, type, and usage for end-entity’s key pairs. When you update this information, the key archival option is automatically set. For information on specifying the key type, length, and algorithm, see in Javascript API generateCRMFRequest() for Client Certificate Management.
Page 221 Configuring Key Archival and Recovery Process Scroll down to the section that says “Installing this certificate in a server.” Copy the base-64 encoded certificate, excluding the marker lines -----BEGIN , to a text file. An CERTIFICATE----- -----END CERTIFICATE----- example is shown below: MIICDjCCAXegAwIBAgICAfMwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCV VMxLDAqBgNVBAoTI0 5ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMREwDwYDVQQLEwh...
Page 222 Configuring Key Archival and Recovery Process Use the command-line tool called to retrieve the transport certificate certutil from the Data Recovery Manager’s certificate database. (For information on the tool, check this site: certutil http://www.mozilla.org/projects/security/pki/nss/tools/ First, go to this directory: <server_root>/cert-<instance_id>/config Next, run this command: <server_root>/bin/cert/tools/certutil -L -d .
Page 223 Configuring Key Archival and Recovery Process Open the text file that has the Data Recovery Manager’s transport certificate (the one you copied earlier) and copy the certificate. Paste the certificate as the value of the variable. kraTransportCert Paste the certificate in front of the sign, remove any line breaks, enclose the certificate within double-quotation marks ( ), and end the string with a...
Page 224: Step 2. Set Up The Key Recovery Process
Configuring Key Archival and Recovery Process Save your changes. Step D. Configure Key Archival Policies This step is optional. Unlike Certificate Manager and Registration Manager, no policy plug-in modules are provided for the Data Recovery Manager. If you have implemented any custom policy modules for the Data Recovery Manager’s key archival process, you should make sure that they are configured properly.
Page 225 Configuring Key Archival and Recovery Process Step B. Facilitate the Key Recovery Agents to Change the Passwords During the installation of Data Recovery Manager, after you specified the m of n scheme, you were also prompted to provide unique passwords for each recovery agent. It is quite likely that you specified these passwords yourself instead of it being done by those individuals who have been designated with the key recovery agents’...
Page 226: Step 3. Test Your Key Archival And Recovery Setup
Configuring Key Archival and Recovery Process Unlike Certificate Manager and Registration Manager, no policy plug-in modules are provided for the Data Recovery Manager. If you have implemented any custom policies for the Data Recovery Manager’s key recovery process, you should make sure that they are configured properly.
Page 227 Configuring Key Archival and Recovery Process Click the link that says List Requests. In the form that appears, select the “Show pending requests” option and click Find. You should see your request in the list of pending requests. Make sure the request has the appropriate extensions set for S/MIME (E-mail bit of the Certificate Type extension selected) and the subject name contains Netscape...
Page 228 Configuring Key Archival and Recovery Process Step B. Verify the Key To do this: Open a browser window again. Open the email client, Messenger, and send a signed and encrypted email to yourself. When you receive the email, open it, and check the message to see if it is signed and encrypted.
Page 229 Configuring Key Archival and Recovery Process Click Show Key. If the key has been archived successfully, you should see the information pertaining to that key. Click Recover. In the form that appears, enter the following information: The PKCS #12 password; the Data Recovery Manager uses this password to ❍...
Page 230 Configuring Key Archival and Recovery Process Red Hat Certificate System Administrator’s Guide • September 2005...
Page 231: Chapter 7 Token Management System
Chapter 7 Token Management System To support the use of smart cards and similar hardware tokens that store certificates and related data, CS includes a Token Management System. This consists of the three components introduced in this chapter, which are integrated with the rest of CS: •...
Page 232: Token Key Service
Token Key Service Token Key Service The Token Key Service (TKS) is a CS component that manages the master key(s) and the transport key(s) required to generate and distribute keys for hardware tokens. TKS provides the security between tokens and TPS, where the security relies upon the relationship between the master key and the token keys.
Page 233 Enterprise Security Client • Provides support for two types of tokens. The type allows the use of the key UserKey on a token to identify a specific individual. The simpler can be used only DeviceKey to identify the key itself, without verifying an individual’s identity. •...
Page 234 Enterprise Security Client 234 Red Hat Certificate System Administrator’s Guide • September 2005...
Page 235: Chapter 8 Administrative Basics
Chapter 8 Administrative Basics This chapter discusses the Red Hat Certificate System (CS) user interface, the configuration file, and other basic administrative tasks like starting and stopping the server, managing logs, changing port assignments, and changing the internal database. This chapter contains the following sections: •...
Page 236: The Administrative Interface
The Administrative Interface The Administrative Interface CS provides a GUI-based administration tool called the CS console that is accessible from Red Hat Console. Red Hat Console is a GUI-based front-end for Red Hat Administration Server and allows you to manager servers as well as users. This section provides an overview of Red Hat Administration Server and the CS console.
Page 237: Red Hat Console
The Administrative Interface Red Hat Console Red Hat Console is a stand-alone Java application that provides a GUI-based front end to all network resources registered in an organization’s configuration directory. This unified administration interface simplifies network administration by supplying access points to all Red Hat Directory and Certificate server instances installed across a network.
Page 238 The Administrative Interface Log into Red Hat Console by filling in the following field: User ID. Type the administrator user ID. You should login using the administrator user ID, using the Manager user ID allows you full privileges with cn=Directory Directory Server, but does not allow you to create CS server instances.
Page 239: The Cs Console
The Administrative Interface The CS Console The CS console is a GUI-based administration interface that allows you to perform day-to-day operational and managerial duties for CS and configure the server. You launch the CS console from within Red Hat Console. You can use the CS console to access the server locally or remotely.
Page 240 The Administrative Interface Note: If SSL client authentication is set up for this server, you will be presented with a list of your certificates to choose from in order to login. You will not be presented with the userID/Password entry dialog. The CS console opens.
Page 241: Setting Up Certificate Authentication For The Cs Console
The Administrative Interface Description. Additional information that helps you identify the CS instance. You can change this description. Installation Date. The date the server was installed. Server Root. The directory in which all servers are installed. Product Name. The complete product name. Vendor.
Page 242 The Administrative Interface Make sure the client certificate is good for SSL client authentication, otherwise, the server will not accept the client certificate and will post the following error message in the error log located in the directory <server_root>/cert-<instanceID>/logs/errors failure (14290): Error receiving connection (SEC_ERROR_INADEQUATE_CERT_TYPE - Certificate type not approved for application.) Enabling SSL Client Authentication...
Page 243 The Administrative Interface Paste the certificate into the window. Click Import. Repeat from step 6 for each administrator until the certificates for all administrators have been imported. Click Done. Stop the CS server. Go to the directory <serverRoot>/cert-<instanceID>/config Open the file CS.cfg Change the value of the parameter from...
Page 244: System Passwords
System Passwords System Passwords CS has a password-quality checker for internal passwords that you can configure to your needs. It stores token passwords in a plain text file, and stores all other passwords in an encrypted password cache file. Password-Quality Checker CS comes with a plug-in, called password-quality checker, to monitor the quality of passwords set within the CS system.
Page 245 System Passwords • For a Registration Manager the token password unlocks the private keys for the Registration Manager’s signing and SSL server certificates. • For a Data Recovery Manager the token password unlocks the private keys for the Data Recovery Manager’s storage keys and transport and SSL server certificates. •...
Page 246: Starting, Stopping, And Restarting Cs Instances
Starting, Stopping, and Restarting CS Instances Starting, Stopping, and Restarting CS Instances Each instance of CS is started, stopped, and restarted separately. This section describes how to start, stop, and restart CS instances and how to check its current status. Starting a Server Instance You can start the server from either Red Hat Console or from the command line.
Page 247: Stopping A Server Instance
Starting, Stopping, and Restarting CS Instances NOTE If CS is already running, the start-up command fails. Stop the server first using the command, then use the command. stop-cert start-cert Stopping a Server Instance You can stop the server from either Red Hat Console or from the command line. With this version of CS, CS is enabled for a clean shutdown.
Page 248: Restarting A Server Instance
Subsystem Configuration Overview Restarting a Server Instance You can restart the server from either Red Hat Console or from the command line. Restarting From the CS Console To restart a CS instance from the CS console: Log in to Red Hat Console (see “Logging Into Red Hat Console” on page 237). Double-click the CS instance you want to open from the Red Hat Console navigation tab, or select the instance and click Open.
Page 249: Configuring Multiple Cs Instances
Subsystem Configuration Overview Configuring Multiple CS Instances When CS is installed on a host, a single instance of CS is also created and ready to be configured. You can created more instances of the server on the same machine and then set them up.
Page 250: Mail Server
Mail Server Select the CS instance you want to remove and choose Remove Server from the Object menu. Alternatively, you can select the CS instance you want to remove and then right-click your mouse choosing Remove Server from the pop-up menu. When prompted, confirm that you want to remove the instance.
Page 251: Locating The Configuration File
Configuration Files When you install CS, the installer creates an ASCII file, named , and populates it CS.cfg with the appropriate configuration parameters. You can control the way CS functions by making the appropriate changes in the CS console, which is the recommended method for making configuration changes.
Page 252: Guidelines For Editing The Configuration File
Configuration Files Stop the CS instance whose configuration file you want to edit (see “Starting, Stopping, and Restarting CS Instances” on page 246). The configuration file is stored in the cache when you start CS. Any changes you make to CS through the CS console are changed in the cached version of the file. When you stop or restart the server, the configuration file stored in the cache is written to disk.
Page 253 Configuration Files • The parameter names and their values are strings. The parameter names can be hierarchically structured with notation with multiple levels—for example, . The entries corresponding to a lower ca.Policy.rule.RSAKeyRule.maxSize level (such as in the example) can be requested from the configuration Policy corresponding to its higher level ( in the example).
Page 254: Duplicating Configuration From One Instance To Another
Configuration Files You can create as many instances of an implementation as you like; each instance ❍ must have a unique name. To do this, you would copy all of the parameters belonging to the module used to create the instance. Change the name of each of these parameters to the new name for this instance, and then change the value of all the parameters as is appropriate for your needs.
Page 255: Logs
Logs Logs This section explains how to use the CS console to configure logs maintained by CS, and how to monitor the server’s activities by viewing log contents. This section contains the following sub-sections: • About Logs • Configuring Logs in the CS Console •...
Page 256 Logs Error and Access Logs The error and access logs are created by Red Hat Enterprise Server, which is installed with CS providing HTTP services. The error log contains the HTTP error messages the server has encountered. The access log lists access activity through the HTTP interface. These logs are not available or configurable from within CS;...
Page 257: Services That Are Logged
Logs Transactions Log This log records messages specific to the certificate service—messages such as certificate requests, certificate renewal and revocation requests, and CRL publication—and enables you to detect any unauthorized access or activity. This log is on by default. Signed Audit Log This log contains audit records for events that have been set up as recordable events.
Page 258: Log Levels (Message Categories)
Logs Table 8-1 Services Logged (Continued) Service Description OCSP Specifies logged events related to OCSP. Others Specifies logged events related to other activities of this server, such as command-line utilities and other processes. Registration Authority Specifies logged events related to the Registration Manager. Request Queue Specifies logged events related to the request queue activity of this server.
Page 259: Buffered Versus Unbuffered Logging
Logs Table 8-2 Classification of Log Entries or Messages (Continued) Log level Message category Description Failure These messages indicate errors and failures that prevent (default selection for the server from operating normally. system and error logs) Examples of messages that fall into this category include failures to perform a certificate service operation (“User authentication failed”...
Page 260 Logs If you configure for buffered logging, the server creates buffers for the corresponding logs, and it holds the messages in these buffers for as long as possible. The server flushes out the messages to the log files only when either of the following conditions occurs: •...
Page 261: Configuring Logs In The Cs Console
Logs Note that signing log files is an alternative to the signed audit logs feature. Signed audit logs allows you to create audit logs that are automatically signed, whereas this process describes how to manually sign archived logs. See “Signed Audit Log,” on page 257 for details about signed audit logs.
Page 262 Logs Click Edit/View. The Log Event Listener Editor window opens. Continue to step 4. Make changes to the following fields in the Log Event Listener Editor window: Log Event Listener ID. Type a unique name that will help you identify the listener; be sure to note the following: Use any combination of letters ( ), digits (0 to 9), an underscore (_), and a...
Page 263: Configuring Logs In The Cs.cfg File
Logs expirationTime. Type, in seconds, the age limit for deleting the rotated log files. The default value is 0 seconds, which indicates that the rotated log files should not be deleted. If you provide a value, the rotated log will be deleted from your system after that time has elapsed.
Page 264 Logs bufferSize. Specify the buffer size in kilobytes (KB) for the log. The default size is 512 KB. For more information, see “Buffered Versus Unbuffered Logging” on page 259. Once the buffer reaches this size, the contents of the buffer are flushed out and copied to the log file.
Page 265: Monitoring Logs
Logs Monitoring Logs When you have problems with CS that require troubleshooting, you may find it helpful to check the error or informational messages that the server has logged. Also, by examining the log files you can monitor many aspects of the server’s operation. You can view certain log files in the CS console.
Page 266: Signing Log Files
Logs Date. Indicates the date on which the entry was logged. Time. Indicates the time at which the entry was logged. Details. Provides a brief description of the log. To view an entry in its entirety, either double-click it or select the entry and click View. Signing Log Files CS allows you to digitally sign log files before you archive them or distribute them for audit purposes.
Page 267: Registering A Log Module
Logs Specifies the path to the directory that contains the log <input> files. Registering a Log Module You can create new log modules using the CS SDK. If you do create a log module, you need to register it before it is available for use. You can register new log plug-in modules using the CS console.
Page 268: Deleting A Log Module
Signed Audit Log Deleting a Log Module You can delete unwanted log plug-in modules using the CS console. Before deleting a module, be sure to delete all the listeners that are based on this module; see “Log File Rotation” on page 260. To delete a module: Log in to the CS console (see “Logging Into the CS Console”...
Page 269 Signed Audit Log Table 8-3 Signed-Audit Log Events Logging Event Type of Log Messages are Generated The startup of the subsystem, and thus the start of the AUDIT_LOG_STARTUP startup of the audit function. The shutdown of the subsystem, and thus the start of the AUDIT_LOG_SHUTDOWN startup of the audit function.
Page 270 Signed Audit Log Table 8-3 Signed-Audit Log Events Logging Event Type of Log Messages are Generated The path or name for the signed audit, system, LOG_PATH_CHANGE transaction or any customized log is changed. Note: The authorization system should not allow such a change. When an attempt is made to change log expiration time.
Page 271: Setting Up Signed Audit Logs
Signed Audit Log Table 8-3 Signed-Audit Log Events Logging Event Type of Log Messages are Generated When proof of possession is checked during certificate PROOF_OF_POSSESSION enrollment. When a CRL is retrieved by the OCSP Responder CRL_RETRIEVAL When a CRL is retrieved and validation process occurs. CRL_VALIDATION Used when CMC (agent-pre-signed) cert requests or CMC_SIGNED_REQUEST_SIG_VER...
Page 272: Audit Logging Failures
Self Tests Set up the signed audit log—it is disabled by default—by setting it up in Red Hat Console. Follow the procedure in the section “Configuring Logs in the CS Console,” on page 261. Specify the nickname of the log you received in the previous step as the value of the parameter and specify the events that will signedAuditCertNickname...
Page 273: Self Test Logging
Self Tests The self-tests are run at start up and can also be run on demand. The start up self tests run when the server starts up, and will keep the server from starting up if a critical self-test fails. The on-demand self tests are run by clicking the self tests button in a new CS window interface page.
Page 274: Modifying Self Test Configuration
Self Tests You turn the self test off, or change which self tests are considered critical by changing those setting in the file. To turn a self test off, you remove from the list of self tests CS.cfg that run either on-demand or at start up. Modifying Self Test Configuration To modify the configuration settings for self tests: Stop the CS instance.
Page 275: Ports
Ports maxFileSize. Specify the file size in kilobytes (KB) for the error log. The default size is 100 KB. The determines how large a log file can become before it is maxFileSize rotated. Once it reaches this size, the file is copied to a rotated file, and the log file is started anew.
Page 276 Ports Figure 8-1 CS Ports Port Considerations When choosing ports for CS consider the following: • Be sure to choose ports that are unique on the host system. • To verify that a port is available for use, check the appropriate file for your operating system;...
Page 277 Ports Administration Port The administration port is an SSL (encrypted) port on which CS listens to requests from its administration interface, the CS console. When you install CS, a random number (greater than 1024) is assigned to the administration port. You can change this port number at any time, to any number between 1 and 65535.
Page 278: Changing A Port Number
Ports • The HTTP port can be used to service end-entity-initiated PKI requests, such as enrollment, renewal, and revocation; enrollment requests can include requests from Cisco routers (using the CEP protocol); general certificate retrieval requests, such as retrieving a single certificate identified by a serial number, listing certificates based on certain criteria (for example, an LDAP search filter defined over standard attributes), and getting a CA’s certificate chain.
Page 279 Ports To change the agent port, locate this line and edit the value of the attribute: port ❍ <LS id="agent" ip="0.0.0.0" port="8100" security="on" acceptorthreads="1" blocking="no"> To change the end-entity HTTP port, locate this line and edit the value of the port ❍...
Page 280: Changing An Ip Addresses
Changing an IP Addresses Changing an IP Addresses You can configure CS instances to listen to specific IP addresses. For example, you can install the Certificate Manager and Data Recovery Manager on a single host, in separate instances, and then configure the instances so that the Certificate Manager is served on one IP address and the Data Recovery Manager is served on another address, if the host is configured with more than one IP address.
Page 281: The Internal Database
The Internal Database The Internal Database Each instance of CS uses a Red Hat Directory Server instance as its internal database. When you install a CS instance, an internal database is created for that instance. The install program also allows you to share a directory server between two or more instances. You can change the internal database used by a CS instance.
Page 282: Changing The Internal Database Configuration
The Internal Database • In Red Hat Console, you can distinguish an internal database instance from other Directory Server instances. It is in this form: <CS_instance_id>-db is the ID of the CS instance that is using the database. You first <CS_instance_id>...
Page 283: Enable Ssl Client Authentication With The Internal Database
The Internal Database Port number. Type a TCP/IP port number; CS uses this port for non-SSL communications with the Directory Server instance that is functioning as the internal database. Make sure that the port you specify is unique on the host system. Directory manager DN.
Page 284: Restricting Access To The Internal Database
The Internal Database Go to Directory tab and Right click “ ”. DirectoryServer Add the entry created in Step 6 into the Configuration Administrators group. Click “set Access Control Permission” and then Click Add. Fill in the following information: ACIName. clientauth Check all the rights in the Rights tab.
Page 285: Managing The Certificate Database
Managing the Certificate Database Click Save to save your changes. You are prompted to restart the server. Click the Tasks tab and click “Restart the Directory Server.” Close the Directory Server console. When the server is restarted, from Red Hat Console, open the Directory Server console. The “Login to Directory”...
Page 286: Changing The Trust Settings Of A Ca Certificate
Managing the Certificate Database Removing unwanted certificates also reduces the size of the certificate database. NOTE When deleting CA certificates from the certificate database, be careful not to delete the intermediate CA certificates, which help a subsystem chain up to the trusted CA certificate. If in doubt, leave the certificates in the database as untrusted CA certificates;...
Page 287 Managing the Certificate Database You may need to change the status of a currently trusted CA to untrusted (or vice versa) temporarily or permanently. By making the CA certificate untrusted, you can prevent entities whose certificates have been signed by that CA from successfully authenticating to CS.
Page 288: Installing A New Ca Certificate In The Certificate Database
Managing the Certificate Database Installing a New CA Certificate in the Certificate Database You may need to install new trusted CA certificates in the certificate database of a CS instance. For example, assume that you renewed the signing certificate of a Registration Manager.
Page 289: Certificate Setup Wizard
Managing the Certificate Database Certificate Setup Wizard CS provides a wizard, called the Certificate Setup Wizard, which automates the process of requesting and installing the certificates required by the CS manager—Certificate Manager, Registration Manager, Data Recovery Manager, or Online Certificate Status Manager—installed in a CS instance.
Page 290 Managing the Certificate Database Using the wizard to request a certificate involves the following steps: • Step 1. Select the Operation • Step 2. Choose the Certificate • Step 3. Specify the Key-Pair Information • Step 4. Specify the Subject Name for the Certificate •...
Page 291 Managing the Certificate Database Depending on the certificate you want to generate, choose the one in the drop-down list: • Certificate Manager Signing Certificate—choose this option if you want to request a signing certificate for the Certificate Manager. If you choose this option, you must also specify whether the certificate request is for a self-signed CA (also known as the root CA) or a subordinate CA.
Page 292 Managing the Certificate Database The names of external tokens vary, matching the names specified when the tokens ❍ were installed. You should choose this option if the key pair for the certificate you chose in the previous step is in an external cryptographic device. If you don’t see the token you want to use, exit from the wizard, make sure the token is installed properly, restart the server, and repeat the process.
Page 293 Managing the Certificate Database Step 4. Specify the Subject Name for the Certificate Specify the subject name, in distinguished name (DN) format, for the certificate to be requested. Note that you will see this screen only if you chose to generate the certificate for a new key pair.
Page 294 Managing the Certificate Database Step 6. Specify Extensions You need to complete this step only if you chose to generate a CA signing certificate request for a Certificate Manager (deployed as either the root CA or a subordinate CA). This screen allows you to set the standard X.509 version 3 extensions and Red Hat-defined extensions for the certificate to be requested.
Page 295 Managing the Certificate Database CS provides tools that generate MIME-64 encoded blobs for many standard extensions. You can use these tools for generating MIME-64 encoded blobs for any extensions that you may want to include in CA and other certificate requests. For details about these tools, check this directory in your CS installation: <server_root>/bin/cert/tools Note that the text field provided for pasting the extension in general accepts a single...
Page 296 Managing the Certificate Database Table 8-4 Names of files created for certificate signing requests (Continued) Filename Certificate Signing Request Registration Manager signing certificate racsr.txt Data Recovery Manager transport certificate kracsr.txt Online Certificate Status Manager signing certificate ocspcsr.txt SSL server certificate sslcsr.txt Other certificates, such as Certificate Manager CRL signing othercsr.txt...
Page 297 Managing the Certificate Database Click Next to submit your request to the CA. The Certificate Manager returns a request ID for your request. Note the request ID as you can use it later to get the certificate from the Certificate Manager to which you submitted the request.
Page 298 Managing the Certificate Database In the form that appears, enter the required information and paste the CSR from either the clipboard or text file. For information on how a form works, click the Help button provided on the form. Be sure to include the marker lines, -----BEGIN NEW CERTIFICATE REQUEST----- -----END NEW CERTIFICATE REQUEST-----...
Page 299 Managing the Certificate Database Step 8. Check the Certificate Request Status The wizard now informs you of the status of the request. • If you requested a self-signed CA certificate, the wizard automatically submits the CSR to the CA. If the CSR includes all the required information, the CA signs the certificate and returns it to the wizard, which then installs it in the appropriate token.
Page 300 The value of the field should be contentType , while the content field is the following structure: redhat-cert-sequence CertificateSequence ::= SEQUENCE OF Certificate This format allows multiple certificates to be downloaded at once. Text Formats The wizard can also import certificates and certificate chains in text formats. Here’s what...
Page 301 Managing the Certificate Database Following this line should be the certificate data, which can be in any of the binary formats described in “Binary Formats” on page 300. This data should be base-64 encoded as described by RFC 1113 (for details, see http://www.scit.wlv.ac.uk/rfc/rfc11xx/RFC1113.html Following the certificate data must be this line: -----END CERTIFICATE-----...
Page 302 Managing the Certificate Database • Cross-Signed Certificate—choose this option if you want to install a cross-signed certificate. • Untrusted CA Certificate Chain—choose this option if you want to install an untrusted CA certificate chain. Step 3. Specify the Location of the Certificate Locate the certificate or certificate chain you want to install.
Page 303: Consideration When Getting New Certificates For The Subsystems
Managing the Certificate Database Step 4. View the Certificate or Certificate Chain The wizard displays the certificate or certificate chain you have chosen to install. Make sure you have chosen the right one; otherwise, use the Back button to go back and locate the right one.
Page 304 Managing the Certificate Database Getting a new certificate for a CS manager requires careful planning. This section provides some guidelines that will help you request and install the new certificate. Determine which certificate you want to get You can get CA signing, OCSP signing, CRL signing, and SSL server certificates for the Certificate Manager;...
Page 305: Tokens For Storing Cs Keys And Certificates
Tokens for Storing CS Keys and Certificates • If you want to get a new signing certificate for a Registration Manager, check whether the Registration Manager has been set up as a trusted manager for a Certificate Manager and Data Recovery Manager—that is, you must identify the subsystems that have been configured to receive requests from this Registration Manager;...
Page 306: Internal Token
Tokens for Storing CS Keys and Certificates Internal Token An internal (software) token refers to a pair of software files, usually called certificate database and key database, that Certificate System uses to generate and store its key pairs and certificates. Certificate System automatically generates these files in the file system of its host machine when you choose to use the internal token for the first time.
Page 307 Tokens for Storing CS Keys and Certificates Install the PKCS #11 Module PKCS #11 is a standard set of APIs and shared libraries used by Red Hat and a number of encryption vendors. PKCS #11 isolates an application from the details of the cryptographic device, thus enabling the application to provide a unified interface for PKCS #11-compliant cryptographic devices.
Page 308: Managing Tokens Used By The Subsystems
Tokens for Storing CS Keys and Certificates <server_root>/shared/bin/modutil -dbdir . -nocertdb -create This creates the required security module database file ( ) in the secmod.db Administration Server’s configuration directory. At the prompt, enter this command: <server_root>/shared/bin/modutil -dbdir . -nocertdb -add <module_name> -libfile <library_file> specifies the path to the DLL or other library file containing the <library_file>...
Page 309: Hardware Cryptographic Accelerators
Hardware Cryptographic Accelerators It is good security practice to periodically change the password that protects your server’s keys and certificates; changing the password periodically minimizes the risk of someone finding out the password. To change a token’s password, use the command-line certutil utility, the documentation for which can be found at this site:...
Page 310: Configuring The Server To Use Separate Ssl Server Certificates
Configuring the Server’s Security Preferences • The version of SSL that an instance of CS must use during SSL communication. The latest version is SSL version 3, but many older clients use SSL version 2. Because client authentication is required for performing privileged operations, you must enable SSL version 3 ciphers supported by CS.
Page 311: Getting An Ssl Client Certificate For A Subsystem
Configuring the Server’s Security Preferences To change the certificate used for authenticating to the end-entity services ❍ interface, edit the value assigned to the parameter in the servercertnickname section. id="ee_nonSSL" To change the certificate used for authenticating to the SSL-enabled end-entity ❍...
Page 312 Configuring the Server’s Security Preferences If you submitted the request to a Certificate Manager and if you have agent privileges for that Certificate Manager, log in to its Agent Services interface, locate the request, and check the request for required extensions. (If you submitted the request to any other CA, you must ask the person managing that CA to make the same changes to the request before approving it.) Make sure that only the...
Page 313: Chapter 9 Authorization
Chapter 9 Authorization This chapter explains how to set up authorization for access to the administrative, agent services, and end-entity interfaces and contains the following sections: • About Authorization • Setting up Administrators, Agents, and Auditors • Setting Up a Trusted Manager •...
Page 314: How Authorization Works
About Authorization and end-entity interface that perform an authorization check before allowing an operation to be performed in that area. Access Control Instructions (ACI s) in each of the ACLs are created that specifically allow or deny one or more possible operations for that ACL to specified users, groups, or IP addresses.
Page 315 About Authorization Administrators. This group is given full access to all of the tasks available in the administrative interface. Agents. This group is given full access to all of the tasks available in the agent services interface. Note: There is more than one agent group. A separate agent group is created for each of the subsystem with a different name.
Page 316 About Authorization Authentication of Auditors Auditors are authenticated into the CS console by using their login and password. Once authenticated, they can only view the audit logs, they are not able to edit other parts of the system. You can change the method of authentication for an auditor to SSL client authentication. See “Setting up Certificate Authentication for the CS Console,”...
Page 317 About Authorization • Data Recovery Manager Agents group is the agent group for a Data Recovery Manager. No members are added to this group during installation, you must add members after installation. • Online Certificate Status Manager Agents group is the agent group for an Online Certificate Status Manager.
Page 318: Setting Up Administrators, Agents, And Auditors
Setting up Administrators, Agents, and Auditors Trusted Manager’s Certificate for SSL Client Authentication A Registration Manager or Certificate Manager that has been set up to function as a trusted manager uses its SSL server certificate for SSL client authentication to the subsystem that trusts it.
Page 319: Storing A User's Certificate
Setting up Administrators, Agents, and Auditors Phone. Type the user’s phone number. Group. Select the correct group. Click OK. You are returned to the Users tab. The user you just added will be displayed in the list of users, and the user ID now has the privileges of the group they are assigned in this instance of CS.
Page 320: Setting Up Agents Using The Automated Process
Setting up Administrators, Agents, and Auditors Click Done. You are returned to the Users tab. Click Refresh to view the updated configuration. Setting up Agents Using the Automated Process (Not for certificate profile enrollment) CS automates the process of setting up agents if agents request their certificate using the manual enrollment form.
Page 321: Setting Up A Trusted Manager
Setting Up a Trusted Manager To verify, log in to the CS console for the Certificate Manager. In the navigation tree, click Users and Groups. The user ID you specified for the new agent will be listed there. To view the certificate issued to the new agent, select the user ID and click Certificates. Setting Up a Trusted Manager You can set up a trusted manager in two ways.
Page 322 Setting Up a Trusted Manager Providing a user ID for the subsystem. ❍ Approving the request. ❍ Setting Up a Trusted Managers Manually If you set up a Certificate Manager or a Registration Manager using the automated process either during or after installation, you do not need to perform any of the manual setup for a trusted manager.
Page 323 Setting Up a Trusted Manager Click Import. The Import Certificate dialog opens. Click inside the text area, and paste the Registration Manager’s or Certificate Manager’s certificate in base-64 encoded form. Be sure to include the -----BEGIN CERTIFICATE----- -----END marker lines. CERTIFICATE----- Click OK.
Page 324: Agent Certificates
Agent Certificates The Edit Connector dialog opens. Select Enable to enable the connector configuration, and enter the appropriate information: Host. Type the fully qualified host name of the subsystem that trusts this Registration Manager or Certificate Manager. Port. Type the number of the TCP/IP port number of the agent port for the subsystem that trusts this Registration Manager or Certificate Manager.
Page 325: First Agent Certificate For A Certificate Manager
Agent Certificates First Agent Certificate for a Certificate Manager CS adds the administrator set up during installation of a Certificate Manager as the first agent if this option is selected during installation. A special agent enrollment form is provided for this administrator to get the agent certificate. This form is automatically disabled after this initial request is approved and the certificate is issued.
Page 326 Agent Certificates Country. Type the two-letter code for the administrator/agent’s country. Validity. Set certificate validity period by selecting dates, for which certificate is not valid before and not valid after. Click Submit. Follow the instructions your browser presents as it generates a key pair. If authentication is successful, the new certificate will be imported into your browser.
Page 327: Getting An Agent's Certificate From A Public Ca
Agent Certificates Getting an Agent’s Certificate from a Public CA The following general guidelines explain how a user can get a client certificate from a public CA and how you can copy that certificate (in base-64 encoded form) to the internal database of the appropriate subsystem: Have the user send a client certificate request to a public CA from the computer they will use to access the subsystem from the Agent Services interface.
Page 328 Agent Certificates The user sends a client certificate request to CS from the computer that they will use to access the subsystem from the Agent Services interface. It is important that user generate and submit this request from the computer they will use later to access the subsystem, because part of this request process generates a private key on the local machine.
Page 329: Revocation Status Checking Of Agent Certificates
Agent Certificates Revocation Status Checking of Agent Certificates You can configure a Certificate Manager and Registration Manager to check the revocation status of an agent’s certificate the server receives during SSL client authentication. You can configure a Data Recovery Manager (or Online Certificate Status Manager) to check the revocation status of its agents’...
Page 330 Agent Certificates Specifies the total number of last-checked revocationChecking.bufferSize certificates the server should maintain in its cache. For example, if you configure the buffer size to be 2, the server retains the last two certificates it checked in its cache. By default, the server caches the last 50 certificates.
Page 331: Modifying Cs User Entries
Modifying CS User Entries Modifying CS User Entries You can change a user entry, delete the user, or change the certificate associated with the user. Changing a CS User’s Login Information To change a CS user’s login information: Log in to the CS console (see “Logging Into the CS Console” on page 239). In the navigation tree, select Users and Groups.
Page 332: Changing Members In A Group
Modifying CS User Entries To add a new certificate for this user to the internal database, click Import. In the ❍ Import Certificate window that appears, paste the new certificate in the text area. Be sure to paste the entire base-64 encoded block, including the -----BEGIN marker lines.
Page 333: Deleting A Cs User
Creating a New Group Deleting a CS User You can delete CS users from the internal database. Deleting a user from the internal database deletes that user from all groups to which the user belongs. If you want to delete a user from specific groups, you should modify the appropriate groups;...
Page 334: Authorization For Cs Users
Authorization for CS Users Edit the ACLs to give this group the privileges you want this group to have. See “Authorization for CS Users,” on page 334 for complete information. If you don’t add ACIs to the ACLs giving this group permissions, the group will have no access permissions to any part of CS.
Page 335: How Acis Are Formed
Authorization for CS Users for administrators who are only authorized to view logs. You could name the group and modify the ACLs relevant to logs to allow read or modify access to this LogAdmins group. If you did not add this group to any other ACLs, members of this group would only have access to the logs.
Page 336 Authorization for CS Users If a user is not allowed access to any of the operations for a resource, then this user is considered denied; they do not specifically need to be denied access. For example, user is a member of the group Administrators. If an ACL has only the following ACI, JohnB would be denied any access since he does not match any of the allow ACIs: JohnB...
Page 337 Authorization for CS Users to specify that the user ID named is to be allowed or denied access to the user=”userID” operation specified. to specify that any user ID except for the user ID named is to be allowed user!=”userID” or denied access to the operation specified.
Page 338: Editing Acls
Authorization for CS Users Editing ACLs ACLs are stored in the internal database and can only be modified in the CS console interface. To edit the existing ACLs: Log in to the CS console (see “Logging Into the CS Console” on page 239). In the navigation tree, select Access Control List.
Page 339: Acl Reference
ACL Reference Select Allow or Deny from the Access field to allow or deny the operation specified in this ACI to the group(s), user(s) or IP address(es) specified. For more information about allowing or denying access, see “Allow and Deny,” on page 335.
Page 340: Certserver.admin.certificate
ACL Reference Agents, administrators, and auditors can read ACL configuration; only administrators can modify ACL configuration. certServer.admin.certificate This entry is associated with the CA administration interface and is ONLY available during the setup configuration of the target of evaluation (TOE), and is unavailable after the CA is up and running.
Page 341: Certserver.auth.configuration
ACL Reference certServer.auth.configuration Allow or deny a read or modify operation to the authentication configuration. Operations read Viewing authentication plug-ins, authentication type, configured authentication manager plug-ins, and authentication instances. Listing authentication manager plug-ins and authentication manager instances. modify Adding or deleting authentication plug-in and authentication instance. Modifying authentication instance.
Page 342: Certserver.ca.certificates
ACL Reference certServer.ca.certificates Allow or deny a revoke or list operation to certificates in the agent services interface. Operations revoke Revoking certificates, or approving certificate revocation requests. list Listing certificates based on a search. Retrieving details about a range of certificates based on providing a range of serial numbers.
Page 343: Certserver.ca.connector
ACL Reference certServer.ca.connector Allow or deny a submit operation for a connection to the CA. Operations submit Submitting requests from remote trusted managers. Default ACIs allow (submit) group="Trusted Managers" Trusted Manager can submit requests to this interface. certServer.ca.clone Allow or deny a submit operation for a connection to the CA by a cloned CA. Operations submit Submitting information about a revoked certificate from a cloned CA.
Page 344: Certserver.ca.directory
ACL Reference certServer.ca.directory Allow or deny an update operation to the directory. Operations update Publishing CA certificates and user certificates to the LDAP directory. Default ACIs allow (update) group="Certificate Manager Agents" Certificate Manager agents can update the directory. certServer.ca.group Allow or deny an update operation to add a group. Operations Adding groups.
Page 345: Certserver.ca.profile
ACL Reference Operations list Listing certificate profiles. Default ACIs allow (list) group="Certificate Manager Agents" Certificate Manager agents can list certificate profiles. certServer.ca.profile Allow or deny a read or approve operation for certificate profiles in the agent services interface. Operations read Viewing the details of a certificate profile.
Page 346: Certserver.ca.request.profile
ACL Reference Operations submit Submitting an enrollment request. read Viewing an enrollment request. execute Modifying the approval state of a request. assign Assigning a request to a Certificate Manager Agent. unassign Changing the assignment of a request. Default ACIs allow (submit) user="anybody" allow (read,execute,assign,unassign) group="Certificate Manager Agents"...
Page 347: Certserver.ee.certificate
ACL Reference Operations read Viewing statistics. Default ACIs allow (read) group="Certificate Manager Agents" Only Certificate Manager agents may view statistics. certServer.ee.certificate Allow or deny a renew, revoke, read, or import operation in the end-entity interface. Operations renew Submitting a certificate for a renewal of an existing certificate. revoke Submitting a revocation for a user’s own certificate.
Page 348: Certserver.ee.certchain
ACL Reference certServer.ee.certchain Allow or deny a download or read operation for the CA’s certificate chain in the end-entity interface. Operations download Downloading the CA's certificate chain. read Viewing the CA's certificate chain. Default ACIs allow (download,read) user="anybody" Anyone can read or download a CA’s certificate chain. certServer.ee.crl Allow or deny a read or add operation for CRLs in the end-entity interface.
Page 349: Certserver.ee.profiles
ACL Reference certServer.ee.profiles Allow or deny a list operation for certificate profiles in the end-entity interface. Operations list Listing of certificate profiles. Default ACIs allow (list) user="anybody" Anyone can list certificate profiles. certServer.ee.facetofaceenrollment Allow or deny a list operation for certificate profiles to read face to face enrollment pages. Operations read Read face to face enrollment page.
Page 350: Certserver.ee.request.ocsp
ACL Reference Operations submit Submiting face to face enrollment. Default ACIs allow (submit) user="anybody" Anyone can submit face to face enrollment. certServer.ee.request.ocsp Allow or deny to submit ocsp requests. Operations submit Submitting OCSP requests. Default ACIs allow (submit) user="anybody" Any clients can submit OCSP requests certServer.ee.request.revocation Allow or deny a submit operation for certificate revocation requests in the end-entity interface.
Page 351: Certserver.general.configuration
ACL Reference Operations read Retrieving the status of a request, and serial numbers of any certificates that have been issued against that request. Default ACIs allow (read) user="anybody" Anyone can read a request status. certServer.general.configuration Allow or deny a read or modify operation to the general configuration of the subsystem. Operations read Viewing operating environment, LDAP configuration, SMTP...
Page 352: Certserver.kra.certificate.transport
ACL Reference Operations read Viewing basic job settings, job instance settings, and job plug-in settings. Listing job plug-ins and job instances. modify Adding and deleting job plug-ins and job instances. Modifying job plug-ins and job instances. Default ACIs allow (read) group="Administrators" || group=”Certificate Manager Agents”...
Page 353: Certserver.kra.connector
ACL Reference Operations read Viewing automatic key recovery automatic configuration, key recovery archive configuration, and notification request in queue configuration. modify Modifying automatic key recovery archive configuration, agent passwords, scheme, and notification request in queue configuration. Default ACIs allow (read) group="Administrators" || group="Auditors" || group=”Certificate Manager Agents”...
Page 354: Certserver.kra.keys
ACL Reference Operations read Displaying a key recovery request. recover Indicating that a Data Recovery Manager has approved the key recovery. Finalizing a key recovery operation. download Downloading a PKCS#12 file containing a private key. Default ACIs allow (read,recover,download) group="Data Recovery Manager Agents" Only Data Recovery Manager agents can read, recover, or retrieve key information.
Page 355: Certserver.kra.request.status
ACL Reference Operations list Retrieve a range of key archival requests. Default ACIs allow (list) group="Data Recovery Manager Agents" Only Data Recovery Manager Agents can list key archival requests. certServer.kra.request.status Allow or deny a read operation for a Data Recovery Manager request. Operations read Getting the status of a completed key recovery request.
Page 356: Certserver.log.configuration.signedaudit.expirationtime
ACL Reference Operations read Viewing log plug-in information, log plug-in configuration, log instance configuration. Listing log plug-ins and log instances. modify Adding and deleting log plug-ins and log instances. Modifying log instances. Default ACIs allow (read) group="Administrators" || group="Auditors" || group=”Certificate Manager Agents”...
Page 357: Certserver.log.configuration.filename
ACL Reference certServer.log.configuration.fileName Allow or deny a read or modify operation to the parameter of a log instance. fileName Operations read Viewing the value of the parameter for a log instance showing fileName the name of the log. modify Modifying the value of the parameter for a log instance fileName showing the name of the log.
Page 358: Certserver.ocsp.ca
ACL Reference Operations read Viewing log content. Listing all logs. Default ACIs allow (read) group="Administrators" || group="Auditors" || group=”Certificate Manager Agents” || group=”Registration Manager Agents” || group=”Data Recovery Manager Agents” || group=”Online Certificate Status Manager Agents” Administrators, agents, and auditors can read all logs. certServer.ocsp.ca Allow or deny an add operation for adding a CA to an Online Certificate Status Manager.
Page 359: Certserver.ocsp.certificate
ACL Reference certServer.ocsp.certificate Allow or deny a validate operation for checking certificate revocation information. Operations validate Checking if the OCSP responder has data indicating that a certificate is revoked. Default ACIs allow (validate) group="Online Certificate Status Manager Agents" Online Certificate Status Manager agents can validate certificate status. certServer.ocsp.configuration Allow or deny a read or modify operation to the OCSP configuration.
Page 360: Certserver.policy.configuration
ACL Reference Operations Submitting a CRL with new revocation status information. Default ACIs allow (add) group="Online Certificate Status Manager Agents" Online Certificate Status Manager agents can add CRL. certServer.policy.configuration Allow or deny a read or modify operation to the policy configuration. Operations read Viewing policy plug-ins and instances.
Page 361: Certserver.publisher.configuration
ACL Reference Operations read Viewing certificate profile defaults and constraints, certificate profile input, certificate profile output, certificate profile input configuration, certificate profile output configuration, default configuration, policy constraints configuration, and certificate profile instance configuration. Listing certificate profile plug-ins and certificate profile instances. modify Adding, modifying, and deleting certificate profile defaults and constraints, certificate profile input, certificate profile output, and...
Page 362: Certserver.ra.configuration
ACL Reference allow (modify) group="Administrators" Administrators, auditors, and agents are allowed to read publisher configuration; only administrators are allowed to modify publisher configuration. certServer.ra.configuration Allow or deny a read or modify operation for the configuration of a Registration Manager (RA). Operations read Viewing general RA configuration, connector configuration, notification...
Page 363: Certserver.ra.connector
ACL Reference Operations import Retrieving a certificate by serial number. unrevoke Removing the revoked status from a certificate. revoke Revoking certificates, or approving certificate revocation requests. read Retrieving certificates based on associated request ID. Displaying certificate details for a certificate, based on associated request ID Default ACIs allow (import,unrevoke,revoke,read) group="Registration Manager Agents"...
Page 364: Certserver.ra.facetofaceenrollment.enablehosts
ACL Reference certServer.ra.facetofaceenrollment.enableHosts Allow or deny reading all hosts enabled for face to face registration Operations read Read all hosts enabled for face to face registration. Default ACIs allow (read) group="Registration Manager Agents" Allow only Registration Manager agents to read hosts enabled for face to face registration certServer.ra.group Allow or deny adding groups.
Page 365: Certserver.ra.profiles
ACL Reference certServer.ra.profiles Allow or deny a list operation to certificate profiles in the agent services interface in a Registration Manager. Operations list Displaying a list of certificate profiles. Default ACIs allow (list) group="Registration Manager Agents" Registration Manager agents can list certificate profiles. certServer.ra.request.enrollment Allow or deny a submit, read, or execute operation to enrollment requests in the agent services interface of a Registration Manager.
Page 366: Certserver.ra.requests
ACL Reference Operations approve Modifying the approval state of a certificate profile-based request. read Viewing a certificate profile-based request. Default ACIs allow (approve,read) group="Registration Manager Agents" Registration Manager agents can view and approve certificate profile-based requests. certServer.ra.requests Allow or deny a list operation for requests in the agent services interface of a Registration Manager.
Page 367: Certserver.ra.systemstatus
ACL Reference certServer.ra.systemstatus Allow or deny a read operation to the system status of the Registration Manager. Operations read Providing statistical data of request and certificate records. Default ACIs allow (read) group="Registration Manager Agents" Only Registration Manager Agents can view system status. certServer.usrgrp.administration Allow or deny a read or modify operation to the user and group configuration.
Page 368 ACL Reference Red Hat Certificate System Administrator’s Guide • September 2005...
Page 369: Chapter 10 Authentication
Chapter 10 Authentication This chapter discusses the authentication methods available in Red Hat Certificate System (CS) during the enrollment of end entities, and details how to set up those authentication methods. This chapter contains the following sections: • Enrollment Overview •...
Page 370: How Authentication Works
Enrollment Overview • Agent-approved enrollment is the method in which end-entity enrollment requests are sent to an agent for approval. The agent approves the certificate request. • Automatic enrollment is the method in which end-entity enrollment requests are authenticated using a plug-in for that type of authentication, and then the certificate request is processed;...
Page 371: About Renewal
Enrollment Overview If the authentication method is an agent-approved enrollment, the end entity submits the request, which is then sent to the request queue of the agent services interface. If the automated notification for request in queue is set up, an email message is sent to the agent or agents set up to receive this message, informing them that a new request has been received.
Page 372: Dual-Key Pairs
Dual-Key Pairs • The certificate being presented by the end user for renewal must be currently valid or must have expired; it cannot have been revoked. • The validity period of a renewed certificate is determined by the policy rule , see “RenewalValidityConstraints,”...
Page 373: Agent-Approved Enrollment
Agent-Approved Enrollment Agent-Approved Enrollment Both the Registration Manager and Certificate Manager are initially configured for agent-approved enrollment. An end entity makes a request which is then sent to the agent services interface for an agent’s approval. An agent can change some aspects of the request, change the status of the request, reject the request, or approve the request.
Page 374: Setting Up Directory Based Enrollment
Automated Enrollment • Pin Based Enrollment. End entities are authenticated against an LDAP directory using their user ID, password, and a pin you set up in their directory entry and then given to the end entity. See “Setting Up Pin Based Enrollment,” on page 377. •...
Page 375 Automated Enrollment • In the case of policy-based enrollments, customize the HTML enrollment forms. Make sure the proper authentication method is contained in the form, and do any other customization required. In the enrollment form you use, be sure to include the following line, and replace with the name of the authentication instance you added.
Page 376 Automated Enrollment ldapStringAttributes. Specifies the list of LDAP string attributes that should be considered authentic for the end entity. If specified, the values corresponding to these attributes will be copied from the authentication directory into the authentication token—that is, values retrieved from this parameter can be used by policy modules to formulate subject names for certificates or to make other policy decisions.
Page 377: Setting Up Pin Based Enrollment
Automated Enrollment Setting Up Pin Based Enrollment Pin based authentication involves setting up pins for each of your users in the LDAP directory, distributing those pins to your users, and then having the users provide their pin along with their user ID and password when they fill out a certificate request. Users are then authenticated both against an LDAP directory using their user ID and password, and against the pin that is contained in their LDAP entry.
Page 378 Automated Enrollment • Adds the necessary schema for pins to the LDAP directory. • Adds a pin manager user who has read-write permissions to the pins that are set up. • Sets up ACIs to allow for pin removal once the pin has been used, giving read-write permissions for pins to the pin manager, and preventing users from creating or changing pins.
Page 379 Automated Enrollment Use the output file for delivering PINs to users after you complete setting up the required authentication method. After you have confirmed that the PIN-based enrollment works, deliver the PINs to users so they can use them during enrollment. To protect the privacy of PINs, be sure to use a secure, out-of-band method for delivery.
Page 380 Automated Enrollment removePin. Specifies whether to remove PINs from the authentication directory after end users successfully authenticate. Removing PINs from the directory restricts users from enrolling more than once, and thus prevents them from getting more than one certificate. Select if you want to remove PINs providing the bindDN and password of the pin manager.
Page 381 Automated Enrollment ldap.ldapauth.bindDN. Specifies the user entry to bind as when removing PINs from the authentication directory. You need to specify this parameter only if you’ve selected . It is recommended that you create and use a separate user entry that has removePin permission to modify only the PIN attribute in the directory.
Page 382: Setting Up Portal Enrollment
Automated Enrollment Setting Up Portal Enrollment Portal enrollment enables you to issue certificates and create directory entries for users who do not yet have an entry in your directory. Portal enrollment involves registering users by adding them to your directory while simultaneously issuing them a certificate. When a user requests a certificate, the information they provide is used to add the user to the directory, if an entry does not presently exist for that user, and to issue the user a certificate.
Page 383 Automated Enrollment • Set any policies for certificate extensions, or for constraints on certificates, see Chapter 12, “Policies” for information about policies. Alternatively, you can enroll users through the certificate profile functionality setting policies for specific certificates in the certificate profile, see Chapter 11, “Certificate Profiles” for information about policies.
Page 384 Automated Enrollment Authentication Instance ID. Accept the default instance name, or enter a new name. If you chose to use a different name, be sure to edit this name in the enrollment forms. dnpattern. Specifies a string representing a subject name pattern to formulate from the directory attributes and entry DN.
Page 385: Setting Up Cmc Enrollment
Automated Enrollment ldap.basedn. Specifies the base DN for searching the authentication directory—the server uses the value of the field from the HTTP input (what a user enters in the enrollment from) and the base DN to construct an LDAP search filter. ldap.objectclass.
Page 386 Automated Enrollment • Use your agent certificate to sign certificate requests using the utility. See CMCEnroll “CMC Enroll Utility,” on page 386 for information on signing requests. Setting Up the CMCAuth Authentication Plug-in Note: This method of authentication is setup by default. You only need to perform the following procedure if you deleted the instance that was set up by default.
Page 387 Automated Enrollment where The location of the directory containing the , and cert8.db key3.db associated with the agent certificate. secmod.db files Password to the database specified in the option. The common name of the certificate. The file name of the certificate request. The password to the browser certificate database.
Page 388 Automated Enrollment <form method="post" action="/enrollment" onSubmit="return validate(document.forms[0])"> Add the following line below the line you just found: <input type="hidden" name="authenticator" value="CMCAuth"> Testing CMCEnroll Enable CMCEnroll. Create a certificate request. You can use the tool found in the following certutil directory to create the request: <server_root>/bin/cert/tools Copy the pkcs10 ascii output to a text file.
Page 389: Agent Initiated End User Enrollment
Agent Initiated End User Enrollment Remove "-----BEGIN NEW CERTIFICATE REQUEST-----" "----END from the pasted content. NEW CERTIFICATE REQUEST-----" Select Certificate Type User Certificate, fill in the contact information, and submit the form. The certificate will be immediately processed and returned since a signed request was sent, and the CMCAuth plug-in was enabled.
Page 390: Certificate-Based Enrollment
Certificate-Based Enrollment • Customize the HTML enrollment forms. Make sure the proper authentication method is contained in the form, and do any other customization required. In the enrollment form you use, be sure to include the following line, and replace with the name of the authentication instance you added.
Page 391: Setting Up Certificate Based Enrollment
Certificate-Based Enrollment Setting Up Certificate Based Enrollment General guidelines to set up certificate-based enrollment are as follows: • Customize the enrollment form you want your users to use for enrollment. • Enable the appropriate enrollment option, such as directory-based enrollment or certificate-based enrollment.
Page 392: Issuing And Managing Server Certificates
Issuing and Managing Server Certificates In general, the following three hidden variables distinguish certificate-based enrollment forms from other enrollment forms: —this variable specifies whether certificate-based enrollment is certauthEnroll ❍ turned —this variable specifies one of the three certauthEnrollType ❍ certificate-based-enrollment types: , or dual single...
Page 393: Renewal Of Server Certificates
Issuing and Managing Server Certificates The request is processed using the enrollment method associated with the request form. The server administrator goes to the agent-approved enrollment form hosted by the Registration Manager, pastes in the certificate signing request in PKCS #10 format, completes the other information in the enrollment form, and submits the form.
Page 394 Issuing and Managing Server Certificates • Submit the request manually by pasting the request (which is in the form of a base-64 encoded blob) into the Certificate Manager’s server enrollment form; in this method, you need to copy the request when the wizard displays it. When the wizard generates the certificate signing request for the key size and type you specified, you’re presented with the opportunity to choose how you want to submit the request to the CA.
Page 395: Cep Enrollment
CEP Enrollment Additional Comments. Type any information that will help you identify this request in the future or will help the person who will process this request. Click Submit. CEP Enrollment Note: This feature is supported in legacy enrollment only. CS can issue certificates to a wide variety of entities, such as web browsers, SSL-enables servers, routers, virtual private network (VPN) clients, and so on.
Page 396: Setting Up Automated Cep Enrollment
CEP Enrollment Setting Up Automated CEP Enrollment You can configure the Certificate Manager to use either the challenge password or the subject name (all or a part of it) as an authentication token during a CEP enrollment, thus enabling users to get router certificates without any action on the part of the Certificate Manager agent.
Page 397 CEP Enrollment Specifies the serial number of the router (for example, 239333). SERIALNUMBER This can sometimes be found on a label on the back of the router. It is also available by typing the show version command. This may not be in the request—a user may not want to include this in the subject name of the router certificate, and hence choose not to specify one during enrollment.
Page 398 CEP Enrollment The right pane shows the Authentication Instance tab listing currently configured authentication instances. Click Add. The Select Authentication Plug-in Implementation window appears. Select the plug-in module. FlatFileAuth Click Next. The Authentication Instance Editor window appears. Fill in the following fields in the Authentication Instance Editor window: authName.
Page 399 CEP Enrollment It is possible to set up multiple instances of CEP, each with a different configuration, each listening on a different URL. This is useful if you have different requirements for different types of users. For example, you might want to have one CEP service that authenticates routers and publishes their certificates to the directory and another CEP service that authenticates VPN clients but does not publish their certificates to the directory.
Page 400: Setting Up Publishing Of Cep Certificates And Crls
CEP Enrollment Setting Up Publishing of CEP Certificates and CRLs Set up the Directory for Publishing CEP Certificates and CRLs You need to do the following to set up the directory to publish CEP Certificates and CRLs: • Set up the schema in the directory for publishing. Chapter 16, “Publishing” contains information on setting up Red Hat Directory Server for publishing certificates and CRLs—it covers directory schema required for publishing certificates and the attributes to which a Certificate Manager publishes end-entity certificates and CRLs.
Page 401 CEP Enrollment • Create an instance of the policy plug-in named CRLDistributionPointsExt router certificates. This extension, if present in a certificate, enables the user of the certificate to find revocation information pertaining to that certificate. When you create an instance of the plug-in, be sure to leave the CRLDistributionPointsExt fields blank and to enter...
Page 402: Certificate Issuance To Routers Or Vpn Clients
CEP Enrollment Certificate Issuance to Routers or VPN Clients In general, issuing a certificate to a router involves the following steps: Note or print the certificate fingerprint information of the Certificate Manager CA signing certificate. You will be required to compare this with the fingerprint the router will show on the screen.
Page 403 CEP Enrollment —An identity for the CA. You can give any identity; choose something you will remember, since you will be required to provide it when you submit the certificate request. —The CA’s enrollment URL; this is the enrollment URL you identified in Step 1. The router gets the CA certificate and displays its fingerprint on your screen.
Page 404: Example
The name for the keys will be: redhat.mcom.com Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes.
Page 405: Testing Your Enrollment Setup
CA Certificate Status: Available Certificate Serial Number: 1 Key Usage: Not Set Certificate Subject Name Name: redhat.mcom.com IP Address: 208.12.63.193 Serial Number: 08342063 Status: Pending Key Usage: General Purpose Fingerprint: 91D70D7F D8BF0DFA E13F00B0 6EA706A0 00000000 Testing Your Enrollment Setup This section provides a procedure for testing your enrollment setup in the legacy enrollment.
Page 406 Testing Your Enrollment Setup When you enter the correct password, the client generates the key pair. Do not interrupt the key-generation process. Upon completion of the key generation, the request is submitted to the server for certificate issuance. The server subjects the request to the currently configured policy rules and issues the certificate only if the request passes all the policy rules.
Page 407: Managing Authentication Plug-Ins
Managing Authentication Plug-ins Managing Authentication Plug-ins You can register custom authentication plug-in modules from the CS window. You can delete an authentication plug-in module that you no longer need by using the CS window. Before deleting a module, be sure to delete all the instances that are based on this module. To register or delete a module: Log in to the CS window (see “Logging Into the CS Console”...
Page 408 Generating Files Required By Third-Party Object Signing Tools To generate the private-key file: Go to this directory: <server_root>/cert-<instance_id>/web-apps/ee Locate the file named ManObjSignEnroll.html Open it in an editor. Search for this line: Enroll.GenKeyFlags = 1 ' key exportable Type the following line below it: Enroll.PVKFilename = "<pvk_file_path>"...
Page 409 Generating Files Required By Third-Party Object Signing Tools Scroll down the page (that shows the certificate information in detail) to find the certificate in base-64 encoded format. It looks like this: -----BEGIN CERTIFICATE----- MIICJzCCAZCgAwIBAgIBAzANBgkqhkiG9w0BAQQFADBCSAwHgYDVQQKExdOZXRzY 2FwZSBD b21tdW5pY2F0aW9uczngjhnMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDg yNzE5MDw MFoXDTk5MDIyMzE5MDAwMnbjdgngYoxIDAeBgNVBAoTF05ldHNjYXBlIENvbW11b mljYXRpb 25zMQ8wDQYDVQQLEwZQZW9wbGUxFzAVBgoJkiaJkIsZAEBEwdzdXByaXlhMRcwFQ YDVQQDw5 TdXByaXlhIFNoZXR0eTEjMCEGCSqGSIb3DbndgJA -----END CERTIFICATE-----...
Page 410 Generating Files Required By Third-Party Object Signing Tools Red Hat Certificate System Administrator’s Guide • September 2005...
Page 411: Chapter 11 Certificate Profiles
Chapter 11 Certificate Profiles This chapter describes how to configure certificate profiles. This chapter contains the following sections: • About Certificate Profiles • Setting Up Certificate Profiles • Certificate Profile Reference • Input Reference • Output Reference • Defaults Reference •...
Page 412 About Certificate Profiles For example, you could set up a certificate profile for user certificates that defines all aspects of that certificate including the validity period of the issued certificate. You can set a default that defines the default validity period as two years. You would also set up a constraint that the validity period for certificates issued from requests submitted to this certificate profile cannot exceed two years.
Page 413: How Certificate Profiles Work
About Certificate Profiles An output specifies how the response page to a successful enrollment is presented. It usually displays the certificate in a user-readable format. A single output has been created that shows the pretty print version of the resultant certificate. You can create other outputs using the CS SDK.
Page 414: Setting Up Certificate Profiles
Setting Up Certificate Profiles The issued certificate contains the content defined in the defaults for this certificate profile, such as the extensions and validity period for the certificate, and the content of the certificate is constrained by the constraints set up for each default. You can set up more than one set of policies (defaults and constraints) within one profile, distinguishing each set by using the same value in the Policy Set ID for each set.
Page 415: Modifying A Certificate Profile
Setting Up Certificate Profiles Changing the constraints set up by changing the value of the parameters in the ❍ constraints. Changing the authentication method set up for this certificate profile. ❍ Changing the inputs set up by adding or deleting inputs in the certificate profile ❍...
Page 416 Setting Up Certificate Profiles To create a new certificate profile: Click Add. The Select Certificate Profile Plugin Implementation window appears. Select if this is a Certificate Certificate Authority Enrollment Profile Manager or if this is a Registration Authority Enrollment Profile Registration Manager.
Page 417 Setting Up Certificate Profiles Certificate Profile Description. Provide a description to identify the use of this certificate profile. End User Certificate Profile. Specifies whether or not the request must be made to the input form associated with this certificate profile. Generally, you will set this to true.
Page 418 Setting Up Certificate Profiles The Certificate Profile Rule Editor window appears. This window contains a lot of information, you may want to enlarge the window by pulling out on one of the corners of the window. Change the information in the Certificate Profile Rule Editor for any of the following fields: Certificate Profile Name.
Page 419 Setting Up Certificate Profiles Certificate Profile Authentication. Specify the authentication method. Specify an automated authentication by providing the instance ID for the authentication instance that will be used. If this field is left blank, the request is authenticated as an agent-approved enrollment;...
Page 420 Setting Up Certificate Profiles Fill in the following fields: Policy Set Id. Type a name or identifier for this set of policies. When you are issuing dual key pairs, you can use separate sets to define the policies associated with each certificate. Certificate Profile Policy ID.
Page 421 Setting Up Certificate Profiles The Policy Rule Editor window contains two tabs, Defaults and Constraints. Defaults define attributes that populate the certificate request that will be used to create the issued certificate. These can be extensions, validity periods, or other fields contained in the certificates.
Page 422 Setting Up Certificate Profiles The inputs tab lists inputs that have been set up for this certificate profile. You can add an input or you can delete an input. You can select an input and then select edit; but since the input has no parameters or other settings, there is nothing to configure. To add an input: Click Add.
Page 423: Certificate Profile Reference
Certificate Profile Reference Click Ok. This output will be listed in the output tab. You can edit it to provide values to the parameters in this output. To delete an output: Select the output. Click delete. Delete any certificate profiles you don’t want approved by an agent. Any certificate profile that appears in the Certificate Profile Instance Management tab also appears on the Certificate Profiles page in the agent services interface.
Page 424 Certificate Profile Reference Configured for enrollments for a CA signing certificate in a Certificate Manager. • caRACert Configured for enrollments for an RA signing certificate in a Certificate Manager. • caOCSPCert Configured for enrollments for an OCSP signing certificate in a Certificate Manager. •...
Page 425 Certificate Profile Reference When installed in an RA, the value of the End User Certificate Profile field is set to true; when installed in a CA, the value of the End User Certificate Profile field is set to false. In a CA, you set this certificate profile up to match the certificate profile set up in the RA;...
Page 426: Input Reference
Input Reference Configured for enrollments for a signed audit signing certificate, used by a subsystem to sign the signed audit logs. Input Reference An input puts certain fields on the enrollment page associated with a particular certificate profile. You define inputs for a certificate profile which are used to dynamically generate the enrollment page.
Page 427: Key Generation Input
Input Reference Key Generation Input input is used for enrollments in which a single key pair will Key Generation Input be generated, generally used for user-based certificate enrollments. This input puts the following fields into the enrollment form: Key Generation Request Type. This field is a read only field displaying as the crmf request type.
Page 428: Output Reference
Output Reference Requestor Phone. This field is used to enter the phone number of the requestor of this certificate. Output Reference An output represents the response to the end user of a successful enrollment. certOutputImpl This output displays the certificate in pretty print format. It is the only output defined at this time.
Page 429 Defaults Reference • No Constraints, see “No Constraint,” on page 456. This default allows you to define 5 locations and specify parameters for each location. The parameters are marked with an in the table to distinguish that the parameter is <n>...
Page 430: Authority Key Identifier Extension Default
Defaults Reference Table 11-1 Authority Info Access Extension Default Configuration Parameters (Continued) Parameter Description • If you selected iPAddress, the value must be a valid IP address (IPv4 or IPv6). IPv4 address must be in n.n.n.n format, with endmost must be in n.n.n.n,m.m.m.m format.
Page 431: Basic Constraints Extension Default
Defaults Reference Basic Constraints Extension Default This default populates Basic Constraint extension in the certificate request. The extension identifies whether or not the Certificate Manager is a CA. The extension is also used during the certificate chain verification process to identify CA certificates and to apply certificate chain-path length constraints.
Page 432: Crl Distribution Points Extension Default
Defaults Reference Table 11-2 Basic Constraints Extension Default Configuration Parameters (Continued) Parameter Description • n must be an integer greater than zero. It specifies at the most n subordinate CA certificates are allowed below the subordinate CA certificate being used. If you leave the field blank, the path length defaults to a value that is determined by the path length set in the Basic Constraints extension in the issuer’s certificate.
Page 433 Defaults Reference Table 11-3 CRL Distribution Points Extension Configuration Parameters (Continued) Parameter Description Specifies the name of the CRL distribution point, the name can Name_<n> be in any of the following formats: • An X.500 directory name in the RFC 2253 syntax. For example, the name would look similar to the subject name in a certificate, like this: CN=CA Central, OU=Research Dept, O=Example Corporation,...
Page 434: Extended Key Usage Extension Default
Defaults Reference Table 11-3 CRL Distribution Points Extension Configuration Parameters (Continued) Parameter Description Specifies the general-name type of the CRL issuer that has IssuerType_<n> signed the CRL maintained at distribution point. Permissible values: DirectoryName or URIName. The value you specify for this parameter must correspond to the value in the issuerName field.
Page 435 Defaults Reference Note that Windows 2000 allows you to encrypt files on the hard disk, a feature known as encrypted file system (EFS), using certificates that contain the Extended Key Usage extension with the following two OIDs: (this OID is for the EFS certificate) 1.3.6.1.4.1.311.10.3.4 (this OID is for the EFS recovery certificate) 1.3.6.1.4.1.311.10.3.4.1...
Page 436: Freshest Crl Extension Default
Defaults Reference Freshest CRL Extension Default This default populates the Freshest CRL extension in the certificate request. The Freshest enables you to configure a Certificate Manager to set the CRL Extension Default FreshestCRL Extension in certificate. You can define the following constraints with this default: •...
Page 437: Key Usage Extension Default
Defaults Reference Table 11-6 Freshest CRL Extension Default Configuration Parameters (Continued) Parameter Description Specifies the general-name type of the CRL issuer that signed the CRL PointType_<n> maintained at distribution point. Permissible values: DirectoryName or URIName. The value you specify for this parameter must correspond to the value in the issuerName field.
Page 438: Name Constraints Extension Default
Defaults Reference Table 11-7 Key Usage Extension Default Configuration Parameters (Continued) Parameter Description Specifies whether to set the extension for SSL server certificates and keyEncipherment S/MIME encryption certificates. Select true to set, select false to not set. Specifies whether to set the extension when the subjects’s public key is dataEncipherment used to encipher user data (as opposed to key material).
Page 439 Defaults Reference Table 11-8 Name Constraints Extension Default Configuration Parameters Parameter Description Select true to mark this extension critical; select false to mark the critical extension noncritical. Specifies the minimum number of permitted subtrees. permittedSubtrees <n>. • -1 specifies that the field should not be set in the extension. •...
Page 440 Defaults Reference Table 11-8 Name Constraints Extension Default Configuration Parameters (Continued) Parameter Description • If you selected URIName, the value must be a non-relative universal resource identifier (URI) following the URL syntax and encoding rules. The name must include both a scheme (for example, http) and a fully qualified domain name or IP address of the host.
Page 441 Defaults Reference Table 11-8 Name Constraints Extension Default Configuration Parameters (Continued) Parameter Description Specifies the general-name type for the excluded subtree you want to ExcludedSubtree include in the extension. NameChoice_<n> Permissible values: RFC822Name, DirectoryName, DNSName, EDIPartyName, URIName, IPAddress, OIDName, or OtherName.
Page 442: Red Hat Comment Extension Default
Defaults Reference Table 11-8 Name Constraints Extension Default Configuration Parameters (Continued) Parameter Description • If you selected OtherName, the value must be the absolute path to the file that contains the base-64 encoded string of the subtree. For example, /usr/netscape/servers/ext/nc/othername.txt. Select true to enable this excluded subtree entry, select false to disable ExcludedSubtree this excluded subtree entry.
Page 443 Defaults Reference • If the extension exists in a certificate, it limits the uses of the certificate to those specified (it limits the applications for a certificate). • If the extension is not present, the certificate can be used for all applications except object signing.
Page 444: No Default Extension
Defaults Reference No Default Extension This default can be used to set constraints when no defaults are being used. This default has not settings and sets no defaults, but does allow you to set all of the constraints available. OCSP No Check Extension Default This default populates an OCSP No Check extension in the certificate request.
Page 445 Defaults Reference • Extension Constraint, see “Extension Constraint,” on page 454. • No Constraints, see “No Constraint,” on page 456. Table 11-12 Policy Constraints Extension Default Configuration Parameters Parameter Description Select true to mark this extension critical; select false to mark the critical extension noncritical.
Page 446: Policy Mappers Extension Default
Defaults Reference Policy Mappers Extension Default This default populates a policy mappings extension in the certificate request. The extension lists one or more pairs of OIDs, each pair identifying two policy statements of two CAs. The pairing indicates that the corresponding policies of one CA are equivalent to policies of another CA.
Page 447: Signing Algorithm Default
Defaults Reference Signing Algorithm Default This default populates a signing algorithm in the certificate request. This default presents an agent with the possible algorithms that can be used for signing the certificate in a list that the agent can select from. You can define the following constraints with this default: •...
Page 448 Defaults Reference In general, you can configure which attributes should or shouldn’t be stored in the request; for example, you can exclude sensitive attributes such as passwords from getting stored in the request with the help of the parameter named defined in the CS dontSaveHttpParams configuration file.
Page 449: Subject Key Identifier Extension Default
Defaults Reference Table 11-15 Subject Alternative Name Extension Default Configuration Parameters (Continued) Parameter Description • Select DNSName if the request-attribute value is a DNS name. For example, corpDirectory.example.com. • Select EDIPartyName if the request-attribute value is a EDI party name. For example, Example Corporation.
Page 450: Subject Name Default
Defaults Reference Subject Name Default This default populates server-side configurable subject name into the certificate request. You provide a static subject name that is used as the subject name in the certificate. You can define the following constraints with this default: •...
Page 451: User Supplied Key Default
Defaults Reference No inputs are provided to add user supplied extensions to the enrollment form. You can create an input for this purpose using the CS SDK. You can also submit a request that contains this information. You can define the following constraints with this default: •...
Page 452: User Supplied Subject Name Default
Defaults Reference User Supplied Subject Name Default This default populates a user-supplied subject name into the certificate request. If included in the certificate profile, allows a user to supply a subject name for the certificate, subject to the constraints set. You can define the following constraints with this default: •...
Page 453: Constraints Reference
Constraints Reference Constraints Reference Constraints are used to define the allowable contents of a certificate and the values associated with that content. This section lists the pre built constraints with complete definitions of each. Basics Constraints Extension Constraint The basic constraints extension constraint checks if the basic constraint in the certificate request satisfies the criteria set in this constraint.
Page 454: Extended Key Usage Extension Constraint
Constraints Reference Table 11-18 Basic Constraints Extension Constraint Configuration Parameters (Continued) Parameter Description If you leave the field blank, the path length defaults to a value that is determined by the path length set on the Basic Constraints extension in the issuer’s certificate. If the issuer’s path length is unlimited, the path length in the subordinate CA certificate will also be unlimited.
Page 455: Key Usage Extension Constraint
Constraints Reference Table 11-20 Key Constraint Configuration Parameters Parameter Description Select which key type is allowed from DSA and RSA. Type Specifies the minimum allowable key length. MinLength Specifies the maximum allowable key length. MaxLength Key Usage Extension Constraint The key usage extension constraint checks if the key usage constraint in the certificate request satisfies the criteria set in this constraint.
Page 456: No Constraint
Constraints Reference Table 11-21 Key Usage Extension Constraint Configuration Parameters (Continued) Parameter Description Specifies whether to set the extension whenever the subject’s public keyAgreement key is used for key agreement. Select true to allow this to be set; select false to not allow this to be set; select “-” to indicate no constraints are placed for this parameter.
Page 457: Signing Algorithm Constraint
Constraints Reference Netscape Certificate Type Table 11-22 Extension Constraint Configuration Parameters Parameter Description Select true to allow this extension to be marked critical; select critical false to keep this extension from being marked critical; select “-” to indicate no constraints are placed for this parameter. Specifies that the certificate can be used by clients for SSLClient authentication during SSL connections.
Page 458: Subject Name Constraint
Constraints Reference Table 11-23 Signing Algorithms Constraint Configuration Parameters Parameter Description List the signing algorithms that can be specified for use in signingAlgsAllowed signing this certificate. Specify any or all of the following: MD2withRSA,MD5withRSA,SHA1withRSA Subject Name Constraint This constraint implements the subject name constraint. It checks if the subject name in the certificate request satisfies the criteria.
Page 459 Constraints Reference Table 11-25 Validity Constraint Configuration Parameters Parameter Description The range parameter is of type integer. And the unit of this value range is day. Chapter 11 Certificate Profiles...
Page 460 Constraints Reference Red Hat Certificate System Administrator’s Guide • September 2005...
Page 461: Chapter 12 Policies
Chapter 12 Policies Red Hat Certificate System (CS) provides a customizable policy framework for the Certificate Manager, Registration Manager, and Data Recovery Manager. This chapter explains how to configure these subsystems to apply organizational and other policies on incoming certificate and key-related requests. Note: This feature is provided for legacy purposes.
Page 462: Introduction To Policy
Introduction to Policy Introduction to Policy You can configure the main subsystems of CS—the Certificate Manager, Registration Manager, and Data Recovery Manager—to apply certain organizational policies on an end-entity’s certificate enrollment and management requests before servicing them. For example, some of the policies you might want a Certificate Manager to impose on these requests may include setting a minimum and maximum limit on validity period and key length of certificates, setting extensions based on the end entity's role within an organization, setting signing algorithms, and so on.
Page 463: Policy Rules
Introduction to Policy • Screen the request for specific content, and modify, reject, or defer (for agent approval) it accordingly. For example, the request might be checked for the inclusion of organizational constraints, such as key algorithm, key size, validity period, or a particular signing algorithm;...
Page 464: Policy Processor
Introduction to Policy To facilitate this classification, CS supports a parent interface for a generic policy rule and other operation-specific interfaces that extend the parent interface. Check the CS SDK. Policy Processor Each subsystem—the Certificate Manager, Registration Manager, or Data Recovery Manager—has its own policy processor.
Page 465: Using Predicates In Policy Rules
Introduction to Policy Using Predicates in Policy Rules You can use predicates in a policy rule. A predicate indicates whether the rule that contains the predicate applies to a request. If you specify a predicate as part of the rule configuration, the policy rule applies that predicate based on request attributes to determine whether the rule is applicable for a request.
Page 466 Introduction to Policy is equal to: Expression Expression AndExpression ❍ is equal to: Expression Expression OrExpression ❍ In an expression, the operator takes precedence over an operator. For example, the expression HTTP_PARAMS.certType==client AND HTTP_PARAMS.ou==Engineering OR HTTP_PARAMS.certType==ca is interpreted as (HTTP_PARAMS.certType==client AND HTTP_PARAMS.ou==Engineering) OR HTTP_PARAMS.certType==ca CS evaluates an expression based on the attributes in the request.
Page 467 Introduction to Policy Attributes for Predicates Attributes for predicates can come from any of the following: • Input form—that is, the HTML form that end entities use for submitting certificate requests. • Authentication token—what the authentication subsystem returns after successfully authenticating an end entity.
Page 468 Introduction to Policy Table 12-2 Attributes supported by request object implementations (Continued) Request type Variable name Description Enrollment Specifies the certificate type. Default values include the following: certType • ca (Certificate Manager’s CA signing certificate) • caCrlSigning (Certificate Manager’s CRL signing certificate) •...
Page 469 Introduction to Policy Table 12-2 Attributes supported by request object implementations (Continued) Request type Variable name Description Enrollment Specifies the name of the CEP service; for example, cep1 and cepsubstore cep2. When setting up multiple CEP services, you can use predicates to differentiate one service for another;...
Page 470 Introduction to Policy Assuming that the new attribute you define for the organizational unit is , the line orgunit you would add to the enrollment form would be: <input type="HIDDEN" name="orgunit" value="Sales"> To add this line to an enrollment form, you would: Open the corresponding HTML file in a text editor.
Page 471: Configuring Policy Rules For A Subsystem
Configuring Policy Rules for a Subsystem A sample of the resulting configuration entries in the CS configuration file would be as follows: ca.Policy.rule.ValidityRule2.enable=true ca.Policy.rule.ValidityRule2.implName=ValidityConstraints ca.Policy.rule.ValidityRule2.maxValidity=60 ca.Policy.rule.ValidityRule2.minValidity=10 ca.Policy.rule.ValidityRule2.predicate=HTTP_PARAMS.certType== client AND HTTP_PARAMS.orgunit!=Sales The new configuration would result in certificates with a validity period of six months for users in the Sales organizational unit and a validity period of three months for users in the Manufacturing unit.
Page 472: Deleting Policy Rules
Configuring Policy Rules for a Subsystem Make the necessary changes and click OK. You are returned to the Policy Rules Management tab. Repeat steps 5 through 7 for the remaining rules. Click Refresh. Deleting Policy Rules You can delete any unwanted policy rules from the CS configuration. If you think you might need a rule in the future, instead of deleting it from the configuration you should disable it by deselecting the parameter.
Page 473: Reordering Policy Rules
Configuring Policy Rules for a Subsystem • The status of the rule, enabled or disabled, depends on whether you check or deselect parameter. A subsystem subjects certificate requests only to rules that are enable enabled. • The server does not automatically reorder rules. Be sure to change the order of the rule, if required.
Page 474: Testing Policy Configuration
Using JavaScript for Policies In the Policy Rules Management tab, click Reorder. The Reorder Policy Rules window appears. It lists configured policy rules in the order in which they are executed by the subsystem. To change the order of a rule, select it in the list and click the Up or Down button, as appropriate.
Page 475: Constraints-Specific Policy Module Reference
Constraints-Specific Policy Module Reference CS uses the Rhino JavaScript engine from . You can get more details about Mozilla.org the Rhino project from this site: http://www.mozilla.org/rhino To learn more about how to use JavaScript in CS, consult the sample file policy.js included in the distribution: <server_root>/bin/cert/profiles/policy.js...
Page 476 Constraints-Specific Policy Module Reference In the case of multi-valued attributes, the request will be accepted if any of the values matches the specified value; comparisons are case sensitive. Unlike some of the other policy modules, CS does not create an instance of the attribute present constraints policy during installation.
Page 477: Dsakeyconstraints
Constraints-Specific Policy Module Reference Table 12-3 AttributePresentConstraints Configuration Parameters (Continued) Parameter Description Specifies the nickname or the friendly name of the certificate to be used for SSL client ldap.ldapauth. authentication to the LDAP directory in order to check attributes. Make sure that the clientCertNick certificate is valid and has been signed by a CA that is trusted in the directory’s certificate name...
Page 478 Constraints-Specific Policy Module Reference • The minimum and maximum sizes for keys • The sizes of exponents The policy restricts the key size to one of the sizes, such as 512 or 1024, supported by CS. You may apply this policy to end-entity certificate enrollment and renewal requests. For example, if you want your CA to certify public keys up to 512 bits in length for end users and 1024 for servers, you can configure CS to do so using the policy.
Page 479: Issuerconstraints
Constraints-Specific Policy Module Reference IssuerConstraints plug-in module enables you to effectively deploy IssuerConstraints certificate-based enrollment explained in “Certificate-Based Enrollment” on page 390. The policy enables the Certificate Manager to authenticate an end user by checking the issuer DN of the CA that has issued the certificate the user presents as an enrollment token during enrollment.
Page 480: Renewalconstraints
Constraints-Specific Policy Module Reference Table 12-6 describes the configuration parameters of the KeyAlgorithmConstraints policy. Table 12-6 KeyAlgorithmConstraints Configuration Parameters Parameter Description Specifies whether the rule is enabled or disabled. Select to enable (default), deselect to disable. enable Specifies the predicate expression for this rule. If you want this rule to be applied to all predicate certificate requests, leave the field blank (default).
Page 481: Renewalvalidityconstraints
Constraints-Specific Policy Module Reference RenewalValidityConstraints plug-in module governs the formulation of content RenewalValidityConstraints in the renewed certificate based on the currently issued certificate. The renewal validity constraints policy enables you to enforce certain restrictions on certificate-renewal requests, when end entities attempt to renew their certificates. During installation, CS automatically creates an instance of the renewal validity constraints policy, named , that is enabled by default.
Page 482: Rsakeyconstraints
Constraints-Specific Policy Module Reference Table 12-9 RevocationConstraints Configuration Parameters Parameter Description Specifies whether the rule is enabled or disabled. Select to enable (default), deselect to enable disable. Specifies the predicate expression for this rule. If you want this rule to be applied to all predicate certificate requests, leave the field blank (default).
Page 483: Signingalgorithmconstraints
Constraints-Specific Policy Module Reference Table 12-10 RSAKeyConstraints Configuration Parameters (Continued) Parameter Description Specifies the minimum length, in bits, for the key (the length of the modulus in bits). The value minSize must be smaller than or equal to the one specified by the maxSize parameter. Permissible values: 512, 1024, 2048, or 4096.
Page 484: Subcanameconstraints
Constraints-Specific Policy Module Reference Table 12-11 describes the configuration parameters of the policy. SigningAlgorithmConstraints Table 12-11 SigningAlgorithmConstraintsConfiguration Parameters Parameter Description Specifies whether the rule is enabled or disabled. Select to enable (default), deselect to disable. enable Specifies the predicate expression for this rule. If you want this rule to be applied to all predicate certificate requests, leave the field blank (default).
Page 485: Uniquesubjectnameconstraints
Constraints-Specific Policy Module Reference Table 12-12 describes the configuration parameters of the SubCANameConstraints policy. Table 12-12 SubCANameConstraints Configuration Parameters Parameter Description Specifies whether the rule is enabled or disabled. Select to enable, deselect to disable (default). enable Specifies the predicate expression for this rule. If you want this rule to be applied to all predicate certificate requests, leave the field blank (default).
Page 486 Constraints-Specific Policy Module Reference Table 12-13 UniqueSubjectNameConstraints Configuration Parameters Parameter Description Specifies whether the rule is enabled or disabled. Select to enable, deselect to disable (default). enable Specifies the predicate expression for this rule. If you want this rule to be applied to all predicate certificate requests, leave the field blank (default).
Page 487: Validityconstraints
Constraints-Specific Policy Module Reference ValidityConstraints plug-in module enforces minimum and maximum validity ValidityConstraints periods for certificates and changes them if the policy is not met. Specifically, the policy imposes constraints on the following: • The duration of a certificate’s validity period (based on supported minimum and maximum validity periods).
Page 488 Constraints-Specific Policy Module Reference During installation, CS automatically creates an instance of the validity constraints policy, named , that is enabled by default. DefaultValidityRule Table 12-14 describes the configuration parameters of the policy. ValidityConstraints Table 12-14 ValidityConstraints Configuration Parameters Parameter Description Specifies whether the rule is enabled or disabled.
Page 489: Extension-Specific Policy Module Reference
Extension-Specific Policy Module Reference Extension-Specific Policy Module Reference To enable you to add standard and private extensions to end-entity certificates, CS provides a set of policy plug-in modules; each module enables you to add a particular extension to a certificate request. When deciding whether to add any of the X.509 v3 certificate extensions, keep in mind that not all applications support X.509 v3 extensions.
Page 490 Extension-Specific Policy Module Reference Note that if you installed the Certificate Manager with it’s built-in OCSP service enabled, the policy rule will be enabled and the address location ( ) will be pointed ad0_location= to the Certificate Manager’s non-SSL end-entity port. For example, if the non-SSL end-entity port of your Certificate Manager is 80, the URL would look like this: http://ocspResponder.example.com:80/ocsp NOTE...
Page 491 Extension-Specific Policy Module Reference Table 12-15 AuthInfoAccessExt Configuration Parameters (Continued) Parameter Description Permissible values: • ocsp (or 1.3.6.1.5.5.7.48.1). • caIssuers (or 1.3.6.1.5.5.7.48.2). • renewal (or 2.16.840.1.113730.16.1) Specifies the general-name type for the location that contains additional information about the ad<n>_location CA that has issued the certificate in which this extension appears.
Page 492: Authoritykeyidentifierext
Extension-Specific Policy Module Reference Table 12-15 AuthInfoAccessExt Configuration Parameters (Continued) Parameter Description • If you selected URL, the value must be a non-relative universal resource identifier (URI) following the URL syntax and encoding rules. That is, the name must include both a scheme (for example, http) and a fully qualified domain name or IP address of the host.
Page 493: Basicconstraintsext
Extension-Specific Policy Module Reference Table 12-16 AuthorityKeyIdentifierExt Configuration Parameters Parameter Description Specifies whether the rule is enabled or disabled. Select to enable, deselect to disable. enable Specifies the predicate expression for this rule. If you want this rule to be applied to all predicate certificate requests, leave the field blank (default).
Page 494: Certificatepoliciesext
Extension-Specific Policy Module Reference Table 12-17 BasicConstraintsExt Configuration Parameters (Continued) Parameter Description Specifies whether the certificate subject is a CA. If you select the option, the server checks the isCA maxPathLen parameter and sets the specified path length in the certificate. If you deselect the option, the server treats the certificate subject as a non-CA and ignores the value specified for the maxPathLen parameter.
Page 495 Extension-Specific Policy Module Reference During installation, CS automatically creates an instance of the certificate policies extension policy, named , that is disabled by default. CertificatePoliciesExt Table 12-18 CertificatePoliciesExt Configuration Parameters Parameter Description Specifies whether the rule is enabled or disabled. Select to enable, deselect to disable. enable Specifies the predicate expression for this rule.
Page 496: Certificaterenewalwindowext
Extension-Specific Policy Module Reference Table 12-18 CertificatePoliciesExt Configuration Parameters (Continued) Parameter Description Specifies the textual statement to be included in certificates; this parameter corresponds to displayText the explicitText field of the user notice. If you want to embed a textual statement (for example, your company’s legal notice) in certificates, then add that statement here.
Page 497 Extension-Specific Policy Module Reference Table 12-19 CertificateRenewalWindowExt Configuration Parameters (Continued) Parameter Description Specifies the predicate expression for this rule. If you want this rule to be applied to all predicate certificate requests, leave the field blank (default). To form a predicate expression, see “Using Predicates in Policy Rules”...
Page 498: Certificatescopeofuseext
Extension-Specific Policy Module Reference Table 12-19 CertificateRenewalWindowExt Configuration Parameters (Continued) Parameter Description • n specifies a past or future time, in seconds, by which the certificate must be renewed; the endTime field of the extension will be set to the specified time since certificate issuance.
Page 499 Extension-Specific Policy Module Reference By using a particular certificate for SSL client authentication, the client releases information about itself to the server. This information may include the name and key information contained in the certificate. It also releases the information that the client holds a certificate from a particular CA.
Page 500 Extension-Specific Policy Module Reference Table 12-20 CertificateScopeOfUseExt Configuration Parameters (Continued) Parameter Description Specifies the general-name type for the site that you want to include in the extension. entry<n>_name_type Select from one of the following: • Select rfc822Name if the site is an Internet mail address. •...
Page 501: Crldistributionpointsext
Extension-Specific Policy Module Reference Table 12-20 CertificateScopeOfUseExt Configuration Parameters (Continued) Parameter Description • If you selected iPAddress, the value must be a valid IP address specified in dot-separated numeric component notation. The syntax for specifying the IP address is as follows: IPv4 address must be in the n.n.n.n format;...
Page 502 Extension-Specific Policy Module Reference Table 12-21 CRLDistributionPointsExt Configuration Parameters Parameter Description Specifies whether the rule is enabled or disabled. Select to enable, deselect to disable. enable Specifies the predicate expression for this rule. If you want this rule to be applied to all predicate certificate requests, leave the field blank (default).
Page 503: Extendedkeyusageext
Extension-Specific Policy Module Reference Table 12-21 CRLDistributionPointsExt Configuration Parameters (Continued) Parameter Description Specifies revocation reasons covered by the CRL maintained at the distribution point. Provide reasons<n> a comma-separated list of the following constants: • unused • keyCompromise • cACompromise • affiliationChanged •...
Page 504 Extension-Specific Policy Module Reference Table 12-22 PKIX usage definitions for the extended key usage extension Usage Server authentication 1.3.6.1.5.5.7.3.1 Client authentication 1.3.6.1.5.5.7.3.2 Code signing 1.3.6.1.5.5.7.3.3 Email 1.3.6.1.5.5.7.3.4 IPSec end system 1.3.6.1.5.5.7.3.5 IPSec tunnel 1.3.6.1.5.5.7.3.6 IPSec user 1.3.6.1.5.5.7.3.7 Timestamping 1.3.6.1.5.5.7.3.8 Note that Windows 2000 allows you to encrypt files on the hard disk, a feature known as encrypted file system (EFS), using certificates that contain the Extended Key Usage extension with the following two OIDs:...
Page 505: Genericasn1Ext
Extension-Specific Policy Module Reference Table 12-23 ExtendedKeyUsageExt Configuration Parameters Parameter Description Specifies whether the rule is enabled or disabled. Select to enable, deselect to disable. enable Specifies the predicate expression for this rule. If you want this rule to be applied to all predicate certificate requests, leave the field blank (default).
Page 506 Extension-Specific Policy Module Reference The generic extension policy in CS accepts custom extensions in the form of object identifiers (OIDs) and values as DER-encoded extension values. That is, for the server to add a custom extension to certificates it issues, you need to first define the extension and then configure the server with extension details.
Page 507 Extension-Specific Policy Module Reference Configuration Parameters of GenericASN1Ext The configuration defines a custom extension named with OID 2.4.5.99. testGenASN1Ext The extension is non-critical, and it will be added to all certificates issued by the server. The expected output (see “dumpasn1 Tool” in CS Command-Line Tools Guide) of dumpasn1 the resulting extension, would look like this: 337 30...
Page 508 Extension-Specific Policy Module Reference Table 12-24 GenericASN1Ext Configuration Parameters (Continued) Parameter Description Specifies the OID assigned to the extension. Permissible values: A valid OID specified in dot-separated numeric component notation (see the example). Although you can invent your own OIDs for the purposes of evaluating and testing this server, in a production environment, you should comply with the ISO rules for Appendix H, “Object Identifiers”...
Page 509 Extension-Specific Policy Module Reference Table 12-24 GenericASN1Ext Configuration Parameters (Continued) Parameter Description • Select OID for extensions that have ASN.1 OBJECT IDENTIFIER values. • Select Boolean for extensions that have ASN.1 BOOLEAN values. It’s case insensitive and accepts true or false as value. Specifies the data source for attribute n in the extension, where n is an identifier assigned to attribute.<n>.
Page 510: Issueraltnameext
Extension-Specific Policy Module Reference IssuerAltNameExt plug-in module enables you to add the Issuer Alternative Name IssuerAltNameExt Extension defined in X.509 and PKIX standard RFC 2459 (see ) to certificates. This extension enables http://www.ietf.org/rfc/rfc2459.txt binding of or associating Internet style identities—such as Internet electronic mail address, a DNS name, an IP address, and a uniform resource indicator (URI)—...
Page 511 Extension-Specific Policy Module Reference Table 12-25 IssuerAltNameExt Configuration Parameters (Continued) Parameter Description Specifies the total number of alternative names or identities permitted in the numGeneralNames extension. Note that each name has a set of configuration parameters—generalName<n>.generalNameChoice and generalName<n>.generalNameValue—and you must specify appropriate values for each of those parameters;...
Page 512 Extension-Specific Policy Module Reference Table 12-25 IssuerAltNameExt Configuration Parameters (Continued) Parameter Description Specifies the general-name value for the alternative name you want to include in generalName<n>.general the extension. NameValue Permissible values: Depends on the general-name type you selected in the generalName<n>.generalNameChoice field.
Page 513: Keyusageext
Extension-Specific Policy Module Reference Table 12-25 IssuerAltNameExt Configuration Parameters (Continued) Parameter Description • If you selected iPAddress, the value must be a valid IP address (IPv4 or IPv6) specified in dot-separated numeric component notation. The syntax for specifying the IP address is as follows: For IP version 4 (IPv4), the address should be in the form specified in RFC 791 (http://www.ietf.org/rfc/rfc0791.txt).
Page 514 Extension-Specific Policy Module Reference Table 12-26 Key usage extension bits and designated purposes Purpose digitalSignature nonRepudiation keyEncipherment dataEncipherment keyAgreement keyCertSign cRLSign encipherOnly decipherOnly You can restrict the purposes for which a key pair (and thus the corresponding certificate) should be used by setting the appropriate key-usage bits. For example, if you want to restrict a key pair to be used for digital signature only, when issuing the certificate you would add the key usage extension to the certificate with bit (or bit...
Page 515 Extension-Specific Policy Module Reference Typically, you won’t have to change the key-usage bit setting by editing the enrollment forms as you can do this easily by making the appropriate changes to the policy instance (bits set on the server side override the ones set on the client side). However, if you want to add new variables on the client side, you can do that too.
Page 516 Extension-Specific Policy Module Reference • This rule is for setting the appropriate key-usage bits in RMCertKeyUsageExt Registration Managers’ signing certificates and is enabled by defualt. The server is configured to set bits in digitalSignature nonRepudiation Registration Manager signing certificates. Notice that the key-usage bits specified in the default policy rule match the bits specified in the enrollment form ) for requesting Registration Manager signing certificates.
Page 517 Extension-Specific Policy Module Reference Table 12-28 KeyUsageExt Configuration Parameters (Continued) Parameter Description Specifies whether the extension should be marked critical or noncritical. Select to mark critical critical (default), deselect to mark noncritical. Specifies whether to set the digitalSignature bit (or bit 0) of the key usage extension digitalSignature in certificates specified by the predicate parameter.
Page 518 Extension-Specific Policy Module Reference Table 12-28 KeyUsageExt Configuration Parameters (Continued) Parameter Description Specifies whether to set the dataEncipherment bit (or bit 3) of the key usage extension dataEncipherment in certificates specified by the predicate parameter. Permissible values: true, false, or HTTP_INPUT. •...
Page 519: Nameconstraintsext
Extension-Specific Policy Module Reference Table 12-28 KeyUsageExt Configuration Parameters (Continued) Parameter Description Specifies whether to set the cRLSign bit (or bit 6) of the key usage extension in cRLSign certificates specified by the predicate parameter. Permissible values: true, false, or HTTP_INPUT. •...
Page 520 Extension-Specific Policy Module Reference For general information about this extension, see “nameConstraints” on page 737. During installation, CS automatically creates an instance of the name constraints extension policy, named , that is disabled by default. NameConstraintsExt Table 12-29 NameConstraintsExt Configuration Parameters Parameter Description Specifies whether the rule is enabled or disabled.
Page 521 Extension-Specific Policy Module Reference Table 12-29 NameConstraintsExt Configuration Parameters (Continued) Parameter Description Permissible values: 0 or n. • 0 specifies that no excluded subtrees can be contained in the extension. • n specifies the total number of excluded subtrees to be included in the extension;...
Page 522 Extension-Specific Policy Module Reference Table 12-29 NameConstraintsExt Configuration Parameters (Continued) Parameter Description • If you selected dNSName, the value must be a valid domain name in the preferred-name syntax as specified by RFC 1034 (http://www.ietf.org/rfc/rfc1034.txt). You may use upper and lower case letters in the domain name; no significance is attached to the case.
Page 523 Extension-Specific Policy Module Reference Table 12-29 NameConstraintsExt Configuration Parameters (Continued) Parameter Description Specifies the minimum number of permitted subtrees. permittedSubtrees<n>. Permissible values: -1, 0, or n. • -1 specifies that the field should not be set in the extension. • 0 specifies that the minimum number of subtrees is zero (default).
Page 524 Extension-Specific Policy Module Reference Table 12-29 NameConstraintsExt Configuration Parameters (Continued) Parameter Description Permissible values: Depends on the general-name type you selected in the excludedSubtrees<n>.base.generalNameChoice field. • If you selected rfc822Name, the value must be a valid Internet mail address in the local-part@domain format; see the definition of an rfc822Name as defined in RFC 822 (http://www.ietf.org/rfc/rfc0822.txt).
Page 525 Extension-Specific Policy Module Reference Table 12-29 NameConstraintsExt Configuration Parameters (Continued) Parameter Description • If you selected iPAddress, the value must be a valid IP address (IPv4 or IPv6) specified in the dot-separated numeric component notation. The syntax for specifying the IP address is as follows: For IP version 4 (IPv4), the address should be in the form specified in RFC 791 (http://www.ietf.org/rfc/rfc0791.txt).
Page 526: Nsccommentext
Extension-Specific Policy Module Reference NSCCommentExt plug-in module enables you to add the Netscape Certificate NSCCommentExt Comment Extension to certificates. The extension can be used to include textual comments in certificates. Applications that are capable of interpreting the comment may display it to a relying party when the certificate is used or viewed.
Page 527: Nscerttypeext
Extension-Specific Policy Module Reference Table 12-30 NSCCommentExt Configuration Parameters (Continued) Parameter Description Specifies the textual statement that should be included in certificates. If you want to embed a displayText textual statement (for example, your company’s legal notice) in certificates, then add that statement here.
Page 528 Extension-Specific Policy Module Reference Netscape Table 12-31 certificate type extension bits and designated purposes (Continued) Purpose Description S/MIME Specifies that the certificate can be used to send secure email messages. Object Signing Specifies that the certificate can be used for signing objects such as Java applets and plug-ins.
Page 529 Extension-Specific Policy Module Reference Netscape certificate Table 12-32 HTTP input variables for type extension bits (Continued) HTTP input variable Netscape certificate type extension bit Object Signing (bit 3) object_signing Reserved for future use (bit 4) SSL CA (bit 5) ssl_ca S/MIME CA (bit 6) email_ca Object Signing CA (bit 7)
Page 530: Ocspnocheckext
Extension-Specific Policy Module Reference Table 12-33 NSCertTypeExt Configuration Parameters (Continued) Parameter Description Netscape certificate Specifies whether to set the type extension with default bits in setDefaultBits certificates specified by the predicate expression. • Select if you want the server to add the extension, with default bits, to certificates. If you Netscape select and if no bits are requested from the HTTP input, the server adds the certificate...
Page 531: Policyconstraintsext
Extension-Specific Policy Module Reference PolicyConstraintsExt plug-in module enables you to add the Policy Constraints PolicyConstraintsExt Extension to certificates. The extension, which can be used in CA certificates only, constrains path validation in two ways—either to prohibit policy mapping or to require that each certificate in a path contain an acceptable policy identifier.
Page 532: Policymappingsext
Extension-Specific Policy Module Reference Table 12-35 PolicyConstraintsExt Configuration Parameters (Continued) Parameter Description Specifies the total number of certificates permitted in the path before policy mapping is no inhibitPolicy longer permitted. Mapping Permissible values: -1, 0, or n. • -1 specifies that the field should not be set in the extension (default). •...
Page 533 Extension-Specific Policy Module Reference Table 12-36 PolicyMappingsExt Configuration Parameters (Continued) Parameter Description Specifies the predicate expression for this rule. If you want this rule to be applied to all predicate certificate requests, leave the field blank (default). To form a predicate expression, see “Using Predicates in Policy Rules,”...
Page 534: Privatekeyusageperiodext
Extension-Specific Policy Module Reference PrivateKeyUsagePeriodExt plug-in module enables you to add the Private Key PrivateKeyUsagePeriodExt Usage Period Extension to certificates. The extension allows the certificate issuer to specify a different validity period for the private key than the one specified for the corresponding certificate.
Page 535: Subjectaltnameext
Extension-Specific Policy Module Reference Table 12-38 RemoveBasicConstraintsExt Configuration Parameters Parameter Description Specifies whether the rule is enabled or disabled. Select to enable, deselect to disable. enable Specifies the predicate expression for this rule. If you want this rule to be applied to all predicate certificate requests, leave the field blank (default).
Page 536 Extension-Specific Policy Module Reference If enabled, the subject alternative extension policy checks the certificate request for configured attributes. If the request contains an attribute, the policy reads its value and sets it in the extension. This way, the extension that gets to added to certificates contains all the configured attributes.
Page 537 Extension-Specific Policy Module Reference Table 12-39 SubjectAltNameExt Configuration Parameters (Continued) Parameter Description Specifies the general-name type for the request attribute. generalName<n>. generalNameChoice Permissible values: rfc822Name, directoryName, dNSName, ediPartyName, URL, iPAddress, OID, or otherName. • Select rfc822Name if the request-attribute value is an Internet mail address in the local-part@domain format (default).
Page 538: Subjectdirectoryattributesext
Extension-Specific Policy Module Reference • parameter in the authentication instance is set to ldapStringAttributes mail , or to both. mailalternateaddress The third attribute, , is the email component of the HTTP_PARAMS.csrRequestorEmail subject name in an enrollment request—it is an HTTP input value that gets added to the request when a user uses the manual enrollment form;...
Page 539 Extension-Specific Policy Module Reference Table 12-40 SubjectDirectoryAttributesExt Configuration Parameters (Continued) Parameter Description Specifies the predicate expression for this rule. If you want this rule to be applied to all predicate certificate requests, leave the field blank (default). To form a predicate expression, see “Using Predicates in Policy Rules,”...
Page 540: Subjectkeyidentifierext
Extension-Specific Policy Module Reference SubjectKeyIdentifierExt plug-in module enables you to add the Subject Key SubjectKeyIdentifierExt Identifier Extension to certificates. The extension is used to identify certificates that contain a particular public key—that is, the extension is used to uniquely identify a certificate from among several that have the same subject name.
Page 541: Managing Policy Plug-In Modules
Java class that implements the policy interface. For example, you can add a policy implementation, named as follows, to the Data Recovery Manager’s policy framework: com.redhat.policy.KeyArchivalPolicy Before registering a plug-in module, be sure to put the Java class for the module in the directory (the implementation must be on the class path).
Page 542: Deleting A Policy Module
Managing Policy Plug-in Modules Click OK. You are returned to the Policy Plugin Registration tab. To view the updated configuration, click Refresh. Deleting a Policy Module You can delete unwanted policy plug-in modules using the CS window. Before deleting a module, be sure to delete all the policy rules that are based on this module.
Page 543: Chapter 13 Automated Notifications
Chapter 13 Automated Notifications Red Hat Certificate System (CS) can be configured to send automatic email notifications to end users when certificates are issued and revoked, or to an agent when a new request has arrived in the agent request queue. This chapter describes automated notifications, details how to enable and configure them, and details how to customize the notification email messages that are sent.
Page 544: Types Of Automated Notifications
About Automated Notifications • Enabling and configuring one of the notification types and setting preferences for that notification type; see “Setting Up Automated Notifications” on page 545 for complete details. • Customizing the email notification messages that are sent. You do this by changing the template associated with a type of notification.
Page 545: Determining End-Entity Email Addresses
Setting Up Automated Notifications Determining End-Entity Email Addresses The notification system determines the email address of an end entity by checking in the certificate request or revocation request itself, then in the subject name of the certificate, and last in the Subject Alternative Name extension of the certificate—if the certificate contains this extension.
Page 546 Setting Up Automated Notifications To enable Certificate Issued notifications, go to the Certificate Issued tab and specify information in the following fields: Enable Certificate Issued notification. Select this field to enable Certificate Issued notifications. Sender’s E-mail Address. Type the sender’s full email address; this is the email address of the person who is notified of any delivery problems.
Page 547: Configuring Specific Notifications By Editing The Configuration File
Setting Up Automated Notifications Customize the notification message templates. See “Customizing Notification Messages,” on page 548. Test your configuration. See “Testing Your Configuration,” on page 547. Configuring Specific Notifications By Editing the Configuration File Stop the server instance whose configuration file you will be editing. Open the file for that server instance in a text editor.
Page 548: Customizing Notification Messages
Customizing Notification Messages Login to the agent interface and approve the request. When the server issues a certificate, you should receive a Certificate Issued email notification. Check the message to see if has the correct information. Login to the agent interface and revoke the certificate. You should receive an email message notifying you that the certificate has been revoked.
Page 549: Notification Message Templates
Customizing Notification Messages You could change the message by changing the text and tokens, shown as follows: THE EXAMPLE COMPANY CERTIFICATE ISSUANCE CENTER Your certificate has been issued! You can pick up your new certficate at the following website: https://$HttpHost:$HttpPort/displayBySerial?op=displayBySerial&seri alNumber=$SerialNumber This certificate has been issued with the following information: Serial Number= 0x$HexSerialNumber...
Page 550 Customizing Notification Messages Table 13-1 Notification Templates (Continued) Filename Description Template for the Registration Manager to send certIssued_RA plain-text notifications to end entities upon issuance of certificates. Template for the Registration Manager to send certIssued_RA.html HTML-based notifications to end entities upon issuance of certificates.
Page 551: Token Definitions
Customizing Notification Messages Token Definitions Table 13-2 lists and defines the tokens that can be used in the notification message templates. Table 13-2 Notification Tokens Token Description Specifies the type of certificate—whether SSL client (client), $CertType SSL server (server), Registration Manager’s signing certificate (ra), Certificate Manager’s CA signing certificate (ca), router certificate (Cisco-router), or other (other).
Page 552 Customizing Notification Messages Table 13-2 Notification Tokens (Continued) Token Description Specifies the email address of the sender (it is the same as the one $SenderEmail you specify in the Sender’s E-mail Address field when you configured this feature. Specifies the serial number of the certificate that has been issued; $SerialNumber the serial number will be displayed as a hexadecimal value in the resulting message.
Page 553: Chapter 14 Automated Jobs
Chapter 14 Automated Jobs Red Hat Certificate System (CS) provides a customizable Job Scheduler component that supports various mechanisms for scheduling jobs. This chapter explains how to cron configure CS to use specific job plug-in modules for accomplishing jobs. This chapter contains the following sections: •...
Page 554: Setting Up Automated Jobs
About Automated Jobs Setting Up Automated Jobs The automated jobs feature is set up by performing the following tasks: • Enabling and configuring the Job Scheduler; see “Setting Up the Job Scheduler” on page 555 for complete details. • Enabling and configuring one or more of the job modules and setting preferences for those job module;...
Page 555: Setting Up The Job Scheduler
Setting Up the Job Scheduler job checks for certificates that have expired and are still UnpublishExpiredJob marked as published in the internal database at the configured time interval. The job connects to the publishing directory and deletes those certificates; it then marks those certificates as unpublished in the internal database.
Page 556: Enabling And Configuring The Job Scheduler
Setting Up the Job Scheduler Table 14-1 Time Format for Scheduling Jobs (Continued) Field Value Month of year 1-12 Day of week 0-6 (where 0=Sunday) For example, the following time entry specifies every hour at 15 minutes (1:15, 2:15, 3:15 and so on): 15 * * * * The following example specifies a job execution time of noon on April 12:...
Page 557 Setting Up the Job Scheduler Enter information as appropriate: Enable Jobs Scheduler. Select this option to enable the Job Scheduler; deselect to disable the Job Scheduler. Disabling turns off all the jobs. Check Frequency. Type the frequency at which the Job Scheduler daemon thread should wake up and call the configured jobs that meet the specification.
Page 558: Setting Up Specific Jobs
Setting Up Specific Jobs Setting Up Specific Jobs You can configure automated jobs using the CS console user interface, or by editing the configuration file directory. We recommend that you make these changes using the CS console. Enabling and Configuring Specific Jobs Using the CS Console To enable and configure an automated job using the CS console: Ensure that the Jobs Scheduler is enabled and configured;...
Page 559 Setting Up Specific Jobs In the navigation tree, select Job Scheduler, then select Jobs. The Job Instance tab appears showing the default jobs. If you want to delete a job instance, select that instance and click delete. If you want to add a job instance, click Add, then select the module you want to add. To enable and configure an existing job instance, or modify the configuration of a job, go to the next step.
Page 560: Enabling Configuring Specific Jobs By Editing The Configuration File
Setting Up Specific Jobs Select Enable and set each of the configuration settings by specifying them in the fields for this dialog. see “Configuration Parameters of RenewalNotificationJob,” RenewalNotifier on page 561 for details about these parameters. see “Configuration Parameters of RequestInQueueJob,” on RequestInQueueJob page 562 for details about these parameters.
Page 561: Configuration Parameters Of Renewalnotificationjob
Setting Up Specific Jobs Save the file. Restart the server instance. If you set up a job that sends automated messages, check that your have correctly set up a mail server. See “Mail Server,” on page 250. If you set up a job that sends automated messages, you can customize those messages. See “Customizing Notification Messages,”...
Page 562: Configuration Parameters Of Requestinqueuejob
Setting Up Specific Jobs Table 14-2 RenewalNotificationJob Parameters (Continued) Parameter Description Specifies the path, including the filename, to the directory that emailTemplate contains the template to be used for formulating the message content. Specifies whether a summary report of renewal notifications summary.enabled should be compiled and sent.
Page 563: Configuration Parameters Of Unpublishexpiredjob
Setting Up Specific Jobs Table 14-3 RequestInQueueJob Parameters (Continued) Parameter Description Specifies the cron specification for when this job should be run. cron This is the time at which the Job Scheduler daemon thread checks the queue for pending requests. Permissible values: Must follow the convention specified in “Frequency Settings for Automated Jobs”...
Page 564 Setting Up Specific Jobs Table 14-4 UnpublishExpiredJob Parameters Parameter Description Specify the value of this parameter as true to enable; specify the enabled value of this parameter as false to disable. Specifies the cron specification for when this job should be run. cron This is the time at which the Job Scheduler daemon thread checks the certificates for removing expired certificates from the...
Page 565: Customizing Notification Messages
Customizing Notification Messages Customizing Notification Messages The email notifications that are sent are constructed using a template for each type of message that is sent. Each type of message has an HTML template and a plain text template associated with it. Messages are constructed from text and tokens, and HTML markup in the case of HTML templates.
Page 566: Token Definitions
Customizing Notification Messages Table 14-5 Notification Templates (Continued) Filename Description RenewalNotificationJob Template for formulating the message content to be sent to rnJob1.txt end entities to inform them that their certificates are about to expire and that they should renew their certificates before expiration.
Page 567: Managing Job Plug-Ins
Managing Job Plug-ins Table 14-6 Tokens for the renewal-notification job’s summary report (Continued) Token Description Specifies the NotAfter attribute of the certificate validity $NotAfter period. Specifies the NotBefore attribute of the certificate validity $NotBefore period. Specifies the email address of the recipient. $RecipientEmail Specifies the request ID.
Page 568: Registering Or Deleting A Job Module
Managing Job Plug-ins Registering or Deleting a Job Module You can register custom job plug-in modules from the CS window. Registering a new module involves specifying the name of the module and the full name of the Java class that implements the module.
Page 569: Chapter 15 Revocation And Crls
Chapter 15 Revocation and CRLs Red Hat Certificate System (CS) provides methods for revoking certificates and for producing lists of revoked certificates, called certificate revocation lists (CRLs). This chapter describes the methods for revoking a certificate, describes CMC Revocation, and provides details about CRLs and setting up CRLs.
Page 570: Authentication Of End Users During Certificate Revocation
Revocation end user can also specify additional details, such as the date of revocation and revocation reason for each certificate or for the list as a whole. For instructions on how end users revoke their certificates, see the online help available by clicking the Help buttons in the end-entity forms.
Page 571: Certificate Revocation Forms
Revocation Challenge-Password-Based Revocation A challenge password is a unique, alphanumeric string that the end user specifies when requesting a certificate; the user is expected to keep this password confidential and use it to authenticate to the server when revoking the certificate. When the server issues the certificate, it associates the password with the certificate, stores both the certificate and password in its internal database, and uses them later for authenticating any revocation requests.
Page 572: Cmcrevocation
CMCRevocation For details on individual form elements, see the online help available by clicking the Help button on the form. For more information on customizing the form, see CS Customization Guide. CMCRevocation Note: The revocation method described here will return Javascript rather than a CMC response.
Page 573: Testing Cmc Revoke
.\CMCRevoke -d<dir to cert8.db, key3.db> -n<nickname> -i<issuerName> -s<serialName> -m<reason to revoke> -c<comment> For example, if the directory containing the agent certificate is , the nickname .redhat of the certificate is , and the serial number of the RegistartionManagerAgentCert certificate is...
Page 574: About Crls
About CRLs .\CMCRevoke -d".\.redhat" -n"RegistartionManagerAgentCert" -i"cn=agentAuthMgr" -s22 -m0 -c"test comment" Go to the end entity interface at the following URL: https://localhost/ca/ Select the Revocation Tab. Select the CMC Revoke link on the menu. Paste the output of step 2 into the text area Remove "-----BEGIN NEW CERTIFICATE REQUEST-----"...
Page 575: Reasons For Revoking A Certificate
About CRLs framework, see “Setting CRL Extensions,” on page 582” for more information on setting up CRL extensions for issuing points. You can configure the Certificate Manager to generate the CRL every time a certificate is revoked and at periodic intervals which is stored in its internal database.
Page 576: Revocation Checking By Red Hat Servers
About CRLs A certificate can be revoked by administrators, agents, and end entities. Agents and administrators (with agent privileges) can revoke certificates by using the forms provided in the agent interface. End users can revoke certificates by using the forms provided in the Revocation tab of the end-entity interface.
Page 577: Crl Issuing Points
About CRLs CRL Issuing Points Because CRLs can grow very large, several methods have been developed to minimize the overhead of retrieving and delivering large CRLs. One of these methods is based on partitioning the entire certificate space and associating a separate CRL with every partition. This partition is called a CRL issuing point—it is the location where a subset of all the revoked certificates are maintained.
Page 578: Setting Up The Issuance Of Crls
Setting Up the Issuance of CRLs The cache is copied to the internal directory at the intervals that you specify for copying the cache. When the interval for creating a CRL is reached, as specified in the configuration for that issuing point, a CRL is created from the cache. If a delta CRL has been set up for this issuing point, a delta CRL is also created at this time.
Page 579: Configuring Issuing Points
Setting Up the Issuance of CRLs Setting up CRL Issuing Points by enabling those you want to actually issue CRLs. An issuing point is already set up and enabled for a Master CRL. You can create any additional Issuing Points you want for the CRLs you want to generate from those issuing points.
Page 580: Configuring Crls For Each Issuing Point
Setting Up the Issuance of CRLs To delete an issuing point, select that issuing point and click Delete. To edit an issuing point, select that issuing point and click Edit. You can only change the description for the issuing point, and change the status from enabled to disabled. To add an issuing point, click Add.
Page 581 Setting Up the Issuance of CRLs Configure the CRL for this issuing point by specifying the fields in the Revocation List tab for that issuing point. You may want to expand the CS console window by dragging at one of the corners, some fields in this window do not appear large enough to read the content.
Page 582: Setting Crl Extensions
Setting Up the Issuance of CRLs Include expired certificates. Select if you want the server to include revoked certificates that have expired in the CRL. If this is enabled, information about revoked certificates will remain in the CRL after the certificate expires. If you do not enable, information about revoked certificates is removed when the certificate expires.
Page 583: Crl Extension Reference
CRL Extension Reference The right pane shows the CRL Extensions Management tab, which lists configured extensions. To modify a rule, select it and then click Edit/View. Change the information as appropriate. Be sure to supply all the required values. See “CRL Extension Reference,” on page 583 for complete information about each extension and the parameters for those extensions.
Page 584: Crlnumber
CRL Extension Reference Table 15-1 AuthorityKeyIdentifierExt Configuration Parameters Parameter Description Specifies whether the rule is enabled or disabled. Select to enable, enable deselect to disable (default). Select if you want the server to mark the extension critical; deselect if you critical want the server to mark the extension noncritical (default).
Page 585: Deltacrlindicator
CRL Extension Reference Table 15-3 CRLReason Configuration Parameters Parameter Description Specifies whether the rule is enabled or disabled. Select to enable (default), enable deselect to disable. Select if you want the server to mark the extension critical; deselect if you want critical the server to mark the extension noncritical (default).
Page 586: Holdinstruction
CRL Extension Reference Table 15-5 FreshestCRL Configuration Parameters (Continued) Parameter Description Indicates the number of issuing points for delta CRL. Can be set to 0 or any numPoints positive integer, the default is 0. Note: When you set this to an integer other than 0, you need to set this and then click OK to close this window.
Page 587: Invaliditydate
CRL Extension Reference Table 15-6 HoldInstruction Configuration Parameters (Continued) Parameter Description Specifies the action a validating application must take when it encounters instruction a certificate that has been put on hold. , or Permissible values: none callissuer reject • none specifies that the validating application need not do anything; the PKIX standard says that this is semantically equivalent to the absence of a holdInstructionCode (default).
Page 588 CRL Extension Reference For general guidelines on setting the issuer alternative name extension in CRLs, see “issuerAltName” on page 746. Table 15-8 IssuerAlternativeName Configuration Parameters Parameter Description Specifies whether the rule is enabled or disabled. Select to enable, deselect to enable disable (disable).
Page 589: Issuingdistributionpoint
CRL Extension Reference Table 15-8 IssuerAlternativeName Configuration Parameters (Continued) Parameter Description • If the type is dNSName, the value must be a valid domain name in the DNS format. For example, testCA.example.com. • If the type is ediPartyName, the name must be an IA5String. For example, Example Corporation.
Page 590 CRL Extension Reference Table 15-9 IssuingDistributionPoint Configuration Parameters Parameter Description Specifies whether the rule is enabled or disabled. Select to enable enable, deselect to disable (default). Select you want the server to mark the extension critical critical (default); deselect if you want the server to mark the extension noncritical.
Page 591 CRL Extension Reference Table 15-9 IssuingDistributionPoint Configuration Parameters (Continued) Parameter Description Select if the distribution point contains user certificates only; onlyContainsUserCerts deselect if the distribution point contains all types of certificates (default). Select if the distribution point contains an indirect CRL; deselect indirectCRL if the distribution point doesn’t contain an indirect CRL (default).
Page 592 CRL Extension Reference Red Hat Certificate System Administrator’s Guide • September 2005...
Page 593: Chapter 16 Publishing
Chapter 16 Publishing Red Hat Certificate System (CS) provides a customizable publishing framework for the Certificate Manager and the Registration Manager, enabling them to publish certificates, certificate revocation lists (CRLs), and other certificate-related objects to any of the supported repositories—an LDAP-compliant directory, a flat file, and an online validation authority—using the appropriate protocol.
Page 594: About Publishing
About Publishing About Publishing CS is capable of publishing certificates to a file or an LDAP directory, and CRLs to a file, an LDAP directory, or to an OSCP responder. The publishing feature is very flexible allowing you to publish to a file, publish to an LDAP directory, to an OSCP responder, or all three.
Page 595: About Mappers
About Publishing With file publishing, you set up a publisher for every location you will publish to. With LDAP publishing, you set up a publisher for every DN that needs a different formula for deriving that DN. When you create a rule that determines whether a given certificate or CRL will be published, you associate a publisher with each rule providing the location for the rule.
Page 596: About Ldap Publishing
About Publishing • For each certificate the server issues, it creates a file that contains the certificate in its DER-encoded format. Each file is named , where cert-<serial_number>.der specifies the serial number of the certificate contained in the file. <serial_number> For example, the filename for a certificate with serial number will be 1234...
Page 597: About Ocsp Publishing
About Publishing About OCSP Publishing CS provides two forms of OCSP services, an internal service and the Online Certificate Status Manager subsystem. The internal service checks the internal database of the Certificate Manager to report on the status of a certificate. The internal service is not set up for publishing, it uses the certificates stored in its internal database to determine the status of a certificate.
Page 598: Setting Up Publishing
Setting Up Publishing For rules that specify to publish to a file, a new file is created when either a certificate or a CRL is issued in the stipulated directory. For rules that specify to publish to an LDAP directory, the certificate or CRL is published to the entry specified in the directory, in the attribute specified.
Page 599 Setting Up Publishing If you are publishing all CRLs to one location, create one publisher specifying the ❍ location where you want to publish all CRLs. If you are publishing different types of CRLS to separate locations, create a ❍ publisher for each location you will publish to specifying the location you will publish.
Page 600: Publishers
Publishers The rule first determines if the object meets the rule, and then where it is to be published. Determining if the object meets the rule is done by matching the type and predicate set up in the rule with the object itself. Determining where matching objects are published is determined by the Publisher and Mapper that is associated with this rule.
Page 601: Configuring Publishers For Publishing To A File
Publishers Configuring Publishers for Publishing to a File You need to create and configure a Publisher for each publishing location; publishers are not automatically created for publishing to a file. If you are publishing all to one location, you can create one publisher. If you are publishing to different locations, you need to create a publisher for each location you will be publishing to.
Page 602 Publishers Select the module named FileBasedPublisher This is the only Publisher module that enables the Certificate Manager to publish certificates and CRLs to files. Click Next. The Publisher Editor window appears. Fill in the following fields in this window: Publisher ID. Type a name for the rule. Be sure to use an alphanumeric string with no spaces.
Page 603: Configuring Publishers For Publishing To Ocsp
Publishers Click OK. You are returned to the Publishers Management tab. It should now list the publisher you just created. Repeat this procedure creating all the publishers you will need. Configuring Publishers for Publishing to OCSP You need to create and configure a Publisher for each publishing location; publishers are not automatically created for publishing to the OCSP responder.
Page 604 Publishers Click Add. The Select Publisher Plug-in Implementation window appears. It lists registered publisher modules. Select the module named OCSPPublisher This is the only Publisher module that enables the Certificate Manager to publish CRLs to the Online Certificate Status Manager. Click Next.
Page 605: Configuring Publishers For Ldap Publishing
Publishers Fill in the following fields in this window: Publisher ID. Type a name for the rule; use an alphanumeric string with no spaces. For example, Ca1CrlToOcspResponder host. Type the fully-qualified DNS host name of the Online Certificate Status Manager. For example: ocspResponder.example.com port.
Page 606: Publisher Plug-In Module Reference
Publishers • Used to publish CRLs to the LDAP directory. LdapCrlPublisher • Used to publish Delta CRLs to the LDAP directory. LdapDeltaCrlPublisher • Used to publish all types of end-entity certificates to the LdapUserCertPublisher LDAP directory. • Used to publish cross-signed certificates to the LdapCrossCertPairPublisher LDAP directory.
Page 607 Publishers Table 16-1 FileBasedPublisher Configuration Parameters Parameter Description Specifies a name for the publisher. You can use an alphanumeric string Publisher ID with no spaces. For example, PublishCertsToFile. Specifies the complete path to the directory in which the Certificate directory Manager should create the DER-encoded files;...
Page 608 Publishers You can use this module to publish any end-entity certificate to an LDAP directory. Types of end-entity certificates include SSL client, S/MIME, SSL server, object signing, router, and OCSP responder. During installation, the Certificate Manager automatically creates an instance of the module for publishing end-entity certificates to the directory.
Page 609 Publishers Table 16-5 LdapDeltaCrlPublisher Configuration Parameters Parameter Description Specifies the directory attribute of the mapped entry to which the crlAttr Certificate Manager should publish the certificate. Must be deltaRevocationList;binary. LdapCertificatePairPublisher The LdapCertificatePairPublisher plug-in module enables you to configure a Certificate Manager to publish or unpublish a cross-signed certificate to the crossCertPair;binary attribute of the CA’s directory entry.
Page 610: Mappers
Mappers Table 16-7 OCSPPublisher Parameters Parameter Description Specifies the fully qualified hostname of the Online Certificate Status host Manager. Specifies the port number on which the Online Certificate Status port Manager is listening to the Certificate Manager, this is the Online Certificate Status Manager’s end-entity SSL port number.
Page 611 Mappers To use the default mappers, configure each of these macros specifying the DN pattern used and whether or not you want CS to create the CA entry in the directory. To use other mappers, create an instance of the mapper you want to use, and then configure it.
Page 612 Mappers To create a new mapper instance: Click Add. The Select Mapper Plugin Implementation window appears. It lists registered mapper modules. Select a module. For complete information about these modules, see “Mapper Plug-in Modules Reference,” on page 613. Click Next. The Mapper Editor window appears.
Page 613: Mapper Plug-In Modules Reference
Mappers Mapper Plug-in Modules Reference This section describes the mapper plug-in modules provided for the Certificate Manager. You can use these modules to configure a Certificate Manager to enable and configure specific Mapper instances. The available mapper plug-in modules include the following: •...
Page 614 Mappers If the mapper fails to create a second CA entry, be sure to check the base DN that the uid uniqueness plug-in is set to (in the file) and also check if an entry with slapd.ldbm.conf the same UID already exists in the directory. If it’s true, adjust the mapper setting, remove the old CA entry, comment out the plug-in, or create the entry manually using the Console window.
Page 615 Mappers LdapCaCertMap The mapper named is an instance of the module. The LdapCaCertMap LdapCaSimpleMap Certificate Manager automatically creates this mapper during installation. You can use this mapper for creating an entry for the CA in the directory and for mapping the CA certificate to the CA’s entry in the directory.
Page 616 Mappers LdapSimpleMap plug-in module enables you to configure a Certificate Manager to LdapSimpleMap map a certificate to an LDAP directory entry by deriving the entry’s DN from components specified in the certificate request, certificate’s subject name, certificate extension, and attribute variable assertion (AVA) constants. For more information on AVAs, see the directory documentation.
Page 617 Mappers certSubjectDN=UID=jdoe, O=Example Corporation, C=US and then narrows down the search to an entry that has only this: certSubjectDN=UID=jdoe, O=Example Corporation, C=US If no matching entries are found, the server returns an error and writes it to the log. Configuration Parameters of LdapSubjAttrMap Table 16-9 describes these parameters.
Page 618 Mappers Note that both parameters accept valid DN components or DNComps filterComps attributes separated by commas. The parameters don’t accept multiple entries of an attribute; for example, you can set , but not to . If filterComps CN,OU CN,OU2,OU1 there’s a need for you to support such a filter, for example, if your directory entries contain multiple s and you want to use multiple s in your...
Page 619 Mappers The Certificate Manager can use some or all of these components ( , and to build a DN for searching the directory. When creating a mapper rule, you can specify the components the server should use to build a DN (that is, components to match attributes in the directory).
Page 620 Mappers NOTE Generally, the , and components are not included in the standard set of certificate request forms provided for end entities. You can add these components to the forms, or you can have the issuing agents insert these components when editing the subject name in the certificate issuance forms.
Page 621: Rules
Rules Table 16-10 LdapDNCompsMap Configuration Parameters (Continued) Parameter Description Specifies components the Certificate Manager should use to filter entries filterComps from the search result. The server uses the filterComps values to form an LDAP search filter for the subtree. The server constructs the filter by gathering values for these attributes from the certificate subject name;...
Page 622: Modifying Publishing Rules For Certificates And Crls
Rules Modifying Publishing Rules for Certificates and CRLs Creating a publishing rule for CA certificate and end-entity certificates involves creating a rule that uses the publisher that you created in the previous step. You create a rule for each type of certificate the Certificate Manager issues. To modify publishing rules: Log in to the CS console for the Certificate Manager (see “Logging Into the CS Console”...
Page 623 Rules To create a rule: Click Add. The Select Rule Plugin Implementation window appears. Select the module named Rule This is the only module. (If you have registered any custom modules, they too will be available for selection.) Click Next. The Rule Editor window appears.
Page 624 Rules Enter the appropriate information: Rule ID. Type a name for the rule that will help you identify it later; use an alphanumeric string with no spaces. For example, PublishCaCertToFile type. Select the type value from the list. The type value depends on which type of certificate this rule applies.
Page 625 Rules Click OK. The Rules Management tab appears, listing the new rule you just created for publishing the CA certificate to the file. Repeat this procedure to create publishing rules for each rule you will need. Predicates Used In Publishing Rules Table 16-11 lists the predicates that can be used to identify certificate types.
Page 626: Rule Instance Reference
Rules Rule Instance Reference This section discusses the rule instances that have been set up. LdapCaCertRule can be used to publish CA certificates to an LDAP directory. LdapCaCertRule Table 16-13 LdapCaCert Rule Configuration Parameters Parameter Value Description type cacert Specifies the type of certificate that will be published.
Page 627 Rules Table 16-14 LdapXCert Rule Configuration Parameters Parameter Value Description enable Select to enable. mapper LdapCaCertMap Specifies the mapper used with this rule. See “LdapCaCertMap,” on page 615 for details on this mapper. publisher LdapCrossCertPairPublisher Specifies the publisher used with this rule.
Page 628: Enabling Publishing
Enabling Publishing LdapCRLRule can be used to publish CRLs to an LDAP directory. LdapCRLRule Table 16-16 LdapCRL Rule Configuration Parameters Parameter Value Description type Specifies the type of certificate that will be published. Select from the pull down menu. predicate Specifies a predicate for this publisher.
Page 629 Enabling Publishing To enable LDAP publishing, select both Enable Publishing and Enable Default LDAP Connection options. In the Destination section, identify the Directory Server instance. Host name. Type the fully qualified DNS host name of the Directory Server. For example: host1.example.com If you configured the Directory Server for SSL client authenticated communication, the name you enter here must match the...
Page 630: Testing Publishing To Files
Testing Publishing to Files If you configured the Directory Server for SSL communication with client authentication, select , select the SSL client authentication Use SSL option, and identify the certificate that the Certificate Manager must communication use for SSL client authentication to the directory. To save your changes, click Save.
Page 631 Testing Publishing to Files At the prompt, enter this: BtoA <input_file> <output_file> substituting with the path to the file that contains the DER <input_file> encoded certificate and with the path to the file to write the <output_file> base-64 encoded certificate. For example, if the file is in and you want C:\certificates\cert-1234.der...
Page 632: Configuring The Directory For Ldap Publishing
Configuring the Directory for LDAP Publishing For example, if the base-64 encoded certificate is in and you want the human-readable form of C:\certificates\cert-1234.txt the certificate to be displayed on your screen, the command would look like this: PrettyPrintCert C:\certificates\cert-1234.txt When the conversion is complete, you should see the certificate you issued in human-readable form.
Page 633: Schema
Configuring the Directory for LDAP Publishing • Bind DN • Directory Authentication Method Schema For a Certificate Manager to publish certificates and CRLs to a directory, it must be configured with specific attributes and object classes. This section discusses those basic schema requirements.
Page 634: Entry For The Ca
Configuring the Directory for LDAP Publishing This attribute is an attribute of the object class . The value of certificationAuthority the attribute is the DER encoded binary X.509 certificate revocation list. The CA’s entry must already be a certificate authority. Entry for the CA You can have the Certificate Manager automatically create an entry for the CA in your directory.
Page 635: Directory Authentication Method
Updating Certificates and CRLs in a Directory To provide the Certificate Manager with a user entry that has read-write permission, you can do either of the following: • Use the DN of an existing entry that has write access. For example, you can use the entry of the Directory Manager or choose an alternative.
Page 636: Manually Updating Certificates In The Directory
Updating Certificates and CRLs in a Directory To help find certificates that are out of sync with the directory—that is, valid certificates that are not in the directory and revoked or expired certificates that are still in the directory—the Certificate Manager keeps a record of whether a certificate in its internal database has been published to the directory.
Page 637 Updating Certificates and CRLs in a Directory To manually update the directory with changes: Go to the Certificate Manager Agent Services interface. You must submit the proper certificate to get access to this page. Select the Update Directory Server link. The Update Directory Server page appears.
Page 638: Manually Updating The Crl In The Directory
Registering and Deleting Mapper and Publisher Plug-in Modules Manually Updating the CRL in the Directory The Update Certificate Revocation List form in the Certificate Manager Agent Services interface to enables you to manually update the directory with CRL-related information. To manually update the CRL information in the directory: Go to the Certificate Manager Agent Services page.
Page 639 Registering and Deleting Mapper and Publisher Plug-in Modules To register or delete a mapper module, select Mappers, and then in the right pane, ❍ select the Mapper Plugin Registration tab. To register or delete a publisher module, select Publishers, and then in the right ❍...
Page 640 Registering and Deleting Mapper and Publisher Plug-in Modules Red Hat Certificate System Administrator’s Guide • September 2005...
Page 641: Chapter 17 Configuring Cs For High Availability
Chapter 17 Configuring CS for High Availability This chapter explains how to create and configure the Red Hat Certificate System for high availability. CS allows you to clone various subsystems and run the cloned instances on different machines. This provides failover support by ensuring that CS services continue, even if the machine on which the master instance was installed goes down.
Page 642: Architecture Of A Failover System
CS High Availability Overview all requests to the machine that is still up and running until such time as the other machine is brought back online. The cloning feature in CS also supports scalability by assigning the same task to separate instances on different machines (e.g., handling certificate requests) in a seemless way.
Page 643: Load Balancing
CS High Availability Overview As this diagram indicates, only one of the CAs can generate the CRLs. See “Cloned-Master CA Conversion” on page 659 for more information about configuring a clone for CRL generation during failover. Load balancing The load balancer in front of a CS system is what provides the actual failover support in a high availability system.
Page 644: Cloning The Certificate Manager
Cloning the Certificate Manager • DNS round robin, a feature for managing network congestion that distributes load across several different servers. • Sticky SSL, which makes it possible for a user returning to the system to be routed the same host they used previously. Consult the documentation for the load balancer you intend to use with CS to read more about the features, advantages, and configuration of a load balancer.
Page 645 Cloning the Certificate Manager Verify that this master instance is running. ❍ The CA instance automatically starts up once it’s been properly configured. If you need to start or restart the Certificate Manager manually, you may do so by invoking the commands, which are available in start-cert restart-cert...
Page 646: Cloning The Ca
Cloning the Certificate Manager configuration which expects usernames [A-M] using one machine and usernames [N-Z] using the other machine), then the SSL server certificate DNs should contain the hostname of their resident machines with their own unique keys obtained by using the renewal process (this scenario requires advanced manual configuration and therefore is not recommended).
Page 647 Cloning the Certificate Manager The Installation Wizard asks you to copy the key and certificates from the master CA to the clone if you have not already done so. Chapter 17 Configuring CS for High Availability...
Page 648 Cloning the Certificate Manager Copy the master CA’s Certificate and Key Database. Because you want the cloned Certificate Manager to own the same keys and certificates as that of the master Certificate Manager, you need to make the keys and certificates used by the master Certificate Manager available to the Certificate Manager clone.
Page 649 Cloning the Certificate Manager On the host machine of the cloned Certificate Manager, go to this directory: III. <server_root>/alias Copy the certificate and key database files from the master Certificate Manager to the clone. If the master Certificate Manager’s keys and certificates are stored in the hardware ❍...
Page 650 Cloning the Certificate Manager In the Local Consumer Database dialog, specify what type of database you are creating. Either select Create a local consumer database to create a new clone database local to the cloned Certificate Manager: Red Hat Certificate System Administrator’s Guide • September 2005...
Page 651 Cloning the Certificate Manager Or select Connect to the existing remote LDAP server to use the existing LDAP server as the internal database for the cloned Certificate Manager instance. If you select the remote database, make sure that you have already created an LDAP server containing a base suffix of on the host o=CertificateServer...
Page 652 Cloning the Certificate Manager Configure replication between the cloned CA database and the master CA database in the following dialog. Red Hat Certificate System Administrator’s Guide • September 2005...
Page 653 Cloning the Certificate Manager Follow the instructions on screen to create the password for the Replication Manager role in the Master database, the password for the Replication Manager role in the Consumer database, and the agreement names between the master and clone’s databases.
Page 654 Cloning the Certificate Manager Be aware of the following as you designate the serial number ranges for the certificate and request numbers of the cloned Certificate Manager: CA’s serial number range—On this screen, specify the lowest serial number the ❍ CA should assign to certificates it creates in the “Starting certificate number”...
Page 655 Cloning the Certificate Manager Specify the master CA’s agent port in the Agent Port field so that the clone can redirect “Update CRL” requests to the master CA (see “About CRLs” on page 574 for more information about CRLs). Choose the cloned CA’s signing certificate, the OCSP’s signing certificate, and the SSL server certificate from the pull-down menus provided in the Clone Key and Certificate Materials for CA Subsystem dialog.
Page 656 Cloning the Certificate Manager In order for these fields to be populated properly, you have to have already copied over the appropriate certificates from the master CA. If you do not see certificates in the pull-down menus, follow the instructions in Step 4 above to copy the key and certificate database material over correctly.
Page 657: Testing The Ca Cloned-Master Connection
Cloning the Certificate Manager Stop the master CA server by issuing the following command in that directory: ./stop-cert Go to the master CA's server config directory: cd <serverRoot>/cert-<masterID>/config Edit the CS.cfg file by adding the following line: ca.listenToCloneModifications=true Close and save the CS.cfg file. Go to the master CA directory at the command line: cd <serverRoot>/cert-<masterID>...
Page 658: Additional Crl Scheduling Information
Additional CRL Scheduling Information Check master CA’s CRL for the revoked certificate. To verify that the revoked certificate has been included in the master Certificate Manager’s CRL, go to the master Certificate Manager’s Agent Services interface. In the left frame, click Update Certificate Revocation List. Find the CRL and display it. The CRL appears in the browser window.
Page 659: Cloned-Master Ca Conversion
Cloned-Master CA Conversion Cloned-Master CA Conversion In the event that the user needs to convert an existing cloned CA into a new master CA (e. g., a catastrophic failure of the existing master CA), one needs to first convert the existing offline master CA into a clone followed by converting one of the current existing online cloned CAs into the new online master CA.
Page 660: Converting A Cloned Ca Into A Master Ca
Converting a Cloned CA into a Master CA To disable monitoring database replication changes, modify the following line if it exists by changing "true" to "false" (adding the line in if it does not already exist): ca.listenToCloneModifications=false To disable maintenance of the CRL cache, modify all of the "enableCRLCache" lines if they exist by changing "true"...
Page 661 Converting a Cloned CA into a Master CA Delete each line of configuration data from this cloned CA’s configuration file called which begins with <serverRoot>/cert-<cloneID>/config/CS.cfg the ca.crl. prefix: ca.crl.* Copy the configuration data from the existing offline master CA to this cloned CA by opening the file called <serverRoot>/cert-<masterID>/config/CS.cfg nd copying each line beginning with the ca.crl.
Page 662: Cloning The Online Certificate Status Manager
Cloning the Online Certificate Status Manager Cloning the Online Certificate Status Manager Recall that CS systems may include both an OCSP service internal to the Certificate Manager, which responds to status requests by going to the Certificate Manager’s internal database, and a separate Online Certificate Status Manager subsystem. When you create an OCSP clone, you are setting up a second instance of this Online Certificate Status Manager subsystem to handle status requests based on CRLs published to it by one or more Certificate Managers (see “Publishing of CRLs”...
Page 663: Preparing To Clone The Online Certificate Status Manager
Cloning the Online Certificate Status Manager Preparing to Clone the Online Certificate Status Manager Before you can create a clone of the Online Certificate Status Manager, you must make sure that the instance you are cloning has been properly installed and configured, since some of that configuration data is copied over to the new instance.
Page 664: Cloning The Ocsp Responder
Cloning the Online Certificate Status Manager Cloning the OCSP Responder The following are the steps to setup cloning for an Online Certificate Status Manager: From the Object menu in the Red Hat Console, choose Create Instance Of, then choose Red Hat Certificate System. Alternatively, you can right-click the Server Group node and choose Create Instance Of >...
Page 665 Cloning the Online Certificate Status Manager Designate the password for the internal token in the Logon Token dialog. In the Master Database dialog, enter the hostname, port, and password for the Master Database of the CS system. In the Local Consumer Database dialog, specify what type of database you are creating. Either select Create a local consumer database to create a new clone database local to the cloned Online Certificate Status Manager.
Page 666 Cloning the Online Certificate Status Manager In order for these fields to be populated properly, you have to have already copied over the appropriate certificates from the master CA. If you do not see certificates in the pull-down menus, follow the instructions in Step 2 above to copy the key and certificate database material over correctly.
Page 667: Testing The Ocsp Cloned-Master Connection
Cloning the Online Certificate Status Manager Testing the OCSP Cloned-Master Connection Follow these steps to test whether your cloned-master OCSP setup is complete and functional. Setup OCSP Publishing in the master CA so that the CRL will be published to the master Online Certificate Status Manager.
Page 668: Converting A Cloned Ocsp Responder Into A Master Ocsp Responder
Cloning the Online Certificate Status Manager Open the CS.cfg file for editing, and add the following line (21600 is the default value for a cloned OCSP Responder. This value can be changed to any other non-zero number): ocsp.store.defStore.refreshInSec=21600 Close and save the CS.cfg file. Converting a Cloned OCSP Responder into a Master OCSP Responder Having already converted the existing offline master OCSP Responder into an offline...
Page 669: Cloning The Data Recovery Manager
Cloning the Data Recovery Manager Cloning the Data Recovery Manager The process for setting up a DRM clone is very similar to that for setting up a cloned CA. Since DRM cache information is stored in the memory for recovery operations, the whole remove recovery process needs to be performed on the same DRM.
Page 670: Cloning The Drm
Cloning the Data Recovery Manager DRM’s SSL server key and certificate—This depends on the way in which you ❍ have deployed the clone environment. If you are using a load balancer, regardless of whether or not the host machines are different, you do not need to generate a new SSL server certificate for the cloned Data Recovery Manager, since the SSL server certificate DN should contain the hostname of the load balancer as the common name (CN) attribute.
Page 671 Cloning the Data Recovery Manager Locate the certificate and key database files for the Data Recovery Manager; the file names are as follows: cert-<kra_instance_id>-<machine_name>-cert8.db cert-<kra_instance_id>-<machine_name>-key3.db On the host machine of the clone, go to this directory: III. <server_root>/alias Copy the certificate and key database files from the master Data Recovery Manager to the clone.
Page 672 Cloning the Data Recovery Manager Designate the password for the internal token in the Logon Token dialog. In the Master Database dialog, enter the hostname, port, and password for the Master Database of the CS system. In the Local Consumer Database dialog, specify what type of database you are creating. Either select Create a local consumer database to create a new clone database local to the cloned Data Recovery Manager.
Page 673 Cloning the Data Recovery Manager Be aware of the following as you designate the key number ranges and request numbers of the cloned Data Recovery Manager: DRM's key number range—On this screen, specify the lowest key number the ❍ DRM should assign for archives it creates in the "Starting key number" field. In the "Ending key number"...
Page 674 Cloning the Data Recovery Manager In order for these fields to be populated properly, you have to have already copied over the appropriate certificates from the master DRM. If you do not see certificates in the pull-down menus, follow the instructions in Steps 4 and 5 above to copy the key and certificate database material and configuration files over correctly.
Page 675: Testing The Drm Cloned-Master Connection
Cloning the Data Recovery Manager Testing the DRM Cloned-Master Connection Follow these steps to test whether your cloned-master DRM setup is complete and functional. Go to the DRM agent page. Click List Requests. Select "Show all requests" from the pull-down menu for Request type. Select "Show all requests"...
Page 676 Cloning the Data Recovery Manager Red Hat Certificate System Administrator’s Guide • September 2005...
Page 677: Security Requirements For The It Environment
Appendix A Common Criteria Environment: Security Requirements The text in this document is copied directly from the ST (Security Target). Security Requirements for the IT Environment This chapter specifies the security functional requirements that are applicable to the IT environment. Table A-1 IT Environment Functional Security Requirements Security Functional Class...
Page 678: Security Audit (Fau)
Security Requirements for the IT Environment Table A-1 IT Environment Functional Security Requirements Security Functional Class Security Functional Components FDP_ITT.1 Basic internal transfer protection (iterations 1 and 2) FDP_UCT.1 Basic data exchange confidentiality (iteration 1) Identification and authentication (FIA) FIA_AFL.1 Authentication failure handling FIA_ATD.1 User attribute definition FIA_UAU.1 Timing of authentication (iteration 1) FIA_UID.1 Timing of identification (iteration 1)
Page 679 Security Requirements for the IT Environment All auditable events for the minimum level of audit; and The events listed in Table 2 below. FAU_GEN.1.2 The IT environment shall record within each audit record at least the following information: Date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event;...
Page 680 Security Requirements for the IT Environment FAU_GEN.2 User identity association (iteration 1) FAU_GEN.2.1 The IT environment shall be able to associate each auditable event with the identity of the user that caused the event. FAU_SAR.1 Audit review FAU_SAR.1.1 The IT environment shall provide Auditors with the capability to read all information from the audit records.
Page 681: User Data Protection (Fdp)
Security Requirements for the IT Environment Cryptographic support (FCS) FCS_CKM.1 Cryptographic key generation FCS_CKM.1.1 The FIPS 140-1 validated cryptographic module shall generate cryptographic keys in accordance with [any FIPS-approved or recommended cryptographic key generation algorithm] that meet the following: [FIPS 140-1]. FCS_CKM.4 Cryptographic key destruction FCS_CKM.4.1 The IT environment shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method [any FIPS-approved or recommended...
Page 682: Identification And Authentication (Fia)
Security Requirements for the IT Environment FDP_ITT.1.1 The IT environment shall enforce the CIMC IT Environment Access Control Policy specified in “CIMC TOE Access Control Policy,” on page 687 to prevent the modification of security-relevant user data when it is transmitted between physically-separated parts of the IT environment.
Page 683: Security Management (Fmt)
Security Requirements for the IT Environment FIA_UAU.1.2 The IT environment shall require each user to be successfully authenticated before allowing any other IT environment-mediated actions on behalf of that user. FIA_UID.1 Timing of identification (iteration 1) FIA_UID.1.1 The IT environment shall allow [HTTP and LDAP based services] on behalf of the user to be performed before the user is identified.
Page 684 Security Requirements for the IT Environment FMT_MSA.1.1 The IT environment shall enforce the CIMC IT Environment Access Control Policy specified in “CIMC TOE Access Control Policy,” on page 687 to restrict the ability to modify the security attributes [user definitions and role assignments] to Administrators.
Page 685: Protection Of The Tsf (Fpt)
Security Requirements for the IT Environment Protection of the TSF (FPT) FPT_AMT.1 Abstract machine testing FPT_AMT.1.1 The IT environment shall run a suite of tests [other conditions: during initial start-up, periodically during normal operation, or at the request of an authorized user] to demonstrate the correct operation of the security assumptions provided by the abstract machine that underlies the IT environment.
Page 686: Trusted Path/Channels (Ftp)
Security Requirements for the IT Environment FPT_TST_CIMC.2.1 An error detection code (EDC) or FIPS-approved or recommended authentication technique (e.g., the computation and verification of an authentication code, keyed hash, or digital signature algorithm) shall be applied to all security-relevant software and firmware residing within the CIMC (e.g., within EEPROM and RAM).
Page 687: Cimc Toe Access Control Policy
Security Requirements for the IT Environment CIMC TOE Access Control Policy The TOE shall support the administration and enforcement of a CIMC TOE access control policy that provides the capabilities described below. Subjects (human users) will be granted access to objects (data/files) based upon the: Identity of the subject requesting access, Role (or roles) the subject is authorized to assume, Type of access requested,...
Page 688 Security Requirements for the IT Environment Red Hat Certificate System Administrator’s Guide • September 2005...
Page 689: Pki Overview
Appendix B Common Criteria Environment: Setup and Operations This chapter provides information about the configuration used to set up Red Hat Certificate System (CS) in the Common Criteria Environment. For an overview of PKI, see Appendix J, “Introduction to Public-Key Cryptography.” This chapter contains the following sections: •...
Page 690: Toe Security Environment Assumptions
TOE Security Environment Assumptions TOE Security Environment Assumptions For information about the TOE Security Environment, see Appendix E, “Common Criteria Environment: TOE Security Environment Assumptions”. Security Requirements for the IT Environment The security requirements for the IT environment are detailed in Appendix A, “Common Criteria Environment: Security Requirements.”...
Page 691: Password And Certificate Storage
IT Environment Assumptions Password and Certificate Storage Plan for the storage of any passwords and certificates. Also plan your user password policy. Make sure everyone knows and adheres to these policies. Hardware Token This environment requires a FIPS 140-1 level 3 certified hardware cryptographic module. You need to install the software and hardware for this hardware token before installing and configuring the subsystems.
Page 692: Supported Operating Systems
CS Privileged Users and Groups (Roles) Supported Operating Systems CS runs on the Solaris 2.8 and RedHat Advanced Server 2.1 operating systems. Supported Browsers The browsers that are supported in the Common Criteria Environment are Netscape 4.79, Netscape 6.2, and Netscape 7.x.
Page 693 CS Privileged Users and Groups (Roles) Can view signed audit logs (from the IT environment). This is the only role ❍ allowed this privilege. Can verify audit log signatures by running the AuditVerify tool (from the IT ❍ environment). • Trusted Manager The Trusted Manager role is a special role that is not for privileged users.
Page 694: Ocsp
CS Privileged Users and Groups (Roles) • Administrators Can start/stop server (from the command-line). ❍ Can perform all configuration management for the DRM (via the CS Console). ❍ Can backup (CSBackup) and restore (CSRestore) the subsystem from the ❍ command-line •...
Page 695: About Roles
CS Privileged Users and Groups (Roles) Can backup (CSBackup) and restore (CSRestore) the subsystem from the ❍ command-line. • Online Certificate Status Manager Agents Can add CRLs (to the OCSP Responder Agent interface via SSL-capable ❍ browsers). Can define supported CAs (via SSL-capable browsers to the OCSP Responder ❍...
Page 696: Cs Common Criteria Environment Setup And Installation Guide
CS Common Criteria Environment Setup and Installation Guide CS Common Criteria Environment Setup and Installation Guide Understanding Setup of Common Criteria Evaluated Red Hat CS Appendix C, “Understanding the Common Criteria Evaluated CS Setup,” provides a high level description of the steps for setup, installation, and configuration of Red Hat CS in an IT environment of the kind described in “IT Environment Assumptions”...
Page 697: Appendix C Understanding The Common Criteria Evaluated Cs Setup
Appendix C Understanding the Common Criteria Evaluated CS Setup This document describes at a high level the steps for setup, installation, and configuration of the Red Hat Certificate System (CS) in an IT environment of the kind described in “IT Environment Assumptions”...
Page 698: Cs Roles Assignment
Understanding the Common Criteria Environment Operating System Environment Because CS relies on the IT environment to provide the basic operating system file system security, inter-process communication, and process space protection, it is highly recommended that you install and run CS on an operation system certified at a Common Criteria assurance level no less than the level of CS itself.
Page 699: Understanding Cs Installation
Understanding CS Installation When you begin installation, you will be instructed to create a special user ID, which you will then use to log in to the Operating System when you install CS. This user ID will be the effective user ID of the CS server itself during runtime. You will then need to create groups for the auditor and administrator roles, which you must then assign to the actual user IDs for the CS administrators and CS auditor users on the operating system.
Page 700: Cs Administrative Console
Common Criteria Deployment Scenarios CS Administrative Console In the Common Criteria Environment, you will not be able to start a CS instance using Red Hat Console and the CS console. You must start the server on the command line because when you set up the Common Criteria environment, you disable the password plain-text file used for remote start-up.
Page 701: Features That Are Not Part Of The Common Criteria Environment
Common Criteria Deployment Scenarios You can configure one or more RAs to any CA you set up. You can also install a Data Recovery Manager to any CA that you install. Though connecting a Data Recovery Manager to a Registration Manager is one possible CS deployment scenario, it is not currently part of the Common Criteria Evaluation.
Page 702: Understanding Subsystem Setup
Understanding Subsystem Setup You will be instructed on how to disable these features in order to conform to the Common Criteria Environment. Understanding Subsystem Setup This section describes at a high-level what to expect when you configure a subsystem following the instructions in the document CS Common Criteria Setup Procedure. This section contains links to the main guidance documents where detailed information is provided for each feature, but you will need to follow the CS Common Criteria Setup Procedure in order to set up a Red Hat CS Common Criteria evaluated environment.
Page 703: Audit Logs
Understanding Subsystem Setup Audit Logs The Common Criteria Environment requires that the signed audit log file feature be enabled and configured. “Signed Audit Log” on page 268 provides complete information about how to set up the signed audit feature. Certificate Profiles In the Common Criteria Environment, you must set up the certificate profiles feature for certificate enrollment in a CA or RA subsystem.
Page 704: Crls
Understanding Subsystem Setup CRLs In a CA subsystem, you can set up the CRL feature and any of the three issuing points for CRLs under the Common Criteria Environment. When setting up the CRL feature, you cannot set up a CRL that does not have an update frequency specified in the “Update at this frequency”...
Page 705: Self Tests
Understanding Subsystem Setup Self Tests CS provides a self-diagnostic feature that checks the sanity of a few key items during a CS subsystem startup. Any failed self test is an indication of a fatal error to the subsystem. Technically, CS allows users to add their own self tests as plug-ins; however, only the self-tests provided by default are Common Criteria evaluated.
Page 706: Ocsp Responder Revocation Information Store
Common Criteria Environment Setup Procedures OCSP Responder Revocation Information Store The OCSP Responder revocation store contains information about where the CRLs can be retrieved for serving OCSP requests. You will be instructed to configure the Online Certificate Status Manager revocation store. If you setup the Online Certificate Status Manager to use the ldapstore option, the LDAP store you use must be configured for SSL authentication.
Page 707: Appendix D Common Criteria Environment: Security Objectives
1.1 Security Objectives for the TOE Appendix D Common Criteria Environment: Security Objectives The text in this document is copied directly from the ST (Security Target). This section includes the security objectives including security objectives for the TOE, security objectives for the environment, and security objectives for both the TOE and environment.
Page 708: 1.1.2 System
1.2 Security Objectives for the Environment 1.1.2 System O. Preservation/trusted recovery of secure state Preserve the secure state of the system in the event of a secure component failure and/or recover to a secure state. Sufficient backup storage and effective restoration Provide sufficient backup storage and effective restoration to ensure that the system can be recreated.
Page 709 1.2 Security Objectives for the Environment O. Auditors Review Audit Logs Identify and monitor security-relevant events by requiring auditors to review audit logs on a frequency sufficient to address level of risk. O. Authentication Data Management Ensure that users change their authentication data at appropriate intervals and to appropriate values (e.g., proper lengths, histories, variations, etc.) through enforced authentication data management (Note: this objective is not applicable to biometric authentication data.) O.
Page 710: 1.2.2 It Security Objectives For The Environment
1.2 Security Objectives for the Environment O. Notify Authorities of Security Issues Notify proper authorities of any security issues that impact their systems to minimize the potential for the loss or compromise of data. O. Physical Protection Those responsible for the TOE must ensure that the security-relevant components of the TOE are protected from physical attack that might compromise IT security.
Page 711: Security Objectives For Both The Toe And The Environment
1.3 Security Objectives for both the TOE and the Environment O. Periodically check integrity Provide periodic integrity checks on both system and software. O. Security roles Maintain security-relevant roles and the association of users with those roles. O. Validation of security function Ensure that security-relevant software, hardware, and firmware are correctly functioning through features and procedures.
Page 712 1.3 Security Objectives for both the TOE and the Environment O. Integrity protection of user data and software Provide appropriate integrity protection for user data and software. O. Limitation of administrative access Design administrative functions so that Administrators, Operators, Officers and Auditors do not automatically have access to user objects, except for necessary exceptions.
Page 713 1.3 Security Objectives for both the TOE and the Environment O. Restrict actions before authentication Restrict the actions a user may perform before the TOE authenticates the identity of the user. O. Security-relevant configuration management Manage and update system security policy data and enforcement functions, and other security-relevant configuration data, to ensure they are consistent with organizational security policies.
Page 714 1.3 Security Objectives for both the TOE and the Environment Red Hat Certificate System Administrator’s Guide • September 2005...
Page 715: Appendix E Common Criteria Environment: Toe Security Environment Assumptions
1.1 Secure Usage Assumptions Appendix E Common Criteria Environment: TOE Security Environment Assumptions The text in this document is copied directly from the ST (Security Target). This section includes the following: • 1.1 Secure Usage Assumptions • 1.2 Threats • 1.3 Organization Security Policies 1.1 Secure Usage Assumptions The usage assumptions are organized in three categories: personnel (assumptions about...
Page 716 1.1 Secure Usage Assumptions A. Authentication Data Management An authentication data management policy is enforced to ensure that users change their authentication data at appropriate intervals and to appropriate values (e.g., proper lengths, histories, variations, etc.) (Note: this assumption is not applicable to biometric authentication data.) A.
Page 717: 1.1.2 Physical Assumptions
1.2 Threats 1.1.2 Physical Assumptions A. Communications Protection The system is adequately physically protected against loss of communications i.e., availability of communications. A. Physical Protection The TOE hardware, software, and firmware critical to security policy enforcement will be protected from unauthorized physical modification. 1.1.3 Connectivity Assumptions A.
Page 718: 1.2.2 System
1.2 Threats T. User error makes data inaccessible User accidentally deletes user data rendering user data inaccessible. T. Administrators, Operators, Officers and Auditors commit errors or hostile actions An Administrator, Operator, Officer or Auditor commits errors that change the intended security policy of the system or application or maliciously modify the system’s configuration to allow security violations to occur.
Page 719: 1.2.4 External Attacks
1.3 Organization Security Policies T. Modification of private/secret keys A secret/private key is modified. T. Sender denies sending information The sender of a message denies sending the message to avoid accountability for sending the message and for subsequent action or inaction. 1.2.4 External Attacks T.
Page 720 1.3 Organization Security Policies Red Hat Certificate System Administrator’s Guide • September 2005...
Page 721: Data Formats
Appendix F Certificate Download Specification This appendix describes the data formats used by Netscape Communicator 4.x for installing certificates. It also describes how certificates are imported into different environments. This appendix contains the following sections: • “Data Formats,” on page 721 •...
Page 722: Text Formats
ContentInfo field should be (see “Object Identifiers,” on contentType redhat-cert-sequence page 724), while the content field has the following structure: CertificateSequence ::= SEQUENCE OF Certificate This format allows multiple certificates to be downloaded at once. See “Importing Certificate Chains,” on page 722 for more information about handling multiple certificates.
Page 723: Appendix F Certificate Download Specification
Subsequent certificates are all treated the same. If the certificates contain the SSL-CA bit in the redhat-cert-type certificate extension and do not already exist in the local certificate database, they are added as untrusted CAs. In this way they can be used for certificate chain validation as long as there is a trusted CA somewhere along the chain.
Page 724: Importing Certificates Into Red Hat Servers
CA certificates. Object Identifiers The base of all Red Hat object IDs is redhat OBJECT IDENTIFIER ::= { 2 16 840 1 113730 } The hexadecimal byte value of this OID, when DER-encoded, is 0x60, 0x86, 0x48, 0x01, 0x86, 0xf8, 0x42...
Page 725: Introduction To Certificate Extensions
Appendix G Certificate and CRL Extensions This appendix explains both the standard certificate extensions defined by X.509 v3 and the extensions defined by Red Hat that were used in versions of products released before X.509 v3 was finalized. It also provides recommendations for extensions to use with specific kinds of certificates, including both PKIX Part 1 recommendations and Red Hat extensions that must be supported for compatibility with early versions of Red Hat products.
Page 726 Introduction to Certificate Extensions Trust— The X.500 specification establishes trust by means of a strict directory hierarchy. • By contrast, Internet and extranet deployments frequently involve distributed trust models that do not conform to the hierarchical X.500 approach. • Certificate use—Some organizations may wish to restrict the use of certificates for policy reasons.
Page 727: Structure Of Certificate Extensions
Introduction to Certificate Extensions Before the X.509 v3 standard was finalized, Netscape and other companies had to address some of the most pressing issues listed above with their own extension definitions. For example, applications (Netscape Navigator 3.0 or higher, and Enterprise Server 2.01 or higher) support an extension known as Certificate Type Extension that specifies Netscape...
Page 728: Sample Certificate Extensions
Introduction to Certificate Extensions The value, which can be either true or false, assigned to this field indicates whether the extension is critical or noncritical to the certificate. If the extension is critical and the certificate is sent to an application that does not ❍...
Page 729 Introduction to Certificate Extensions Not Before: Friday, February 21, 2003 12:00:00 AM PST America/Los_Angeles After: Monday, February 21, 2005 12:00:00 AM PST America/Los_Angeles Subject: CN=Certificate Manager,OU=netscape,O=aol,L=MV,ST=CA,C=US Subject Public Key Info: Algorithm: RSA - 1.2.840.113549.1.1.1 Public Key: Exponent: 65537 Public Key Modulus: (1024 bits) : E4:71:2A:CE:E4:24:DC:C4:AB:DF:A3:2E:80:42:0B:D9: CF:90:BE:88:4A:5C:C5:B3:73:BF:49:4D:77:31:8A:88: 15:A7:56:5F:E4:93:68:83:00:BB:4F:C0:47:03:67:F1:...
Page 730: Standard X.509 V3 Certificate Extensions
Standard X.509 v3 Certificate Extensions 3B:46:83:85:27:BC:F5:9D:8E:63:E3:BE:79:EF:AF:79: 9C:37:85:84 Identifier: Key Usage: - 2.5.29.15 Critical: yes Key Usage: Digital Signature Key CertSign Crl Sign Signature: Algorithm: SHA1withRSA - 1.2.840.113549.1.1.5 Signature: AA:96:65:3D:10:FA:C7:0B:74:38:2D:93:54:32:C0:5B: 2F:18:93:E9:7C:32:E6:A4:4F:4E:38:93:61:83:3A:6A: A2:11:91:C2:D2:A3:48:07:6C:07:54:A8:B8:42:0E:B4: E4:AE:42:B4:B5:36:24:46:4F:83:61:64:13:69:03:DF: 41:88:0B:CB:39:57:8C:6B:9F:52:7E:26:F9:24:5E:E7: BC:FB:FD:93:13:AF:24:3A:8F:DB:E3:DC:C9:F9:1F:67: A8:BD:0B:95:84:9D:EB:FC:02:95:A0:49:2C:05:D4:B0: 35:EA:A6:80:30:20:FF:B1:85:C8:4B:74:D9:DC:BB:50 Standard X.509 v3 Certificate Extensions This section summarizes the extension types that are defined as part of the Internet X.509 Version 3 standard, as of September 1998, and indicates which types are recommended by the PKIX working group.
Page 731 Standard X.509 v3 Certificate Extensions CS (CS) version support is listed for each extension. “Supported” means that the indicated version of CS ships with built-in support for the extension via a policy plug-in. “Not supported” means that the indicated version of CS does not ship a policy plug-in for the extension (although the extension can be used if a custom plug-in is written).
Page 732 Standard X.509 v3 Certificate Extensions Discussion The Authority Key Identifier extension identifies the public key corresponding to the private key used to sign a certificate. This extension is useful when an issuer has multiple signing keys (for example, due to CA certificate renewal). The extension consists of either or both of the following: •...
Page 733 Standard X.509 v3 Certificate Extensions Discussion This extension is used during the certificate chain verification process to identify CA certificates and to apply certificate chain path length constraints. The component should be set to true for all CA certificates. PKIX recommends that this extension should not appear in end-entity certificates.
Page 734 Standard X.509 v3 Certificate Extensions Criticality PKIX recommends that this extension be marked noncritical and that it be supported for all certificates. Discussion This extension defines how CRL information for this certificate is to be obtained. It should be used if the system is configured to use CRL issuing points. If the extension contains a of type URI, the URI is assumed to DistributionPointName...
Page 735 Standard X.509 v3 Certificate Extensions Table G-1 lists the uses defined by PKIX for this extension, and Table G-2 lists uses privately defined by Red Hat. Table G-1 PKIX Extended Key Usage Extension Uses Server authentication 1.3.6.1.5.5.7.3.1 Client authentication 1.3.6.1.5.5.7.3.2 Code signing 1.3.6.1.5.5.7.3.3 Email...
Page 736 Standard X.509 v3 Certificate Extensions Criticality PKIX Part 1 recommends that this extension be marked noncritical. Discussion The Issuer Alternative Name extension is used to associate Internet-style identities with the certificate issuer. Names must use the forms defined for subjectAltName. CS Version Support Supported since CS 4.2.
Page 737 Standard X.509 v3 Certificate Extensions • ) if the public key is to be used only for enciphering data. If this bit encipherOnly is set, should also be set. keyAgreement • ) if the public key is to be used only for deciphering data. If this bit decipherOnly is set, should also be set.
Page 738 Standard X.509 v3 Certificate Extensions Discussion This extension, which can used in CA certificates only, defines a name space within which all subject names in subsequent certificates in a certification path must be located. CS Version Support Supported since CS 4.2. Refer to “NameConstraintsExt” on page 519. OCSPNocheck 1.3.6.1.5.5.7.48.4 Criticality...
Page 739 Standard X.509 v3 Certificate Extensions Discussion This extension, which is for CA certificates only, constrains path validation in two ways. It can be used to prohibit policy mapping or to require that each certificate in a path contain an acceptable policy identifier. PKIX requires that, if present, this extension must never consist of a null sequence.
Page 740 Standard X.509 v3 Certificate Extensions subjectAltName 2.5.29.17 Criticality If the certificate’s subject field is empty, this extension must be marked critical. Discussion The Subject Alternative Name extension includes one or more alternative (non-X.500) names for the identity bound by the CA to the certified public key. It may be used in addition to the certificate’s subject name or as a replacement for it.
Page 741: Introduction To Crl Extensions
Introduction to CRL Extensions subjectKeyIdentifier 2.5.29.14 Criticality This extension is always noncritical. Discussion The Subject Key Identifier extension identifies the public key certified by this certificate. This extension provides a way of distinguishing public keys if more than one is available for a given subject name, for example after the certificate has been renewed with a new key.
Page 742: Structure Of Crl Extensions
Introduction to CRL Extensions The standard also suggests that you can define your own extensions and include them in CRLs you issue. These extensions are called private, proprietary, or custom CRL extensions and they carry information unique to your organization or business. Keep in mind that applications may not able to validate CRLs that contain private, critical extensions, thus preventing the use of these CRLs in a general context.
Page 743: Sample Crl And Crl Entry Extensions
Introduction to CRL Extensions Sample CRL and CRL Entry Extensions The following is an example of the section of a CRL containing X.509 v2 extensions. (CS can display CRLs in human-readable format, as shown here.) As shown in the example, CRL extensions appear in sequence and only one instance of a particular extension may appear in a particular CRL;...
Page 744: Standard X.509 V3 Crl Extensions
Standard X.509 v3 CRL Extensions Standard X.509 v3 CRL Extensions In addition to certificate extensions, the X.509 v3 proposed standard defines extensions to CRLs, which provide methods for associating additional attributes with Internet CRLs. These are of two kinds: extensions to the CRL itself, and extensions to individual certificate entries in the CRL.
Page 745 Standard X.509 v3 CRL Extensions CRLNumber 2.5.29.20 Criticality This extension must not be critical. Discussion The CRL Number extension specifies a sequential number for each CRL issued by a CA. It allows users to easily determine when a particular CRL supersedes another CRL. PKIX requires that all CRLs have this extension.
Page 746: Crl Entry Extensions
Standard X.509 v3 CRL Extensions Discussion The freshest CRL extension identifies how delta CRL information is obtained. The FreshestCRL extension is placed in the full CRL to indicate where to find latest delta CRL. CS Version Support Supported since CS 6.1. Refer to “FreshestCRL” on page 585. issuerAltName 2.5.29.18 Discussion...
Page 747 Standard X.509 v3 CRL Extensions certificateIssuer 2.5.29.29 Discussion The Certificate Issuer extension identifies the certificate issuer associated with an entry in an indirect CRL. This extension is used only with indirect CRLs, which are not supported by CS. holdInstructionCode 2.5.29.23 Discussion The Hold Instruction Code extension indicates the action to be taken after encountering a certificate that has been placed on hold.
Page 748: Netscape-Defined Certificate Extensions
Netscape-Defined Certificate Extensions CS Version Support Supported since CS 4.2. Refer to “CRLReason” on page 584. Netscape-Defined Certificate Extensions Netscape defined certain certificate extensions for use with Navigator and Communicator. Some of the extensions that have been defined are now obsolete, and others can be superseded by the extensions defined in the X.509 proposed standard.
Page 749: Ca Certificates And Extension Interactions
The certificate is a CA certificate if the cA component is true. Path length processing is done as described above. Only redhat-cert-type The certificate is a CA if at least one of the CA bits is set: SSL CA (5), S/MIME CA (6), or object-signing CA (7). The certificates issued by this CA are limited to the particular applications specified.
Page 750 If one or more of the SSL CA (5), S/MIME CA (6), or object-signing CA (7) bits are set in the redhat-cert-type extension, then the CA will be limited to issuing certificates for the specified application areas; otherwise, the CA can issue certificates for any application.
Page 751: Appendix H Object Identifiers
Appendix H Object Identifiers Red Hat Certificate System (CS) comes with a set of extension-specific policy plug-in modules that enable you to add X.509 certificate extensions to the certificates the server issues. Some of the extensions contain fields for specifying object identifiers. This appendix explain what’s an object indentifier (OID) and the significance of registering it.
Page 752 Registration of Object Identifiers custom extension that points to a certificate practice statement (CPS) of your company. To implement this, you need to compose the policy statement you want to include in the extension, define an OID for the policy statement, and configure Certificate System with the OID so that it can add that to the certificate it issues.
Page 753: What Is A Distinguished Name
Appendix I Distinguished Names This appendix explains what a distinguished name is and how Red Hat Certificate System (CS) uses distinguished names to automatically update certificate information in your corporate LDAP directory. This appendix contains the following sections: • “What Is a Distinguished Name?,” on page 753 •...
Page 754: Distinguished Name Components
What Is a Distinguished Name? Distinguished Name Components A DN identifies an entry in an LDAP directory. Because directories are hierarchical, DNs identify the entry by its location as a path in a hierarchical tree (much as a path in a file system identifies a file).
Page 755 What Is a Distinguished Name? Table I-1 Definitions of standard DN components (Continued) Component Name Definition Locality Identifies the place where the entry resides. The locality can be a city, county, township, or other geographic region. For example: • L=Mountain View •...
Page 756: Dns In Certificate System
DNs in Certificate System Typically, an LDAP search consists of the following components: • The base DN—for example, , which initiates a subtree search O=example.com C=US through all entries below this entry in the directory (in other words, all entries with the suffix O=example.com C=US...
Page 757 DNs in Certificate System Table I-2 Allowed characters for value types (Continued) Attribute Value type Object identifier Directory String 2.5.4.8 STREET Directory String 2.5.4.9 TITLE Directory String 2.5.4.12 Directory String 0.9.2342.19200300.100.1.1 MAIL IA5String 0.9.2342.19200300.100.1.3 IA5String 1.2.840.113549.1.9.1 IA5String 0.9.2342.19200300.100.1.2. SERIALNUMBER (for CEP Printable String 2.5.4.5 support)
Page 758: Extending Attribute Support
DNs in Certificate System Table I-3 Explanation of character sets for DNs (Continued) Value type Character set allowed Directory String Any character in format as specified in Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names (see http://www.ietf.org/rfc/rfc2253.txt). Certificate System conforms to all of this standard, including support of using hex numbers to escape characters.
Page 759 • Value converter class converts a string to a ASN.1 value. • It must implement interface. redhat.security.x509.AVAValueConverter The string-to-value converter class can be one of these: • —converts a string to a Printable redhat.security.x509.PrintableConverter String value. The string must have only printable characters.
Page 760 DNs in Certificate System Save your changes and close the file. Next, add each new attribute or component (for example, MYATTR1 MYATTR2 ) to the enrollment form. For instructions, see “Adding Attributes to an MYATTR3 Enrollment Form” on page 760. Restart the Certificate Manager.
Page 761 DNs in Certificate System <td valign="TOP"> <input type="TEXT" name="OU" size="30" onchange="formulateDN(this.form, this.form.subject)"> </td> </tr> <tr> <td valign="TOP"> <div align="RIGHT"> <font face="PrimaSans BT, Verdana, Arial, Helvetica, sans-serif" size="-1">Domain component: </font> </div> </td> <td valign="TOP"> <input type="TEXT" name="DC" size="30" onchange="formulateDN(this.form, this.form.subject)"> </td> </tr>...
Page 762 DNs in Certificate System if (form.DC != null) { if (DC.value != '') { if (doubleQuotes(DC.value) == true) { alert('Double quotes are not allowed in DC field'); DC.value = ''; DC.focus(); return; if (distinguishedName.value != '') distinguishedName.value += ', '; distinguishedName.value += 'DC=' + escapeDNComponent(DC.value);...
Page 763: Role Of Distinguished Names In Certificates
DNs in Certificate System Add the encoding order to the configuration file. For example, if you want to specify two encoding values, PrintableString , and the encoding order is first and UniversalString PrintableString next, you would add the following line at the end of the UniversalString configuration file: X500Name.directoryStringEncodingOrder=PrintableString,...
Page 764 DNs in Certificate System For example: CN=Jane Doe, OU=Human Resources, O=Example Corporation, C=US • The server that owns the certified key pair (for SSL server certificates)—to form this type of DN, use the component to specify the server’s fully qualified host name in the form <machine_name>.<your_domain>.<domain>...
Page 765 DNs in Certificate System configuration variable supports escaped commas and multiple attribute dnpattern variable assertions (AVAs) in a RDN. Below is the syntax for the DN pattern followed by examples. Syntax dnPattern := rdnPattern *[ "," rdnPattern ] rdnPattern := avaPattern *[ "+" avaPattern ] avaPattern := name "="...
Page 766 DNs in Certificate System the first ‘ ’ LDAP attribute value in user’s entry. mail the (first) ‘ ’ LDAP attribute value in the user’s entry. the second ‘ ’ value in the user’s entry DN; note the multiple AVAs in a RDN in this example.
Page 767: Internet Security Issues
Appendix J Introduction to Public-Key Cryptography Public-key cryptography and related standards and techniques underlie security features of many Red Hat products, including signed and encrypted email, form signing, object signing, single sign-on, and the Secure Sockets Layer (SSL) protocol. This document introduces the basic concepts of public-key cryptography.
Page 768 Internet Security Issues • Tampering. Information in transit is changed or replaced and then sent on to the recipient. For example, someone could alter an order for goods or change a person's resume. • Impersonation. Information passes to a person who poses as the intended recipient. Impersonation can take two forms: •...
Page 769: Encryption And Decryption
Encryption and Decryption Encryption and Decryption Encryption is the process of transforming information so it is unintelligible to anyone but the intended recipient. Decryption is the process of transforming encrypted information so that it is intelligible again. A cryptographic algorithm, also called a cipher, is a mathematical function used for encryption or decryption.
Page 770: Symmetric-Key Encryption
Encryption and Decryption Symmetric-Key Encryption With symmetric-key encryption, the encryption key can be calculated from the decryption key and vice versa. With most symmetric algorithms, the same key is used for both encryption and decryption, as shown in Figure J-1. Figure J-1 Symmetric-Key Encryption Implementations of symmetric-key encryption can be highly efficient, so that users do not...
Page 771: Public-Key Encryption
Encryption and Decryption Public-Key Encryption The most commonly used implementations of public-key encryption are based on algorithms patented by RSA Data Security. Therefore, this section describes the RSA approach to public-key encryption. Public-key encryption (also called asymmetric encryption) involves a pair of keys—a public key and a private key—associated with an entity that needs to authenticate its identity electronically or to sign or encrypt data.
Page 772: Key Length And Encryption Strength
Digital Signatures Key Length and Encryption Strength In general, the strength of encryption is related to the difficulty of discovering the key, which in turn depends on both the cipher used and the length of the key. For example, the difficulty of discovering the key for the RSA cipher most commonly used for public-key encryption depends on the difficulty of factoring large numbers, a well-known mathematical problem.
Page 773 Digital Signatures Tamper detection and related authentication techniques rely on a mathematical function called a one-way hash (also called a message digest). A one-way hash is a number of fixed length with the following characteristics: • The value of the hash is unique for the hashed data. Any change in the data, even deleting or altering a single character, results in a different value.
Page 774: Certificates And Authentication
Certificates and Authentication the new hash against the original hash. If the two hashes match, the data has not changed since it was signed. If they don’t match, the data may have been tampered with since it was signed, or the signature may have been created with a private key that doesn’t correspond to the public key presented by the signer.
Page 775: Authentication Confirms An Identity
Certificates and Authentication To get a driver’s license, you typically apply to a government agency, such as the Department of Motor Vehicles, which verifies your identity, your ability to drive, your address, and other information before issuing the license. To get a student ID, you apply to a school or college, which performs different checks (such as whether you have paid your tuition) before issuing the ID.
Page 776 Certificates and Authentication Network interactions typically take place between a client, such as browser software running on a personal computer, and a server, such as the software and hardware used to host a Web site. Client authentication refers to the confident identification of a client by a server (that is, identification of the person assumed to be using the client software).
Page 777 Certificates and Authentication Figure J-4 Using a Password to Authenticate a Client to a Server These are the steps shown in Figure J-4: In response to an authentication request from the server, the client displays a dialog box requesting the user’s name and password for that server. The user must supply a name and password separately for each new server the user wishes to use during a work session.
Page 778 Certificates and Authentication Certificate-Based Authentication Figure J-5 shows how client authentication works using certificates and the SSL protocol. To authenticate a user to a server, a client digitally signs a randomly generated piece of data and sends both the certificate and the signed data across the network. For the purposes of this discussion, the digital signature associated with some data can be thought of as evidence provided by the client to the server.
Page 779 Certificates and Authentication NOTE Neither password-based authentication nor certificate-based authentication address security issues related to physical access to individual machines or passwords. Public-key cryptography can only verify that a private key used to sign some data corresponds to the public key in a certificate. It is the user’s responsibility to protect a machine’s physical security and to keep the private-key password secret.
Page 780: How Certificates Are Used
Certificates and Authentication As you can see by comparing Figure J-5 to Figure J-4, certificates replace the authentication portion of the interaction between the client and the server. Instead of requiring a user to send passwords across the network throughout the day, single sign-on requires the user to enter the private-key database password just once, without sending it across the network.
Page 781 Certificates and Authentication Example: Internet sites that engage in electronic commerce (commonly known as e-commerce) usually support certificate-based server authentication, at a minimum, to establish an encrypted SSL session and to assure customers that they are dealing with a web site identified with a particular company. The encrypted SSL session ensures that personal information sent over the network, such as credit card numbers, cannot easily be intercepted.
Page 782 Certificates and Authentication SSL Protocol The Secure Sockets Layer (SSL) protocol is a set of rules governing server authentication, client authentication, and encrypted communication between servers and clients. SSL is widely used on the Internet, especially for interactions that involve exchanging confidential information such as credit card numbers.
Page 783 Certificates and Authentication S/MIME also makes it possible to encrypt email messages. This is also important for some business users. However, using encryption for email requires careful planning. If the recipient of encrypted email messages loses his or her private key and does not have access to a backup copy of the key, for example, the encrypted messages can never be decrypted.
Page 784 Certificates and Authentication Both client SSL certificates and S/MIME certificates can play a significant role in a comprehensive single sign-on solution. For example, one form of single sign-on supported by Red Hat products relies on SSL client authentication (see “Certificate-Based Authentication,”...
Page 785 Certificates and Authentication Distinguished Names An X.509 v3 certificate binds a distinguished name (DN) to a public key. A DN is a series of name-value pairs, such as , that uniquely identify an entity—that is, the uid=doe certificate subject. For example, this might be a typical DN for an employee of Red Hat, Inc.: uid=doe,e=doe@example.net,cn=John Doe,o=Red Hat, Inc.,c=US The abbreviations before each equal sign in this example have these meanings: •...
Page 786 Certificates and Authentication • The DN of the certificate subject (for example, in a client SSL certificate this would be the user’s DN), also called the subject name. • Optional certificate extensions, which may provide additional data used by the client or server.
Page 787 Certificates and Authentication Here are the data and signature sections of a certificate in human-readable format: Certificate: Data: Version: v3 (0x2) Serial Number: 3 (0x3) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Issuer: OU=Ace Certificate Authority, O=Ace Industry, C=US Validity: Not Before: Fri Oct 17 18:36:25 1997 After: Sun Oct 17 18:36:25 1999...
Page 788: How Ca Certificates Are Used To Establish Trust
Certificates and Authentication Here is the same certificate displayed in the 64-byte-encoded form interpreted by software: -----BEGIN CERTIFICATE----- MIICKzCCAZSgAwIBAgIBAzANBgkqhkiG9w0BAQQFADA3MQswCQYDVQQGEwJVUzER MA8GA1UEChMITmV0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncyBDQTAeFw05NzEw MTgwMTM2MjVaFw05OTEwMTgwMTM2MjVaMEgxCzAJBgNVBAYTAlVTMREwDwYDVQQK EwhOZXRzY2FwZTENMAsGA1UECxMEUHViczEXMBUGA1UEAxMOU3Vwcml5YSBTaGV0 dHkwgZ8wDQYJKoZIhvcNAQEFBQADgY0AMIGJAoGBAMr6eZiPGfjX3uRJgEjmKiqG 7SdATYazBcABu1AVyd7chRkiQ31FbXFOGD3wNktbf6hRo6EAmM5/R1AskzZ8AW7L iQZBcrXpc0k4du+2Q6xJu2MPm/8WKuMOnTuvzpo+SGXelmHVChEqooCwfdiZywyZ NMmrJgaoMa2MS6pUkfQVAgMBAAGjNjA0MBEGCWCGSAGG+EIBAQQEAwIAgDAfBgNV HSMEGDAWgBTy8gZZkBhHUfWJM1oxeuZc+zYmyTANBgkqhkiG9w0BAQQFAAOBgQBt I6/z07Z635DfzX4XbAFpjlRl/AYwQzTSYx8GfcNAqCqCwaSDKvsuj/vwbf91o3j3 UkdGYpcd2cYRCgKi4MwqdWyLtpuHAH18hHZ5uvi00mJYw8W2wUOsY0RC/a/IDy84 hW3WWehBUqVK5SY4/zJ4oTjx7dwNMdGwbWfpRqjd1A== -----END CERTIFICATE----- How CA Certificates Are Used to Establish Trust Certificate authorities (CAs) are entities that validate identities and issue certificates.
Page 789 Certificates and Authentication CA Hierarchies In large organizations, it may be appropriate to delegate the responsibility for issuing certificates to several different certificate authorities. For example, the number of certificates required may be too large for a single CA to maintain; different organizational units may have different policy requirements;...
Page 790 Certificates and Authentication Certificate Chains CA hierarchies are reflected in certificate chains. A certificate chain is series of certificates issued by successive CAs. Figure J-7 shows a certificate chain leading from a certificate that identifies some entity through two subordinate CA certificates to the CA certificate for the root CA (based on the CA hierarchy shown in Figure J-6).
Page 791 Certificates and Authentication In Figure J-7, the Engineering CA certificate contains the DN of the CA (that is, USA CA), that issued that certificate. USA CA’s DN is also the subject name of the next certificate in the chain. • Each certificate is signed with the private key of its issuer.
Page 792 Certificates and Authentication Figure J-8 Verifying a Certificate Chain All the Way to the Root CA Figure J-8 shows what happens when only Root CA is included in the verifier’s local database. If a certificate for one of the intermediate CAs shown in Figure J-8, such as Engineering CA, is found in the verifier’s local database, verification stops with that certificate, as shown in Figure J-9.
Page 793 Certificates and Authentication Figure J-9 Verifying a Certificate Chain to an Intermediate CA Expired validity dates, an invalid signature, or the absence of a certificate for the issuing CA at any point in the certificate chain causes authentication to fail. For example, Figure J-10 shows how verification fails if neither the Root CA certificate nor any of the intermediate CA certificates are included in the verifier’s local database.
Page 794: Managing Certificates
Managing Certificates Figure J-10 A Certificate Chain That Can’t Be Verified For general information about the way digital signatures work, see “Digital Signatures,” which begins on page 772.” For a more detailed description of the signature verification process in the context of SSL client and server authentication, see Appendix K, “Introduction to SSL.”...
Page 795: Issuing Certificates
Managing Certificates • Certificates and the LDAP Directory • Key Management • Renewing and Revoking Certificates • Registration Authorities Issuing Certificates The process for issuing a certificate depends on the certificate authority that issues it and the purpose for which it will be used. The process for issuing nondigital forms of identification varies in similar ways.
Page 796: Certificates And The Ldap Directory
Managing Certificates Certificates and the LDAP Directory The Lightweight Directory Access Protocol (LDAP) for accessing directory services supports great flexibility in the management of certificates within an organization. System administrators can store much of the information required to manage certificates in an LDAP-compliant directory.
Page 797: Renewing And Revoking Certificates
Managing Certificates Renewing and Revoking Certificates Like a driver’s license, a certificate specifies a period of time during which it is valid. Attempts to use a certificate for authentication before or after its validity period will fail. Therefore, mechanisms for managing certificate renewal are essential for any certificate management strategy.
Page 798 Managing Certificates An RA acts as a front end to a CA by receiving end entity requests, authenticating them, and forwarding them to the CA. After receiving a response from the CA, the RA notifies the end entity of the results. RAs can be helpful in scaling an PKI across different departments, geographical areas, or other operational units with varying policies and authentication requirements.
Page 799: The Ssl Protocol
Appendix K Introduction to SSL This document introduces the Secure Sockets Layer (SSL) protocol. SSL has been universally accepted on the World Wide Web for authenticated and encrypted communication between clients and servers. • The SSL Protocol • Ciphers Used with SSL •...
Page 800 The SSL Protocol Figure K-1 Where SSL Runs The SSL protocol runs above TCP/IP and below higher-level protocols such as HTTP or IMAP. It uses TCP/IP on behalf of the higher-level protocols, and in the process allows an SSL-enabled server to authenticate itself to an SSL-enabled client, allows the client to authenticate itself to the server, and allows both machines to establish an encrypted connection.
Page 801 Ciphers Used with SSL The SSL protocol includes two sub-protocols: the SSL record protocol and the SSL handshake protocol. The SSL record protocol defines the format used to transmit data. The SSL handshake protocol involves using the SSL record protocol to exchange a series of messages between an SSL-enabled server and an SSL-enabled client when they first establish an SSL connection.
Page 802 Ciphers Used with SSL Some organizations may want to disable the weaker ciphers to prevent SSL connections with weaker encryption. However, due to U.S. government restrictions on products that support anything stronger than 40-bit encryption, disabling support for all 40-bit ciphers effectively restricts access to network browsers that are available only in the United States (unless the server involved has a special Global Server ID that permits the international client to “step up”...
Page 803 Ciphers Used with SSL Table K-1 Cipher Suites Supported by the SSL Protocol That Use the RSA Key-Exchange Algorithm Strength Category and Cipher Suites Recommended Use Strongest Cipher Suite Triple DES With 168-Bit Encryption and SHA-1 Message Authentication Permitted for deployments within Triple DES is the strongest cipher supported by SSL, but it is not as fast as the United States only.
Page 804 Ciphers Used with SSL Table K-1 Cipher Suites Supported by the SSL Protocol That Use the RSA Key-Exchange Algorithm Strength Category and Cipher Suites Recommended Use Exportable Cipher Suites RC4 With 40-Bit Encryption and MD5 Message Authentication These cipher suites are not as RC4 40-bit encryption permits approximately 1.1 * 10 (a trillion) possible strong as those listed above, but...
Page 805 The SSL Handshake Red Hat Table K-2 Cipher Suites Supported by When Using Fortezza for SSL 3.0 Strength Category and Cipher Suites Recommended Use Strong Fortezza Cipher Suites RC4 With 128-bit Encryption and SHA-1 Message Authentication Permitted for deployments within Like RC4 with 128-bit encryption and MD5 message authentication, this the United States only.
Page 806 The SSL Handshake authenticate itself to the client using public-key techniques, then allows the client and the server to cooperate in the creation of symmetric keys used for rapid encryption, decryption, and tamper detection during the session that follows. Optionally, the handshake also allows the client to authenticate itself to the server.
Page 807 The SSL Handshake The client sends a message to the server informing it that future messages from the client will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the client portion of the handshake is finished. The server sends a message to the client informing it that future messages from the server will be encrypted with the session key.
Page 808 The SSL Handshake To authenticate the binding between a public key and the server identified by the certificate that contains the public key, an SSL-enabled client must receive a “yes” answer to the four questions shown in Figure K-2. Although the fourth question is not technically part of the SSL protocol, it is the client’s responsibility to support this requirement, which provides some assurance of the server’s identity and thus helps protect against a form of security attack known as “man in the middle.”...
Page 809 The SSL Handshake Is the issuing CA a trusted CA? Each SSL-enabled client maintains a list of trusted CA certificates, represented by the shaded area on the right side of Figure K-3. This list determines which server certificates the client will accept. If the distinguished name (DN) of the issuing CA matches the DN of a CA on the client’s list of trusted CAs, the answer to this question is yes, and the client goes on to Step 3.
Page 810: Man-In-The-Middle Attack
The SSL Handshake Man-in-the-Middle Attack As suggested in Step 4 above, the client application must check the server domain name specified in the server certificate against the actual domain name of the server with which the client is attempting to communicate. This step is necessary to protect against a man-in-the-middle attack, which works as follows.
Page 811 The SSL Handshake Figure K-3 Authentication and Verification of a Client Certificate An SSL-enabled server goes through these steps to authenticate a user’s identity: Does the user’s public key validate the user’s digital signature? The server checks that the user’s digital signature can be validated with the public key in the certificate. If so, the server has established that the public key asserted to belong to John Doe matches the private key used to create the signature and that the data has not been tampered with since it was signed.
Page 812 The SSL Handshake Is today’s date within the validity period? The server checks the certificate’s validity period. If the current date and time are outside of that range, the authentication process won’t go any further. If the current date and time are within the certificate’s validity period, the server goes on to Step 3.
Page 813 Glossary access control The process of controlling who is allowed to do what. For example, access control to servers is typically based on an identity, established by a password or a certificate, and on rules regarding what that entity can do. See also access control list (ACL).
Page 814 attribute value assertion (AVA) An assertion of the form attribute = value, where attribute consists of a tag, such as o (organization) or (user ID), and value consists of a value, such as “Red Hat, Inc.” or a login name. AVAs are used to form the distinguished name (DN) that identifies the subject of a certificate (called the subject name of the certificate).
Page 815 CA hierarchy A hierarchy of CAs in which a root CA delegates the authority to issue certificates to subordinate CAs. Subordinate CAs can also expand the hierarchy by delegating issuing status to other CAs. See also certificate authority (CA), subordinate CA, root CA.
Page 816 Certificate Enrollment Protocol (CEP) A certificate management protocol jointly developed by Cisco Systems and VeriSign, Inc. CEP is an early implementation of Certificate Management Messages over Cryptographic Message Syntax (CMC). CEP specifies how a device communicates with a CA, including how to retrieve the CA’s public key, how to enroll a device with the CA, and how to retrieve a CRL.
Page 817 Certificate Manager agent A user who belongs to a group authorized to manage agent services for a Certificate Manager. These services include the ability to access and modify (approve and reject) certificate requests and issue certificates. certificate profile A set of configuration settings that defines a certain type of enrollment.
Page 818 CS subsystem One of the four CS Managers: Certificate Manager, Registration Manager, Online Certificate Status Manager, or Data Recovery Manager. CS console A console that can be opened for any single CS instance from within Red Hat Console. A CS console allows the CS administrator to control configuration settings for the corresponding CS instance.
Page 819 Data Recovery Manager An optional, independent CS subsystem that manages the long-term archival and recovery of RSA encryption keys for end entities. A Certificate Manager or Registration Manager can be configured to archive end entities’ encryption keys with a Data Recovery Manager before issuing new certificates. The Data Recovery Manager is useful only if end entities are encrypting data (such as sensitive email) that the organization may need to recover someday.
Page 820 digital signature To create a digital signature, the signing software first creates a one-way hash from the data to be signed (such as a newly issued certificate). The one-way hash is then encrypted with the private key of the signer. The resulting digital signature is unique for each piece of data signed.
Page 821 end entity In a public-key infrastructure (PKI), a person, router, server, or other entity that uses a certificate to identify itself. extensions field See certificate extensions. Federal Bridge Certificate Authority (FBCA) A configuration where two CAs form a circle of trust by issuing cross-pair certificates to each other, and storing the two cross-pair certificates as a certificate pair.
Page 822 Java Development Kit (JDK) Software development kit provided by Sun Microsystems for developing applications and applets using the Java programming language. Java Native Interface (JNI) A standard programming interface that provides binary compatibility across different implementations of the Java Virtual Machine (JVM) on a given platform, allowing existing code written in a language such as C or C++ for a single platform to bind to Java.
Page 823 message digest See one-way hash. misrepresentation The presentation of an entity as a person or organization that it is not. For example, a web site might pretend to be a furniture store when it is really just a site that takes credit-card payments but never sends any goods.
Page 824 PKCS #10 The public-key cryptography standard that governs certificate requests. PKCS #11 The public-key cryptography standard that governs cryptographic tokens such as smart cards. PKCS #11 module A driver for a cryptographic device that provides cryptographic services, such as encryption and decryption, via the PKCS #11 interface. A PKCS #11 module (also called a cryptographic module or cryptographic service provider) can be implemented in either hardware or software.
Page 825 public-key infrastructure (PKI) The standards and services that facilitate the use of public-key cryptography and X.509 v3 certificates in a networked environment. RC2, RC4 Cryptographic algorithms developed for RSA Data Security by Rivest. See also cryptographic algorithm. Red Hat Certificate System (CS) A highly configurable set of software components and tools for creating, deploying, and managing certificates.
Page 826 Secure Sockets Layer (SSL) A protocol that allows mutual authentication between a client and server and the establishment of an authenticated and encrypted connection. SSL runs above TCP/IP and below HTTP, LDAP, IMAP, NNTP, and other high-level network protocols. self tests A feature that allows you to set up tests of a CS instance both when the instance starts up and on-demand.
Page 827 , or a computer can identify itself as a site jdoe@example.com called when it is not. Spoofing is one form of impersonation. See also www.redhat.com misrepresentation, impersonation. SSL See Secure Sockets Layer (SSL). subject The entity identified by a certificate. In particular, the subject field of a certificate contains a subject name that uniquely describes the certified entity.
Page 828 token A hardware or software device that is associated with a slot in a PKCS #11 module. It provides cryptographic services and optionally stores certificates and keys. tree hierarchy The hierarchical structure of an LDAP directory. trust Confident reliance on a person or other entity. In a public-key infrastructure (PKI), trust refers to the relationship between the user of a certificate and the certificate authority (CA) that issued the certificate.
Page 829 Index tools provided CMS console 239 accelerators 309 Netscape Console 237 active logs Agent Services interface default file location 255 URL for 277 message categories 258 AgentDirEnrollment instance 389 See also logging agents adding authorizing remote key recovery 195 agents deleting 333 automated process 320 enrolling users in person 390, 572...
Page 830 managing from CMS window 121, 375, 379, 383, 386, changing trust settings of 286 deleting 285 password-based 776–777 getting a new one 289, 303 See also client authentication nickname 80 See also server authentication renewing 289 viewing details of 286 authentication modules agent initiated user enrollment 390, 572 CEP 63...
Page 831 OCSP signing certificate 80 revocation reasons 575 SSL server certificate 81 revoking 797 wTLS CA signing certificate 80 S/MIME 781 manual updates to publishing directory 636 self-signed 789 master CA 54 serial numbers Registration Manager and 50–51 what to do when a CA exhausts all 110 serial number range 110 verifying a certificate chain 791 specifying IP address for 280...
Page 832 where it’s stored 281 cRLDistributionPoints 733 CMS instance CRLNumber 745 changing the name 241 CRLs viewing information 240 Certificate Manager support for 34 installation date 241 defined 574 on/off/unknown status 241 extensions for 744–?? security level 241 extension-specific modules 741 version number 241 issuing or distribution points 577 CMS window...
Page 833 setting up conventions followed 26 key archival 218 downloading certificates 721–724 key recovery 224 DSA 82, 132, 165, 206 specifying IP address for 280 defining custom OIDs 751 deleting authentication modules 407 certificates from the token precaution 286 email resolver 545 log modules 268 email, signed and encrypted 782 mapper modules 638...
Page 834 deltaCRLIndicator 745 extKeyUsage 734 getting new certificates for subsystems 303 holdInstructionCode 747 groups introduction to 726 changing members 332 invalidityDate 747 issuerAltName 735, 746 issuingDistributionPoint 746 keyUsage 736 nameConstraints 737 netscape-cert-type 748 Netscape-defined 748–750 hardware accelerators 309 policyConstraints 738 hardware tokens policyMappings 739 See external tokens privateKeyUsagePeriod 739...
Page 835 what is it used for 281 interface for agents 194 when installed 281 local vs. remote 194 internal tokens 306 key recovery agents passwords 193 invalidityDate 747 significance 193 IP address 280 when specified the first time 193 issuerAltName 735, 746 responsibilities 193 issuing certificates role defined 193...
Page 836 how they’re represented 258 nickname significance of choosing the right level 259 for CA signing certificate 80 what it means 258 for CRL signing certificate 312 managing from CMS console 265 for OCSP signing certificate 81 services that are logged 257 for signing certificate 130, 162 types of logs 255 for SSL server certificate 81, 130, 162, 204...
Page 837 using for authentication 776 JavaScript 474 result of processing 464 password cache 245 when used 464 password-based authentication, defined 776–777 what can you use it for 462 password-quality checker 244 policy modules PIN Generator tool deleting 542 delivering PINs to users 379 registering new ones 541 PKCS #10 64 policy rules...
Page 838 management 796 configuring to use separate SSL server certificates 310 publisher modules key pairs and certificates deleting 638 getting new ones 303 registering new ones 638 remote admin server certificate 203 publishers signing certificate 130 created during installation 605, 607, 608, 609 SSL server certificate 130 publishers that can publish to specifying IP address for 280...
Page 839 self-signed certificate 789 subjectDirectoryAttributes 740 server certificate renewal 393 subjectKeyIdentifier 741 server instance subordinate CA 31 finding out details 240 support for DN characters in CMS 756 server status off 241 on 241 unknown 241 setting CRL extensions 582, 583 setting up Tasks tab 239 key archival 218...
Page 840 unbuffered logging 259 uninstalling Certificate Management System 76 version number 241 viewing CMS instance information 240 VPN clients getting certificates for 395 when the server was installed 241 why should you revoke certificates 575 wireless CA certificate 86, 91 wireless certificates 86, 91 wizard See Certificate Setup Wizard writing policies in JavaScript 474...

This manual is also suitable for:

Certificate system 7.1 - adminsistrator

Red Hat CERTIFICATE SYSTEM 7.1 - ADMINISTRATOR Administrator's Manual

About this Guide

Chapter 1 Overview

Chapter 2 Installation

Chapter 3 Certificate Manager

Chapter 4 Registration Manager

Chapter 5 OCSP Responder

Chapter 6 Data Recovery Manager

Chapter 7 Token Management System

Chapter 8 Administrative Basics

Chapter 9 Authorization

Quick Links

Related Manuals for Red Hat CERTIFICATE SYSTEM 7.1 - ADMINISTRATOR

Summary of Contents for Red Hat CERTIFICATE SYSTEM 7.1 - ADMINISTRATOR