Token management support for server-side key generation, key archival and recovery

If a token is lost, stolen, or broken, end users may now easily get a usable, permanent replacement. This is possible because the encryption key on the token is now backed up. In addition, users can now obtain a temporary replacement if they leave a token at home.

This feature was accomplished through development in two broad areas:

ACL-based recovery approval

In past releases, key recovery used a cryptographic key-splitting scheme, where n of m administrators each contribute a portion of the token password required to recover a user's private key. To support a more flexible and manageable approach, this version of Certificate System supports:

Support of SHA-256 and SHA-512

There are two additional message digests supported in this release:   SHA-256 and SHA-512. These two choices have been added to the configuration wizard screens for creating a Certificate Authority (CA) signing certificate or an SSL server certificate. In the CA subsystem, a certificate can be signed with either SHA256withRSA or SHA512withRSA in addition to the existing signing algorithms.

Data Recovery Manager (DRM): Entropy Collection for Server-side Key Generation

The DRM now collects additional random data to feed into the cryprographic pseudo random number generator (PRNG) between each key generation. This is collected from the /dev/random device. The operating system feeds /dev/random by collecting entropy from a variety of sources, including high-resolution timer intervals between I/O interrupts. The number of bits of entropy to collect for each key generation is configurable.

RHCS 7.1 Migration

Two new migration scripts have been provided for Certificate System 7.1:


• The first new script, located in the <serverRoot>/bin/cert/upgrade/71ToTxt/ directory, will create output files of a Red Hat Certificate System 7.1 installation for use by other Red Hat Certificate System 7.1 (and future) installations.
• The second new script, located in the <serverRoot>/bin/cert/upgrade/TxtTo71/ directory, will accept output files created from the migration scripts of previous releases of the Netscape Certificate Management Systems. This script will also accept output files generated by other installations of Red Hat Certificate System 7.1.

Additionally, the documentation will be updated to provide the following information:


• Migration of RHCS 7.1 data from one machine to another machine running the same operating system (e. g. - RHEL 4 machine "foo" to RHEL 4 machine "bar").
• Migration of RHCS 7.1 data from one machine to another machine running a different operating system (e. g. - Solaris 8 machine "alpha" to RHEL 4 machine "beta").

For detailed information regarding the proper use of these, and earlier, migration scripts, please follow the instructions located in chapter 2 of the RHCS Command-Line Tools Guide.

Integrated 32-bit IBM JRE 1.4.2 (RHEL only)

On RHEL platforms, Certificate System 7.1 bundles the 32-bit version of IBM JRE 1.4.2; no preliminary download of any other JRE is necessary.

For Solaris, administrators still need to download and unpack the 32-bit version of Solaris JRE 1.4.2_06 from Sun's Java web site. The path to the unpackaged binary must be provided during setup (see details described below under the 32-bit JRE Installation Procedure (Solaris only) section).

Support for RPMs (RHEL only)

On RHEL platforms, Certificate System 7.1 is packaged in Red Hat's rpm packaging format. This package will be available via Red Hat Network for distribution.

Certificate System 7.1 consists of both clients and servers. This section contains the following information:

• Supported Client Platforms
• Supported Server Platforms
• Supported Server Platform Requirements
• Other Required Server Software
• Optional Client Hardware
• Optional Server Hardware

Certificate System 7.1 clients exist solely on 32-bit platforms:


32-bit Client Platforms

• Apple Mac OS X 10.3 (Panther)
• Microsoft Windows XP Professional
• Red Hat Enterprise Linux Advanced Server (AS) 4 (Intel 32-bit)
  
• Red Hat Enterprise Linux Enterprise Server (ES) 4 (Intel 32-bit)
  



NOTE:	Due to problems with RHEL 3 universal serial bus (USB) drivers, ESC will not be supported for RHEL 3 AS or RHEL 3 ES.

Certificate System 7.1 servers can perform on 32-bit and 64-bit platforms and architecture. The 32-bit and 64-bit applications are separate; an overview of the supported operating systems for 32-bit and 64-bit platforms is given here:

32-bit Server Platforms
• Red Hat Enterprise Linux AS 3 (Intel 32-bit)
• Red Hat Enterprise Linux AS 4 (Intel 32-bit)
• Red Hat Enterprise Linux ES 3 (Intel 32-bit)
• Red Hat Enterprise Linux ES 4 (Intel 32-bit)
• Sun Solaris 9 (Sparc 32-bit)
  

64-bit Server Platforms
• Sun Solaris 9 (Sparc 64-bit)

Upgrading from a Previous Version of Netscape CMS

Upgrading from a previous version of Netscape CMS can be accomplished by installing Red Hat CS 7.1 into a server root which differs from the previous installation's server root, and migrating the data as described in chapter 2 of the RHCS Command-Line Tools Guide. Note that although the original installation should not be adversely affected, it is still always advisable to backup the entire original server root before upgrading.

Common Criteria Certification

Red Hat CS 7.1 is not Common Criteria certified.


While instructions are included to set up RHCS 7.1 in this mode, it should be understood that this version of the CS product is NOT officially Common Criteria certified. To run CS as an officially certified Common Criteria product, use Netscape CMS 6.1 (SP 1) and follow the detailed Common Criteria setup instructions included in Appendix B of the RHCS Administrator's Guide.

Installing RHCS 7.1 via CDROM (RHEL only)

When installing Red Hat Certificate System from a CDROM onto a RHEL platform, the Package Manager GUI is used to perform the RPM installation. After the RPM installation is complete, you still need to run <serverRoot>/setup/setup to create your Certificate System and Directory Server instances.

32-bit JRE Installation Procedure (Solaris only)

Be sure to read these release notes, the JRE instructions that follow, and the installation instructions in the RHCS Administrator's Guide before installing the product.

IMPORTANT:   Before you attempt to install this release, you must  download and extract a 32-bit JRE 1.4.2_06. Follow these steps:

• Download and extract a 32-bit JRE from sun.com website
• Goto http://java.sun.com
• Locate the 32-bit JRE 1.4.2 (location may vary over time)
• NOTE:   RHCS 7.1 has only been tested with the 32-bit JRE 1.4.2_06. Later versions may work, but this is not guaranteed.
• Download the 'self-extracting' file into a 'new' directory (for example, /opt/jre/) and extract it.

                For example,

                    bash-2.05# ./j2re-1_4_2_06-solaris-sparc.sh
                    Unpacking...
                    Checksumming...
                    Extracting...
                    Archive:  ./install.sfx.15236
                    creating: j2re1.4.2_06/
                    ...
                    ...
                    Creating j2re1.4.2_06/lib/plugin.jar
                    Creating j2re1.4.2_06/javaws/javaws.jar
                    Done.
                

