1. Manuals
  2. Brands
  3. Red Hat Manuals
  4. Software
  5. CERTIFICATE SYSTEM 8 - DEPLOYMENT
  6. Install manual

Red Hat CERTIFICATE SYSTEM 8 Install Manual

Hide thumbs Also See for CERTIFICATE SYSTEM 8:
Table of Contents

Advertisement

Quick Links

Download this manual See also: Manual
Red Hat Certificate
System 8
Install Guide
Ella Deon Lackey
Publication date: July 22, 2009, updated on March 25, 2010

Advertisement

Table of Contents
loading

Related Manuals for Red Hat CERTIFICATE SYSTEM 8

Summary of Contents for Red Hat CERTIFICATE SYSTEM 8

  • Page 1 Red Hat Certificate System 8 Install Guide Ella Deon Lackey Publication date: July 22, 2009, updated on March 25, 2010...
  • Page 2 Install Guide Red Hat Certificate System 8 Install Guide Author Ella Deon Lackey Copyright © 2009 Red Hat, Inc. Copyright © 2009 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA").

  • Page 3: Table Of Contents

    About This Guide 1. Examples and Formatting ....................vii 1.1. Formatting for Examples and Commands ............. vii 1.2. Tool Locations ....................vii 1.3. Guide Formatting ....................vii 2. Additional Reading ......................viii 3. Giving Feedback ......................ix 4. Document History ......................x 1.
  • Page 4 Install Guide 4. Additional Installation Options 4.1. Requesting Subsystem Certificates from an External CA ..........61 4.2. Installing a CA with ECC Enabled ................64 4.2.1. Loading a Third-Party ECC Module ..............64 4.2.2. Loading the Certicom ECC Module ..............65 4.3.
  • Page 5 9.5.7. Shared Certificate System Subsystem File Locations ........119 Index...

  • Page 7: About This Guide

    About This Guide This guide explains how to install and configure Red Hat Certificate System subsystems, as well as covering some basic administrative tasks and advanced installation techniques. This guide also lists the supported platforms and dependencies for Red Hat Certificate System; for other information, see the Release Notes.

  • Page 8: Additional Reading

    About This Guide Formatting Style Italicized text Bolded text Other formatting styles draw attention to important text. NOTE A note provides additional information that can help illustrate the behavior of the system or provide more detail for a specific issue. IMPORTANT Important information is necessary, but possibly unexpected, such as a configuration change that will not persist after a reboot.

  • Page 9: Giving Feedback

    If there is any error in this Installation Guide or there is any way to improve the documentation, please let us know. Bugs can be filed against the documentation for Red Hat Certificate System through Bugzilla, http://bugzilla.redhat.com/bugzilla. Make the bug report as specific as possible, so we can be more effective in correcting any issues: •...

  • Page 10: Document History

    About This Guide 4. Document History Revision March 25, 2010 Ella Deon Lackey dlackey@redhat.com 8.0.10 Adding information on new end-entities client authentication port for the CA, related to the MitM resolution in Errata RHBA-2010:0169. Revision 8.0.9 February 18, 2009 Ella Deon Lackey dlackey@redhat.com...

  • Page 11: Overview Of Certificate System Subsystems

    Chapter 1. Overview of Certificate System Subsystems Red Hat Certificate System is a highly configurable set of components which create and manage certificates and keys at every point of the certificate lifecycle. Certificate System is based on open standards so that it effectively creates a scalable, customizable, and robust public-key infrastructure (PKI).
  • Page 12 Chapter 1. Overview of Certificate System Subsystems The core of the Certificate System is the Certificate Manager. This is the only required subsystem and handles the actual certificate management tasks. The other subsystems can be added for additional functionality (the DRM) or to move the load for some common operations off of the CA, such as using an OCSP for status requests and an RA to process certificate requests.

  • Page 13: Certificate Manager

    Certificate Manager 7. Revoking the certificate (CA) 8. Checking whether the certificate is revoked or active when an entity tries to use the certificate for authentication (OCSP) All of the subsystems (CA, RA, DRM, and OCSP, as well as the token subsystems) are organized together in security domains.

  • Page 14: Online Certificate Status Manager

    Chapter 1. Overview of Certificate System Subsystems NOTE The DRM only archives encryption keys, not signing keys, because that compromises the non-repudiation properties of signing keys. Non-repudiation means that a user cannot deny having performed some action, such as sending an encrypted email, because they are the only possessor of that key.

  • Page 15: Token Processing System

    Token Processing System 1.2.1. Token Processing System The Token Processing System (TPS) is the conduit between the user-centered Enterprise Security Client, which interacts with the tokens, and the Certificate System backend subsystems, such as the Certificate Manager. The TPS is required in order to manage smart cards. The TPS communicates with the CA and DRM for processing token operations.

  • Page 16: Planning The Installation

    Chapter 1. Overview of Certificate System Subsystems 1.3. Planning the Installation Before beginning to install and configure the Certificate System subsystems, determine what the organization of the PKI is. What types of subsystems do you need to install? This depends on the kind of functionality you need and the load you expect to have. There (Section 1.1, “Subsystems are several different kinds of subsystems for managing certificates for Managing...
  • Page 17 Planning the Installation A Certificate Manager can be configured as either a root CA or a subordinate CA. The difference between a root CA and a subordinate CA is who signs the CA signing certificate. A root CA signs its own certificate. A subordinate CA has another CA (either internal or external) sign its certificate.

  • Page 19: Prerequisites Before Installing Certificate System

    Chapter 2. Prerequisites Before Installing Certificate System Before installing the Red Hat Certificate System subsystems, check out the requirements and dependencies for the specific platform, as well as looking at the installed packages. 2.1. Supported Platforms, Hardware, and Programs 2.1.1. Supported Platforms The Certificate System subsystems (CA, RA, DRM, OCSP, TKS, and TPS) are supported on the following platforms: •...

  • Page 20: Supported Smart Cards

    Chapter 2. Prerequisites Before Installing Certificate System Platform Agent Services End User Pages Internet Explorer 6 and higher Mac OS 10.x Agent services are not Firefox 2.x supported for Mac Table 2.1. Supported Web Browsers by Platform 2.1.3. Supported Smart Cards The Enterprise Security Client supports Global Platform 2.01-compliant smart cards and JavaCard 2.1 or higher.

  • Page 21: Required Programs, Dependencies, And Configuration

    ----------------------------------------------- /usr/lib/jvm/jre-1.4.2-gcj/bin/java /usr/lib/jvm/jre-1.6.0-openjdk/bin/java *+ 3 /usr/lib/jvm/jre-1.6.0-sun.x86_64/bin/java http://kbase.redhat.com/faq/FAQ_54_4667.shtm for more information on using the JDK for Red Hat Certificate System. 2.2.2. Apache Apache 2.x must be installed in order to install the TPS subsystem. Check that the appropriate version of Apache is installed.

  • Page 22: Red Hat Directory Server

    Enterprise Linux 5.3 32-bit, Red Hat Enterprise Linux 5.3 64-bit, or Solaris 9 Sparc 64-bit, regardless of the system on which Red Hat Certificate System is installed. Check that the Red Hat Directory Server is already installed. For example: yum info redhat-ds Installed Packages Name...

  • Page 23: Firewall Configuration And Iptables

    • SELinux policies must be set for any nCipher netHSM 2000 modules, as described in Section 2.5.2.4, “Setting up SELinux on nCiper netHSM 2000”. 2.3. Packages Installed on Red Hat Enterprise Linux Multiple packages are installed with the Certificate System, in addition to the core Certificate System components. http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Deployment_Guide/s1-fireall-ipt-act.html...
  • Page 24 Chapter 2. Prerequisites Before Installing Certificate System RPMs for Certificate System Subsystems and Components osutil pki-kra pki-tks pki-setup pki-tps pki-ca pki-migrate pki-common pki-native-tools symkey pki-console pki-ocsp pki-java-tools RPMs for Tomcat Web Services jakarta-commons-discovery jakarta-oro avalon-framework jakarta-commons-el regexp avalon-logkit jakarta-commons-fileupload tomcat5 axis jakarta-commons-httpclient tomcat5-common...

  • Page 25: Required Information For Subsystem Configuration

    Required Information for Subsystem Configuration RPMs for NSS and NSPR nspr svrcore 2.4. Required Information for Subsystem Configuration When the Certificate System subsystems are configured, some outside information must be available, Table 2.2, “Required Information for Configuring Subsystems”. as listed in Information Description Login PIN...

  • Page 26: Setting Up Tokens For Storing Certificate System Subsystem Keys And Certificates

    Chapter 2. Prerequisites Before Installing Certificate System Information Description default Directory Manager DN is cn=Directory Manager. Certificate and key recovery files (for cloning) If the subsystem being configured is a clone of another subsystem, then the backup files for the master subsystem must be locally accessible.

  • Page 27: Using Hardware Security Modules With Subsystems

    Using Hardware Security Modules with Subsystems Before using external tokens, plan how the external token is going to be used with the subsystem: • All system keys for a subsystem must be generated on the same token. • The subsystem keys must be installed in an empty HSM slot. If the HSM slot has previously been used to store other keys, then use the HSM vendor's utilities to delete the contents of the slot.
  • Page 28 Chapter 2. Prerequisites Before Installing Certificate System preop.configModules.module1.userFriendlyName=nCipher's nFast Token Hardware Module preop.configModules.module2.commonName=lunasa preop.configModules.module2.imagePath=../img/safenet.png preop.configModules.module2.userFriendlyName=SafeNet's LunaSA Token Hardware Module #selected token preop.module.token=Internal Key Storage Token In addition, the following parameter is set in the password.conf for the HSM password: hardware-nethsm=caPassword 2.5.2.2.
  • Page 29 Using Hardware Security Modules with Subsystems service subsystem_name start 2. Open the /etc/Chrystoki.conf configuration file. 3. Add this configuration parameter. Misc { NetscapeCustomize=1023; } 4. If they are there, remove these two configuration lines for the applet version. AppIdMajor=2; AppIdMinor=4; Then, after going through the subsystem configuration, but before restarting the server when completing the configuration wizard, edit the subsystem configuration to recognize the token: 1.
  • Page 30 Chapter 2. Prerequisites Before Installing Certificate System cd /var/lib/pki-ca/alias b. The required security module database file, secmod.db, should be created by default when the subsystem is created. If it does not exist, use the modutil utility to create secmod.db. modutil -dbdir . -nocertdb -create c.

  • Page 31: Viewing Tokens

    Viewing Tokens 2.5.3. Viewing Tokens To view a list of the tokens currently installed for a Certificate System instance, use the modutil utility. 1. Open the instance alias directory. For example: cd /var/lib/pki-ca/alias 2. Show the information about the installed PKCS #11 modules installed as well as information on the corresponding tokens using the modutil tool.

  • Page 33: Installation And Configuration

    Chapter 3. Installation and Configuration The Certificate System is comprised of subsystems which can be independently installed on different servers, multiple instances installed on a single server, and other flexible configurations for availability, scalability, and failover support. The procedures for downloading, installing, and configuring instances of Certificate System subsystems are described in this chapter.
  • Page 34 Chapter 3. Installation and Configuration Section 3.5, “Configuring a DRM, OCSP, or TKS” Section 3.4, “Configuring an RA” for the process on installing and configuring the OCSP, DRM, TKS, and RA subsystems. 6. Configure the TPS subsystem. The TPS requires having an existing TKS and DRM available when it is configured, so this is the last subsystem to set up.

  • Page 35: Installing The Certificate System Packages

    Installing the Certificate System Packages 3.2. Installing the Certificate System Packages There are two ways to obtain and install the subsystem packages. For all supported platforms, the Certificate System packages can be downloaded as ISO images through the appropriate Red Hat Network channel.
  • Page 36 Chapter 3. Installation and Configuration NOTE yum is used only for the first subsystem instance; any additional subsystem instances are added using pkicreate. subsystem can be any of the Certificate System subsystems: • ca for the Certificate Manager. • ra for the Registration Authority. •...

  • Page 37: Installing From An Iso Image

    Installing from an ISO Image 3.2.2. Installing from an ISO Image Red Hat Certificate System 8.0 can also be downloaded from Red Hat Network as an ISO image. This ISO image contains an RPMS/ directory which can be used as a local yum repository. 1.
  • Page 38 Chapter 3. Installation and Configuration The default CA instance must create a new security domain. Subsequent CAs can create a new domain or join an existing security domain, but it is recommended that each CA have its own security domain. 4.
  • Page 39 Configuring a CA 5. Set up the PKI hierarchy. Commonly, the first CA is a root, or self-signed, CA, meaning that it signs its own CA signing certificate rather than submitting its certificates to a third-party CA for issuance. Subsequent CAs can be subordinate CAs to that root. There are many other options, depending on the PKI environment.
  • Page 40 Chapter 3. Installation and Configuration • Subordinate CA. A subordinate CA receives its CA signing certificate from a root CA. The root CA must be referenced here; it can be another Certificate System CA, but, for the default (i.e., first) CA instance, this will probably be an external root CA. The certificate requests generated in this process must be submitted to the external CA and be approved before configuration can be completed.
  • Page 41 Configuring a CA If the Red Hat Directory Server instances is on a different server or network than the Certificate System subsystem, then make sure that the Certificate System host's firewall allows access to whatever LDAP port was set in the previous configuration panel.
  • Page 42 Chapter 3. Installation and Configuration • LunaSA: /usr/lunasa/lib/libCryptoki2.so • nCipher: /opt/nfast/toolkits/pkcs11/libcknfast.so 8. Set the key size and the hashing algorithm to use. By default, the settings for the signing key are applied to the keys for every certificate for the CA. To set different key types, sizes, or hashing algorithms for each certificate, click the [Advanced] link to expand the form so each key pair is listed.
  • Page 43 Configuring a CA The hashing algorithms that are available depend on whether RSA or ECC is selected as the key type. For RSA, the available algorithms are as follows: • SHA256withRSA (the default) • SHA1withRSA • SHA256withRSA • SHA512withRSA • MD5withRSA •...
  • Page 44 Chapter 3. Installation and Configuration Having unique certificate nicknames is vital for using an HSM, since any nickname conflicts (even for subsystems on different servers) will cause configuration to fail. 10. The next panels generate and show certificate requests, certificates, and key pairs. If an external CA is used to issue the certificates, configuration cannot go forward until they are received from the external CA.
  • Page 45 Configuring a CA 12. Provide the information for the new subsystem administrator. 13. Click Next through the remaining panels to import the agent certificate into the browser and complete the configuration. 14. When the configuration is complete, restart the subsystem.

  • Page 46: Configuring An Ra

    Chapter 3. Installation and Configuration service pki-ca restart IMPORTANT The new instance is not active until it is restarted, and weird behaviors can occur if you try to use the instance without restarting it first. 3.4. Configuring an RA Subsystem configuration is done by accessing a unique web-based configuration page for the instance.
  • Page 47 Configuring an RA The hostname for the security domain CA can be the fully-qualified domain name or an IPv4 or IPv6 address, if IPv6 was configured before the packages were installed. 4. Enter a name for the new instance.
  • Page 48 Chapter 3. Installation and Configuration 5. Select the CA which will issue, renew, and revoke certificates for certificates processed through the RA. All of the CAs configured in the security domain are listed in a dropdown menu. 6. Click Next on the Internal Database panel; the SQLite database is created automatically. NOTE The RA uses a SQLite database to store its configuration and user data rather than an LDAP database, as the other subsystems do.
  • Page 49 Configuring an RA The Certificate System automatically discovers Safenet's LunaSA and nCipher's netHSM hardware security modules. The discovery process assumes that the client software installations for these modules are local to the Certificate System subsystem and are in the following locations: •...
  • Page 50 Chapter 3. Installation and Configuration 9. Optionally, change the subject names for the certificates.
  • Page 51 Configuring an RA NOTE Certificate nicknames must be unique, and changing the default nicknames is one way to ensure that. Having unique certificate nicknames is vital for using an HSM, since any nickname conflicts (even for subsystems on different servers) will cause configuration to fail. 10.
  • Page 52 Chapter 3. Installation and Configuration If an external CA is used to issue the certificates, configuration cannot go forward until they are received from the CA. When they are issued, paste the certificates into this panel to add them to the subsystem database, and then proceed with the installation. Click Apply to view the certificates as they are imported.

  • Page 53: Configuring A Drm, Ocsp, Or Tks

    Configuring a DRM, OCSP, or TKS 12. Click Next through the remaining panels to import the agent certificate into the browser and complete the configuration. 13. When the configuration is complete, restart the subsystem. service pki-ra restart IMPORTANT The new instance is not active until it is restarted, and weird behaviors can occur if you try to use the instance without restarting it first.
  • Page 54 Chapter 3. Installation and Configuration NOTE A Data Recovery Manager (DRM) is also known as a Key Recovery Agent (KRA). All command-line tools and many files for the DRM use the abbreviation kra for this reason. In the documentation, the subsystem used to archive and recover keys is called the DRM or KRA interchangeably.
  • Page 55 Configuring a DRM, OCSP, or TKS 5. Select the CA which will perform the operations processed through the subsystem, such as key archival. 6. Fill in the information for the LDAP server which will be used for the instance's internal database. This requires connection information for the Directory Server instance, such as the hostname, port number, bind DN (username), and password.
  • Page 56 Chapter 3. Installation and Configuration The hostname can be the fully-qualified domain name or an IPv4 or IPv6 address. NOTE One thing that can derail subsystem configuration or function is having services that are unable to connect with each other. If servers that need to communicate with each other are on different servers or networks, when the firewalls and iptables must be configured to give the required access.
  • Page 57 Configuring a DRM, OCSP, or TKS IMPORTANT Any hardware tokens used with the instance must be configured before configuring the subsystem instance. If the HSM is not properly configured, it may not be listed in the key stores panel or the instance may not function properly. HSM configuration is Section 2.5.2, “Using Hardware Security Modules with Subsystems”.
  • Page 58 Chapter 3. Installation and Configuration 9. Optionally, change subject names to the listed certificates. NOTE Certificate nicknames must be unique, and changing the default nicknames is one way to ensure that.
  • Page 59 Configuring a DRM, OCSP, or TKS Having unique certificate nicknames is vital for using an HSM, since any nickname conflicts (even for subsystems on different servers) will cause configuration to fail. 10. The next panels generate and show certificate requests, certificates, and key pairs. If an external CA is used to issue the certificates, configuration cannot go forward until they are received from the CA.

  • Page 60: Configuring A Tps

    Chapter 3. Installation and Configuration 12. Click Next through the remaining panels to import the agent certificate into the browser and complete the configuration. 13. When the configuration is complete, restart the subsystem. service pki-kra restart IMPORTANT The new instance is not active until it is restarted, and weird behaviors can occur if you try to use the instance without restarting it first.
  • Page 61 Configuring a TPS Once the packages are installed, then the installer automatically launches the pkicreate script to create the default subsystem instance automatically. A URL to access the new instance is printed to the screen which gives the subsystem instances hostname, port, and a login PIN to access the configuration wizard.
  • Page 62 Chapter 3. Installation and Configuration 5. Select the CA which will issue, renew, and revoke certificates for token operations requested through the TPS subsystem. 6. Supply information about the TKS which will manage the TPS keys. Select the TKS from the drop- down menu of TKS subsystems within the security domain.
  • Page 63 Configuring a TPS 7. There is an option for server-side key generation for tokens enrolled through the TPS. If server- side key generation is selected, supply information about the DRM which will generate keys and archive encryption keys. Key and certificate recovery is initiated automatically through the TPS, which is a DRM agent.
  • Page 64 Chapter 3. Installation and Configuration The hostname of the LDAP server can be the fully-qualified domain name or an IPv4 or IPv6 address. 9. Fill in the information for the LDAP server which will be used for the instance's internal database. This requires connection information for the Directory Server instance, such as the hostname, port number, bind DN (username), and password.
  • Page 65 Configuring a TPS The hostname can be the fully-qualified domain name or an IPv4 or IPv6 address. NOTE One thing that can derail subsystem configuration or function is having services that are unable to connect with each other. If servers that need to communicate with each other are on different servers or networks, when the firewalls and iptables must be configured to give the required access.
  • Page 66 Chapter 3. Installation and Configuration IMPORTANT Any hardware tokens used with the instance must be configured before configuring the subsystem instance. If the HSM is not properly configured, it may not be listed in the key stores panel or the instance may not function properly. HSM configuration is Section 2.5.2, “Using Hardware Security Modules with Subsystems”.
  • Page 67 Configuring a TPS 12. Optionally, change subject names to the listed certificates. NOTE Certificate nicknames must be unique, and changing the default nicknames is one way to ensure that. Having unique certificate nicknames is vital for using an HSM, since any nickname conflicts (even for subsystems on different servers) will cause configuration to fail.
  • Page 68 Chapter 3. Installation and Configuration 13. The next panels generate and show certificate requests, certificates, and key pairs. If an external CA is used to issue the certificates, configuration cannot go forward until they are received from the CA. When they are issued, paste the certificates into this panel to add them to the TPS database, and then proceed with the installation.
  • Page 69 Configuring a TPS 15. Click Next through the remaining panels to import the agent certificate into the browser and complete the configuration. 16. When the configuration is complete, restart the subsystem. service pki-tps restart IMPORTANT The new instance is not active until it is restarted, and weird behaviors can occur if you try to use the instance without restarting it first.

  • Page 71: Additional Installation Options

    Chapter 4. Additional Installation Options The Certificate System default installation, and all subsequent instances created with pkicreate, make certain assumptions about the instances being installed, such as the default signing algorithm to use for CA signing certificates and whether to allow IPv6 addresses for hosts. This chapter describes additional configuration options that impact the installation and configuration for new instances, so many of these procedures occur before the instance is created.
  • Page 72 Chapter 4. Additional Installation Options 8. In the Requests and Certificates panel, the CA signing certificate is listed, with an action required label. Once that certificate is generated, the other certificates for the CA will be automatically generated. For other subsystems, each subsystem certificate has an action required label and must be submitted to the external CA.
  • Page 73 Requesting Subsystem Certificates from an External CA 9. Click the Step 1: Copy the certificate request link, and copy the certificate request to a file or the clipboard. 10. Submit the request to the external CA. Leave the browser with the configuration wizard open as you wait for the certificates to be generated, so that it is easier to pick up the process.

  • Page 74: Installing A Ca With Ecc Enabled

    Chapter 4. Additional Installation Options service subsystem_name restart 4.2. Installing a CA with ECC Enabled Elliptic curve cryptography (ECC) is much more secure than the more common RSA-style encryption, which allows it to use much shorter key lengths and makes it faster to generate certificates. CAs which are ECC-enabled can issue both RSA and ECC certificates, using their ECC signing certificate.

  • Page 75: Loading The Certicom Ecc Module

    ECC module can be loaded. 13. Load the ECC module into the console security databases. cd ~/.redhat-idm-console/ modutil -dbdir . -nocertdb -add THIRD_PARTY_MODULE -libfile /usr/lib/libYourNewModule.so Now, logging into the console succeeds.
  • Page 76 Chapter 4. Additional Installation Options 1. Copy the third-party libraries to a common directory, like /usr/lib for 32-bit systems or /usr/ lib64 for 64-bit systems. There are two library files for the Certicom ECC modules, libsbcpgse.so and libsbgse2.so. 2. Cache the recent shared libraries. ldconfig 3.
  • Page 77 Loading the Certicom ECC Module CryptoAes() success CryptoArc4() success CryptoDes() success CryptoDh() success CryptoDsa() success CryptoEcdh() success CryptoEcdsa() success CryptoEcmqv() success CryptoPkcs1Enc() success CryptoPkcs1Sig() success CryptoRsaEnc() success CryptoRsaSig() success CryptoSha1() success Token() samples starting Slot info for Slot 0 Desc: FIPS Generic Crypto Services V1.0.1d manufacturerID: Certicom Corp.
  • Page 78 This fails, because the console is not yet configure to run in ECC. However, this does create the security databases for the console, so the ECC module can be loaded. Load the ECC module into the console security databases. cd ~/.redhat-idm-console/ modutil -dbdir . -nocertdb -add certicom -libfile /usr/lib/libsbcpgse.so Now, logging into the console succeeds.

  • Page 79: Changing The Hashing Algorithm Used For Subsystem Keys

    Changing the Hashing Algorithm Used for Subsystem Keys chown -R agent-pki:agent-pki /home/agent-pki h. In the terminal with the /home/agent-pki directory open, export the environment variable that allows ECC support. export NSS_USE_DECODED_CKA_EC_POINT=1 Open Firefox again. The Certicom module should be available and you should be able to log into it successfully.

  • Page 80: Enabling Ipv6 For A Subsystem

    Chapter 4. Additional Installation Options Editing certificate profiles is covered in the Administrator's Guide. Each of the subsystem certificate profiles can be edited: • caInternalAuthOCSPCert.cfg • caInternalAuthTransportCert.cfg • caInternalAuthAuditSigningCert.cfg • caInternalAuthServerCert.cfg • caInternalAuthDRMstorageCert.cfg • caInternalAuthSubsystemCert.cfg The hashing algorithms that are available depend on whether RSA or ECC is selected as the key type. For RSA, the available algorithms are as follows: •...

  • Page 81: Configuring Separate Ra Instances

    Configuring Separate RA Instances op=var_set name=ca_host value=IPv6 address If a host has both an IPv4 address and an IPv6 name, then an environment variable can be set before the Certificate System packages are installed so that Certificate System setup scripts will recognize the IPv6 name.
  • Page 82 Chapter 4. Additional Installation Options e. Click OK. 3. Add the new RA authentication instance to the CA: a. Open the CA configuration directory, and edit the CS.cfg file cd /etc/pki-ca vi CS.cfg b. Search for the string raCertAuth. c. Copy those lines for the first RA instance, paste them, and edit them for the second RA instance's information.
  • Page 83 Configuring Separate RA Instances profile.caDualRA2userCert.config=/var/lib/pki-ca/profiles/ca/caDualRA2userCert.cfg 6. Add a new URI mapping to allow the new RA agent to be registered in the new RA group. a. Open the CA web applications directory, and edit the web.xml file: cd /var/lib/pki-ca/webapps/ca/WEB-INF vi web.xml b.
  • Page 84 Chapter 4. Additional Installation Options cd /var/lib/pki-ra2/conf/ vi CS.cfg 10. Change the registerRaUser setting to registerRa2User. conn.ca1.servlet.addagent=/ca/admin/ca/registerRa2User 11. Change the caDualRAuserCert setting to caDualRA2userCert. request.renewal.approve_request.0.profileId=caDualRAuser2Cert request.user.approve_request.0.profileId=caDualRA2userCert 12. Restart the new RA instance. For example: # service pki-ra2 restart 13. A URL was generated at the end of the pkicreate command; go to that URL to configure the second RA.

  • Page 85: Creating Additional Subsystem Instances

    Chapter 5. Creating Additional Subsystem Instances The number of subsystems that you have is flexible. There can be a single instance, there can be multiple instances on the same machine, or there can be multiple instances on multiple servers. Creating additional subsystem instances is similar to installing and configuring the default instances; there is a script to run to create a basic installation and then an HTML-based configuration wizard to complete the setup for the instance.
  • Page 86 Chapter 5. Creating Additional Subsystem Instances To get full usage examples and syntax for the pkicreate command, run pkicreate -- help. Parameter Description pki_instance_root Gives the full path to the new instance configuration directory. subsystem_type Gives the type of subsystem being created. pki_instance_name Gives the name of the new instance.

  • Page 87: Running Pkicreate For A Single Ssl Port

    Running pkicreate for a Single SSL Port Parameter Description recommended that administrators set this value to make sure there are no conflicts with SELinux labels for other services. tomcat_server_port Sets the port number for the Tomcat web server for OCSP, TKS, and DRM instances. redirect_conf Sets the location for the configuration files for the new instance.

  • Page 88: Running Pkicreate With Port Separation

    Chapter 5. Creating Additional Subsystem Instances 5.3. Running pkicreate with Port Separation To create an instance with three separate ports for the different subsystem services, run pkicreate with three options which specify the services ports: -admin_secure_port, -agent_secure_port, and -ee_secure_port. For CAs only, there is an additional port for end-entity client authentication, - ee_secure_client_auth_port.

  • Page 89: Cloning Subsystems

    Chapter 6. Cloning Subsystems When a new subsystem instance is first configured, the Red Hat Certificate System allows subsystems to be cloned, or duplicated, for high availability of the Certificate System. The cloned instances run on different machines to avoid a single point of failure and their databases are synchronized through replication.

  • Page 90: Cloning For Cas

    Chapter 6. Cloning Subsystems Figure 6.1. Cloning Example The load balancer in front of a Certificate System subsystem is what provides the actual failover support in a high availability system. A load balancer can also provide the following advantages as part of a Certificate System subsystem: •...

  • Page 91: Cloning For Drms

    Cloning for DRMs Cloned CAs do have limits on what operations they can perform. Most important, cloned CAs cannot generate or publish CRLs. Any CRL requests submitted to a cloned CA are immediately redirected to the master CA. Anything related to generating or caching CRLs is disabled in the CS.cfg file for the clone.

  • Page 92: Cloning Considerations

    Chapter 6. Cloning Subsystems • If the token is network-based, then the keys and certificates simply need to be available to the token; the keys and certificates do not need to be copied. • When using a network-based hardware token, make sure the high-availability feature is enabled on the hardware token to avoid single point of failure.
  • Page 93 Cloning a CA 4. Copy the exported PKCS#12 file containing the master instance's keys to the clone's alias/ directory. The keys for the master instance could have been exported to a .p12 file when the instance was configured. Alternatively, the keys can be exported using the PKCS12Export command, as in Section 6.2, “Exporting Keys from a Software Database”.
  • Page 94 Chapter 6. Cloning Subsystems NOTE When cloning a CA, the master and clone instances have the same CA signing key. 10. The subsystem information is automatically supplied from the master instance to the clone instance once the keys are successfully restored. Complete the configuration process. NOTE By default, the instance configuration wizard uses localhost as the location for the internal LDAP database for a new instance.

  • Page 95: Cloning Ocsp Subsystems

    Cloning OCSP Subsystems ca.crl.IssuingPointId.enableCRLUpdates=false • Enable the clone to redirect CRL requests to the master clone: master.ca.agent.host=master_hostname master.ca.agent.port=master_port 12. Restart the clone instance. service subsystem_name restart After configuring the clone, test to make sure that the master-clone relationship is functioning: 1.
  • Page 96 Chapter 6. Cloning Subsystems The keys for the master instance could have been exported to a .p12 file when the instance was configured. Alternatively, the keys can be exported using the PKCS12Export command, as in Section 6.2, “Exporting Keys from a Software Database”.
  • Page 97 Cloning OCSP Subsystems 10. The subsystem information is automatically supplied from the master instance to the clone instance once the keys are successfully restored. Complete the configuration process. NOTE By default, the instance configuration wizard uses localhost as the location for the internal LDAP database for a new instance.

  • Page 98: Cloning Drm And Tks Subsystems

    Chapter 6. Cloning Subsystems 6.5. Cloning DRM and TKS Subsystems Section 3.5, “Configuring a DRM, OCSP, or 1. Configure the master subsystem, as described in TKS”, and back up the keys. 2. Create the clone subsystem instance. IMPORTANT Do not go through the setup wizard for the instance yet. 3.
  • Page 99 Cloning DRM and TKS Subsystems 8. Give the path and filename of the PKCS #12 backup file which was saved when the master instance was created or that were exported in 3. If the keys are stored on an HSM that is accessible to the clone, then they are picked up automatically.

  • Page 100: Converting Masters And Clones

    Chapter 6. Cloning Subsystems 9. The subsystem information is automatically supplied from the master instance to the clone instance once the keys are successfully restored. Complete the configuration process. NOTE By default, the instance configuration wizard uses localhost as the location for the internal LDAP database for a new instance.
  • Page 101 Converting CA Clones and Masters ca.certStatusUpdateInterval=0 • Disable monitoring database replication changes: ca.listenToCloneModifications=false • Disable maintenance of the CRL cache: ca.crl.IssuingPointId.enableCRLCache=false • Disable CRL generation: ca.crl.IssuingPointId.enableCRLUpdates=false • Set the CA to redirect CRL requests to the new master: master.ca.agent.host=new_master_hostname master.ca.agent.port=new_master_port 4.

  • Page 102: Converting Ocsp Clones

    Chapter 6. Cloning Subsystems ca.crl.IssuingPointId.enableCRLUpdates=true g. Disable the redirect settings for CRL generation requests: master.ca.agent.host=hostname master.ca.agent.port=port number 7. Start the new master CA server. service subsystem_name start 6.6.2. Converting OCSP Clones 1. Stop the OCSP master, if it is still running. 2.
  • Page 103 Updating CA Clones To update any clone CAs with new DRM configuration in the master CA: 1. Stop the clone CA. service subsystem_name stop Always stop a subsystem instance before editing its configuration files. 2. Copy all of the ca.connecter.KRA.* parameters for the new DRM connection in the CS.cfg for the master CA over to the clone CA CS.cfg file.

  • Page 105: Silent Configuration

    Chapter 7. Silent Configuration The Certificate System includes a tool, pkisilent, which configures an instance in a single step. Normally, instances are configured by accessing the subsystem HTML page and going through the setup wizard. pkisilent can be used to pass all of the configuration parameters to a new instance simply from the command line.
  • Page 106 Chapter 7. Silent Configuration The Configuretype option sets what kind of subsystem is being configured. This can be any of the following: • ConfigureCA (for a root CA) or ConfigureSubCA (for a subordinate CA) • ConfigureRA • ConfigureDRM • ConfigureOCSP •...
  • Page 107 About pkisilent Parameter Description domain_name The name of the security domain to which the subsystem will be added. sd_hostname The hostname of the CA which hosts security domain. sd_admin_port The administrative SSL port of the CA which hosts security domain. sd_agent_port The agent SSL port of the CA which hosts security domain.
  • Page 108 Chapter 7. Silent Configuration Parameter Description backup_fname The file to which to export the the PKCS #12 backup file. ca_subsystem_cert_subject_name The subject names for the CA subsystem ca_ocsp_cert_subject_name certificates. ca_server_cert_subject_name ca_sign_cert_subject_name ca_audit_signing_cert_subject_name ra_subsystem_cert_subject_name The subject names and nicknames for the RA ra_server_cert_subject_name subsystem certificates.

  • Page 109: Silently Configuring Subsystem

    Silently Configuring Subsystem Parameter Description ldap_auth_host Gives the hostname of the LDAP directory database to use for the TPS subsystem token database. Only for the TPS subsystem. ldap_auth_port Gives the port number of the LDAP directory database to use for the TPS subsystem token database.
  • Page 110 Chapter 7. Silent Configuration It is recommended that every CA have its own security domain, because each system within the security domain depends on having the security domain running and accessible. However, subordinate CAs can only be configured within the root CA's security domain using the pkisilent script.
  • Page 111 Silently Configuring Subsystem pkisilent ConfigureCA -cs_hostname localhost -cs_port 9445 -subsystem_name "pki-ca2" - client_certdb_dir /tmp/ -client_certdb_pwd password -preop_pin sYY8er834FG9793fsef7et5 - sd_hostname "domain.example.com" -sd_admin_port 9445 -sd_agent_port 9443 -sd_ssl_port 9444 -sd_admin_name admin -sd_admin_password secret -admin_user admin -admin_email "admin@example.com" -admin_password secret -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject "cn=ca\ agent\ cert"...

  • Page 112: Cloning A Subsystem Silently

    Chapter 7. Silent Configuration 7.3. Cloning a Subsystem Silently IMPORTANT Only CA instances can be cloned using pkisilent. The other subsystem clones must be configured using the HTML-based configuration wizard. When creating a new subsystem, there are options to set the type of keys to generate and to back up the keys to a PKCS #12 file.
  • Page 113 Performing Silent Configuration Using an External CA To submit the subsystem certificate requests to an external CA, explicitly set the -external option to true. The generated certificate requests are exported to a file, and then can be submitted to the external CA. Once they are issued, files which contain the subsystem certificates and the CA certificate chain for the issuing external CA can be passed using the pkisilent command.

  • Page 115: Updating And Removing Subsystem Packages

    Chapter 8. Updating and Removing Subsystem Packages Certificate System is installed using individual packages for each of its subsystems and its supporting systems, like Red Hat Directory Server and NSS. This makes the Certificate System modular, and each individual subsystem and its packages can be installed, updated, and removed independently. 8.1.

  • Page 116: Uninstalling Certificate System Subsystems

    Chapter 8. Updating and Removing Subsystem Packages rpm -Uvh package_name For example: rpm -Uvh pki-java-tools-8.0.0-4.noarch.rpm 4. Restart the Certificate System instances. service instance_ID start 8.2. Uninstalling Certificate System Subsystems It is possible to remove individual subsystem instances or to uninstall all packages associated with an entire subsystem.

  • Page 117: Removing Certificate System Subsystem Packages

    Removing Certificate System Subsystem Packages 8.2.2. Removing Certificate System Subsystem Packages A number of subsystem-related packages and dependencies are installed with Red Hat Certificate Section 2.3, “Packages Installed on Red Hat Enterprise Linux”. Removing System; these are listed in a subsystem instance removes only the files and directories associated with that specific instance. It does not remove the actual installed packages are that used by that instance.

  • Page 119: Using Certificate System

    This can be changed by resetting the configuration in chkconfig to on. For example, this automatically restarts Red Hat Directory Server, Administration Server, and the CA: http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Deployment_Guide-en-US/s1-services-chkconfig.html...
  • Page 120 Chapter 9. Using Certificate System /sbin/chkconfig --level 2345 dirsrv-admin on /sbin/chkconfig --level 2345 dirsrv on /sbin/chkconfig --level 2345 pki-ca on Make sure the subsystem is listed with the other services. chkconfig --list | grep subsystem_name To remove the subsystem from the start list, simply turn the level to off: chkconfig --level 35 subsystem_name off Red Hat Enterprise Linux also has a GUI console that can manage chkconfig settings.

  • Page 121: Finding The Subsystem Web Services

    Finding the Subsystem Web Services Pages are started before any of the subsystem instances. Likewise, processes with a low number for their shutdown priority are shut down first, so the subsystem processes are stopped before the processes they depend on are stopped. Server Process Name Start Priority...
  • Page 122 Chapter 9. Using Certificate System NOTE Anyone can access the end user pages for a subsystem, but accessing agent or admin web services pages requires that an agent or administrator certificate be issued and installed in the web browser, or authentication to the web services fails. Port Used for SSL Used for Client...
  • Page 123 Finding the Subsystem Web Services Pages Port Used for SSL Used for Client Web Services Web Service Authentication Location Online Certificate Status Manager 11180 End Entities ocsp/ee/ocsp 11444 End Entities ocsp/ee/ocsp 11443 Agents ocsp/agent/ocsp 11445 Configuration ocsp/admin/ console/config/ login?pin=pin 11445 Services ocsp/services 11445...

  • Page 124: Default File And Directory Locations For Certificate System

    Chapter 9. Using Certificate System Port Used for SSL Used for Client Web Services Web Service Authentication Location 7889 Enterprise cgi-bin/sow/ Security Client welcome.cgi Security Officer Workstation 7889 Agents 7889 Admin tus? op=index_admin 7889 Operator tus? op=index_operator 7890 Configuration tps/admin/ console/config/ login?pin=pin 7890...

  • Page 125: Default Ca Instance Information

    Default CA Instance Information When the Certificate System is first installed, one instance for each subsystem type is also installed. The default information such as the port numbers, instance name, and configuration file location for each subsystem (after being installed and going through the setup process) is listed in the following sections.

  • Page 126: Default Ra Instance Information

    Chapter 9. Using Certificate System 9.5.2. Default RA Instance Information Table 9.4, “Default RA Instance Information”. Most of these The default RA configuration is listed in values are unique to the default instance; the default certificates and some other settings are true for every RA instance.

  • Page 127: Default Ocsp Instance Information

    Default OCSP Instance Information Setting Value Storage certificate SSL server certificate Audit log signing certificate Subsystem certificate Security Databases /var/lib/pki-kra/alias Log Files /var/log/pki-kra Install Logs /var/log/pki-kra-install.log Process File /var/run/pki-kra.pid Web Services Files /var/lib/pki-kra/webapps - Agent services /var/lib/pki-kra/webapps.admin - Admin services The subsystem certificate is always issued by the security domain so that domain-level operations that require client authentication are based on this subsystem certificate.

  • Page 128: Default Tks Instance Information

    Chapter 9. Using Certificate System Setting Value /var/lib/pki-ocsp/webapps.admin - Admin services The subsystem certificate is always issued by the security domain so that domain-level operations that require client authentication are based on this subsystem certificate. Table 9.6. Default OCSP Instance Information 9.5.5.
  • Page 129 Shared Certificate System Subsystem File Locations Setting Value Instance Name pki-tps Main Directory /var/lib/pki-tps Configuration Directory /etc/pki-tps Configuration File /etc/pki-tps/CS.cfg /etc/pki-tps/nss.conf /etc/pki-tps/password.conf Subsystem Certificates SSL server certificate Subsystem certificate Security Databases /var/lib/pki-tps/alias Log Files /var/log/pki-tps Install Logs /var/log/pki-tps-install.log Web Services Files /var/lib/pki-tps/docroot /var/lib/pki-tps/cgi-bin /var/lib/pki-tps/lib...
  • Page 130 Chapter 9. Using Certificate System Directory Location Contents pki/tps (TPS) /usr/bin Contains the pkicreate and pkiremove instance configuration scripts and tools (Java, native, and security) shared by the Certificate System subsystems. /var/lib/tomcat5/common/lib Contains Java archive files shared by local Tomcat web applications and shared by the Certificate System subsystems.
  • Page 131 Index Enterprise Security Client, 5 overview, 5 Token Key Service, 5 Token Processing System, 5 accelerators, 17 additional installation options tokens changing hashing algorithm for subsystem defined, 16, 16 keys, 69 external, 16, 16 internal, 16 viewing which tokens are installed, 21 certificate lifecycle, 2 Certificate System...

This manual is also suitable for:

System 8 - install guide 25-03-2010

Table of Contents