Red Hat CERTIFICATE 7.2 RELEASE NOTES Instruction Manual

Release Notes
7.2 and Updates
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 ht-
tp://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 copy-
right 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-2072USAPhone: [phone]
Phone: [phone]
Fax: [phone]
PO Box 13588Research Triangle Park, NC 27709USA
1. Introduction .....................................................................................................................2
2. New Features in Red Hat Certificate System 7.2 ................................................................2
3. Deployment Notes ...........................................................................................................4
3.1. Server Support ......................................................................................................4
3.2. Optional Server Hardware ......................................................................................5
3.3. Client Support .......................................................................................................6
3.4. Optional Client Hardware .......................................................................................6
3.5. Other Required Software .......................................................................................6
3.6. Red Hat Enterprise Linux Considerations ................................................................6
3.7. Sun Solaris Considerations ....................................................................................7
4. Obtaining Packages .........................................................................................................7
5. Important Notes ...............................................................................................................8
5.1. Installation Notes ...................................................................................................8
5.2. Required JRE .......................................................................................................8
5.3. Required JDK .......................................................................................................9
5.4. TPS Subsystem Considerations ...........................................................................10
5.5. Directory Server Information ................................................................................10
5.6. Source RPMs ......................................................................................................10
1

5.7. New File Locations and Subsystem URIs ..............................................................10
6. Known Issues ................................................................................................................11
7. Updates and Errata Releases for Red Hat Certificate System 7.2 ......................................16
8. Documentation ..............................................................................................................19
9. Copyright and Third-Party Acknowledgments ...................................................................20
10. Document History .........................................................................................................24
1. Introduction
These release notes contain important information available at the time of release for Red Hat Certific-
ate System 7.2. New features, system requirements, installation notes, known problems, resources,
and other current issues are addressed here. Read this document before beginning to use Red Hat
Certificate System.
2. New Features in Red Hat Certificate System 7.2
Red Hat Certificate System 7.2 is a powerful public-key infrastructure (PKI) system containing the fol-
lowing new features:
•New silent installation script to ease installing and configuring multiple subsystem instances
•New security domain structure to organize and streamline communications between subsystems
•Enhanced cloning functionalities utilizing the new security domain organization
•Enhanced Red Hat Enterprise Security Client GUI and diagnostic and Phone Home functionality
•Multiple distinct packages rather than a single all-encompassing package
•A new standards-based architecture which more closely integrates Red Hat Certificate System with
its base operating system
•Simplified browser-based HTML configuration panels for setting up subsystems
•Replaced Netscape Enterprise Server (NES) with Tomcat and Apache web servers
•Decoupled Red Hat Directory Server from Red Hat Certificate System
•Relocatable Red Hat Certificate System subsystem instances
•New supported server platform, Red Hat Enterprise Linux AS 4 (Intel 64-bit)
•New supported client platform, Apple Macintosh OS X 10.4.x (Tiger) (Power PC 32-bit)
Release Notes
2

Red Hat Certificate System 7.1 was comprised of a single large package. Red Hat Certificate System
7.2 has been modularized into numerous smaller packages to allow easier support by updating an ex-
isting package rather than the entire server. This has the additional advantage of allowing changes to
be more easily tracked through the operating system's package management database. For example,
32-bit Red Hat Enterprise Linux 4 version of Certificate System is comprised of the following nine
entry-point packages:
Package Name Package Description
rhpki-ca-7.2.0-1.noarch.rpm Certificate Authority (CA)
rhpki-kra-7.2.0-1.noarch.rpm Data Recovery Manager (DRM); also known as Key Recovery
Authority (KRA)
rhpki-ocsp-7.2.0-1.noarch.rpm Online Certificate Status Protocol (OCSP) Responder
rhpki-tks-7.2.0-1.noarch.rpm Token Key Service (TKS)
rhpki-tps-7.2.0-1.i386.rpm Token Processing System (TPS)
rhpki-console-7.2.0-1.noarch.rpm PKI Console
rhpki-java-tools-7.2.0-1.noarch.rpm Java™-based command-line tools
rhpki-native-tools-7.2.0-1.i386.rpm Native command-line tools
esc-1.0.0-16.i386.rpm Red Hat Enterprise Security Client
Table 1. Packages in Red Hat Certificate System 7.2
The new modular architecture is based upon standards such as the Filesystem Hierarchy Standard
(FHS) 2.3. This means that there is no longer an all-inclusive server root. Rather, Red Hat Certificate
System server functionality is implemented through distribution to appropriate locations within the op-
erating system. For example, 32-bit Red Hat Certificate System libraries are located under /usr/lib,
binaries are located under /usr/bin, and Java™archives (jars) are located under /
usr/share/java.
In Red Hat Certificate System 7.1, the Java™-based tool startconsole was used to configure and
manage any server instance of Red Hat Certificate System. In Red Hat Certificate System 7.2, an
HTML-based configuration wizard is used to configure any new subsystem instance, while a utility
called pkiconsole is used to manage existing instances. The HTML configuration panels are indi-
vidually customized for subsystem type.
Red Hat Certificate System 7.1 used Netscape Enterprise Server as an integrated web server for all of
its HTTP/HTTPS transactions. Red Hat Fortitude provides a Network Security Services (NSS) module
to the Apache HTTP Server 2.0 and a Java™Security Services (JSS) plug-in to Tomcat 5.5. The leg-
acy NES web server in CA, DRM, OCSP, and TKS subsystems has been replaced by Tomcat running
Fortitude, and the legacy NES web server in TPS subsystems has been replaced by Apache running
Fortitude.
Previously, Red Hat Directory Server was bundled and installed with Red Hat Certificate System. Red
Hat Certificate System 7.2 still requires a Red Hat Directory Server 7.1 (SP 3) installation for each
subsystem at configuration, but this server must be installed separately and before the Certificate Sys-
tem is installed.
New Features in Red Hat Certificate System 7.2
3