• Run the setup script provided with RHCS 7.1 and provide the JRE installation location:

            bash-2.05# ./setup
            In order to run setup, you need to have version 1.4.2 of
            Sun's 32-bit Solaris Java runtime environment on your system.

            Enter the path to the unpackaged JRE: /opt/jre/

            Note:   The setup script then bundles the JRE
            into the RHCS package and proceeds with normal installation.

            

Installation Procedure using "root" (Default)

When installing RHCS 7.1 as "root" using RPM (RHEL platforms only):


1. Login as "root".
2. Install the RPM by executing the command 'rpm -ivh redhat-cs-7.1-2.RHEL4.i386.rpm'.
3. Change directory into the <serverRoot> by executing the command 'cd <serverRoot>'.
4. Install the initial RHCS 7.1 instance by executing the command './setup/setup'.
   
   
   1. When asked to specify a Directory Server user, select the default user (e. g. - "root").
   2. When asked to specify a Directory Server group, select the default group (e. g. - "root").
   3. When asked to specify an Administration Server user, select the default user (e. g. - "root").
   4. Perform all future instance creations, configurations, and administration as "root".
   
   
5. Logout as "root".

When installing RHCS 7.1 as "root" (Solaris platforms only):


1. Login as "root".
2. Download the 64-bit RHCS 7.1 (certificate-7.1-domestic-us.sparc-sun-solaris9-64.tar.gz) or the 32-bit RHCS 7.1 (certificate-7.1-domestic-us.sparc-sun-solaris9.tar.gz) as desired.
3. Decompress the 64-bit RHCS 7.1 by executing a command similar to '/usr/bin/gunzip certificate-7.1-domestic-us.sparc-sun-solaris9-64.tar.gz' specifying additional options as desired, or the 32-bit RHCS 7.1 by executing a command similar to '/usr/bin/gunzip certificate-7.1-domestic-us.sparc-sun-solaris9.tar.gz' specifying additional options as desired.
4. Unpack the 64-bit RHCS 7.1 by executing a command similar to '/usr/sbin/tar -xvf certificate-7.1-domestic-us.sparc-sun-solaris9-64.tar' specifying additional options as desired, or the 32-bit RHCS 7.1 by executing a command similar to '/usr/sbin/tar -xvf certificate-7.1-domestic-us.sparc-sun-solaris9.tar.gz' specifying additional options as desired.
5. Install the initial RHCS 7.1 instance by executing the command './setup'.
   
   
   1. When asked to specify a Directory Server user, select the default user (e. g. - "nobody").
   2. When asked to specify a Directory Server group, select the default group (e. g. - "nobody").
   3. When asked to specify an Administration Server user, select the default user (e. g. - "root").
   4. Change directory into the <serverRoot> by executing the command 'cd <serverRoot>'.
   5. Perform all future instance creations, configurations, and administration as "root".
   
   
6. Logout as "root".

Installation Procedure using non-"root" User (Recommended)

NOTE:   To use privileged ports (i. e. - ports <= 1024), users must install RHCS 7.1 as "root" (regardless of platform).

When installing RHCS 7.1 as non-"root" using RPM (RHEL platforms only):


• The following commands must still be executed as "root":
  
  
  1. Login as "root".
  2. Install the RPM by executing the command 'rpm -ivh redhat-cs-7.1-2.RHEL4.i386.rpm'.
  3. Create a new group for RHCS (e. g. - "csgroup") by executing a command similar to '/usr/sbin/groupadd csgroup' specifying additional options as desired.
  4. Create a new user for RHCS (e. g. - "csuser") by executing a command similar to '/usr/sbin/useradd -c "RHCS User" -d <home_dir> -g csgroup -m -p <password> csuser' specifying additional options as desired.
  5. Edit the "/etc/group" file, and append the new user (e. g. - "csuser") to the new group (e. g. - "csgroup"); for example, something that looks like 'csgroup:x:1517:csuser' where "x" refers to a potential encrypted password, and "1517" represents a sample group id.
  6. Recursively change the ownership of all of the files and directories that were originally installed as "root" to the new user/group (e. g. - "csuser/csgroup") by executing the command 'chown -R csuser:csgroup <serverRoot>'.
  7. Logout as "root".
  
  
• The following commands must be executed as the new user (e. g. - "csuser"):
  
  
  8. Login as the new user (e. g. - "csuser").
  9. Change directory into the <serverRoot> by executing the command 'cd <serverRoot>'.
  10. Install the initial RHCS 7.1 instance by executing the command './setup/setup'.
      
      
      1. When asked to specify a Directory Server user, specify the new user (e. g. - "csuser").
      2. When asked to specify a Directory Server group, specify the new group (e. g. - "csgroup").
      3. When asked to specify a port for the Directory Server, be sure to specify an unused, non-privileged port (one greater than "1024").
      4. When asked to specify an Administration Server user, specify the new user (e. g. - "csuser").
      5. When asked to specify a port for the Administration Server, be sure to specify an unused, non-privileged port (one greater than "1024").
      6. Perform all future instance creations, configurations, and administration as the new user (e. g. - "csuser"); remember to always specify unused, non-privileged ports.
      
      
  11. Logout as the new user (e. g. - "csuser").

When installing RHCS 7.1 as non-"root" (Solaris platforms only):


• The following commands must still be executed as "root":
  
  
  1. Login as "root".
  2. Create a new group for RHCS (e. g. - "csgroup") by executing a command similar to '/usr/sbin/groupadd csgroup' specifying additional options as desired.
  3. Create a new user for RHCS (e. g. - "csuser") by executing a command similar to '/usr/sbin/useradd -c "RHCS User" -d <home_dir> -g csgroup -m csuser' specifying additional options as desired.
  4. Generate a password for the new user for RHCS (e. g. - "csuser") by executing a command similar to '/usr/bin/passwd csuser' specifying additional options as desired; enter the desired password(s) as prompted.
  5. Edit the "/etc/group" file, and append the new user (e. g. - "csuser") to the new group (e. g. - "csgroup"); for example, something that looks like 'csgroup::1517:csuser' where "::" indicates no password, and "1517" represents a sample group id.
  6. Logout as "root".
  
  
