Red Hat NETWORK SATELLITE 5.1.0 - CHANNEL MANAGEMENT User manual

Red Hat Network Satellite
Client Configuration
Guide 5.1.0
5.1
ISBN: N/A
Publication date:

Red Hat Network Satellite

Red Hat Network Satellite: Client Configuration Guide 5.1.0
Copyright ©2008 Red Hat, Inc.
Copyright ©2008 Red Hat, Inc. This material may only be distributed subject to the terms and conditions set forth in the
Open Publication License, V1.0 or later with the restrictions noted below (the latest version of the OPL is presently
available at http://www.opencontent.org/openpub/).
Distribution of substantively modified versions of this document is prohibited without the explicit permission of the
copyright holder.
Distribution of the work or derivative of the work in any standard (paper) book form for commercial purposes is
prohibited unless prior permission is obtained from the copyright holder.
Red Hat and the Red Hat "Shadow Man" logo are registered trademarks of Red Hat, Inc. in the United States and other
countries.
All other trademarks referenced herein are the property of their respective owners.
The GPG fingerprint of the [email protected] key is:
CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E
1801 Varsity Drive
Raleigh, NC 27606-2072
USA
Phone: [phone]
Phone: [phone]
Fax: [phone]
PO Box 13588
Research Triangle Park, NC 27709
USA

Red Hat Network Satellite

1. Introduction ........................................................................................................... 1
2. Client Applications ................................................................................................. 3
1. Deploying the Latest Red Hat Network Client RPMs ......................................... 3
2. Configuring the Client Applications .................................................................. 4
2.1. Registering with Activation Keys ........................................................... 5
2.2. Using the --configure Option ............................................................. 6
2.3. Updating the Configuration Files Manually ............................................ 8
2.4. Implementing Server Failover ............................................................... 9
3. Configuring the Red Hat Network Alert Notification Tool with Satellite ..........10
3. SSL Infrastructure .................................................................................................11
1. A Brief Introduction To SSL ...........................................................................11
2. The RHN SSL Maintenance Tool .................................................................12
2.1. SSL Generation Explained ..................................................................13
2.2. RHN SSL Maintenance Tool Options .................................................14
2.3. Generating the Certificate Authority SSL Key Pair ................................18
2.4. Generating Web Server SSL Key Sets .................................................19
3. Deploying the CA SSL Public Certificate to Clients ..........................................20
4. Configuring Client Systems ............................................................................21
4. Importing Custom GPG Keys .................................................................................23
5. Using RHN Bootstrap ...........................................................................................25
1. Preparation ...................................................................................................25
2. Generation ...................................................................................................26
3. Script Use ....................................................................................................27
4. RHN Bootstrap Options ................................................................................27
6. Manually Scripting the Configuration ......................................................................31
7. Implementing Kickstart ..........................................................................................33
A. Sample Bootstrap Script ........................................................................................35
Index .......................................................................................................................39
v

vi

Introduction
This best practices guide is intended to help customers of RHN Satellite Server and RHN Proxy
Server configure their client systems more easily.
By default, all Red Hat Network client applications are configured to communicate with central
Red Hat Network Servers. When connecting clients to RHN Satellite Server or RHN Proxy
Server instead, many of these settings must be altered. Altering client settings for a system or
two may be relatively simple. A large enterprise environment, containing hundreds or thousands
of systems, will likely benefit from the mass reconfiguration steps described here.
Due to the complexity of this undertaking, customers may utilize a pre-populated script that
automates many of the tasks necessary to access their Satellite or Proxy server; refer to
Chapter 5, Using RHN Bootstrap for details. Red Hat believes that understanding the
implications of these changes is helpful and therefore describes the manual steps for
reconfiguration in the opening chapters. Use your best judgement in determining the ideal
solution for your organization.
Although many of the commands provided within this guide can be applied as they appear, it is
impossible to predict all potential network configurations adopted by customers. Therefore, Red
Hat encourages you to use these commands as references that must take into account your
organization's individual settings.
Note
Unix client configuration information may be found in the RHN Satellite Server
Reference Guide in the Unix Support chapter.
Chapter 1.
1

2

Client Applications
In order to utilize most enterprise-class features of Red Hat Network, such as registering with a
RHN Satellite, configuration of the latest client applications is required. Obtaining these
applications before the client has registered with Red Hat Network can be difficult. This paradox
is especially problematic for customers migrating large numbers of older systems to Red Hat
Network. This chapter identifies techniques to resolve this dilemma.
Important
Red Hat strongly recommends that clients connected to a RHN Proxy Server or
RHN Satellite Server be running the latest update of Red Hat Enterprise Linux to
ensure proper connectivity.
Additionally, if client firewalls are configured, ports 80 and 443 should be open
for proper functionality with Red Hat Network.
1. Deploying the Latest Red Hat Network Client RPMs
Red Hat Update Agent (up2date) and Red Hat Network Registration Client (rhn_register)
are prerequisites for using much of Red Hat Network's enterprise functionality. It is crucial to
install them on client systems before attempting to use RHN Proxy Server or RHN Satellite
Server in your environment.
There are several sensible approaches to accomplish this update of the RHN client software.
One of which involves storing the RPMs in a location that is accessible by all client systems and
deploying the packages with the simplest command possible. In nearly all cases, a manual
deployment of up2date and rhn_register (if RHEL 2.1) do not need to be performed. Those
client tools should have no issues connecting to your RHN Satellite or Proxy environment.
These discussion below assumes that the "out of box" up2date and rhn_register are not the
latest and do not work for your environment.
Remember, only systems running Red Hat Enterprise Linux 2.1 must use the Red Hat Network
Registration Client to register with RHN. Systems running Red Hat Enterprise Linux 3 and
later can use the registration functionality built into the Red Hat Update Agent.
This document presumes that the customer has installed at least one RHN Satellite Server
and/or RHN Proxy Server on their network. The example below demonstrates a simple
approach of deploying up2date and rhn_register for the first time by an administrator
assuming the machines don't already have a working RHN. The administrator has populated the
/var/www/html/pub/ directory with a copy of the up2date and rhn_register (for RHEL 2.1
systems) RPMs that his client systems need, and then has simply deployed those RPMs onto
his client systems with a simple rpm -Uvh command. Run from a client, this command installs
the RPMs to that client, assuming the domain name, paths, and RPM versions are correct:
Chapter 2.
3

rpm -Uvh \
http://your_proxy_or_sat.your_domain.com/pub/rhn_register-2.9.12-1.2.1AS.i386.rpm
\
http://your_proxy_or_sat.your_domain.com/pub/rhn_register-gnome-2.9.12-1.2.1AS.i386.rpm
\
http://your_proxy_or_sat.your_domain.com/pub/up2date-2.9.14-1.2.1AS.i386.rpm
\
http://your_proxy_or_sat.your_domain.com/pub/up2date-gnome-2.9.14-1.2.1AS.i386.rpm
Note the inclusion of the associated gnome RPMs. Keep in mind, the architecture (in this case,
i386) may need to be altered depending on the systems to be served.
2. Configuring the Client Applications
Not every customer must connect securely to a RHN Satellite Server or RHN Proxy Server
within their organization. Not every customer needs to build and deploy a GPG key for custom
packages. (Both of these topics are explained in detail later.) Every customer who uses RHN
Satellite Server or RHN Proxy Server must reconfigure the Red Hat Update Agent (up2date)
and possibly the Red Hat Network Registration Client (rhn_register) to redirect it from Red
Hat Network to their RHN Satellite Server or RHN Proxy Server.
Important
Although this is not configurable, note that the port used by the Red Hat Update
Agent is 443 for SSL (HTTPS) and 80 for non-SSL (HTTP). By default, up2date
uses SSL only. For this reason, users should ensure that their firewalls allow
connections over port 443. To bypass SSL, change the protocol for serverURL
from https to http in /etc/sysconfig/rhn/up2date. Similarly, to use RHN's
Monitoring feature and probes requiring the Red Hat Network Monitoring
Daemon, note that client systems must allow connections on port 4545 (or port
22, if using sshd instead).
By default, the Red Hat Network Registration Client and the Red Hat Update Agent refer to
the main Red Hat Network Servers. Users must reconfigure client systems to refer to their RHN
Satellite Server or RHN Proxy Server.
Note that the latest versions of the Red Hat Update Agent can be configured to accommodate
several RHN Servers, thereby providing failover protection in case the primary server is
inaccessible. Refer to Section 2.4, “Implementing Server Failover” for instructions on enabling
this feature.
The next sections describe three methods of configuring the client systems to access your RHN
Satellite Server or RHN Proxy Server: using an Activation Key, up2date --configure, and
manually updating the configuration files.( To see how virtually all reconfiguration can be
scripted, see Chapter 6, Manually Scripting the Configuration.)
Chapter 2. Client Applications
4

2.1. Registering with Activation Keys
Red Hat recommends using activation keys for registering and configuring client systems that
access RHN Proxy Server or RHN Satellite Server. Activation keys can be used to register,
entitle, and subscribe systems in a batch. Refer to the Activation Keys section of the Red Hat
Update Agent chapter within the RHN Management Reference Guide for instructions on use.
Registering with an activation key has four basic steps:
1. Generate an Activation Key as described in the Activation Keys section of the Red Hat
Update Agent chapter within the RHN Management Reference Guide
2. Import custom GPG keys.
3. Download and install the SSL Certificate RPM from the /pub/ directory of the RHN Proxy
Server or RHN Satellite Server. The command for this step could look something like this:
rpm -Uvh\
http://your-satellite.com/pub/rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm
4. Register the system with your RHN Proxy Server or RHN Satellite Server. The command for
this step could look something like:
rhnreg_ks --activationkey mykey --serverUrl
https://your-satellite.com/XMLRPC
Alternatively, most of the above steps can be combined in a shell script that includes the
following lines:
wget -0 - http://your-satellite-DQDN/pub/bootstrap.sh | bash \ && rhnreg_ks
--activation-key my_key --serverUrl \ https://your-satellite-FQDN/XMLRPC
The bootstrap script, generated at installation and available for both RHN Satellite Server and
RHN Proxy Server, is such a script. The script and the RHN Bootstrap that generates it are
discussed in detail in Chapter 5, Using RHN Bootstrap.
Warning
Systems running Red Hat Enterprise Linux 2.1 and versions of Red Hat Linux
prior to 8.0 may experience problems using Activation Keys to migrate SSL
certificate settings from rhn_register to up2date. Therefore, the SSL certificate
information on those systems must be set manually. All other settings, such as
the server URL, transfer properly.
Using the --configure Option
5

2.2. Using the --configure Option
Both the Red Hat Network Registration Client and the Red Hat Update Agent that ship with
Red Hat Enterprise Linux provide interfaces for configuring various settings. For full listings of
these settings, refer to the chapters dedicated to the applications in the RHN Management
Reference Guide.
Each application offers a graphical user interface (GUI) for configuration that enables you to
change the settings required by RHN Proxy Server or RHN Satellite Server. The GUI requires
that the client system run the X Window System. The command to launch the GUI configuration
interface will look like:
application_filename --configure
To reconfigure the Red Hat Update Agent, issue the following command as root:
up2date --configure
You are presented with a dialog box offering various settings that may be reconfigured. In the
General tab, under Select a Red Hat Network Server to use replace the default value
with the fully qualified domain name (FQDN) of the RHN Satellite Server or RHN Proxy Server,
such as https://your_proxy_or_sat.your_domain.com/XMLRPC. Retain the /XMLRPC at the
end. When finished, click OK.
Chapter 2. Client Applications
6

Figure 2.1. Red Hat Update Agent GUI Configuration
Make sure you enter the domain name of your RHN Satellite Server or RHN Proxy Server
correctly. Entering an incorrect domain or leaving the field blank may prevent up2date
--configure from launching. This may be resolved, however, by editing the value in the
up2date configuration file. Refer to Section 2.3, “Updating the Configuration Files Manually” for
precise instructions.
Warning
Systems running Red Hat Enterprise Linux 3 or newer have registration
functionality built into the Red Hat Update Agent and therefore do not install the
Red Hat Network Registration Client. Systems running Red Hat Enterprise
Linux 2.1 (and versions of Red Hat Linux prior to 8.0) must reconfigure and use
the Red Hat Network Registration Client, as well as the Red Hat Update
Agent.
To reconfigure the Red Hat Network Registration Client, perform an almost identical set of
Using the --configure Option
7

steps. As root, run the following command:
/usr/bin/rhn_register --configure
You are presented with a dialog box offering basic settings that may be reconfigured. Under
Select a Red Hat Network server to use replace the default value with the fully qualified
domain name (FQDN) of the RHN Satellite Server or RHN Proxy Server, such as
https://your_proxy_or_sat.your_domain.com/XMLRPC. Retain the /XMLRPC at the end.
Click OK when finished.
Figure 2.2. Red Hat Network Registration Client GUI Configuration
If your version of rhn_register does not display the server field, and you cannot upgrade to a
later version, you may enter the domain name of your RHN Satellite Server or RHN Proxy
Server directly into the rhn_register configuration file. Refer to Section 2.3, “Updating the
Configuration Files Manually” for precise instructions.
2.3. Updating the Configuration Files Manually
As an alternative to the GUI interface described in the previous section, users may also
Chapter 2. Client Applications
8

reconfigure the Red Hat Network Registration Client and the Red Hat Update Agent by
editing the applications' configuration files.
To configure Red Hat Update Agent on the client systems connecting to the RHN Proxy Server
or RHN Satellite Server, edit the values of the serverURL and noSSLServerURL settings in the
/etc/sysconfig/rhn/up2date configuration file (as root). Replace the default Red Hat
Network URL with the fully qualified domain name (FQDN) for the RHN Proxy Server or RHN
Satellite Server. For example:
serverURL[comment]=Remote server URL
serverURL=https://your_primary.your_domain.com/XMLRPC
noSSLServerURL[comment]=Remote server URL without SSL
noSSLServerURL=http://your_primary.your_domain.com/XMLRPC
Warning
The httpProxy setting in /etc/sysconfig/rhn/up2date does not refer to the
RHN Proxy Server. It is used to configure an optional HTTP proxy for the client.
With an RHN Proxy Server in place, the httpProxy setting must be blank (not
set to any value).
Skip this section if you are running Red Hat Enterprise Linux 3 or later on the client system.
Note
You must use version 2.7.11 or higher of rhn_register on client systems so
they can recognize new certificates. This RPM should be available in
/var/spool/up2date on your proxy system after running up2date for the Proxy.
To configure the Red Hat Network Registration Client on the client systems connecting to the
RHN Proxy Server or RHN Satellite Server, edit the values of the serverURL and
noSSLServerURL options in the /etc/sysconfig/rhn/rhn_register configuration file (as
root). Replace the default Red Hat Network URL with the fully qualified domain name (FQDN)
for the RHN Proxy Server or RHN Satellite Server. For example:
serverURL[comment]=Remote server URL
serverURL=https://your_proxy_or_sat.your_domain.com/XMLRPC
noSSLServerURL[comment]=Remote server URL without SSL
noSSLServerURL=http://your_proxy_or_sat.your_domain.com/XMLRPC
2.4. Implementing Server Failover
Implementing Server Failover
9

Beginning with up2date-4.2.38, the Red Hat Update Agent can be configured to seek
updates from a series of RHN Servers. This can be especially helpful in sustaining constant
updates if your primary RHN Proxy Server or RHN Satellite Server may be taken offline.
To use this feature, first ensure that you are running the required version of up2date. Then
manually add the secondary servers to the serverURL and noSSLServerURL settings in the
/etc/sysconfig/rhn/up2date configuration file (as root). Add the fully qualified domain names
(FQDN) for the Proxy or Satellite immediately after the primary server, separated by a
semicolon (;). For example:
serverURL[comment]=Remote server URL
serverURL=https://your_primary.your_domain.com/XMLRPC; \
https://your_secondary.your_domain.com/XMLRPC;
noSSLServerURL[comment]=Remote server URL without SSL
noSSLServerURL=http://your_primary.your_domain.com/XMLRPC; \
https://your_secondary.your_domain.com/XMLRPC;
Connection to the servers is attempted in the order provided here. You can include as many
servers as you wish. You may list the central RHN Servers, as well. This makes sense,
however, only if the client systems can reach the Internet.
3. Configuring the Red Hat Network Alert Notification
Tool with Satellite
The Red Hat Network Alert Notification Tool, the round icon in the panel of your Red Hat
desktop, can be configured on systems running Red Hat Enterprise Linux 3 or later to recognize
updates available from custom channels on your RHN Satellite Server. You must ensure the
RHN Satellite Server is configured to support this feature. (RHN Proxy Server supports the
applet without modification of client or server.) The steps to configure the Red Hat Network
Alert Notification Tool are as follows:
1. Ensure that your RHN Satellite Server is version 3.4 or later and that you have the
rhns-applet package installed on the Satellite. The package can be found in the RHN
Satellite software channel for versions 3.4 and newer.
2. Retrieve the rhn-applet-actions package with up2date or through the Red Hat Network
Tools software channel. Install the package on all Red Hat Enterprise Linux 3 and newer
client systems to be notified of custom updates with the Red Hat Network Alert Notification
Tool. The client systems must be entitled to the Management or Provisioning service levels.
3. Within the Satellite's version of the RHN website, go to the System Details page for each
system and click the link within the RHN Applet area to redirect the Red Hat Network Alert
Notification Tool to the Satellite.
The next time the applet is started, it will apply its new configuration and connect to the RHN
Satellite Server for updates.
Chapter 2. Client Applications
10

SSL Infrastructure
For Red Hat Network customers, security concerns are of the utmost importance. One of the
strengths of Red Hat Network is its ability to process every single request over Secure Sockets
Layer, or SSL. To maintain this level of security, customers installing Red Hat Network within
their infrastructures must generate custom SSL keys and certificates.
Manual creation and deployment of SSL keys and certificates can be quite involved. Both the
RHN Proxy Server and the RHN Satellite Server allow you to build your own SSL keys and
certificates based on your own private Certificate Authority (CA) during installation. In addition, a
separate command line utility, the RHN SSL Maintenance Tool, exists for this purpose.
Regardless, these keys and certificates must then be deployed to all systems within your
managed infrastructure. In many cases, deployment of these SSL keys and certificates is
automated for you. This chapter describes efficient methods for conducting all of these tasks.
Please note that this chapter does not explain SSL in depth. The RHN SSL Maintenance Tool
was designed to hide much of the complexity involved in setting up and maintaining this
public-key infrastructure (PKI). For more information, please consult some of the many good
references available at your nearest bookstore.
1. A Brief Introduction To SSL
SSL, or Secure Sockets Layer, is a protocol that enables client-server applications to pass
information securely. SSL uses a system of public and private key pairs to encrypt
communication passed between clients and servers. Public certificates can be left accessible,
while private keys must be secured. It's the mathematical relationship (a digital signature)
between a private key and its paired public certificate that makes this system work. Through this
relationship, a connection of trust is established.
Note
Throughout this document we discuss SSL private keys and public certificates.
Technically both can be referred to as keys (public and private keys). But it is
convention, when discussing SSL, to refer to the public half of an SSL key pair
(or key set) as the SSL public certificate.
An organization's SSL infrastructure is generally made up of these SSL keys and certificates:
• Certificate Authority (CA) SSL private key and public certificate — only one set per
organization generally generated. The public certificate is digitally signed by its private key.
The public certificate is distributed to every system.
• Web server SSL private key and public certificate — one set per application server. The
public certificate is digitally signed by both its private key and the CA SSL private key. We
Chapter 3.
11

often refer to a Web server's key set; this is because there is an intermediary SSL certificate
request that is generated. The details of what this is used for are not important to this
discussion. All three are deployed to an RHN Server.
Here's a scenario: If you have one RHN Satellite Server and five RHN Proxy Servers, you will
generate one CA SSL key pair and six Web server SSL key sets. The CA SSL public certificate
is distributed to all systems and used by all clients to establish a connection to their respective
upstream servers. Each server has its own SSL key set that is specifically tied to that server's
hostname and generated using its own SSL private key and the CA SSL private key in
combination. This establishes a digitally verifiable association between the Web server's SSL
public certificate and the CA SSL key pair and server's private key. The Web server's key set
cannot be shared with other web servers.
Important
The most critical portion of this system is the CA SSL key pair. From that private
key and public certificate an administrator can regenerate any Web server's SSL
key set. This CA SSL key pair must be secured. It is highly recommended that
once the entire RHN infrastructure of servers is set up and running, you archive
the SSL build directory generated by this tool and/or the installers onto separate
media, write down the CA password, and secure the media and password in a
safe place.
2. The RHN SSL Maintenance Tool
Red Hat Network provides a command line tool to ease management of your secure
infrastructure: the RHN SSL Maintenance Tool, commonly known by its command
rhn-ssl-tool. This tool is available as part of the rhns-certs-tools package. This package
can be found within the software channels for the the latest RHN Proxy Server and RHN
Satellite Server (as well as the RHN Satellite Server ISO). RHN SSL Maintenance Tool
enables you to generate your own Certificate Authority SSL key pair, as well as Web server SSL
key sets (sometimes called key pairs).
This tool is only a build tool. It generates all of the SSL keys and certificates that are required. It
also packages the files in RPM format for quick distribution and installation on all client
machines. It does not deploy them, however. That is left to the administrator, or in many cases,
automated by the RHN Satellite Server.
Note
The rhns-certs-tools, which contains rhn-ssl-tool, can be installed and run
on any current Red Hat Enterprise Linux system with minimal requirements. This
Chapter 3. SSL Infrastructure
12

is offered as a convenience for administrators who wish to manage their SSL
infrastructure from their workstation or another system other than their RHN
Server(s).
Here are the cases in which the tool is required:
• When updating your CA public certificate - this is rare.
• When installing an RHN Proxy Server version 3.6 or later that connects to the central RHN
Servers as its top-level service - the hosted service, for security reasons, cannot be a
repository for your CA SSL key and certificate, which is private to your organization.
• When reconfiguring your RHN infrastructure to use SSL where it previously did not.
• When adding RHN Proxy Servers of versions prior to 3.6 into your RHN infrastructure.
• When adding multiple RHN Satellite Servers to your RHN infrastructure - consult with a Red
Hat representative for instructions regarding this.
Here are the cases in which the tool is not required:
• During installation of an RHN Satellite Server - all SSL settings are configured during the
installation process. The SSL keys and certificate are built and deployed automatically.
• During installation of an RHN Proxy Server version 3.6 or later if connected to an RHN
Satellite Server version 3.6 or later as its top-level service - the RHN Satellite Server contains
all of the SSL information needed to configure, build and deploy the RHN Proxy Server's SSL
keys and certificates.
The installation procedures of both the RHN Satellite Server and the RHN Proxy Server ensure
the CA SSL public certificate is deployed to the /pub directory of each server. This public
certificate is used by the client systems to connect to the RHN Server. Refer to Section 3,
“Deploying the CA SSL Public Certificate to Clients” for more information.
In short, if your organization's RHN infrastructure deploys the latest version of RHN Satellite
Server as its top-level service, you will likely have little need to use the tool. Otherwise, become
familiar with its usage.
2.1. SSL Generation Explained
The primary benefits of using the RHN SSL Maintenance Tool are security, flexibility, and
portability. Security is achieved through the creation of distinct Web server SSL keys and
certificates for each RHN server, all signed by a single Certificate Authority SSL key pair
created by your organization. Flexibility is supplied by the tool's ability to work on any machine
SSL Generation Explained
13

that has the rhns-certs-tools package installed. Portability exists in a build structure that can
be stored anywhere for safe keeping and then installed wherever the need arises.
Again, if your infrastructure's top-level RHN Server is the most current RHN Satellite Server, the
most you may have to do is restore your ssl-build tree from an archive to the /root directory
and utilize the configuration tools provided within the RHN Satellite Server's website.
To make the best use of the RHN SSL Maintenance Tool, complete the following high-level
tasks in roughly this order. Refer to the remaining sections for the required details:
1. Install the rhns-certs-tools package on a system within your organization, perhaps but not
necessarily the RHN Satellite Server or RHN Proxy Server.
2. Create a single Certificate Authority SSL key pair for your organization and install the
resulting RPM or public certificate on all client systems.
3. Create a Web server SSL key set for each of the Proxies and Satellites to be deployed and
install the resulting RPMs on the RHN Servers, restarting the httpd service afterwards:
/sbin/service httpd restart
4. Archive the SSL build tree - consisting of the primary build directory and all subdirectories
and files - to removable media, such as a floppy disk. (Disk space requirements are
insignificant.)
5. Verify and then store that archive in a safe location, such as the one described for backups in
the Additional Requirements sections of either the Proxy or Satellite installation guide.
6. Record and secure the CA password for future use.
7. Delete the build tree from the build system for security purposes, but only once the entire
RHN infrastructure is in place and configured.
8. When additional Web server SSL key sets are needed, restore the build tree on a system
running the RHN SSL Maintenance Tool and repeat steps 3 through 7.
2.2. RHN SSL Maintenance Tool Options
The RHN SSL Maintenance Tool offers a plethora of command line options for generating your
Certificate Authority SSL key pair and managing your server SSL certificates and keys. The tool
offers essentially three command line option help listings: rhn-ssl-tool --help (general),
rhn-ssl-tool --gen-ca --help (Certificate Authority), and rhn-ssl-tool --gen-server
--help (Web server). The manual page for rhn-ssl-tool is also quite detailed and available to
assist: man rhn-ssl-tool.
The two tables below break down the options by their related task, either CA or Web server SSL
key set generation.
Chapter 3. SSL Infrastructure
14