NOTE
The Red Hat Directory Server can be installed on a separate machine, which is the re-
commended scenario for most production deployments.
Red Hat Certificate System 7.2 creates and removes instances of CA, DRM, OCSP, TKS, and TPS
through command-line utilities called pkicreate and pkiremove. The pkicreate utility allows an
instance to be placed anywhere on the operating system, including a data partition that may be RAID-
enabled. This allows true separation of unique Red Hat Certificate System data from shared Red Hat
Certificate System libraries, executables, and jars, thus providing a better means of maintaining the
security and integrity of a user's valuable data. Furthermore, a Red Hat Certificate System instance
may only be removed by running pkiremove; removing the core Red Hat Certificate System services
have no effect on any Red Hat Certificate System instances installed on a given system.
The Red Hat Certificate System 7.2 server product is now available for 64-bit Red Hat Enterprise
Linux 4 (AMD64 and Intel EM64T) platforms, as well as 32-bit Red Hat Enterprise Linux 4 (i386).
Red Hat Enterprise Security Client 1.0 is now available on Apple Macintosh OS X 10.4.x (Tiger), as
well as Microsoft Windows XP Professional and 32-bit and 64-bit Red Hat Enterprise Linux 4. The
TokenD implementation in the new Enterprise Security Client allows use of Red Hat Certificate System
smart card technology to be integrated with Apple applications such as the Safari Web browser and
Apple Mail.
The Red Hat Enterprise Security Client GUI has been completely revamped and standardized across
all platforms. Enhanced diagnostic information has been added to the UI. New Phone Home configur-
ation streamlines the communication between the TPS and Enterprise Security Client and simplifies
the initial Enterprise Security Client configuration.
3. Deployment Notes
This section contains information related to installing Red Hat Certificate System 7.2, including hard-
ware and platform requirements and prerequisites.
3.1. Server Support
The Certificate System subsystems are supported on the following platforms:
•Red Hat Enterprise Linux AS 4 for i386
•Red Hat Enterprise Linux ES 4 for i386
•Red Hat Enterprise Linux AS 4 for AMD64 and Intel EM64T
•Red Hat Enterprise Linux ES 4 for AMD64 and Intel EM64T
•64-bit Solaris 9 for SPARC
Release Notes
4

Component Details
CPU Intel — 2.0 GHz Pentium 4 or faster
RAM 1 GB (required)
Hard disk storage space Total is approximately 5 GB
•Total transient space required during installa-
tion: 1 GB
•Hard disk storage space required for installa-
tion:
•Space required to set up, configure, and run
the server: approximately 2 GB
•Additional space for database growth in pilot
deployment: approximately 1 GB
•Total disk storage space for installation: ap-
proximately 1 GB
Table 2. Server Requirements
3.2. Optional Server Hardware
•Chrysalis-ITS LunaSA Hardware Security Module (HSM)
•Firmware: 4.5.2
•Appliance Software: 3.2.4
•Client Software: 3.2.4
•nCipher netHSM
•Firmware: 2.12
•Software: 9.01
Optional Server Hardware
5

3.3. Client Support
The Enterprise Security Client is supported on the following platforms:
•Apple Macintosh OS X 10.4.x (Tiger) (Power PC, Intel)
•Microsoft Windows XP Professional (i386)
•Red Hat Enterprise Linux AS 4 (i386)
•Red Hat Enterprise Linux ES 4 (i386)
•Red Hat Enterprise Linux AS 4 for AMD64 and Intel EM64T
•Red Hat Enterprise Linux ES 4 for AMD64 and Intel EM64T
3.4. Optional Client Hardware
•Axalto Global Platform compatible Cyberflex eGate token
3.5. Other Required Software
•Red Hat Directory Server 7.1; the source code and binaries for this component are available at ht-
tps://1rhn.redhat.com), through the Red Hat Directory Server 7.1 channel.
•Web browser software that supports SSL. It is strongly recommended that users such as agents or
administrators use Mozilla Firefox. End-entities should use Mozilla Firefox or Microsoft Internet Ex-
plorer.
The only browser that is fully-supported for the HTML-based instance configuration wizard is Mozilla
Firefox.
3.6. Red Hat Enterprise Linux Considerations
Before installing the Certificate System packages, ensure that the proper dependencies are installed
on the Red Hat Enterprise Linux system.
The following package groups and packages must be installed on all Red Hat Enterprise Linux sys-
tems:
•dialup (package group)
Release Notes
6