• The following commands must be executed as the new user (e. g. - "csuser"):
  
  
  7. Login as the new user (e. g. - "csuser").
  8. Download the 64-bit RHCS 7.1 (certificate-7.1-domestic-us.sparc-sun-solaris9-64.tar.gz) or the 32-bit RHCS 7.1 (certificate-7.1-domestic-us.sparc-sun-solaris9.tar.gz) as desired.
  9. Decompress the 64-bit RHCS 7.1 by executing a command similar to '/usr/bin/gunzip certificate-7.1-domestic-us.sparc-sun-solaris9-64.tar.gz' specifying additional options as desired, or the 32-bit RHCS 7.1 by executing a command similar to '/usr/bin/gunzip certificate-7.1-domestic-us.sparc-sun-solaris9.tar.gz' specifying additional options as desired.
  10. Unpack the 64-bit RHCS 7.1 by executing a command similar to '/usr/sbin/tar -xvf certificate-7.1-domestic-us.sparc-sun-solaris9-64.tar' specifying additional options as desired, or the 32-bit RHCS 7.1 by executing a command similar to '/usr/sbin/tar -xvf certificate-7.1-domestic-us.sparc-sun-solaris9.tar.gz' specifying additional options as desired.
  11. Install the initial RHCS 7.1 instance by executing the command './setup'.
      
      
      1. When asked to specify a Directory Server user, specify the new user (e. g. - "csuser").
      2. When asked to specify a Directory Server group, specify the new group (e. g. - "csgroup").
      3. When asked to specify a port for the Directory Server, be sure to specify an unused, non-privileged port (one greater than "1024").
      4. When asked to specify an Administration Server user, specify the new user (e. g. - "csuser").
      5. When asked to specify a port for the Administration Server, be sure to specify an unused, non-privileged port (one greater than "1024").
      6. Change directory into the <serverRoot> by executing the command 'cd <serverRoot>'.
      7. Perform all future instance creations, configurations, and administration as the new user (e. g. - "csuser"); remember to always specify unused, non-privileged ports.
      
      
  12. Logout as the new user (e. g. - "csuser").

Installing a New Version of Red Hat CS 7.1

If you do not have any previous installation of Certificate System, and you are not installing the software for Common Criteria purposes, follow the instructions above for installing the software. Otherwise, simply perform the following stages:

• Stage 1: Run the installation script (setup) to install administration and directory servers as necessary, and perform the initial phase of RHCS installation.

• Stage 2: Run the Installation Wizard to set up the initial configuration of the RHCS instance. This is where you specify which subsystems are to be part of this instance.

• Stage 3: Use Red Hat Console to further configure the new RHCS instance as needed. For example, you must provide it with information about the LDAP publishing and authentication directories.

• Stage 4: If you wish, use Red Hat Console to create additional instances of the Certificate System in the same server root directory, and use the Installation Wizard to configure them.

For information on installing and setting up a token key infrastructure, see the standalone document entitled Administrator's Guide Smartcard Addendum.

For end-user instructions for setting up the Enterprise Security Client, see the standalone document entitled Enterprise Security Client Guide.

Axalto Hardware Tokens

To purchase token hardware, go to Axalto's online store located at http://www.scmegastore.com. Navigate to the pages for buying "Cyberflex e-gate 32K with plug" and "e-gate Token Connector".

Using tksTool with an nCipher nethsm

tksTool can now be used to generate master keys on the nCipher nethsm. By default when trying to do so it throws warning messages like these:

        $ ./tksTool -M -n "xxx" -d /test/alias -h nethsm -p slapd-test-
        CKN (1112719856):    18139 000008CC Warning: Key type CKK_DES
        CKN (1112719856):    18139 000008CC Warning: key is considered weak; set
        CKNFAST_OVERRIDE_SECURITY_ASSURANCES=weak_des to allow
        CKN (1112719856):    18139 000008CC Warning: Key type CKK_DES
        CKN (1112719856):    18139 000008CC Warning: key is considered weak; set
        CKNFAST_OVERRIDE_SECURITY_ASSURANCES=weak_des to allow
        Enter Password or Pin for "nethsm":
        CKN (1112719859):    18139 000008D0 Warning: Key type CKK_DES
        CKN (1112719859):    18139 000008D0 Warning: key is considered weak; set
        CKNFAST_OVERRIDE_SECURITY_ASSURANCES=weak_des to allow
        CKN (1112719859):    18139 000008D0 Warning: Key type CKK_DES
        CKN (1112719859):    18139 000008D0 Warning: key is considered weak; set
        CKNFAST_OVERRIDE_SECURITY_ASSURANCES=weak_des to allow
 
        Generating and storing the master key on the specified token . . .
 
        CKN (1112719859):    18139 000008D3 Application error: Key type CKK_DES2
        CKN (1112719859):    18139 000008D3 Application error: Not allowing
        insecure token key; set CKNFAST_OVERRIDE_SECURITY_ASSURANCES=tokenkeys
        to allow tksTool -M:  unable to generate/store this DES2 master key
        :-8190
        

The simple way to overcome this would be to set the env variable:


export CKNFAST_OVERRIDE_SECURITY_ASSURANCES=tokenkeys

DRM Key Splitting Framework

RHCS 7.1 has a new feature in the DRM subsystem called 'acl based MofN key recovery scheme' which supersedes the old 'MofN key recovery scheme'. With this new scheme, DRM agents could use their certs to approve recovery requests as long as they are part of the DRM Recovery Agents group. But if the customer wishes to deploy the old MofN scheme, they need to follow this procedure:


1. create an instance of DRM
2. modify CertSetup.cfg and add kra.keySplitting=true
3. copy com.netscape.cmscore.shares.[JoinShares+Share].class from any post CMS 6.1 releases into <serverRoot>/bin/cert/classes/com/netscape/cmscore.shares

If this is a new customer that is not upgrading from any CMS 6.x, then please contact technical support to obtain those class files.

CMC Shared Secret

To specify an out-of-band shared secret for use with CMC, you must modify and recompile the source. For CMC, an out-of-band shared secret is involved in some of the control attributes. There is an interface called SharedSecret.class in the com.netscape.cms.authentication package. The administrator may modify the source code in SharedSecret.java, compile it, and install it in the <serverRoot>/bin/cert/classes/com/netscape/cms/authentication directory. The instructions on how to compile the codes are described in the RHCS SDK authentication tutorial.

The source code for SharedSecret.java looks like this:


/* CS_SDK_LICENSE_TEXT */

package com.netscape.cms.authentication;

import java.math.BigInteger;
import org.mozilla.jss.pkix.cmc.PKIData;
import com.netscape.certsrv.authentication.ISharedToken;

public class SharedSecret implements ISharedToken {

    public SharedSecret() {
    }

    //Implements this method to return the shared secret on the server side.
    public String getSharedToken(PKIData cmcdata) {
        return "testing";
    }

    //Implements this method to return the shared secret on the server side.
    public String getSharedToken(BigInteger serial) {
        return "testing";
    }
}

NISAuth Plug-in

Ignore references to the NISAuth plug-in in the Red Hat Console documentation. The Red Hat Console documentation includes some references to the NISAuth plug-in. This plug-in has been removed from this release. Please ignore all references to it.

Raidzilla Bug #34174: RHCS creates local database, even when user specified to use a remote database

Follow these steps to work around this problem:


1. Install an RHCS server as usual, specifying the use of a remote configuration directory).
   
   Unfortunately, the setupSDK will still prompt for a "local configuration directory" port number. This number must be different from the real configuration directory server if it exists on the same machine.


2. Launch Red Hat Console and select the configuration directory generated by the previous setup installation.


3. Right click the configuration directory, choose Remove Server, and answer Yes to the confirmation question. Click OK when success is reported.


4. Select the RHCS instance generated by the previous setup installation, and configure this instance as usual.


NOTE:   Use Red Hat Console to remove the superfluous configuration directory instance, but do NOT use the command line uninstall utility to select removal of the Directory Server component, as this will remove the Directory Server binaries required for RHCS configuration as well as the superfluous directory server instance.

Raidzilla Bug #40977: RFE cms61 console error msg for "server is unreachable"

When opening the RHCS console from the main console, the following error may appear:


The server is unreachable

To correct this problem, stop the console, cd to the .mcc directory located in your home directory, and remove the cert8.db, key3.db, and secmod.db files located here. Upon restarting the console, these files will be automatically regenerated correctly.

Raidzilla Bug #46209: OCSP publishing failed when CRL is large

If you are using OCSP with large CRLs, you may encounter this error:



CRLIssuingPoint MasterCRL - Failed to sign CRL
    java.lang.OutOfMemoryError


If you do see this error, adding more memory may solve the problem.

Raidzilla Bug #56391: CA : Bulk Revocation : Search hangs when searching from "Revoke Certificates" Page

This situation will cause the browser to hang:


• The CA has about 300,000 certificates.
• Go to the CA agent page and click Revoke Certificates.
• Search for some serial numbers like this:
  

  0x1000 - 0x2000 ( max rbs : 1000 )

Raidzilla Bug #57119: CA/DS : lunasa : unable to install CA cert through console

To enable LDAP with SSL with the server cert on the lunsa token, use the command-line utility called certutil (rather than the console) to add the CA cert to the appropriate security database.

Raidzilla Bug #57241: tksTool : unable to generate/store key on nCipher token

When tksTool is used to generate the Master key on an nCipher token, the following environment variable must be set (example is for "bash"):


export CKNFAST_OVERRIDE_SECURITY_ASSURANCES=tokenkeys

Raidzilla Bug #57313: cmc profile causes certs to have $request.requestor_email$

This problem prevents the browser from importing the certificate. To work around the problem, remove the SubjectAltName extension from the profile policies and save the configuration settings for the profile. When you then issue the CMC request, the issued certificate will be successfully imported to the certificate database.

Raidzilla Bug #57315: Missing # in the configuration file for CMCRequest

If you type CMCRequest on the command line in the bin/cert/tools directory, you'll see the usage (what the configuration file looks like) on the screen. You can then copy the content from the screen and paste it in anew file called CMCRequest.cfg as the configuration file, and make modifications for the parameter values.

When you run the command CMCRequest CMCRequest.cfg, you will get the following error:

Error in configuration file: certificate.

You should edit the configuration file and search for the line starting with certificate, then put the # in front of the word certificate. When you run the command again, it should work correctly.

Raidzilla Bug #57357: incorrect error message when trying to authorize a recovery that is done

The message "Credentials Exist" appears when trying to authorize a key recovery request thats already completed. The proper message should be "The key recovery you requested is already complete."

Raidzilla Bug #57368: kra.noOfRequiredRecoveryAgents accepts -ve values

The error message contains a typo that specifies an incorrect parameter called "noOfRequiredecoveryAgents". The correct parameter is called "noOfRequiredRecoveryAgents".

Raidzilla Bug #57402: CA : crl extensions : PrettyPrintCrl can't read issuingdistributionPoint extension - nullPointer

The PrettyPrintCrl tool throws a nullPointer Exception when encountering an unknown CRL extension like issuingDistributionPoint. In the event that this problem is encountered, use the command-line tool called dumpasn1.

Raidzilla Bug #57434: SHA-512 : Configuring CA using LunaSA fails when SHA-512 is used as the signing algorithm

Trying to configure a CA on RHEL with LunaSA 3.1 using the SHA-512 as the CA signing algorithm results in CA not being able to start after configuration is complete. CA complains that the Signature is bad on the server cert.

Raidzilla Bug #57479: Subject alt name for caTokenUserEncryptionKeyEnrollment profile doesn't work

Currently the certificate profiles caTokenUserEncryptionKeyEnrollment and caTempTokenUserEncryptionKeyEnrollment do not include the Subject Alternate Name Extension. In order to include it, you have to make sure to add the policy set (currently it is p6 in the given profile) corresponding to the subject alternate name extension to the policyset.set1.list. Make sure you put the p6 in the right position so that the numbers in the policyset.set1.list is in ascending order. Then you also need to fill in the values for the policyset.set1.p1.default.params.ldap.ldapconn.host and policyset.set1.p1.default.params.ldap.ldapconn.port parameters.

Raidzilla Bug #57496: TPS/DRM : when tps performs key archival the request looks wrong

1. setup tps/tks/drm to do server-side key gen
2. perform enrollment with correct ldap uid/password
Keys are archived in the drm, but can't be seen on the DRM agent page.

3. goto list request on the drm agent page
4. select type : 'show archival requests'. select status : 'show completed requests'. click find.
nothing shows up. But if you select 'show all requests' , you should see those archival requests.

Raidzilla Bug #57498: Firefox UI does not handle invalid password return code from the applet

If you use Firefox to manage the certificates on the token (go to Tools->Options, and then click Advanced in the Options dialog box and then select Manage Certificates), it will prompt you for the password. If you type in any invalid password (anything shorter than 4 characters), the firefox will not give you an error message saying invalid password. It still goes ahead and displays all your certificates on the token in the Certificate Manager dialog box. You will not be able to get access to the key and certificates from the token.