•gnome-desktop (package group)
•compat-arch-support (package group)
•web-server (package group)
•kernel-smp (package)
•e2fsprogs (package)
•firefox (package)
On 64-bit Red Hat Enterprise Linux platforms, ensure that the 64-bit (x86_64) compat-libstdc++
libraries are installed, and not only the 32-bit (i386) libraries. To confirm this, run the following com-
mand as root:
rpm -qa --queryformat 'compat-libstdc++-%{VERSION}-%{RELEASE}.%{ARCH}.rpm
| grep x86_64
Numerous libraries should be displayed.
3.7. Sun Solaris Considerations
The Sun Solaris version of Certificate System was tested on Solaris 9 with patch level 118558-28.
4. Obtaining Packages
Red Hat Network (http://1rhn.redhat.com) is the software distribution mechanism for most Red Hat
customers. Account login information for Red Hat Network, including entitlements for the Red Hat Cer-
tificate System 7.2 release, is required to download this software from Red Hat Network. After logging
into Red Hat Network, go to the appropriate Red Hat Certificate System 7.2 channel to download the
packages for the selected Red Hat Enterprise Linux platform.
NOTE
The source code for Red Hat Directory Server 7.1 is included with the ISO image down-
loaded for the 32-bit Red Hat Enterprise Linux version. Red Hat Certificate System it-
self is not yet open source.
Red Hat Enterprise Linux systems can upgrade or download Red Hat Certificate System using
up2date.
Sun Solaris Considerations
7

5. Important Notes
The following sections contain important installation, configuration, and deployment information for
Red Hat Certificate System 7.2.
5.1. Installation Notes
•Packages are non-relocatable. The Red Hat Certificate System base packages can not be installed
to a user-designated location.
•Do not use the Autorun feature of the CD drive. If you use the Autorun feature with a CD created
from the ISO image, all subsystems (CA, DRM, OCSP, TKS, and TPS) as well as the Enterprise Se-
curity Client are installed on the system by default.
The preferred alternative is to run the installation scripts provided for the server, or to follow the in-
stallation instructions in the Red Hat Certificate System 7.2 Administration Guide.
5.2. Required JRE
Java™1.5.0 Java Runtime Environment (JRE). Certificate System does not support earlier versions of
the JRE. This JRE is required for running Tomcat, among other applications for the Certificate System.
On 32-bit Red Hat Enterprise Linux 4 platforms, Certificate System 7.2 requires the 32-bit version of
the IBM JRE 1.5.0. A pre-packaged binary distribution of this package, java-
1.5.0-ibm-1.5.0.0-1jpp_2rh:0.i386, is available through either the Red Hat Enterprise
Linux AS (v. 4 for x86) Extras Red Hat Network channel or the Red Hat Enterprise Linux ES (v. 4
for x86) Extras Red Hat Network channel.
Similarly, for 64-bit Red Hat Enterprise Linux 4 platforms, Certificate System 7.2 requires the 64-bit
version of the IBM JRE 1.5.0. A pre-packaged binary distribution of this package, java-
1.5.0-ibm-1.5.0.0-1jpp_2rh:0.x86_64, is available through either the Red Hat Enterprise
Linux AS (v. 4 for AMD64/EM64T) Extras Red Hat Network channel or the Red Hat Enterprise
Linux ES (v. 4 for AMD64/EM64T) Extras Red Hat Network channel.
As root, run /usr/sbin/alternatives --config java to ensure that the IBM Java™1.5.0
JRE is selected.
Warning
Both the 32-bit xSeries (Intel-compatible) and 64-bit AMD/Opteron/EM64T versions of
the IBM J2SE JRE 5.0 RPM packages available through the IBM download site are
packaged in a format which is incompatible with Certificate System 7.2.
For 64-bit Solaris 9 (SPARC) platforms, download and install the latest version of the 64-bit Sun J2SE
Java™Runtime Environment 5.0 (Update 8) available from the Sun download site, ht-
tp://java.sun.com/javase/downloads/index.jsp.
Release Notes
8

IMPORTANT
The 64-bit Solaris version of the Certificate System requires the user to install the 32-bit
version of the JRE as well as installing the 64-bit version. The 32-bit version is used for
the applet and Java™Web Start support. Read ht-
tp://java.sun.com/j2se/1.5.0/README.html,ht-
tp://java.sun.com/j2se/1.5.0/ReleaseNotes.html, and ht-
tp://java.sun.com/j2se/1.5.0/jre/install-solaris-64.html before installing the Certificate
System.
Under the section Java Runtime Environment (JRE) 5.0 Update 9, Sun only makes this JRE available
through a self-extracting file which is incompatible with Certificate System since this format does not
use the native Solaris packaging utility database.
It is possible to obtain the Sun 5.0 JRE in a compatible format. Click Download under the JDK 5.0 Up-
date 9 section, and, under Solaris SPARC Platform - J2SETM Development Kit 5.0 Up-
date 9, select Solaris SPARC 32-bit packages - tar.Z
(jdk-1_5_0_09-solaris-sparc.tar.Z) and Solaris SPARC 64-bit packages - tar.Z
(use 32-bit version for applet and Java Web Start support)
(jdk-1_5_0_09-solaris-sparcv9.tar.Z).
After downloading these two files, uncompress them using the gunzip utility, and extract the contents
using the tar utility.
The contents of the 32-bit file, jdk-1_5_0_09-solaris-sparc.tar.Z, are COPYRIGHT,
LICENSE,README.html,SUNWj5cfg,SUNWj5dev,SUNWj5dmo,SUNWj5jmp,SUNWj5man, and
SUNWj5rt.
The contents of the 64-bit file, jdk-1_5_0_09-solaris-sparcv9.tar.Z, are SUNWj5dmx,SUN-
Wj5dvx, and SUNWj5rtx.
Since only the JRE is needed on Solaris 9 systems, use the pkgadd utility to add the 32-bit package,
SUNWj5rt, first, and then add the 64-bit package, SUNWj5rtx.
5.3. Required JDK
A JDK must be present on Red Hat Enterprise Linux systems. See ht-
tp://kbase.redhat.com/faq/FAQ_54_4667.shtm for more information. While almost any JDK is suffi-
cient, installing one of these JDKs is recommended:
•For 32-bit Red Hat Enterprise Linux 4 platforms, a pre-packaged binary distribution of the 32-bit ver-
sion of the IBM JDK 1.5.0, java-1.5.0-ibm-devel-1.5.0.0-1jpp_2rh:0.i386, is available
through either the Red Hat Enterprise Linux AS (v. 4 for x86) Extras Red Hat Network channel or
the Red Hat Enterprise Linux ES (v. 4 for x86) Extras Red Hat Network channel.
•For 64-bit Red Hat Enterprise Linux 4 platforms, a pre-packaged binary distribution of the 64-bit ver-
sion of the IBM JDK 1.5.0, java-1.5.0-ibm-devel-1.5.0.0-1jpp_2rh:0.x86_64, is avail-
able through either the Red Hat Enterprise Linux AS (v. 4 for AMD64/EM64T) Extras Red Hat
Network channel or the Red Hat Enterprise Linux ES (v. 4 for AMD64/EM64T) Extras Red Hat
Network channel.
Required JDK
9

After installing the JDK, run /usr/sbin/alternatives --config javac as root to insure that
a JDK is available.
Solaris 9 systems do not require downloading and installing a JDK; however, it may be required to
download and install the Sun JDK 5.0 package in order to obtain a compatible Sun JRE 5.0 package.
5.4. TPS Subsystem Considerations
•TPS subsystems installed on a Red Hat Enterprise Linux system require a local installation of the
Apache 2.0.x web server. If the installation is made on a newly-installed Red Hat Enterprise Linux
AS or ES system, rather than an upgraded system, and Everything was selected during the
Anaconda installation process, an Apache server should already be present.
When installing the TPS subsystem on Solaris 9, a specially-configured Apache server is included
as part of the Certificate System 7.2 packages.
•The TPS subsystem cannot be cloned.
5.5. Directory Server Information
All subsystems require access to Red Hat Directory Server 7.1 on either the local machine (if it is also
a 32-bit Red Hat Enterprise Linux platform) or a remote machine (acceptable platforms are 32-bit Red
Hat Enterprise Linux 4, 32-bit Solaris 9 for SPARC, or 64-bit Solaris 9 for SPARC).
5.6. Source RPMs
Since Red Hat Certificate System 7.2 is not an open-source product, source RPMs are only available
for third-party packages.
NOTE
Several of these third-party packages may issue warnings when they are installed be-
cause they may contain the UID or GUID of their original packager.
5.7. New File Locations and Subsystem URIs
The subsystem files in Certificate System 7.2 are in different locations than in Certificate System 7.1.
The old and new locations are listed in Table 3, “Certificate System 7.1 and 7.2 File Locations”. These
are explained in more detail in chapter 3, "Administrative Basics," in the Certificate System Adminis-
trator's Guide.
File 7.1 Location 7.2 Location
Subsystem start and stop
scripts /opt/redhat-cs/cert-in- stance_ID /etc/init.d/instance_ID
Release Notes
10

File 7.1 Location 7.2 Location
Subsystem installation directory
(default) /opt/redhat-cs/cert-in- stance_ID /var/lib/instance_ID
Subsystem configuration direct-
ory (default) /opt/redhat-cs/cert-in- stance_ID/config /var/lib/instance_ID/conf
Subsystem log files /opt/redhat-cs/cert-in-
stance_ID/logs /var/log/instance_ID
Tools /
opt/red-
hat-cs/bin/cert/tools
/usr/bin
Security databases /opt/redhat-cs/alias /var/lib/instance_ID/alias
Table 3. Certificate System 7.1 and 7.2 File Locations
In addition to differences between the default directories, versions 7.1 and 7.2 use different URLs for
accessing the services HTML pages. The old and new locations are listed in Table 4, “Certificate Sys-
tem 7.1 and 7.2 URLs”.
Page 7.1 URL 7.2 URL
CA Services Page https://hostname:SSLport https://hostname:SSLport/
ca/services
CA Agents Page https://hostname:SSLport/
ca/agent/ca
CA End-Entities Page https://hostname:SSLport/
ca/ee/ca
DRM Services Page https://hostname:SSLport https://hostname:SSLport/
kra/services
DRM Agents Page https://hostname:SSLport/
kra/agent/kra
OCSP Services Page https://hostname:SSLport https://hostname:SSLport/
ocsp/services
OCSP Agents Page https://hostname:SSLport/
ocsp/agent/ocsp
Table 4. Certificate System 7.1 and 7.2 URLs
6. Known Issues
Table 5, “Known issues in Red Hat Certificate System 7.2” lists the known issues and supported work-
arounds in Red Hat Certificate System 7.2.
Bug Number Description
57434 On Red Hat Enterprise Linux, a new CA server will not start after configuration if a
SafeNet LunaSA 3.1 hardware module is used with SHA-512 as the CA signing al-
gorithm. The CA server returns an error that the signature on the server certificate is
Known Issues
11

Bug Number Description
bad. SHA-256 can be used as the signing algorithm instead.
57514 If a TKS master key is generated on a SafeNet LunaSA HSM, server-side key genera-
tion fails with the following error in the TKS debug log:
"can't generate key encryption key"
A similar message also appears in the debug log if server-side key generation is turned
on:
"TokenServlet: key encryption key generation failed
for CUID"
where CUID is the card unique ID.
57526 If a server certificate contains the Authority Information Access extension, the certificate
cannot be imported on an nCipher netHSM hardware token. The default caServerCert
profile has this extension enabled by default. For example, when installing a subsystem
such as the Token Key Service (TKS), the SSL server certificate fails to import if the
certificate is processed through the default caServerCert profile because the caServer-
Cert profile adds the Authority Information Access extension to the SSL server certific-
ate automatically. If a CA server is already installed on the nCipher netHSM token, then
the CA signing certificate is overwritten, as well. To import the server certificate prop-
erly, first remove the Authority Information Access extension from the caServerCert pro-
file, then install the subsystem.
57677 If the DRM response to the TPS exceeds the timeout period, the server can return the
incorrect response message, 200 HTTP/1.1 OK, signaling that the operation com-
pleted successfully instead of timing out.
57640 If a DRM version 6.1 SP4 is migrated to version 7.2, then the archived keys that were
migrated cannot be recovered because the key splitting schemes are different. To be
able to recover these keys, first obtain a migration patch from Red Hat services. This
patch will recover the PIN needed to access the storage token where the DRM private
key resides, then recover the keys and export them to a PKCS #12 file. However, this
package can potentially expose security issues in the version 6.1 SP 4 DRM, so it
should be used only as necessary.
For information on using these migration scripts, see the README available with the
migration package.
57683 If there are multiple enrollment operations using the tpsclient tool when server-side
key generation is enabled in the TPS, then the DRM connection can time out before the
TPS can generate the keys. The tool will then return the error Failed to generate
key on server. Please check DRM. To correct this, edit the TPS CS.cfg con-
figuration file and add a line increasing the timeout period for the connection to the
DRM:
conn.drm1.timeout=25
Release Notes
12

Bug Number Description
57800 It is possible for inconsistencies to arise between the TPS database and the CA data-
base, so that certificate statuses may not be correct. The TPS database only maintains
the certificate statuses on tokens that were last seen by the TPS system. For example,
if a certificate is manually revoked by the CA agent, then that revocation status does
not get updated automatically in the TPS database. There is no known workaround for
this issue at this time.
57875 To verify if the full CA chain is in a security database, such as an OCSP or subordinate
CA, open the security database directory, like /var/lib/instance_ID/alias.
To list all the CA certificates and their nicknames, run certutil with the following op-
tions:
certutil -d . -L
To confirm that a particular certificate is included in the database, run certutil with
the following options:
certutil -d . -L -n nickname
nickname is the nickname of the certificate.
The only time a certificate chain is needed for the OCSP service is if the CA connects
to the OCSP through SSL authentication when it publishes its CRL. Otherwise, the OC-
SP does not need to have the complete certificate chain to verify the CRL; the OCSP
must have the certificate which signed the CRL, either the CA signing certificate or a
CRL signing certificate. If both a root CA and one of its subordinate CAs publish CRLs
to an OCSP, the OCSP needs the CA signing certificate of both CAs.
The signing certificate can be imported into the OCSP database through the OCSP
agent interface.
57978 Trying to add the nsTokenUserKeySubjectName default with No Constraint ex-
tension to a certificate profile through the Certificate Manager Console throws a null
pointer exception, and the default is not added.
57991 The server certificate nicknames created through the subsystem configuration wizard
cannot be edited in the Requests and Certificates panel. These certificate nicknames
are not currently shown in that part of the configuration UI; that field is left blank in the
pretty-print view. This can cause naming collisions if a hardware token is used for a
subsystem and server certificates are already stored on the token.
58058 Generating key pairs on Safenet LunaSA hardware modules can fail with the error
CKR_MAX_OBJECT_COUNT_EXCEEDED. On LunaSA tokens, the number of objects can-
not exceed 127. When an object is deleted, the label for that object remains and is
counted. Delete the empty labels to lower the count. Key generation can then proceed.
58201 When configuring a cloned CA, the administrator certificate panel is displayed, but
grayed out. Clicking Next to proceed to the next panel displays a pop-up box that the
certificate was successfully imported into the browser when, actually, no action was
taken.
58228 Even after the configuration process is successfully completed, the configuration wizard
Known Issues
13

Bug Number Description
page can still be accessed. This page can be disabled by removing the preop.pin
parameter from the instance's CS.cfg file and restarting the instance.
58301 Using the administrative console to renew an SSL server certificate stored on a hard-
ware token automatically imports the server certificate into the Certificate System soft-
ware token rather than the hardware token.
58354 It is possible for a CA, DRM, OCSP, and TKS subsystem's certificates to be generated
by an external root CA. For a subordinate CA in that case, the new CA signing certific-
ate issued by the external CA must be pasted into the Requests and Certificates page;
this signing certificate is then used to generate the other certificates. For DRM, OCSP,
and TKS subsystems, the SSL server and client certificates and, if required, DRM
transport and storage certificates are generated by the external CA. It can take several
days, even weeks, to receive the certificates from the external root CA, meaning the the
configuration process is suspended at the Requests and Certificates panel in the con-
figuration wizard. When the certificates are received, they must be pasted into the Re-
quests and Certificates panel to complete the subsystem configuration. However, re-
opening the configuration wizard at the beginning of the process can corrupt the previ-
ous setup. To return directly to the Requests and Certificates panel in the configuration
wizard, open the configuration wizard URL with ?p=12 appended to the end. For ex-
ample:
http://server.example.com:9080/ca/admin/
console/config/wizard?p=12
58464 On Mozilla Firefox, when accessing a subsystem URL without specifying the desired
page, such as https://server.example.com:9443, it automatically redirects to
https://server.example.com:9443/ca/services. The redirect does not work
on Internet Explorer 6.0; when trying the URL ht-
tps://server.example.com:9443, Internet Explorer opens a blank page.
58518 When starting or stopping a CA, DRM, OCSP, or TKS on Solaris, the start and stop
script can kill the process before the process completes and exits. This does not occur
on a TPS subsystem on Solaris.
58524 Before reusing an HSM to install and configure a TPS subsystem, manually delete any
existing certificates from the HSM. All conflicting certificates (certificates with the same
nickname) have to be removed from the HSM before the TPS is configured. Otherwise,
the configuration process will still install the new certificates, but it is not certain which
certificate, old or new, will be used. Running certutil with the -D option to delete the
certificates does not work with the -f option to specify a password file.
58555 Safenet LunaSA hardware modules do not have binaries for 64-bit Red Hat Enterprise
Linux platforms. Trying to use LunaSA 32-bit libraries on 64-bit Red Hat Enterprise
Linux platforms, including Red Hat Enterprise Linux 4 (x86_64), will fail with the follow-
ing error:
ERROR: Failed to add module "lunasa". Probable cause: "/
usr/lunasa/lib/libCryptoki2.so:
cannot open shared object file: No such file or directory"
58577 Agent authentication to an ECC-enabled CA can fail in the browser with error -12271 if
an HSM has been added to the secmod.db database on the local machine. To work
around this situation, delete the secmod.db database which contains the HSM entry
Release Notes
14

Bug Number Description
and create a new secmod.db database.
58745 If two TPS instances are running on the same machine, stopping or restarting one in-
stance will automatically restart the other instance. It is recommended that only one
TPS instance run per machine.
58759 There are exception errors when trying to install a renewed certificate in the subsystem
certificate database through the administrative console. Instead of using the Console to
install renewed subsystem certificates, use the certutil utility.
58761 The HTML-based instance configuration wizard is only supported on Mozilla Firefox.
Using an unsupported browser can result in incorrect behavior. For example, in Mi-
crosoft Explorer, the pretty-print certificates and the certificate requests are displayed
on a single line.
58764 When setting up a clone, the Certificate System clone instance may record errors con-
cerning the ancestorid attribute in the error log:
[30/Oct/2006:11:04:00 -0800] - warning:
ancestorid not indexed on 21
[30/Oct/2006:11:04:00 -0800] - warning:
ancestorid not indexed on 21
[30/Oct/2006:11:04:00 -0800] - warning:
ancestorid not indexed on 21
These warnings can be ignored because they only indicate that the request repository
is empty at the time the clone is configured; they do not indicate a problem with the
clone instance.
58773 If a subsystem within a security domain needs to be re-installed, there may be a sub-
system user already created in the security domain CA's user database if the previous
installation was either successfully completed or stopped after the security domain was
selected. Since the user names are created based on the hostname and port number, if
the same port number is reused, the pre-existing entry prevents the next installation
from inserting its subsystem certificate into the subsystem user's entry in the security
domain. This causes the instance to fail to start because the authentication to the se-
curity domain fails. This can happen on any subsystem which is reinstalled, except for
the security domain CA itself.
To reinstall a subsystem without encountering these authentication errors, do the fol-
lowing:
1. When installation is aborted - or when completed, but it needs redone - remove the
instance. For example:
pkiremove -pki_instance_root=/var/lib
-pki_instance_name=rhpki-tps
2. Open the Console for the security domain CA, and remove the subsystem user from
the security domain CA user database:
Known Issues
15

1https://rhn.redhat.com/errata/rhel-certserv-72-errata.html
Bug Number Description
pkiconsole https://server.example.com:9443/ca/
a. Click on Users and Groups in the left navigation tree.
b. Click on the subsystem user name, such as TPS-server.example.com-7889.
c. Click Delete.
3. Recreate the subsystem.
pkicreate -config_dir=/var/lib -subsystem_type=tps
-pki_instance_name=rhpki-tps
-secure_port=7888 -unsecure_port=7889
-user=pkiuser -group=pkigroup -verbose
4. Go through the configuration wizard again. The instance will restart successfully
when the configuration is finished.
58779 When an nCipher HSM is used for a Certificate System instance, the nfast group
needs to include the user ID of the Certificate System instance process. For example,
since default Certificate System instances run as pkiuser, then the pkiuser group
needs to be added as a member to the nfast group, if the Certificate System group
has not already been added.
213805 If a token is plugged in when the Enterprise Security Client is installed, then the client
can fail to recognize the token. To be certain that the Enterprise Security Client will re-
cognize tokens, make sure that no smart card tokens are plugged in when the Enter-
prise Security Client packages are installed.
Certificates cannot be installed or renewed in the certificate database through the Certi-
ficate Setup Wizard in the administrative console in Certificate System 7.2. The cer-
tutil utility can be used to manage certificates instead.
Table 5. Known issues in Red Hat Certificate System 7.2
7. Updates and Errata Releases for Red Hat Certificate Sys-
tem 7.2
The following erratas have been issued for Red Hat Certificate System, fixing important security and
performance issues. The complete list of erratas issued for Red Hat Certificate System 7.2 is available
through Red Hat Network for Red Hat Enterprise Linux 41.
Release Notes
16

Release Date Errata Re-
lease Bug Number Description
January 14,
2009 RHSA 2009:0006 249923
451998 (CVE
2008-2367)
452071
Red Hat Certificate System used insecure de-
fault file permissions on certain configuration
files, such as password.conf, that may con-
tain administrative passwords or other creden-
tials. A local user could use that information to
gain access to sensitive information stored in
Certificate System subsystems.
224732
451200 (CVE
2008-2368)
Red Hat Certificate System stored plain text
passwords in multiple log files, such as some
certificate profile logs and installation logs,
which had insufficient access restrictions to
prevent unauthorized users from viewing them.
A local user could access the plain text pass-
word to gain access to Certificate System in-
formation.
224904 Due to a regression, signing a certificate re-
vocation list (CRL) with approximately 150,000
records may have taken up to five minutes. In
these updated packages, signing such CRLs
takes approximately twenty seconds.
238514
306091 An OCSP client submitting an OCSP request
via the GET method may have caused a Null-
PointerException. This errata adds support for
processing OCSP requests submitted through
a GET method.
239876
308161 Because Certificate System subsystems could
not handling Online Certificate Status Protocol
(OCSP) requests in the GET method, OCSP
GET requests resulted in a 404 error. This was
also related to a problem which caused the
subsystem to use 100% CPU when processing
OCSP requests.
243939 OCSP requests are now logged to the debug
log file.
243804
451726 When a new certificate revocation list (CRL)
was being generated, new revocation requests
were processed but not properly added to the
CRL. This meant that certificates with higher
serial numbers (i.e., more recent certificates)
were not listed in the CRL and were not shown
as revoked until the next CRL was generated.
A user who had a revoked but otherwise valid
certificate could take advantage of this issue to
bypass the revocation list.
243807 Inefficient LDAP search methods caused
LDAP searches for 100,000 or more revoked
certificates to take twenty minutes or longer
during CRL generation. The LDAP search
method has been modified to greatly improve
Updates and Errata Releases for Red Hat Certi-
ficate System 7.2
17

Release Date Errata Re-
lease Bug Number Description
LDAP search times.
249229 The default OCSP verification path has
changed since Red Hat Certificate System 7.1.
These updated packages add support for certi-
ficates that use the old AuthorityInfoAccess
URL.
254232
330261 If an agent automatically approved a certificate
signing request (CSR) using AgentCertAuth,
the iisued certificate contained blank sub-
jectAltName extension fields. A manual enroll-
ment by the same agent produced a certificate
with the correct number of subjectAltName
fields, with no blank fields. This errata fixed
automated enrollements using the AgentCer-
tAuth profile so that the issued certificates do
not have any blank fields.
462143 The initial authentication to a security domain
failed during subsystem configuration.
462145 After its initial configuration, the TPS subsys-
tem failed to restart.
July 2, 2008 RHSA
2008:0577 440356
442963
445227
445231
CVE-
2008-1676
A flaw was found in the way Certificate System
handled extensions in the certificate signing
requests (CSR). All requested extensions were
added to the issued certificate even if con-
straints were defined in the certificate authority
(CA) profile. An attacker could submit a CSR
for a subordinate CA certificate, even if the CA
configuration prohibited subordinate CA certi-
ficates. This led to a bypass of the intended
security policy, possibly simplifying man-
in-the-middle attacks against users that trust
Certificate System CAs.
January 9,
2008 RHBA 2000:0035 330261 If an agent automatically approved a certificate signing request (CSR) using AgentCertAuth,
the iisued certificate contained blank sub-
jectAltName extension fields. A manual enroll-
ment by the same agent produced a certificate
with the correct number of subjectAltName
fields, with no blank fields. This errata fixed
automated enrollements using the AgentCer-
tAuth profile so that the issued certificates do
not have any blank fields.
October 8,
2008 RHSA 2007:0934 224904
243176
243804
243807
304571 (CVE
2007:4994)
When a new certificate revocation list (CRL)
was being generated, new revocation requests
were processed but not properly added to the
CRL. This meant that certificates with higher
serial numbers (i.e., more recent certificates)
were not listed in the CRL and were not shown
as revoked until the next CRL was generated.
Release Notes
18

Release Date Errata Re-
lease Bug Number Description
A user who had a revoked but otherwise valid
certificate could take advantage of this issue to
bypass the revocation list.
308161 If Certificate System received an OCSP re-
quest using the GET method, it returned an
HTTP 404 error because it could not properly
handle GET requests.
September
24, 2007 RHBA 2007:0927 254232 This extracts extensions from PKCS#10 re- quests to use within the profile framework.
Table 6. Bugs Fixed in Errata Updates for Certificate System 7.2
8. Documentation
The Certificate System Administrator's Guide describes how to set up, configure, and administer the
Certificate System subsystems and how to configure backend certificate management functions, such
as publishing and logging. The Administrator's Guide also describes how to configure subsystems to
relate to one another to manage certificates and tokens and how to manage certificates and tokens;
this guide is targeted for Certificate System administrators.
The Certificate System Agent's Guide describes how agents — users responsible for processing certi-
ficate requests and managing other aspects of certificate management — can use the Certificate Sys-
tem subsystems web services pages to process certificate requests, key recovery, OCSP requests
and CRLs, and other functions.
The documentation for Certificate System includes the following guides:
•Certificate System Administrator's Guide explains all administrative functions for the Certificate Sys-
tem, such as adding users, creating and renewing certificates, managing smart cards, publishing
CRLs, and modifying subsystem settings like port numbers.
•Certificate System Agent's Guide details how to perform agent operations for the CA, RA, DRM, and
TPS subsystems through the Certificate System agent services interfaces.
•Certificate System Command-Line Tools Guide covers the command-line scripts supplied with Red
Hat Certificate System.
•Managing Smart Cards with the Enterprise Security Client explains how to install, configure, and use
the Enterprise Security Client, the user client application for managing smart cards, user certificates,
and user keys.
•Certificate System Migration Guides cover version-specific procedures for migrating from older ver-
sions of Certificate System to Red Hat Certificate System 7.2.
•Release Notes contains important information on new features, fixed bugs, known issues and work-
Documentation
19

arounds, and other important deployment information for Red Hat Certificate System 7.2.
Additional Certificate System information is provided in the Certificate System SDK, an online refer-
ence to HTTP interfaces, javadocs, samples, and tutorials related to Certificate System. A download-
able zip file of this material is available for user interaction with the tutorials.
For the latest information about Red Hat Certificate System, including current release notes, complete
product documentation, technical notes, and deployment information, see ht-
tp://1www.redhat.com/1docs/1manuals/1cert-system/.
9. Copyright and Third-Party Acknowledgments
Copyrights and third-party acknowledgments for portions of Red Hat Certificate System 7.2 servers in-
clude the following:
Apache Software Foundation
Red Hat Certificate System TPS subsystems require a locally-installed Apache 2.0.x HTTP server.
Although a local copy of this server is generally installed as part of the operating system (with its
corresponding license located in /usr/share/doc/httpd-version/LICENSE, the latest version of
this server is available at the following URL:
http://1httpd.apache.org
Red Hat Certificate System CA, DRM, OCSP, and TKS subsystems use a locally-installed Tomcat
5.5 web server. Although an appropriate server is installed when any of these subsystems are in-
stalled, the latest version of this server is available at the following URL:
http://1tomcat.apache.org
Red Hat Certificate System uses many components made available from Apache.
•The XML project jars are crimson.jar and xalan.jar. These are available at the following
URL:
http://1xml.apache.org
•The Tomcat project jar files are servlet.jar and jakarta-naming.jar. These are avail-
able at the following URL:
http://1jakarta.apache.org/1tomcat/1index.html
Mozilla Foundation
Red Hat Certificate System uses version 4.2 of the Java™Security Services (JSS) libraries from
the Mozilla Project. If any problems are found in these specific libraries, the source code and build
instructions for the latest version of and, potentially, the binary images for newer versions are
available at the following URL:
http://1www.mozilla.org/1projects/1security/1pki/1jss/1index.html
Red Hat Certificate System also uses version 4.6 of the Netscape Portable Runtime (NSPR) lib-
Release Notes
20