Raidzilla Bug #57514: should support HSM for generating key transport keys on TKS

TKS does not support generating key transport keys on a hardware token. It works on a software token only.

Raidzilla Bug #57526: NETHSM : unable to install server certs with AIA extension

If your certificate contains AIA extension, you will not be able to import the certificate on nethsm. For example, when installing TKS (Token Key Service), you will fail to import the SSL server certificate if the certificate is processed through the default caServerCert profile. The reason is that caServerCert profile will add the AIA extension to the SSL server certificate. The workaround is to remove the AIA extension from the caServerCert profile.

Raidzilla Bug #57534: Thunderbird : crashes when using the usb token

If you plug the egate token in and out, the thunderbird application may crash or stop recognizing the token. If it happens, it means the pcscd daemon crashes. You need to restart the pcscd daemon:


/PKCS11/egate_drivers/pcscd_restart

This happens on the Mac OS X 10.3 platform.

Raidzilla Bug #57538: ESC : on mac OS X crashes when visiting the TPS https web-site

The Mac ESC places its mozilla profile directory within the app bundle, "ESC.app/Contents/MacOS/Embed", where the NSS system places the security database.

If the database is populated with the SSL Server certificate of interest, both the ESC UI and ESC iteraction with the TPS will work just fine.

Raidzilla Bug #57539: TPS : tpsclient with 50 threads for enrollments runs into problems

The TPS client program (tpsclient) has problems to do enrollment with 50 threads. Some of the enrollments are not complete and some of them have errors.

Raidzilla Bug #57541: ESC: doesn't recognize multiple tokens

ESC does not recognize multiple tokens if you plugin more than one token to the USB hub. It recognizes one token only.

Raidzilla Bug #57542: TPS : cancelling enrollment operations a few times crashes TPS

During enrollment, the user may cancel the operation. The token processing system (TPS) may crash if the cancel operation is repeated for a few times. The TPS needs to be restarted and the token be re-formatted.

Raidzilla Bug #57545: Console : running setup without console - not working

Run setup to install Certificate System. The console binary will be installed even when you specify no console component during setup. The same console binary cannot be used to configure the Certificate System.

Raidzilla Bug #57570: TPS : need to add SSL support to the tokendb connection

There is currently no support for an SSL connection between TPS and the tokendb.

Raidzilla Bug #57571: TPS : authentication plugin - LDAPS - ssl doesn't work

TPS does not support LDAPS authentication to the authentication directory.

Raidzilla Bug #57580: ESC: first time token insertion detection problem

The first time you install the ESC client, the ESC will not recognize the token when the ESC client is first launched. You have to restart the ESC and it will then recognize the token.

This happens on windows platforms only.

Raidzilla Bug #57582: NES : servers not stopping properly. had to be killed by killing the process group

NES servers don't stop properly on Solaris-9. They have to be killed by killing the process group.

Raidzilla Bug #57584: RHCS : uninstall error and files left behind

Uninstall does not clean all the files in the <serverRoot> if you use "rpm -e" on RHEL, or "<serverRoot>/uninstall" on Solaris. You need to manually remove all the files left behind and probably kill all the running server processes.

Raidzilla Bug #57599: Token without applet not recognized on RHEL 4

On RHEL 4, if you are using an Axalto eGate Cyberflex 32k token that is a Webstore token, ESC does not recognize the version number of the applet and therefore doesn't recognize the token. If you encounter this problem, ask users to use ESC on Windows to format the token.

Raidzilla Bug #57617: TPS : create.pl : permission problems

1. Install RHCS rpm as root
2. Run create.pl as root
3. When asked for user/group give localuser/localgroup

After installation finishes, TPS tries to start up and runs as localuser/localgroup, but is not able to write to the logs directory because of permission problems.

To avoid this issue entirely, use "root"/"root" to match the Default Installation instructions as documented in the section entitled Installation Procedure using "root" (Default) , or "new user for RHCS"/"new group for RHCS" to match the Recommended Installation instructions as documented in the section entitled Installation Procedure using non-"root" User (Recommended).

Raidzilla Bug #57640: Unable to migrate DRM from 61sp4 to 71 --> old scheme to new scheme

RHCS 7.1 DRMs are unable to recover keys from an earlier migrated DRM.

An extra tool is needed to migrate the old key splitting scheme to the new one.

In the old scheme, the configuration wizard generated a PIN that is applied to the token via a password modify operation. The PIN can only be re-constructed with the help of the recovery agents.

In the new scheme, the PIN is not modified.

The tool needs to prompt for the recovery agent's passwords, and use the information in the kra-mn.conf to re-construct the token password. This tool is not available with this release.

Raidzilla Bug #57653: certutil with nethsm : displays multiple certs with the same subject name when given a unique nickname

The nethsm may contain several certificates with the same subject name but with different nicknames.

If certutil is used to display the certificate by giving a unique nickname, it displays all of those certificates that have the same subject name.

Raidzilla Bug #57658: TPS : agent page searches are not efficient.

To make them more efficient, create a new index as detailed in Red Hat Directory Server Administrator's Guide Chapter 10 Managing Indexes and add the following indexes manually:


• tokenUserID: Equality, Presence, and Substring checked
• tokenID: Equality, Presence, and Substring checked
• dateOfCreate: Equality, Presence, and Substring checked
• dateOfModify: Equality, Presence, and Substring checked
• userCertificate: Equality
• tokenSerial: Equality
• tokenKeyType: Equality

Raidzilla Bug #57661: certutil with nethsm : Cannot have two nicknames with the same cert

1. create a new cert/key db
   
2. use modutil and connect to nethsm
   
3. use certutil and create a self signing cert with nickname "cert-01" onto nethsm
   
4. use certutil and copy the base64 encoded cert for "cert-01" into a tempfile
   
5. use certutil and import 'tempfile' into nethsm with nickname "cert-02"
   
6. the old nickname cert-01 is deleted from nethsm. the new nickname cert-02 is available
   
7. workaround is to just change your servers to use the new nickname, "cert-02"

Raidzilla Bug #57662: nethsm : Can't install all subsystems on the same nethsm

Do not use automatic submission and retrievals of cert requests to the CA. Make sure that certs are installed without the CA chain when installing multiple subsystems on the same nethsm.

Raidzilla Bug #57667: DRM: Agent page - searchkeysforrecovery - max count doesn't work

Setting max count yields something similar to the following:


Assume there are five keys total.

If max count is set to four, the result page shows that the total is five, and the fifth one is undefined.

If max count is set to three, the result page shows that the total is four, and the fourth one is undefined.

Raidzilla Bug #57669: Server-side Key Gen: unable to do this on the clone environment

The clone DRM is missing this parameter:


kra.storageUnit.hardware=<HSM>

and it gives this error when performing server-side key generation:


EncryptionUnit::wrap java.security.InvalidKeyException: key to be wrapped does not live on the same token as the wrapping key

Raidzilla Bug #57674: Server-side Key Gen: additional parameters needed for hardware tokens

In the TKS configuration file CS.cfg, the following parameter 'tks.useSoftToken' could be set to 'true' or 'false'. default value for this parameter is 'true' meaning tks will use internal token for the crypto operations. When this parameter is set to false, tks won't be able to do crypto operations on the specified hsm.

Raidzilla Bug #57675: LUNASA: Luna not responding when under load

Sometimes when under load with multiple parallel threads, the lunasa will fail to return a correct response. Once it is in this state, the only way to fix it is to restart TKS. This problem is often encountered when doing multiple enrollment operations at the same time with the master key for TKS on the lunasa hardware.

Raidzilla Bug #57676: Server-side Key Gen: on lunasa : doesn't work

Server-side Key Generation doesn't work on a lunasa hardware token.

Raidzilla Bug #57683: TPS : enrollment fails with serversidekeygen. tpsclient with 10 threads

When performing Server side key generation for archival/recovery with TPS, some enrollments fail because TPS timesout connecting to the drm server because of load issues. The following parameter is not actually present in the TPS configuration file CS.cfg. This problem goes away if the conn.drm1.timeout parameter is set to a higher value, for example:


conn.drm1.timeout=25

Raidzilla Bug #57684: Enrollment crashes ESC if cert has critical CRL Distribution Point extension

ESC 1.1 does not support CRL Distribution Point Extension. Certificate profiles for the token enrollment in the CA subsystem have the CRL Distribution Point extension disabled by default.

Raidzilla Bug #57687: Encryption certificate on temporary token is in revoked_on_hold state

If CRL checking is turned on, then the user cannot use the encryption certificate on the temporary token because it is in the "revoke_on_hold" status. The workaround is to change the value for the following configuration parameter in TPS from true to false:


        op.enroll.userKey.keyGen.encryption.recovery.onHold.revokeCert=false
        

Then any new encryption certs that are created will not be put to the 'revoked_on_hold' state when the users token is marked 'temporarily lost'.

Documentation

---

For the latest information about Certificate System, including current Release Notes, technical notes, and deployment information, always check the Red Hat Certificate System site:

http://www.redhat.com/docs/manuals/cert-system/

The complete set of stand-alone Certificate System documentation for this release includes the following:

• Red Hat Certificate System Release Notes (this document) -- Contains information on new features of this release, software and hardware requirements for installing the product, important notes and known bugs, up-to-the-minute product information, and how to send feedback.
  
  
• Red Hat Certificate System Administrator's Guide -- Describes how to plan for, install, and administer Certificate System.
  
  
• Red Hat Certificate System Command-Line Tools Guide -- Provides detailed reference information on Certificate System command-line tools.
  
  
• Red Hat Certificate System Software Development Kit -- Provides detailed reference information consisting of product javadocs and HTTP-interfaces, actual plug-in code samples, and tutorial guidance to assist users in creating their own plug-in interfaces.
  
  
• Managing Servers with Red Hat Console -- Provides background information on basic cryptography concepts and the role of Red Hat Console.
  

• Red Hat Certificate System Agent's Guide -- Provides detailed reference information on RHCS agent interfaces. To access this information, click the help button from one of the Agent Services pages.
  

• Red Hat Certificate System End-Entity's Guide -- Provides detailed reference information on RHCS end-entity interfaces. To access this information, click the help button from one of the End-Entity Services pages.
  

• Red Hat Certificate System Console Online Help -- Provides detailed reference information on the Certificate System portion of the Red Hat Console. To access this information, click the help button from the Red Hat Certificate System Console.
  

• Red Hat Console Certificate System Installation Wizard Online Help -- Provides detailed reference information on the Certificate System Installation Wizard portion of the Red Hat Console. To access this information, click the help button from one of the Certificate System Installation Wizard process pages.
  

Copyright and Third-Party Acknowledgments

---

 

Copyrights and Third-Party Acknowledgments for portions of Certificate System 7.1 Clients include:

• Mozilla Foundation

USE AND AVAILABILITY OF OPEN SOURCE CODE.  Portions of the Product
were created using source code governed by the Mozilla Public License
(MPL).  The source code for the portions of the Product governed by
the MPL is available from http://www.mozilla.org under those licenses.

On Apple Mac OS X platforms only, ESC utilizes
version 0.8.3 of the Camino framework.  If any
problems are found in this specific distribution,
the user may obtain the source code and build
instructions for the very latest versions (and/or
potentially a binary image) at the following URL:

    http://www.caminobrowser.org/index.html

On Apple Mac OS X and RHEL platforms only, ESC
utilizes the latest version of the Gecko layout engine.
If any problems are found in this specific distribution,
the user may obtain the source code and build
instructions for the very latest versions (and/or
potentially a binary image) at the following URL:

    http://www.mozilla.org/newlayout/index.html

ESC also utilizes version v4.4.1 of the
Netscape Portable Runtime (NSPR) libraries from
the Mozilla Project.  If any problems are found
in these specific libraries, the user may obtain
the source code and build instructions for the
very latest version of these libraries (and/or
potentially binary images for newer versions) at
the following URL:

    http://www.mozilla.org/projects/nspr/index.html

ESC also utilizes version 3.9.3 of the
Network Security Services (NSS) libraries from the
Mozilla Project.  If any problems are found in these
specific libraries, the user may obtain the source
code and build instructions for the very latest
version of these libraries (and/or potentially binary
images for newer versions) at the following URL:

    http://www.mozilla.org/projects/security/pki/nss/index.html

• Additional ESC Smartcard Libraries and Modules

e-gate Smart Card Drivers for Windows 2000/XP Copyright (C) 
2002-2003 Schlumberger. All rights reserved.

e-gate Smart Card Driver for Mac OS X:

  Copyright (C) 2003 by Chaskiel Grundman  
  (C) 2003 by Philip Edelbrock  

  Significantly based on the Alladin etoken driver (the 
  T=1 code was not needed):
  (C) 2002 by Andreas Jellinghaus 
  (C) 2002 by Olaf Kirch 

  See license terms below for your rights on both parts.

  Some header files are from the pcsclite distribution:
  Copyright (C) 1999 David Corcoran 


MUSCLE smartcard middleware and applets Copyright (C) 1999-2002 
David Corcoran  (C) 2002 Schlumberger 
Network Solutions  All rights reserved.


The following license terms govern the identified modules and 
libraries:

e-gate Smart Card Drivers for Windows 2000/XP:

Limited Warranty/ Exclusive Remedies. Schlumberger warrants 
to the benefit of Customer only, for a term of sixty (60) 
days from the date of acquisition of the e-gate Smart Card 
("Warranty Term"), that if operated as directed under normal 
use and service, the Software will substantially perform the 
functions described in its applicable documentation. 
Schlumberger does not warrant that the Software will meet 
Customer's requirements or will operate in combinations 
that Customer may select for use, or that the operation 
of the Software will be uninterrupted or error-free, or 
that all Software errors will be corrected. Schlumberger's 
sole obligation and liability under this limited warranty 
shall be, at Schlumberger's option, to remedy any substantial
 non-performance of the Software to the functional 
descriptions set forth in its applicable documentation. 
If Schlumberger is unable to satisfy the foregoing limited 
warranty obligations during the Warranty Term, then 
Schlumberger shall, upon Customer's written request for 
termination of this Agreement, refund to Customer all sums 
paid to Schlumberger for the licensing of the Software 
hereunder. These are Customer's sole and exclusive remedies 
for any breach of warranty.
 
WARRANTY DISCLAIMER. EXCEPT FOR THE EXPRESS LIMITED WARRANTY 
SET FORTH IN SECTION 5 ABOVE, THE SOFTWARE IS PROVIDED AS 
IS. SCHLUMBERGER AND ITS SUPPLIERS MAKE NO OTHER EXPRESS 
WARRANTIES. TO THE EXTENT AUTHORIZED BY APPLICABLE LAW, 
ALL OTHER WARRANTIES WHETHER EXPRESS, IMPLIED OR STATUTORY, 
INCLUDING WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF 
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND 
NONINFRINGEMENT, ARE SPECIFICALLY DISCLAIMED. THIS DISCLAIMER 
OF WARRANTY CONSTITUTES AN ESSENTIAL PART OF THIS AGREEMENT.
 
Limitation of Liability. Schlumberger's cumulative liability 
to Customer, or any third party, for loss or damages resulting 
from any claim, demand or action arising out of or relating to 
this Agreement or use of the Software ("Damages"), shall not 
exceed the net amount paid to Schlumberger for the licensing 
of the Software, in this case, the cost of the single e-gate 
Smart Card. In no event shall Schlumberger or any Supplier 
be liable for any indirect, incidental, special consequential 
or exemplary damages of any character, including, without 
limitation, damages for lost profits, goodwill, work stoppage, 
computer failure and all other commercial damages.


e-gate Smart Card Driver for Mac OS X:

Redistribution and use in source and binary forms, with or 
without modification, are permitted provided that the 
following conditions are met:
   
  * Redistributions of source code must retain the above 
    copyright notice, this list of conditions and the 
    following disclaimer.
  * Redistributions in binary form must reproduce the above 
    copyright notice, this list of conditions and the 
    following disclaimer in the documentation and/or other  
    materials provided with the distribution.
  * The names of its contributors may not be used to endorse 
    or promote products derived from this software without 
    specific prior written permission.
       
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 
CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, 
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE  
DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE  
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,  
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,  
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED   
AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT  
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING   
IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF 
THE POSSIBILITY OF SUCH DAMAGE.


MUSCLE smart card middleware and applets:

Redistribution and use in source and binary forms, with or 
without modification, are permitted provided that the following 
conditions are met:

1. Redistributions of source code must retain the above 
   copyright notice, this list of conditions and the following 
   disclaimer.
2. Redistributions in binary form must reproduce the above 
   copyright notice, this list of conditions and the following 
   disclaimer in the documentation and/or other materials 
   provided with the distribution.
3. The name of the author may not be used to endorse or promote 
   products derived from this software without specific prior 
   written permission.

THIS SOFTWARE IS PROVIDED BY THE AUTHOR "AS IS" AND ANY 
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED 
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL 
THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, 
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, 
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 
SUCH DAMAGE.

Copyrights and Third-Party Acknowledgments for portions of Certificate System 7.1 Servers include:

• Apache Software Foundation
  

RHCS uses many components made available from Apache.  XML project jars are
as follows:  crimson.jar and xalan.jar.  These are available at the
following URL:

    http://xml.apache.org/

The Tomcat project jar files are as follows:  servlet.jar, and
jakarta-naming.jar.  These are available at the following URL:

    http://jakarta.apache.org/tomcat/index.html

• IBM

On RHEL platforms only, RHCS includes the 32-bit version
of the IBM JRE 1.4.2. Binary distributions of this
distribution are available at the following URL:

    http://www-106.ibm.com/developerworks/java/jdk/linux140/index.html

• Mozilla Foundation

RHCS utilizes version 3.6 of the
Java Security Services (JSS) libraries from the
Mozilla Project.  If any problems are found in
these specific libraries, the user may obtain
the source code and build instructions for the
very latest version of these libraries (and/or
potentially binary images for newer versions)
at the following URL:

    http://www.mozilla.org/projects/security/pki/jss/index.html

RHCS also utilizes version v4.4.1 of the
Netscape Portable Runtime (NSPR) libraries from
the Mozilla Project.  If any problems are found
in these specific libraries, the user may obtain
the source code and build instructions for the
very latest version of these libraries (and/or
potentially binary images for newer versions) at
the following URL:

    http://www.mozilla.org/projects/nspr/index.html

Additionally, RHCS utilizes version 3.9.3 of the
Network Security Services (NSS) libraries from the
Mozilla Project.  If any problems are found in these
specific libraries, the user may obtain the source
code and build instructions for the very latest
version of these libraries (and/or potentially binary
images for newer versions) at the following URL:

    http://www.mozilla.org/projects/security/pki/nss/index.html

RHCS includes a set of compiled binaries (from NSS 3.9.3)
of several tools from the Mozilla Project provided for the
convenience of the user.  This includes "certutil",
"cmsutil", "modutil", "pk12util", "signtool", "signver",
and "ssltap".  If any problems are found in these specific
tools, the user may obtain the source code and build
instructions for the very latest version of this tool
(and/or potentially a binary image for the newer tool) at
the following URL:

    http://www.mozilla.org/projects/security/pki/nss/tools/index.html

Finally, RHCS includes version 1.5 R3 of Rhino Javascript for
Java.  If any problems are found in this specific distribution,
the user may obtain the source code and build instructions
for the very latest version (and/or potentially a binary
image) at the following URL:

    http://www.mozilla.org/rhino/index.html

• Perl

RHCS uses Perl version 5.6.1.  Perl is ubiquitous.

• Red Hat

RHCS embeds a complete Red Hat Directory Server 7.1 binary and
makes the open source portion available at the following URL:

    https://rhn.redhat.com

    [ NOTE: For third-party components that are ]
    [       part of DS 7.1, see details below.  ]

• SourceForge

RHCS bundles version 1.15 of jikes. The source (and potentially a
binary image) is available at the following URL:

    http://jikes.sourceforge.net

• dumpasn1

RHCS includes compiled binary version of this code and its
corresponding configuration file to dump the contents of
a BINARY BASE 64 blob.  It is compiled during the course of
building the RHCS binary on a per-platform basis, and since
it is merely provided as an added convenience, there are no
extra charges or costs due to the use of this code. Executing
the code from the command line, the following line is displayed:

    Copyright Peter Gutmann 1997, 1998.  Last updated 27 July 1998.

The original source code is freely available from:

    http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c

Likewise, the configuration file is freely available at:

    http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.cfg

• info-ZIP

RHCS incorporates compression code from the Info-ZIP group.
The CSBackup.pl script utilizes version 2.3 (November 29th 1999)
of the "zip" utility to create zip files for archival purposes,
while the CSRestore.pl script utilizes version 5.42 of 14 January 2001
of the "unzip" utility to restore the contents of these zip files back
to an instance of RHCS.  There are no extra charges or costs due to the
use of this code, and the original compression sources are freely
available from:

    http://www.info-zip.org

Copyrights and Third-Party Acknowledgments for portions of the embedded Directory Server 7.1 Servers include:

• IBM

DS uses ICU version 2.4.  The ICU project page is here:

    http://www.ibm.com/software/globalization/icu/

The source code for ICU version 2.4 is available here:

    ftp://ftp.software.ibm.com/software/globalization/icu/2.4/icu-2.4.tgz

On RHEL platforms only, DS includes the 32-bit version
of the IBM JRE 1.4.2. Binary distributions of this
distribution are available at the following URL:

    http://www-106.ibm.com/developerworks/java/jdk/linux140/index.html

• Mozilla Foundation

As bundled with RHCS, DS utilizes version 3.6 of the
Java Security Services (JSS) libraries from the
Mozilla Project.  If any problems are found in
these specific libraries, the user may obtain
the source code and build instructions for the
very latest version of these libraries (and/or
potentially binary images for newer versions)
at the following URL:

    http://www.mozilla.org/projects/security/pki/jss/index.html

DS also utilizes version v4.4.1 of the
Netscape Portable Runtime (NSPR) libraries from
the Mozilla Project.  If any problems are found
in these specific libraries, the user may obtain
the source code and build instructions for the
very latest version of these libraries (and/or
potentially binary images for newer versions) at
the following URL:

    http://www.mozilla.org/projects/nspr/index.html

Additionally, DS utilizes version 3.9.3 of the
Network Security Services (NSS) libraries from the
Mozilla Project.  If any problems are found in these
specific libraries, the user may obtain the source
code and build instructions for the very latest
version of these libraries (and/or potentially binary
images for newer versions) at the following URL:

    http://www.mozilla.org/projects/security/pki/nss/index.html

DS includes a set of compiled binaries (from NSS 3.9.3)
of several tools from the Mozilla Project provided for the
convenience of the user.  This includes "certutil",
"cmsutil", "modutil", "pk12util", "signtool", "signver",
and "ssltap".  If any problems are found in these specific
tools, the user may obtain the source code and build
instructions for the very latest version of this tool
(and/or potentially a binary image for the newer tool) at
the following URL:

    http://www.mozilla.org/projects/security/pki/nss/tools/index.html

DS uses the Mozilla LDAP C SDK version 5.16.  This includes
the runtime shared libraries, command line tools such as "ldapsearch",
"ldapmodify", "ldapdelete", et. al., and the header files.  The
project page lists source and binary download locations at the
following URL:

    http://www.mozilla.org/directory/csdk.html

• Sleepycat (Berkeley DB)
  

DS uses Berkeley DB version 4.2.52 from Sleepycat Software.  The
product information page is at the following URL:

    http://www.sleepycat.com/products/db.shtml

The source code and required patches may be obtained at the following URL:

    http://www.sleepycat.com/download/index.shtml

• Carnegie Mellon - Project Cyrus

DS uses Cyrus SASL version 2.1.20 from Project Cyrus at Carnegie Mellon
University.  The project page is at the following URL:

    http://asg.web.cmu.edu/sasl/

The source code can be obtained at the following URL:

    ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/cyrus-sasl-2.1.20.tar.gz

• Net-SNMP

DS uses Net-SNMP version 5.2.1.  The project page is at the following
URL:

    http://www.net-snmp.org/

Source and binaries can be obtained at the following URL:

    http://www.net-snmp.org/download.html

• Apache Software Foundation
  

DS uses many components made available from Apache.  XML project jars are
as follows: crimson.jar, xalan.jar, xerces.jar.  These are available at
the following URL:

    http://xml.apache.org/

The Tomcat project jar files are as follows: servlet.jar, servlet-2.3-filters-api.jar,
jakarta-naming.jar, servlet-2.3-session-activation-api.jar, jspengine.jar.
These are available at the following URL:

    http://jakarta.apache.org/tomcat/index.html

• Sun Microsystems
  

DS uses the Java API for XML Processing (JAXP) from Sun Microsystems.
This is available at the following URL:

    http://java.sun.com/xml/jaxp/

• Info-ZIP

DS incorporates compression code from the Info-ZIP group.
The DSBackup.pl script utilizes version 2.3 (November 29th 1999)
of the "zip" utility to create zip files for archival purposes.  There are no extra charges or costs due to the
use of this code, and the original compression sources are freely
available from:

    http://www.info-zip.org

• Perl

DS uses Perl version 5.6.1.  Perl is ubiquitous.

---

© 2001 Sun Microsystems, Inc. Used by permission. © 2005 Red Hat, Inc. All rights reserved.

last updated May 27, 2005