Etrust PKI Admin Guide

eTrust PKI
Administrator Guide
2.0
This documentation and related computer software program (hereinafter referred to as the Documentation) is for the end users informational purposes only and is subject to change or withdrawal by Computer Associates International, Inc. (CA) at any time. This documentation may not be copied, transferred, reproduced, disclosed or duplicated, in whole or in part, without the prior written consent of CA. This documentation is proprietary information of CA and protected by the copyright laws of the United States and international treaties. Notwithstanding the foregoing, licensed users may print a reasonable number of copies of this documentation for their own internal use, provided that all CA copyright notices and legends are affixed to each reproduced copy. Only authorized employees, consultants, or agents of the user who are bound by the confidentiality provisions of the license for the software are permitted to have access to such copies. This right to print copies is limited to the period during which the license for the product remains in full force and effect. Should the license terminate for any reason, it shall be the users responsibility to return to CA the reproduced copies or to certify to CA that same have been destroyed. To the extent permitted by applicable law, CA provides this documentation as is without warranty of any kind, including without limitation, any implied warranties of merchantability, fitness for a particular purpose or noninfringement. In no event will CA be liable to the end user or any third party for any loss or damage, direct or indirect, from the use of this documentation, including without limitation, lost profits, business interruption, goodwill, or lost data, even if CA is expressly advised of such loss or damage. The use of any product referenced in this documentation and this documentation is governed by the end users applicable license agreement. The manufacturer of this documentation is Computer Associates International, Inc. Provided with Restricted Rights as set forth in 48 C.F.R. Section 12.212, 48 C.F.R. Sections 52.227-19(c)(1) and (2) or DFARS Section 252.227-7013(c)(1)(ii) or applicable successor provisions.
2002 Computer Associates International, Inc.

All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.
Contents
Chapter 1: Introduction
PKI Capabilities .............................................................................. Hardware Support ........................................................................ PKI Components ............................................................................. Certificate Authority (CA) Server ........................................................... Registration Authority (RA) Server ......................................................... Web Enrolment Server..................................................................... Registration Authority (RA) Client .......................................................... End Entity Software ....................................................................... Certificate Database ....................................................................... Certificate Repository ..................................................................... CA Configuration Repository .................................................................. Configuration Manager .................................................................... 1-1 1-2 1-2 1-2 1-2 1-3 1-3 1-3 1-4 1-4 1-4 1-5
Chapter 2: Setting Up eTrust PKI

Scaling eTrust PKIthe Tiered CA Approach ................................................... 2-1 Advantages of Scaling ..................................................................... 2-2 Setting Up a CA/RA Host ..................................................................... 2-2 Starting the CA/RA Servers ................................................................... 2-3 Setting Up the Servers to Start Automatically ................................................ 2-4 Setting Up a Distributed RA Client ............................................................. 2-5 Task 1Creating Remote RA Client Configuration Information ............................... 2-5 Task 2Deploying the RAC Operators...................................................... 2-6 Task 3Installing the Remote RA Client .................................................... 2-6 Task 4Loading the Remote RA Client onto a Machine ...................................... 2-7 Installing a Distributed End Entity Client ....................................................... 2-8 Task 1Creating End Entity Configuration Information ...................................... 2-8 Task 2Deployment of the End Entity Tier .................................................. 2-9 Task 3Installing the End Entity Client on the Distributed Machine ........................... 2-9 Task 4Loading the End Entity Configuration onto the Target Machine ...................... 2-10
Contents
iii
Installing a Subordinate CA/RA Tier ........................................................... 2-11 Task 1Creating Subordinate CA/RA Tier Configuration Information ........................ 2-11 Task 2Deploying the Subordinate CA/RA Tier ............................................ 2-12 Task 3Installing the Subordinate CA/RA Tier ............................................. 2-12 Task 4Loading the Configuration onto the Target Machine ................................. 2-13
Chapter 3: Using eTrust PKI

Logging In .................................................................................... 3-1 Starting the RA Client ......................................................................... 3-2 Issuing Certificates ............................................................................ 3-3 Certificate Issuing Methods ................................................................. 3-3 Creating a Certificate Request............................................................... 3-4 Revoking a Certificate ......................................................................... 3-8 Renewing Certificates......................................................................... 3-10 Recovering a Private Key ..................................................................... 3-11 Reporting on the Archived Data ............................................................... 3-12 Standard Reports ......................................................................... 3-12 Creating and Saving a Customized Report .................................................. 3-12 Using Certificate Profiles ...................................................................... 3-13 Viewing Profiles ............................................................................. 3-14 Editing Profiles .............................................................................. 3-14 Backing Up Private Keys ...................................................................... 3-15 Backing Up Your Configuration ............................................................... 3-16 Recovering Your Configuration Data ....................................................... 3-17
Chapter 4: Certification Authority Rollover

Setting Up Rollover............................................................................ 4-1 CA Key Rollover .............................................................................. 4-3 Background ............................................................................... 4-3 Further Information ....................................................................... 4-4
iv
eTrust PKI Administrator Guide
Chapter 5: Web Enrolment

Configuring Web Enrolment ................................................................... 5-1 Starting the Web Enrolment Server ............................................................. 5-2 Issuing a CertificateWorkflow ............................................................... 5-3 User Tasks ................................................................................... 5-4 Requesting a New Certificate............................................................... 5-5 Requesting that a Certificate be Renewed .................................................... 5-6 Requesting that a Private Key be Recovered ................................................. 5-7 Requesting that a Certificate be Revoked .................................................... 5-8 Web Enrolment RA Operator Tasks............................................................. 5-9 Creating a Certificate ...................................................................... 5-9 Recovering a Private Key ................................................................. 5-10 Revoking a Certificate .................................................................... 5-11 Renewing a Certificate .................................................................... 5-12 Viewing Web Enrolment Activity .......................................................... 5-13 Customizing the Web Enrolment Interface ..................................................... 5-15 Customizing the eTrust PKI Workflow Logo ................................................ 5-15 Customizing the eTrust PKI Workflow Style Sheet .......................................... 5-15 Customizing the eTrust PKI Workflow Home Screen ........................................ 5-16 Customizing the Group Drop Down List ................................................... 5-16
Chapter 6: Batch Processing

Using the PKI Batch Tool ...................................................................... Creating Certificates in Batch Mode ............................................................ Revoking Certificates in Batch Mode ............................................................ Renewing Certificates in Batch Mode ........................................................... Specifying the File Name and Path ............................................................. Creating a CRL on Demand .................................................................... 6-2 6-3 6-5 6-5 6-6 6-6
Contents
Chapter 7: Software Development Kit (SDK)

Central Concepts .............................................................................. 7-1 Keys ..................................................................................... 7-1 Certificates ................................................................................ 7-2 Cryptographic Providers ................................................................... 7-2 Core Functionality............................................................................. 7-3 Encrypting/Decrypting .................................................................... 7-3 Signing/Verifying ......................................................................... 7-4 Validating Certificates ..................................................................... 7-5 Extracting Certificate Details ................................................................... 7-6 The ETCER Configuration Object ............................................................... 7-6 Setting Properties .......................................................................... 7-6 The Default Section ........................................................................ 7-7 The OCSP Section ......................................................................... 7-7 The Provider Sections ...................................................................... 7-8
Chapter 8: Setting Up HSMs

Setting Up Eracom CSA7000 and CSA8000 HSMs ................................................ 8-1 Saving a Certificate in the Adapter .......................................................... 8-2 Setting Up GemPlus GemPKCS SDKv3 Smartcards ............................................... 8-3 Saving a Certificate on the Smart Card ....................................................... 8-3 Setting Up GemPlus GemSAFE Smartcards ...................................................... 8-5 Saving the Root Certificate on the Smart Card ................................................ 8-5 Setting Up Rainbow iKey 2000 USB Key Tokens ................................................ 8-7 Saving the Root Certificate in the Token ..................................................... 8-7 Setting Up Datakey Smartcards ................................................................. 8-9 Saving the Root Certificate to a Token ...................................................... 8-10 Setting up a Chrysalis HSM ................................................................... 8-11 Task 1Install Software................................................................... 8-11 Task 2Installing the Hardware ........................................................... 8-12 Task 3Testing the Install................................................................. 8-12 Task 4Enabling the Token and Setting Up the PED Keys ................................... 8-13 Saving the Root Certificate ................................................................ 8-14 Saving a Certificate Through the RA Client ................................................. 8-14 Setting Up a GemPlus GemSAFE 3.0 Smartcard ................................................. 8-15 Saving the Root Certificate ................................................................ 8-15 Saving a Certificate Through the RA Client ................................................. 8-16
vi
Chapter 9: Cross Certification

Cross Certification Theory ..................................................................... Publishing Cross Certificates ............................................................... Cross Certification Options ................................................................ Possible Problems with Cross Certification .................................................. Cross Certifying with Another CA.............................................................. Task 1Copying the Public Key............................................................ Task 2Cross Certifying .................................................................. 9-1 9-1 9-2 9-2 9-3 9-3 9-4
Glossary
Contents
vii
Chapter
Introduction
eTrust PKI issues and maintains digital certificates. Digital certificates provide an assured binding of the name of a person or system to a public key; they are a critical part of a public key infrastructure (PKI). eTrust PKI publishes completed digital certificates and certificate revocation lists (CRLs) in a directory. eTrust Directory is the recommended directory, but eTrust PKI will work with any fully LDAP-compliant directory. eTrust PKI can publish CRLs, but it does not rely on them entirely. It can also update the directory whenever a certificate is revokedthis allows the use of eTrust OCSPro for true online certificate status reporting.
PKI Capabilities
eTrust PKI includes eTrust Directory and eTrust OCSPro. eTrust PKI supports the important PKI public standards, including x.509, PKIX standards, and PKCS standards. This provides interoperability for PKI implementations. The administrator can use the Configuration Manager to set up the eTrust PKI security controls to be: Extremely secure Relaxed for less stringent environments
eTrust PKI can be scaled for large environments through the establishing of tiers of Certificate Authority/Registration Authority pairs.
Introduction
11
PKI Components
Hardware Support
eTrust PKI supports key generation and certificate storage on a range of hardware devices by a range of different vendors. Hardware support is by way of PKCS#11, the accepted hardware interface standard. Hardware support includes: Chrysalis-its Luna CA3 Data Key EraCom CSA 7000/8000 HSM GemPlus GPK8000 - Smartcard & GEMSAFE smartcards Rainbow iKey 2000 USB key token
PKI Components
eTrust PKI has several components. These can be installed on different machines, or on the same machine, providing flexibility of configuration.
Certificate Authority (CA) Server

The CA server signs the certificates. It is literally the key to everythingit holds the key used in signing. You must make the CA server physically secure.
Registration Authority (RA) Server

This component is the central server. The RA server: Holds the database describing the certificates that are currently in progress Publishes certificates and CRLs to a directory Communicates with: The CA server to get signatures RA clients to issue and revoke certificates End entity software to accept certificate requests Third party RA servers to chain requests and relay responses to requests
12
PKI Components
Web Enrolment Server

This component provides a web interface between the users and the RA server. The web enrolment server allows the RA operator to issue and maintain certificates for the users without the users being physically present.
Registration Authority (RA) Client

Operators use the RA client to issue and revoke certificates. It is a GUI designed to be used by a minimally trained operator. Use the Configuration Manager policy controls to customize the functionality of the RA client. The RA client communicates with the RA server to: Obtain profiles Obtain data to produce reports Submit certificate issuances Submit certificate revocations
The RA client supports both background batch processes and a foreground wizard-based GUI. The GUI provides direct control; the batch processes are provided for bulk and automated processing. The RA client is a Java GUI that requires the Java Run Time Libraries to be installed on the client machine.
End Entity Software

When issuing a certificate request, the RA operator provides the end entity client software to the user. This software can generate a key-pair, bundle the public key with the rest of the certificate request, and interact with the RA server to get the certificate signed. The end entity client is a Java GUI that requires that the Java Run Time Libraries are installed on the client machine. Tip: For a completely web based certificate issuance tie the batch processes of an RA client to a Windows based web server. There are many web scripting techniques (for example CGI).
Introduction
13
CA Configuration Repository
Certificate Database
The certificate database: Stores requests that are in progress (the user has requested the certificate and received the package, but has yet to return the request with the public key) Contains information on the revoked certificates Stores information from the tiers
This information can be used to generate reports.
Certificate Repository
The certificate repository is a directory service used to publish certificates and CRLs. The interface to the directory uses LDAP connecting to eTrust Directory. This allows access to any directory that offers a fully compliant LDAP interface.
The CA configuration repository is a directory service used to store distributed configuration settings for all PKI components within a defined infrastructure. The only directory supported as the administrative repository is eTrust Directory. This is for reasons of security and distribution. The administrative repository is separated from the publication directory. This allows you to choose eTrust Directory, or a third party directory, as the directory used to publish certificates.
14
Configuration Manager
The configuration manager allows the administrator to control the servers, and the general operation of the system. This includes stopping the servers, and changing the key-pairs available for signing certificates. The Configuration Manager also provides a GUI for controlling the configuration of subordinate tiers. The Configuration Manager communicates locally or remotely with any component by altering the configuration settings in the configuration directory. This allows the central rollout, administration, and maintenance of any component in the infrastructure.
Introduction
15
Chapter
Setting Up eTrust PKI

This chapter discusses how to set up eTrust PKI. eTrust PKI can be set up on: A single host machine In a tier to handle large configurations
Scaling eTrust PKIthe Tiered CA Approach

A system that will handle extremely large numbers must be designed to accommodate scaling. The approach we advocate is to replicate the CA/RA cluster. There are two principles to this approach: The CA/RA pair are treated as a unit (they run on the same machine), and are replicated as such Every pair that is not a root node has its signing certificate signed by a parent
This requires only one modification to the existing designthe signing certificate is not necessarily self-signed. This is not a modification to the software, but rather to the setup processthe signing certificate is installed rather than generated.
21
Setting Up a CA/RA Host
Advantages of Scaling
The advantages of scaling are: You can continue to build on a working design. You can test the software more readilyit will not have different modes of operation depending on the scale of operations. Each CA/RA node is capable of independent operation. Failure of any node does not affect any other node. It is possible for a failing node to be covered by another nodethe RA clients can fail over from one RA server to another without loss of functionality. The load is split. The only commonality required is in the eTrust OCSPro responder, and that has excellent scalability already. Performance problems can be addressed by upgrading or splitting the node. This does not impact other areas. There is no communications load (except for the OCSP traffic), because there is no requirement for on-going connection between the replicated systems the connection is one of issuing certificates. The impact of a compromised CA key is limited to those certificates that include the compromised CA in their chain. To minimize exposure even further, the root CA can be restricted to issuing certificates for subordinate CAs, and can operate off-line. There is no limit to the scaling. A single root CA can issue signing certificates to a vast number of subordinate CAs. One subordinate CA can have its signing certificate signed by another subordinate CA, which in turn might have its certificate signed by the root CA, or even by another level of subordinate CA. This design does not complicate the SDK component. Signing chains are supported for certificates generated by other systems.
Setting Up a CA/RA Host

The CA/RA host was set up in the standard installation procedure. For details see the eTrust PKI Getting Started.
22
Starting the CA/RA Servers

To start up the CA/RA servers: 1. 2. Select Start, Programs, Computer Associates, eTrust PKI, Foreground CA/RA Servers. The Server Status Monitor dialog is displayed. Click the Start button. The CA and RA servers start.
23
Setting Up the Servers to Start Automatically

To set up the CA/RA servers to start automatically: 1. Select Start, Programs, Computer Associates, eTrust PKI, Server Administrative Tools, Install CA and RA Servers as Services. The Command dialog is displayed. Press Enter to complete installation. Right click My Computer and select Manage. Select Services and Applications, Services. Select eTrust PKI Services and click the Start Services button to enable the services.
2. 3. 4. 5.
The next time the computer is restarted, eTrust PKI Services will start automatically. Important! If the servers are running as services, they cannot start in the foreground.
24
Setting Up a Distributed RA Client

To set up remote RA clients to run with the root CA/RA tier, complete the following tasks.
Task 1Creating Remote RA Client Configuration Information

This task is performed on the CA/RA host. 1. 2. 3. Ensure that the foreground CA/RA servers are running. Select Start, Programs, Computer Associates, eTrust PKI, Configuration Manager, Configuration Manager. Select File, Connect, then enter the following data: 4. 5. 6. 7. 8. 9. 10. 11. 12. HOST: localhost PORT: 15389
Select Security Level SSL + SASL + Keystore Password from the drop down list. Enter the client keystore passphrase then click OK. Select the Root Tier node under the eTrust PKI node. Select the RAC Operators node under the Root CA node and click on the Registration Authority Clients tab in the right window. Click the Add New User button. Enter a name for the new RA User, for example, New RA and click Next. Enter the location of the default RAC key (the name of the key will reflect the name of the new RAC operator you entered) and click Next. Enter a key alias for the key and click Next. Enter a passphrase to protect the private key and click Finish.
25
Task 2Deploying the RAC Operators

This task is done on the CA/RA host. 1. 2. 3. 4. 5. 6. 7. Ensure that the foreground CA/RA servers are running. Select the RAC Operators node in the Configuration Manager tree structure. Select the Registration Authority Clients tab. Click Deploy Existing Users. The new RAC, along with any existing RAC, is deployed. A prompt is displayed asking where to save the new RAC. Create a new folder, for example, New RA. Select the new folder without opening it and press Save. A dialog is displayed asking you to enter the directory where your eTrust PKI files are installed on the computer that houses the remote RA Client. The default path for eTrust PKI installations is: C:\Progra~1\CA\eTrust PKI\. Note the location of the files and click OK. The RAC Operator deployment is completed.
8.
Task 3Installing the Remote RA Client

This task is done on the remote RA client. 1. 2. 3. 4. 5. Load the Product Explorer from the eTrust PKI CD onto the computer that the remote RA client will be installed on. Install the Java Runtime Environment from the supporting products folder. Select eTrust PKI from the Product Explorer and click Install. Choose Custom Install. Separately select the CA and RA servers and EE client and choose 'This feature will not be available' so that only the RA client is available for install. Click Next and then Install.
6.
26
Task 4Loading the Remote RA Client onto a Machine

This task is done on the remote RA client. 1. 2. Access the saved RAC data files created in task 2, for example via floppy disk. Run MyConfig.bat. This is located in the folder you saved the new configuration data into, for example New RA.
You can now run the RA client of the remote machine with the servers running on the root machine.
27
Installing a Distributed End Entity Client

To install a distributed end entity client complete the following tasks.
Task 1Creating End Entity Configuration Information

This task is completed on the CA/RA host. 1. 2. Ensure that foreground CA/RA servers on the host computer are running. Select Start, Programs, Computer Associates, eTrust PKI, Configuration Manager, Configuration Manager. The Configuration Manager dialog is displayed. Select File, Connect, then enter the following data: HOST: localhost PORT: 15389 4. 5. 6. 7. Select security level SSL + SASL + Keystore password and enter the client keystore passphrase then select OK. Select the Root Tier Node, and click on the CA-RA Tier Container tab in the right window. Click the Add New Tier button. Enter the information needed to generate a new distributed end entity client. Enter the host's computer name (for example COMPUTER1) and the following port numbers: Screen CA Server RA Server 8. 9. Example Host Name COMPUTER1 COMPUTER1 Port Number 2001 2001
3.
Enter a DN for the computer the end entity client will be installed on. Enter a passphrase to protect all the client keys generated.
10. Enter a unique name for the CA/RA tier and click Finish.
28
Task 2Deployment of the End Entity Tier

This task is done on the CA/RA host. 1. 2. 3. 4. Ensure that the foreground CA/RA servers are running. Select the new CA tier node in the Configuration Manager tree structure. This is in the CA/RA tier just created. Select the CA/RA Tier tab. Click Deploy. A dialog appears prompting for the folder to save the new tier in. Create a new folder and another folder within the new folder. Select the second folder without opening it and press save. A dialog appears asking you to enter the folder on the machine with the remote RA client that you will install the eTrust PKI files in. The default path for PKI installations is: C:\Progra~1\CA\eTrust PKI\. Note the location of the files click OK. The End Entity Tier is deployed.
5. 6. 7.
8.
Task 3Installing the End Entity Client on the Distributed Machine

1. 2. 3. 4. 5. Load the Product Explorer from the eTrust PKI CD onto the computer the end entity client will be installed on. Install the Java Runtime Environment from the Supporting products folder. Select eTrust PKI from the Product Explorer and click Install. Choose Custom Install. Separately select the CA and RA servers and RA client and choose This feature will not be available' so that only the end entity client is available for install. Click Next and then Install.
6.
29
Task 4Loading the End Entity Configuration onto the Target Machine
1. 2. Access the folders created in task 2. Copy the main end entity folder and sub-folders onto the machine where you installed the end entity client. Do this via floppy disk or network connection.
Important: The following step must be done from the local hard drive. Do not try to do this over a network because the subordinate tier may not load properly. 3. Run MyConfig.bat located in the root of the Configuration folder. The existing certificate structure is replaced with the subordinate certificates.
210
Installing a Subordinate CA/RA Tier

To install a subordinate CA/RA tier complete the following tasks.
Task 1Creating Subordinate CA/RA Tier Configuration Information

The task is done on the CA/RA host. 1. 2. 3. Ensure that the Foreground CA/RA Servers on the host computer have been started. Select Start, Programs, Computer Associates, eTrust PKI, Configuration Manager, Configuration Manager. The Configuration Manager is displayed. Select File, Connect, then enter the following data: HOST: localhost PORT: 15389 4. 5. 6. 7. Select SSL + SASL + Keystore Password and enter the default_administrator passphrase then click OK. Select the Root Tier node, and click on the CA-RA Tier Container tab in the right window. Click the Add New Tier button. On the CA-RA Tier tab, enter the information needed to generate a subordinate CA/RA tier. Enter the remote machine name as the CA and RA servers. Screen CA Server RA Server 8. 9. Host Name REMOTEMACHINENAME REMOTEMACHINENAME Port Number 2001 2001
Enter a DN for the computer you will install the subordinate CA/RA tier on. Enter a passphrase to protect the client keys generated.
10. Enter a unique name for the CA/RA tier an click Finish.
211
Task 2Deploying the Subordinate CA/RA Tier

In this task you will deploy the configuration files and certificates (from the CA/RA host with the CA/RA Servers running) to run on the subordinate machine 1. 2. 3. 4. 5. 6. Create a folder to save the configuration data in, then create a second folder within that one. Select the Configuration Manager tree structure and expand the tier created in Task 1. Select the CA Tier node. Select the CA/RA tier tab in the right hand window and click the Deploy button. A dialog box appears prompting for a directory to save into. Selected the second folder created in Step 1 without opening it and press Save. A dialog is displayed asking for the folder on the machine the subordinate tier eTrust PKI files will be installed in. The default is: C:\PROGRA~1\CA\eTrust PKI\. When the certificates are generated and saved, Done! appears next to the Deploy button.
7.
Task 3Installing the Subordinate CA/RA Tier

1. 2. 3. 4. Load the Product Explorer from the eTrust PKI CD onto the computer the subordinate CA/RA tier will be installed on. Install the Java Runtime Environment from the supporting products folder. Select eTrust PKI from the Product Explorer and click Install. Choose Complete Install.
Important: If you choose a custom install you must install all products for the Subordinate CA/RA Tier to work. 5. 6. Click Next and then Install. After the reboot, run the PKI configuration.
212
Task 4Loading the Configuration onto the Target Machine

1. 2. Access the folders created in task 2. Copy the main subordinate tier folder and sub-folders onto the machine where you installed eTrust PKI as a subordinate CA/RA Tier. Do this via floppy disk or network connection.
Important: The following step must be done from the local hard drive. Do not try to do this over a network because the subordinate tier may not load properly. 3. Run MyConfig.bat located in the root of the Configuration folder. This replaces your existing certificate structure with the subordinate certificates.
213
Chapter
Using eTrust PKI

This chapter describes the main functions of eTrust PKI.
Logging In
You must log in before using eTrust PKI. The only commands accepted are Login and Cancel if: The program is first started The operator has logged out A defined time interval without operator activity has elapsed
The form of the login is determined by the policy set by the administrator. It consists of a: Certificate User ID Passphrase
Using eTrust PKI
31
Starting the RA Client

The RA client is the interface used to access: The day-to-day PKI functionality The administration of user certificates
To start the RA client: 1. 2. Log onto the computer that has the RA client loaded. The CA/RA services must be started before the RA client can run. If these services have not been set to automatically load when the computer is started, select Start, Programs, Computer Associates, eTrust PKI, Foreground CA/RA Services, then click Start to launch the services. Select Start, Programs, eTrust PKI, RA Client. The RA Client Logon Information dialog is displayed. Click Browse. The Load Key Store File dialog is displayed. Select the RA client operator p12 certificate (the default is defaultRAC_crt.p12) and click Open.
3. 4. 5.
32
6.
Enter the RA client operators passphrase and click Login. The RA client interface is displayed.
Using eTrust PKI
33
Issuing Certificates
Certificates are issued according to editable profiles set up by the CA administrator. Certificates can be issued: In DER, PEM, and PKCS#12 format. If required, certificates can be converted from PKCS#12 format to PEM format using SSL. For hardware such as: Smartcards USB tokens Cryptographic boards HSMs
Certificate Issuing Methods

There are two main methods of issuing certificates: In a single step at the RA client. This allows private encryption keys to be backed up to allow recovery of encrypted material. In stages: The user registers with an RA client They complete the generation of the keys at their own computer The generated public key is securely sent back to the RA server for inclusion into a certificate The completed certificate is returned to the user
Tip: Use the batch tools provided with eTrust PKI to automatically process a large number of certificates. Use the web enrolment interface to process certificates requests from remote users.
34
Creating a Certificate Request

When a user requires a certificate the process starts at the RA client. The RA client operator issues the user with a certificate request package after the users details are captured. The following tasks describe the capture process. When you request a certificate for the user you are guided through the data capture process by a wizard. This provides a structured process for handling the request. Task 1Processing a User Certificate Request Different organizations have different processesthe steps below are given as a guide. For a typical RA client operator to create a certificate for a user: 1. 2. The RA client operator checks the users credentials. The RA client operator can do one of the following: Create a new entry in the directory and issue a certificate. Any user can approach the RA client operator if they do not have an entry in the directory. It is expected that the RA client operator will also be able to add users to the directory. Search the directory for an existing user to use in certificate generation. PKI allows users that have an entry in the associated directory to have certificates created for them. The directory browser illustrated allows the RA client operator to search the directory and locate the user and their certificates.
Using eTrust PKI
35
Tip: Locating the user in the directory ensures that a valid distinguished name for the user is captured. It is simpler, and less error-prone, for the operator to locate the user in a directory than type in the distinguished name.
3. 4.
The RA client copies the users distinguished name (DN) from directory. The RA client operator chooses the certificate profile and signing key-pair. The operator must select a certificate profile for the request. The list of available certificate profiles is obtained from the RA server when the operator logs in. The certificate profile: Dictates the list of attributes assigned to the certificate Specifies fixed values for some fields Specifies default values for some fieldswhere default values are blank Enforces the fields that must be populated before the certificate process can proceed
For further information on the profile attributes, click Help.
36
Task 2Generating Certificate Items After the RA client operator has requested a certificate, the RA client generates the following list of items needed to complete the certificate request: A key-pair (if the encryption key-pair is to be generated by the PKI). The key-pair is optionally backed up. A message authentication code (if the user is to finish creating the certificate on their own machine). A session key (used to send the certificate request back to the RA client). An incomplete certificate that contains: The users identity The specification of choice of CA signing key-pair
Task 3Creating an RA Clients Package The RA client creates a package for the user that contains: End entity client softwareon the eTrust PKI CD-ROM An incomplete certificateon a floppy disk Configuration fileson a floppy disk Instructions for how the user is to complete the generation of the keys
The floppy contains the information needed by the end entity client software to complete the certificate request and submit it. The information on the floppy includes: The incomplete certificate The MAC session key The address of the RA server
One floppy can hold the information for more than one certificate request. This simplifies matters when generating multiple certificates for a single user. The end entity client software picks up all the certificate requests on the floppy disk, and will act on each of them. Important! A different floppy must be used for each user. The information is stored on the floppy by default. This default can be changed to transport the files via another medium, for example, email the files to the user.
Using eTrust PKI
37
Task 4Setting Up the End Entity Client The end entity client: 1. Generates a signing key-pair. If the user plans to store the certificate on a smart card, they will need to install the software for the smartcard reader before generating their key-pair. Generates an encryption key-pair (if applicable). Stores the private keys. 4. 5. 6. In software using PKCS#12 In smartcard or token or HSM
2. 3.
Places the public keys in an incomplete certificate. Constructs PKCS#10 request for the certificate. Transmits a request to the RA server, encrypted using the unique session key issued by RA client. The RA server validates the request, submits the complete certificate to the CA server for signing using the selected signing key, publishes the certificate in the directory using LDAP, and sends the signed certificate to the end entity client software. Saves the certificate, making it available for use with certificate enabled applications.
7.
38
Revoking a Certificate
There are many reasons why a certificate may be revoked. It may be due to a user becoming concerned that their certificate has been compromised, or because a person is no longer in the organization. The details of the revoked certificates are published in a generally accessible CRL and in the certificate status field held in the directory that contains the user details. To revoke a certificate: 1. 2. Select the Revoke a Certificate option from the RA client interface. Browse the Directory Information Tree (DIT) to locate the certificate to be revoked. You will need to select the specific certificate if multiple certificates have been issued to the user. The interface displays the details of the certificate to be revoked. This is to confirm that you have selected the correct certificate. Confirm both the identity of the certificates subject, and the exact certificate to be revoked. Under Revocation settings select the reason for revoking a certificate as well as how the administrator has been contacted. Tip: Select certificateHold as the revocation reason to revoke the certificate and provide a recovery option.
3.
Once the revocation is confirmed, the RA client notifies the RA server. The RA server marks the certificate as revoked in both the internal database, and in the directory. After the revocation is completed a dialog giving the option to update the CRL is displayed.
Using eTrust PKI
39
4.
Do one of the following: Click Yes to update the CRL immediately Click No to continue working without updating the CRL. You can update the CRL later with the RA Clients Generate CRL option. If your PKI uses certificate revocation lists, the lists are updated by this option.
Depending on the importance of the certificates being revoked, it may be better to wait until all the certificates have been revoked before updating the CRL. Tip: Use the batch tools provided with eTrust PKI to automatically revoke a large number of certificates. Use the web enrolment interface to revoke certificates from remote users.
310
Renewing Certificates
Renewing Certificates
A certificate must contain an expiry date. If a certificate expires and the private key has not been compromised, the certificate owner can apply to have the certificate renewed. The renewal process involves changing the expiry date and having the certificate signed again. The new expiry date of the certificate cannot be later than the expiry of the CA root certificate This option allows a customer to keep their existing set of keys and issue a new certificate for the next period. To renew a certificate: 1. 2. 3. 4. From the RA client interface, select the Renew a Certificate. The Renew a Certificate dialog is displayed. Use the Explore tab and the DIT to find the customer record. Open the customer folder and select certificateSerialNumber. Check that the certificate details match the ID presented by the user. The level of ID required is determined by the profile issued. Profiles for higher levels of security are likely to require the user to provide more ID. In Renewal Settings enter the date the new certificate expires. The date is in MM/DD/YYYY format. Click the Renew button. A dialog to confirm the renewal is displayed. Click Yes to proceed with the renewal. The RA server creates and signs a new version of the certificate. Save the new certificate onto a floppy disk and pass it to the user along with instructions on how to install it.
5. 6. 7. 8. 9.
10. The user can now install the new certificate onto their computer. Tip: Use the batch tools provided with eTrust PKI to automatically renew a large number of certificates. Use the web enrolment interface to renew certificates for remote users.
Using eTrust PKI
311
Recovering a Private Key

This task can only be performed if the private key is backed up on the CA server. The profile selected for certificate creation sets this option. If the user was given a partially completed certificate, which they then completed on their own computer, there was no opportunity for the private key to be backed up by the RA server. WARNING: This task could potentially allow an attacker to impersonate a legitimate user. As such, the use of this task should be limited to the eTrust PKI Administrator. Extra forms of ID may be required to verify the identity of the end user. Check with the CA Administrator for further details. 1. 2. 3. From the RA Client click Recover a Private Key. The Recover a Private Key dialog is displayed. Click the Refresh button to connect to update the directory information tree. Find the certificate to be recovered. Use the DIT with the Explore tab or enter the required name in the search box and click Search to do this. Open the folder and select certificateSerialNumber. Check that the certificate details match the ID presented by the user requesting the recovery. The ID requirements for this task may be higher than for other tasks, this is because an attacker may attempt to impersonate the certificate owner to gain the private key. Click the Recover button to continue. A confirmation dialog is displayed. Click Yes to proceed. Save the private key to a floppy disk and pass it to the user with instructions on how to install it. The private key can now be install onto the certificate owners computer.
4. 5.
6. 7. 8.
9.
312
Reporting on the Archived Data
Reporting on the Archived Data

This option allows you to run standard reports on the current status of the PKI users. You are also able to create your own reports by using SQL commands on the Ingres database.
Standard Reports
There are a number of standard reports installed with the default installation of the RA client. These include: The details for any certificates that have been revoked. The details for any unsigned certificates that have been given to end entities. Systems activity reports for the RA client, RA server, and CA server log. By default, the log files record warnings, information, and debug events. You can change the events recorded to suit your requirements.
To run a standard report, open the RA Client and click Report on the Archived Data.
Creating and Saving a Customized Report

To create customized reports: 1. 2. Click the Edit Reports button. Enter the name of the report, a name to be displayed on the button on the reporting interface, a short description of the report, and the SQL query required to extract the information from the database. Click Save.
3.
The report can be run by you or another RA client operator at a later date.
Using eTrust PKI
313
Using Certificate Profiles
Using Certificate Profiles

To create a certificate profile, select an existing template, edit it (optional), and save it as a new profile. The fully formed and usable certificate profile templates which are installed by default include: Generic Utility Certificate Signing Certificate Subordinate CA Certificate Encrypting Certificate Self Signed CA Certificate SSL Server Certificate Blank Certificate
You can select a profile that suits each applicant. The certificate profile determines: What fields are compulsory Default values The list of possible valid entries Whether the private / public key-pair is generated by the end entity client or by the RA client Whether the RA server is to retain a copy of the private key for backup purposes
314
Viewing Profiles
Viewing Profiles
The RA client operator can see the attributes available for each type of customer profile. Check with the eTrust PKI administrator before editing or creating new profiles. To view a profile: 1. 2. From the RA Client interface click View Profiles. Select a profile from the drop down box. Each profile has common attributes as well as a set of attributes that are personalized for that particular customer profile.
Tip: Use the Edit and Delete buttons to maintain your profiles while in view mode.
To keep previous versions of the profile, modify the version number each time a profile is modified. You can only select the latest version of a profile when issuing a certificate but all versions are kept for auditing and rollback purposes. For information on any of the V1, V2, or V3 certificate versions see RFC2459 on www.ietf.org.
Editing Profiles
To edit a profile: 1. 2. 3. 4. From the RA Client select View Profiles. Select the profile to be edited. Click the Edit button. To make the required changes expand the tree and: Edit the fields that have changed Add new fields Delete any fields not needed
For more information on editing profiles see the online help.
Using eTrust PKI
315
Backing Up Private Keys
Backing Up Private Keys

If certificate profiles are created with the attribute of archive, then when the key-pairs are created at the RA client, the root CA encrypts a copy of the private key. Private encrypting keys should be backed up. This enables the recovery of encrypted files in the case of key loss. Private signing keys should not be backed up; however, some companies back them up for mobility reasons. To recover a key backed up via the RA client: 1. 2. 3. 4. 5. Open the RA client and select Recover Private Key. Navigate to the certificate to be recovered and select the serial number. Select Recover and confirm when prompted. Select the file name and path for the recovered key. Enter a passphrase to protect the key.
316
Backing Up Your Configuration

Before making changes to your eTrust PKI configuration, make a backup of your original configuration. To back up your configuration: 1. Select the Start, Programs, Computer Associates, eTrust PKI, Server Administrative Tools, Backup & Recover. The Backup/Recover Tool dialog is displayed.
2. 3. 4. 5.
Select Backup PKI configuration and click Next. Specify where the original PKI components are installed and where to save the configuration data. Click Next twice. The backup process starts. When the backup is complete, click Finish.
Using eTrust PKI
317
Recovering Your Configuration Data

To recover the original configuration: 1. 2. 3. 4. 5. Select Start, Programs, Computer Associates, eTrust PKI, Backup & Recover. The Backup/Recover Tool dialog is displayed. Select Recover PKI configuration and click Next. Specify where the original PKI configuration data is backed up and where to restore it. Click Next twice. The recovery process starts. When the recovery is completed, click Finish.
Important! If you are recovering from a backup, reinstall PKI with the original path. If you are moving your PKI installation to a new machine, install PKI to the original path and copy the backup directory (pkiconfig) to the original path.
318
Chapter
Certification Authority Rollover
eTrust PKI provides a mechanism for replacing an expired certification authority signing certificate. This process is referred to as rollover. Rollover is needed because certificates have a limited life span. As the root certificate approaches the limit of its life span it needs to be replaced. The life span of the issued customer certificates is controlled by the life span of the root certificates. For example, if the life span of certificates issued to customers is one year, then the root certificate must be valid for at least the end of that year. The rollover tool creates a new certificate with the old. This allows the certificates issued by the old CA certificate to continue to be validated until their expiry.
Setting Up Rollover
Rolling over requires that a new certificate be published to the directory. To set up rollover: 1. 2. Ensure that the CA/RA servers are running. From a computer with a full PKI installation, choose Start, Programs, Computer Associates, eTrust PKI, Server Administrative Tools, Rollover tool. The Rollover Tool Logon Information dialog is displayed. Click Browse. The Load Key Store File dialog is displayed. Select the RA client operator p12 certificate (the default is defaultRAC_crt.p12) and click open. Enter the RA client operators passphrase and click Login. The Rollover Tool dialog is displayed.
3. 4. 5.
41
Setting Up Rollover
6.
Enter the fields on the dialog: Valid Fromthe initial date from which the root certificate will be valid. A calendar is available to ensure that the correct date is selected. This helps to ensure that leap years and short months are taken into account. Valid Tothe final date that the certificate will be valid. A calendar is available to ensure that the correct date is selected. This helps to ensure that leap years and short months are taken into account. Rollover the new certificate as soon as the validity period of the certificates it issues outlasts its own. Make CA certificates last for at least one year beyond the life span of the certificates issued to the end entities. Public Key Encryption Strengththe strength of encryption used for the public certificate. There is a trade-off between higher encryption and faster processing. 1024 or 2048 is recommended. Enter a Passphraseprotects the use of the CA private key.
4.
When you have collected all of the information select Next to complete the rest of the steps required to rollover the old certificate to the new. You will need to enter the passphrase used to create the original CA private key. The Rollover Progress dialog displays the progress of the rollover process. Stop and restart the servers after rolling over the root certificate.
5. 6.
42
CA Key Rollover
CA Key Rollover
When a new root certificate is created it has the same name as the old one, but has a different serial number. Note that this relies on issued certificates containing the authority key identifier extension so that the root certificates can be distinguished from each other. When a new key pair is used it appears to be technically feasible to reuse the same key pair. X.509 section 7, however, implies that the keys would be distinct. If self signed cross certificates are created (the old key, signed with the new, and the new signed with the old) in addition to the new certificate, a path of trust between the new key and the old key is provided. RFC 2510 describes how cross certificates can be used in validation. It is possible to specify a private key usage period for the CA key that implies that it will not be used for signing certificates after a certain date. X.509 section 8.2.2.5 says: With digital signature keys, the usage period for the signing private key is typically shorter than that for the verifying public key. The CA private key is a signing key, so it should follow the same rules.
Background
X.509 section 7 lists the CA certificate types: Self issuedthe issuer and the subject are the same CA. A CA might use self issued certificates, for example, during a key rollover operation to provide trust from the old key to the new key. Self signeda special case of self issued certificates where the private key used by the CA to sign the certificate corresponds to the public key that is certified within the certificate. A CA might use a self signed certificate, for example, to advertise their public key or other information about their operations. Cross certificatethe issuer and the subject are different CAs. CAs issue certificates to other CAs: As a mechanism to authorize the existence of the subject CA (for example in a strict hierarchy) To recognize the existence of the subject CA (for example in a distributed trust model)
43
CA Key Rollover
The IETF's RFC2510 states: "2.4 Root CA key update. This discussion only applies to CAs that are a root CA for some end entity. The basis of the procedure described here is that the CA protects its new public key using its previous private key and vice versa. Thus when a CA updates its key pair it must generate two extra CACertificate attribute values if certificates are made available using an X.500 directory (for a total of four: OldWithOld; OldWithNew; NewWithOld; and NewWithNew). When a CA changes its key pair those entities which have acquired the old CA public key via "out-of-band" means are most affected. It is these end entities who will need access to the new CA public key protected with the old CA private key. However, they will only require this for a limited period (until they have acquired the new CA public key via the "out-of-band" mechanism). This will typically be easily achieved when these end entities' certificates expire. The data structure used to protect the new and old CA public keys is a standard certificate (which may also contain extensions). There are no new data structures required."
Further Information
Information on the IETF can be found at www.ietf.org Information on X.509: http://www.nci.ac.cn/os/linux/security/x509/X.509_4thEditionDraftV5.pdf
44
Chapter
Web Enrolment
Web enrolment enables local and remote users and the RA operator to conduct their certificate issuance and maintenance activities via a web server. The web enrolment server must be the same machine as the RA server. Web enrolment removes the need for users to be physically present with the RA operator when requesting that a certificate be: Issued Revoked Renewed Recovered
Configuring Web Enrolment

To configure web enrolment: 1. Select Start, Programs, Computer Associates, eTrust PKI, Web Enrolment, Configuration. The Web Enrolment Configuration dialog is displayed with the current settings. Edit the configuration and default approvers fields. To access the advanced configuration settings, click Advanced. Edit the specified DNs and approver Emails for specified DNs fields. Click Save.
2. 3. 4. 5.
Tip: For information on the configuration fields and procedures click Help.
Web Enrolment
51
Starting the Web Enrolment Server
Starting the Web Enrolment Server

To start the web enrolment server: 1. 2. 3. 4. 5. Select Start, Programs, Computer Associates, eTrust PKI, Web Enrolment, Start Web Enrolment Server. Enter the path to the trust store. Enter the path to the client keystore filename.p12 file that contains your public key certificate and private key. Enter your RA client logon passphrase and hit Enter. The web enrolment server connects with the RA server. Select "Start the servers".
52
Issuing a CertificateWorkflow
Issuing a CertificateWorkflow
The workflow involved to request, issue, and receive a new certificate is: 1. 2. 3. 4. 5. 6. 7. The user accesses the web enrolment web server via a web browser, enters their details, and submits the request. The RA operator receives an email from the web enrolment server detailing the request. The RA operator confirms the validity of the request then processes it. The web enrolment server generates a request to the RA server to create a certificate. The RA server generates a certificate and notifies the web enrolment server. The web enrolment server notifies the RA operator and the user that the certificate has been generated. The user receives a notification email, downloads the certificate, and installs it. RA Server
Web Enrollment Server
RA Operator
Users
Web Enrolment
53
User Tasks
User Tasks
All of the user tasks are performed from the eTrust PKI Workflow interface page of the web enrolment server. The user can issue a request to: Create a certificate Recover a private key Renew a certificate Revoke a certificate
54
User Tasks
Requesting a New Certificate

To request a new certificate via the web interface: 1. Open Internet Explorer and enter the address of the web enrolment web server (https://webservercomputername.domain.com:8443/user/index.html). The eTrust PKI Workflow home page is displayed. Select Create a Certificate. The Create a Certificate page is displayed. Enter details into the fields. For information on the fields click Help. Click Submit. An email containing the details of the request is generated and sent to the RA operator. Wait for the RA operator to process the request and respond via email. The email is sent to the address specified in step 3. Open the notification email from the RA operator. Click on the hyperlink. The Collect a Certificate page is displayed. Enter the passphrase you used in step 3 and click Download. The File Download dialog is displayed. Specify a location to save the file to and click Save. The filename.p12 certificate downloads.
2. 3. 4. 5. 6. 7. 8. 9.
10. Locate the file and double-click it. A wizard is displayed. 11. Follow the steps in the wizard to extract and save the certificate in the Microsoft Certificate key store.
Web Enrolment
55
User Tasks
Requesting that a Certificate be Renewed

To request that a certificate be renewed via the web interface: 1. 2. 3. 4. 5. 6. Open Internet Explorer and select Tools, Internet Options. The Internet Options dialog is displayed. Select the Contents tab and click Certificates. Double click on the certificate to be renewed. The Certificate dialog is displayed. Select the Details tab and record the Serial Number of the certificate. Close the dialog and return to the Internet Explorer home screen. Enter the address of the web enrolment web server (https://webservercomputername.domain.com:8443/user/). The eTrust PKI Workflow home page is displayed. Select Renew a Certificate. The Renew a Certificate page is displayed. Enter details into the fields using the serial number recorded in step 4 and the certificate passphrase. For information on the fields click Help. Click Submit. An email containing the details of the request is generated and sent to the RA operator.
7. 8. 9.
10. Wait for the RA operator to process the request and respond via email. The email is sent to the address specified in step 8. 11. Open the notification email from the RA operator and click on the hyperlink. The Collect a Certificate page is displayed. 12. Click Download. The File Download dialog is displayed. 13. Specify a location to save the file to and click Save. The filename.p12 certificate downloads. 14. Locate the file and double click it. A wizard is displayed. 15. Follow the steps in the wizard to extract and save the certificate in the Microsoft Certificate key store.
56
User Tasks
Requesting that a Private Key be Recovered

To request that a certificate be recovered via the web interface: 1. 2. 3. 4. 5. 6. Open Internet Explorer and select Tools, Internet Options. The Internet Options dialog is displayed. Select the Contents tab and click Certificates. Double click on the certificate of the key to be recovered. The Certificate dialog is displayed. Select the details tab and record the Serial Number of the certificate. Return to the Internet Explorer home screen. Enter the address of the web enrolment web server (https://webservercomputername.domain.com:8443/user/). The eTrust PKI Workflow home page is displayed. Select Recover a Private Key. The Recover a Private Key page is displayed. Enter details into the fields using the serial number recorded in step 4, and the passphrase you used when requesting the certificate. For information on the fields click Help. Click Submit. An email containing the details of the request is generated and sent to the RA operator.
7. 8.
9.
10. Wait for the RA operator to process the request and respond via email. The email is sent to the address specified in step 8. 11. Open the notification email from the RA operator and click on the hyperlink. The Certificate Collection page is displayed. 12. Click Download. The File Download dialog is displayed. 13. Specify a location and click Save. The name.p12 certificate downloads. 14. Locate the file and double click it. A wizard is displayed 15. Follow the steps in the wizard to extract and save the certificate in the Microsoft Certificate key store.
Web Enrolment
57
User Tasks
Requesting that a Certificate be Revoked

To request that a certificate be revoked via the web interface: 1. 2. 3. 4. 5. 6. Open Internet Explorer and select Tools, Internet Options. The Internet Options dialog is displayed. Select the Contents tab and click Certificates. Double click on the certificate to be revoked. The Certificate dialog is displayed. Select the details tab and record the Serial Number of the certificate. Return to the Internet Explorer home screen. Enter the address of the web enrolment web server (https://webservercomputername.domain.com:8443/user/). The eTrust PKI Workflow home page is displayed. Select Revoke a Certificate. The Revoke a Certificate page is displayed. Enter details into the fields using the serial number recorded in step 4, and the passphrase entered when requesting the certificate. For information on the fields click Help. Click Submit. An email containing the details of the request is generated and sent to the RA operator.
7. 8.
9.
10. Wait for the RA operator to process the request and respond via email. The email is sent to the address specified in step 8. 11. The certificate is revoked and a notification email is sent to the RA operator and the user.
58
Web Enrolment RA Operator Tasks

The RA Operator: Responds to email requests from the users Views the status and history of the tasks performed
Creating a Certificate
To process a certificate request from the web: 1. 2. Open the email that arrived from the user and click on the hyperlink. The Client Authentication dialog is displayed. Confirm your identity by selecting your certificate (the RAC operator certificate) and clicking OK. The eTrust PKI Web Enrolment Operator home page is displayed. Examine the request details and perform the required verification checks. Tick the Approve Request or Deny Request radio button. Click Submit. If you approved the request, the web enrolment server: Sends a request to the RA server for the certificate to be generated Sends an email containing a hyperlink to the certificate to the user Sends an email confirming that the certificate was generated to your email address
3. 4. 5.
Tip: If you reject a request, add a comment explaining why it was rejected. This is included in the notification email to the user.
Web Enrolment
59

To recover a private key with the web enrolment server: 1. 2. 3. 4. 5. Open the email that arrived from the user and click on the hyperlink. The Client Authentication dialog is displayed. Confirm your identity by selecting your certificate and clicking OK. The eTrust PKI Web Enrolment dialog is displayed. Examine the request details and perform the required verification checks. Tick the Approve Request or Deny Request radio button. Click Submit. If you approved the request, the web enrolment server: Sends a request to the RA server for the private key to be recovered Sends an email containing a hyperlink to the recovered private key to the user Sends an email confirming that the private key was recovered to your email address
510
To revoke a certificate with the web enrolment server: 1. 2. 3. 4. 5. Open the email that arrived from the user and click on the hyperlink. The Client Authentication dialog is displayed. Confirm your identity by selecting your certificate and clicking OK. The eTrust PKI Web Enrolment dialog is displayed. Examine the request details and perform the required verification checks. Tick the Approve Request or Deny Request radio button. Click Submit. If you approved the request, the web enrolment server: Sends a request to the RA server for the certificate to be revoked Sends an email confirming that the certificate was revoked to the user Sends an email confirming that the certificate was revoked to your email address
Web Enrolment
511
Renewing a Certificate
To renew a certificate with the web enrolment server: 1. 2. 3. 4. 5. Open the email that arrived from the user and click on the hyperlink. The Client Authentication dialog is displayed. Confirm your identity by selecting your certificate and clicking OK. The eTrust PKI Web Enrolment dialog is displayed. Examine the request details and perform the required verification checks. Tick the Approve Request or Deny Request radio button Click Submit. If you approved the request, the web enrolment server: Sends a request to the RA server for the certificate to be renewed Sends an email containing a hyperlink to the renewed certificate to the user Sends an email confirming that the certificate was renewed to your email address
512
Viewing Web Enrolment Activity

The eTrust PKI Workflow Operator home page displays the status of the web enrolment tasks. You can: View the status of certificate requests Process open certificate requests
Viewing and Processing Certificate Requests To view all certificate requests: 1. Open Internet Explorer and enter the address of the web enrolment operator web server (https://webservercomputername.domain.com:8444/operator/index.html). The eTrust PKI Workflow Operator home page is displayed. Select See all Certificate Requests. The Certificate Requests page is displayed. Open requests have their ID displayed as a hyperlink. To process an open request select the ID hyperlink. The Approve a Request page is displayed. Approve or deny the request.
2. 3. 4.
Web Enrolment
513
Viewing and Processing Revocation Requests To view all revocation requests: 1. Open Internet Explorer and enter the address of the web enrolment operator web server (https://webservercomputername.domain.com:8444/operator/index.html). The eTrust PKI Workflow Operator home page is displayed. Select See all Revocation Requests. The Revocation Requests page is displayed. Open requests have their ID displayed as a hyperlink To process a request select the ID hyperlink. The Approve a Request page is displayed. Approve or deny the request.
2. 3. 4.
Viewing and Processing Renewal Requests To view all renewal requests: 1. Open Internet Explorer and enter the address of the web enrolment operator web server (https://webservercomputername.domain.com:8444/operator/index.html). The eTrust PKI Workflow Operator home page is displayed. Select See all Renewal Requests. The Renewal Requests page is displayed. Open renewals have their ID displayed as a hyperlink To process a request select the ID hyperlink. The Approve a Request page is displayed. Approve or deny the request.
2. 3. 4.
Viewing and Processing Recovery Requests To view all recovery requests: 1. Open Internet Explorer and enter the address of the web enrolment operator web server (https://webservercomputername.domain.com:8444/operator/index.html). The eTrust PKI Workflow Operator home page is displayed. Select See all Revocation Requests. The Recovery Requests page is displayed. Open requests have their ID displayed as a hyperlink To process a request select the ID hyperlink. The Approve a Request page is displayed. Approve or deny the request.
2. 3. 4.
514
Customizing the Web Enrolment Interface

Important! You must have write privileges to the web enrolment server to complete these tasks.
Customizing the eTrust PKI Workflow Logo

The logo displayed in the top left hand corner of each eTrust PKI Workflow Dialog can be replaced with your company logo. To change the logo on the eTrust Workflow pages: 1. 2. 3. 4. 5. 6. 7. Create a gif file with the same dimensions as logo.gif. Navigate to %PKIHOME%\tomcat\user\images. Make a backup of the original logo.gif. Replace the original logo.gif with your new logo.gif. Navigate to %PKIHOME%\tomcat\operator\images. Make a backup of the original logo.gif. Replace the original logo.gif with your new logo.gif.
Customizing the eTrust PKI Workflow Style Sheet

The general appearance of the eTrust PKI Workflow Dialogs is controlled by a cascading style sheet. The style sheet determines things such as the types of font and background colors. To change the style of the eTrust Workflow pages: 1. Make a backup of the files: %PKIHOME%\tomcat\operator\stylesheet.css and %PKIHOME%\tomcat\user\stylesheet.css. Create a new stylesheet.css that reflects your corporate font/color scheme. Replace the original stylesheet.css files with your new one.
2. 3.
Web Enrolment
515
Customizing the eTrust PKI Workflow Home Screen

You can replace the home screen picture displayed in the eTrust PKI Workflow Dialog with a picture of your choice. To change the splash screen on the eTrust Workflow pages: 1. 2. 3. 4. 5. 6. 7. Create a gif file with the same dimensions as splashscreen.gif. Navigate to %PKIHOME%\tomcat\user\images. Make a backup of the original splashscreen.gif. Replace the original splashscreen.gif with your new splashscreen.gif. Navigate to %PKIHOME%\tomcat\operator\images. Make a backup of the original splashscreen.gif. Replace the original splashscreen.gif with your new splashscreen.gif.
Customizing the Group Drop Down List

The group drop down list pre-populates the Country, Organization and Org Unit fields of the distinguished name. The options the user can select from are in the: %PKIHOME%\tomcat\user\web-inf\classes\groups.txt. The structure of this file is: Groupname, CountryValue, OrganizationValue, Org UnitValue. Each value is separated by a comma. Each new line represents a new group, for example:
FirstGroup,AU,Acme,Testing SecondGroup,US,Acme,Marketing ThirdGroup,AU,Acme,HR
516
To add a group to the list: 1. Open the file and add the new group. For example:
FirstGroup,AU,Acme,Testing SecondGroup,US,Acme,Marketing ThirdGroup,AU,Acme,HR FourthGroup,UK,WidgetCo,Finance
2. 3. 4. 5. 6.
Save the file. Reboot the user web server. Navigate to Create a Certificate Request. Select the drop down list. The new group is displayed in the list. Select the new group. The DN fields are populated.
Web Enrolment
517
Chapter
Batch Processing
The batch processor enables you to process a large number of transactions. Use the batch processor to: Create certificates (using a GUI or as a command line tool) Revoke certificates Renew certificates Create reports Generate CRLs on demand
Batch Processing
61
Using the PKI Batch Tool
Using the PKI Batch Tool

Important points to remember when using the PKI batch tool are: Syntax is paramount. When specifying command line parameters, there must be one or more spaces after the switch. This example will work:
batchc p Generic Utility Certificate version 1.0
This example will not work:

batchc pGeneric Utility Certificate version 1.0
Delimiters chosen must be unique, and should not occur naturally within the text file. This is made easy by the fact that delimiters can be multiple characters in length, for example: ZZZZ9999. Values for basic key usage and extended key usage are separated by a pipe symbol (|). The batch file batchc.bat is located in %PKIHOME%\lib directory. It can be executed from any directory when using the command line. A certificate that is not created, revoked, or renewed by the batch client is logged to the text file %PKIHOME%\lib\batchc_retry.log. Use this file to correct any errors and retry the process. Examples of the text files used to create, revoke, and renew certificates are in %PKIHOME%\doc\samples.
62
Creating Certificates in Batch Mode

To create certificates in batch mode: 1. Create a text file that contains the details of the certificates to be produced. The fields required for the text file are determined by the certificate profile selected for the type of certificate to be issued to the user. Open the RA client and select View Profiles. Examine the profile and note all profile attributes marked 'editable'. The text file needs to include an entry for every editable field for every entity being issued a certificate. The entries must be in the same order as they appear in the profile.
C=US,O=CAI Example,OU=Users,CN=Andrew Bumblebee;10/15/1999;10/15/2003;nonRepudiation|digitalSignature;email:0@cai.c om;clientAuth|serverAuth C=US,O=CAI Example,OU=Users,CN=Bart Cummins;10/15/1999;10/15/2003;nonRepudiation|digitalSignature;email:1@cai.com ;clientAuth|serverAuth
2. 3.
Typical input may look like:
Or:
_password_secret01_password_C=US,O=CAI Example,OU=Users,CN=Andrew Bumblebee;10/15/1999;10/15/2003;nonRepudiation|digitalSignature;email:0@cai.c om;clientAuth|serverAuth _password_secreet02_password_C=US,O=CAI Example,OU=Users,CN=Bart Cummins;10/15/1999;10/15/2003;nonRepudiation|digitalSignature;email:1@cai.com ;clientAuth|serverAuth
This makes the passphrase to the certificate issued to Andrew Bumblebee secret01 and the passphrase to the certificate issued to or Bart Cummins secret02. Otherwise, the default passphrase secret is used. 4. To use the GUI to facilitate the production of the batch certificates type one of the following on the command line:
batchc genCert -gui
or
batchc genCert gui certPassword secret4all
This makes secret4 the passphrase for all the certificates created by the job The RAC batch client logon information is displayed. 5. Click Browse and select the client keystore to log onto the batchc application.
Batch Processing
63
6. 7. 8.
Enter your passphrase and click Login. Select the profile for the type of certificate to be issued. Select the file containing the input data and the delimiter used to define the end of each entity. A profile is the full name of the certificate template used to create certificates. Tip: Keystore details can be optionally entered with the certificate creation command. This reduces the command entry to one from three (creation, keystore location, and passphrase). If these are not entered the program prompts for their input.
9.
Select the output directory the certificates will be saved in.
10. To run the entire process from the command line use the command:
batchc genCert profile "<Profile>" datafile "<datafile>" delimiter <delimiter> outputDir "output directory" keystore "<keystore location>" keypassword "<password>"
64
Revoking Certificates in Batch Mode
Revoking Certificates in Batch Mode

To revoke certificates in batch mode: 1. Create a data file that contains the DN, Serial Number, and revocation reason of the certificate to be revoked. For example:
C=US,O=CAI Example,OU=Users,CN=Andrew Bumblebee;21;keyCompromise
2.
From the command line, enter the command:

batchc revokeCert dataFile "<dataFile>" delimiter "<delimiter>"
Renewing Certificates in Batch Mode

To renew certificates in batch mode: 1. Create a data file that contains the DN, Serial Number, and a new 'valid to:' date of the certificate to be renewed. For example:
C=US,O=CAI Example,OU=Users,CN=Andrew Bumblebee;28;=US;10/10/2007
2.
From the command line, enter the command:

batchc renewCert datafile "<datafile>" delimiter "<Delimiter>" -outputDir "<output directory>"
Batch Processing
65
Specifying the File Name and Path
Specifying the File Name and Path

This option allows the report logs to be created and stored in the path\filename of your choice. From the command line, enter the command:
batchc -report query "<Query Name>" outputFile "<Output Path and Filename>"
Note: The query must already be configured and saved using the Reporting option from the RAC before it can be run from the command line.
Creating a CRL on Demand

The gencrl command creates a new CRL. Use it with the scheduling software built into most operating systems to schedule regular CRL production for auditing and legal purposes. This command is case sensitive. From the command line, enter the command:
batchc genCrl
66
Chapter
Software Development Kit (SDK)

This chapter describes the key eTrust PKI SDK concepts.
Central Concepts
The SDK provides functionality that enables the use of public key cryptography in applications. Central concepts for the use of the eTrust PKI SDK are: Keys Certificates Cryptographic providers
Most of the API functions take handles representing these types of objects.
Keys
Keys are used for encrypting/decrypting data. Each key is associated with a specific encryption algorithm. Both symmetric keys and asymmetric keys (public/private key pairs) are available. Symmetric keys complement public key/private key pairs by providing a less computationally intensive encryption operation. To use a key it must be associated with a cryptographic provider. A key should not be used after its associated provider has been closed.
71
Central Concepts
Certificates
A certificate is a signed electronic document that asserts that a particular entity is the holder of the private key that corresponds to a particular public key. The certificate specifies the name of the entity, the name of the authority that makes this assertion, and the public key. Although certificates are frequently stored within cryptographic providers, they can exist independently and can be used even if the providers they have been loaded from are offline.
Cryptographic Providers
A cryptographic provider represents a device that can store certificates and keys. This may be a hardware device such as a smart card, or it may be implemented entirely in software. A default provider is created when the API is initialized, using information specified in a configuration file. The default provider holds all of the trusted certificates. After initialization, it is not possible to add more certificates to the default provider. To use the default provider NULL should be passed instead of a provider handle. When communicating with hardware providers the ETCER API uses the PKCS#11 - Cryptographic Token Interface Standard. Users of the ETCER API should be aware that not all hardware providers implement all algorithms detailed in this standard and not all hardware providers implement the standard in the same way. Although efforts have been made to ensure that the ETCER API will handle such variations in a robust fashion, it cannot be guaranteed that the ETCER API will be able to perform exactly as described for all such devices on the market.
72
Core Functionality
Core Functionality
The ETCER API is designed to provide simple access to common cryptographic functions. The functions that are available with this version include: Encrypting/Decrypting Signing/Verifying Certificate validation Extracting certificate details
Encrypting/Decrypting
There are two types of encryption/decryption supported by the ETCER API: Symmetricencrypts and decrypts using the same key. Symmetric is better suited to large amounts of data than asymmetric encryption/decryption and is usually faster. The biggest draw back with this method is finding a secure way for the sender of a message to inform the intended recipient of the symmetric key used. This method also fails to scale well as each individual that wishes to secretly communicate needs to have a shared secret with each other party. Asymmetricrequires a key pair. Data encrypted with either one of the keys must be decrypted using the other key. Usually one of these keys will be designated the private key and kept secret, the other will be designated the public key and may be freely distributed. The sender of a message can encrypt the message with the desired recipients public key. The recipient can then decrypt the message using the associated private (secret) key. This allows systems that use asymmetric encryption to scale far better than systems that use symmetric keys. This form of encryption is not well suited to large amounts of data.
73
Core Functionality
To get the best from both forms of encryption the following method is used: The sender of a message generates a symmetric key The sender uses the symmetric key to encrypt the message The sender uses recipients public key to encrypt the symmetric keythis is because the public key is usually very short compared to the actual message The sender sends both the encrypted message and the encrypted symmetric key to the recipient The recipient decrypts the symmetric key using their private key The recipient uses the decrypted symmetric key to decrypt the message
This combination of symmetric/asymmetric encryption has a secondary benefit. When sending the same document to multiple recipients the document only needs to be encrypted once. The symmetric key used to encrypt the document can then be asymmetrically encrypted for each recipient using the recipients public key. Sample code that illustrates encryption and decryption is provided within the samples folder of the ETCER SDK installation. See the appropriate readme files for further details.
Signing/Verifying
Digital signing and verifying of data can be used to ensure that the data has come from a particular source and that the data has not been tampered with. Signing is the process of generating a digital signature for a piece of data (often a document or a certificate). Signatures are a fixed length and are generated by first generating a digital hash or fingerprint of the document and then encrypting that fingerprint using the signing entities private key. Verifying is the process of testing that a digital signature and a piece of data match. Verification is performed using the public key associated with the private key used during signing. If the data being checked is not the same as the data that was signed, the signature will be invalid. If the public key used is not valid for the private key used during signing, the signature will also be invalid. It is not possible to distinguish between a signature being found invalid because of tampering with the document content, or because the private key used during signing is not the pair of the public key used during verification.
74
Core Functionality
Sample code is provided in the samples folder of the ETCER SDK installation that illustrates signing and verification. See the appropriate readme files for further details.
Validating Certificates
Certificates provide a means of associating a public key with a particular entity, so that those using the public key can feel secure in the knowledge that the key really does belong to the entity that they think it belongs to. Certification authorities issue certificates. These authorities sign the certificates they issue. The certificate authority will provide a certificate that can be used to verify this signature. This certificate will either be signed by another certificate authority or, if the authority in question is a root certificate authority, it may be self-signed. This is said to occur when a certificate authority signs its own certificate. It is up to the relying party to decide for themselves whether or not to trust a self-signed certificate. The chain of certificate signing that results is called a certification path. Before using a certificate it is vital to check that it is valid. A certificate may be deemed invalid if: It is out of date, either being used before or after its valid date range The issuing certificate authority has revoked it No certificate in the certification path is trusted by the entity performing the validation.
The ETCER API supports all of the above aspects of certificate authentication. Sample code is provided in the samples folder of the ETCER SDK installation that illustrates validation. See the appropriate readme files for further details.
75
Extracting Certificate Details
Extracting Certificate Details

X.509 type certificates can contain a wealth of information, such as the certificate serial number, who issued the certificate, and who is the subject of the certificate. It is often important to be able to extract this information in a portable, humanreadable form. For example, a user who possesses a number of certificates for different aspects of their business can browse through these certificates so that they can identify the one they wish to use to sign a document. The ETCER API provides such access to various certificate fields, returning the values as null terminated strings. Sample code is provided in the samples folder of the ETCER SDK installation that illustrates the extracting and printing of certificate details. See the appropriate readme files for further details.
The ETCER Configuration Object

The ETCER configuration object stores configuration information grouped into various sections. None of these sections is mandatory, however, some properties within a section may be mandatory should that section exist. Missing mandatory properties or incorrect values may cause some functionality to be unavailable, or may cause the API initialization to fail.
Setting Properties
Properties and sections within a configuration object can be created and/or updated directly using the ECTER API function calls:
Etcer_OpenConfigSection, Etcer_CloseConfigSection, Etcer_SetConfigString
Configuration information can also be imported from a file using the ETCER API function call:
Etcer_ImportConfigFile
The file is structured as a Microsoft Windows initialization file. For example, to set the 'initpem' property of the 'default' section the file would look like:
[default] initpem=root.pem
76
The Default Section

This section is used to set properties for the default provider and has the supported property: initpemused to specify the name of a PEM format file containing one or more trusted certificates. If a file is specified but not found, initialization of the API fails.
The OCSP Section

This section is used to specify details of an OCSP responder to use during validation. The following properties are supported: librarythe client library to load for OCSP support. If the value of this property is not a fully qualified path name then the default system rules for locating dynamic link libraries are used to locate the library. responderset this property to the URL where the OCSP responder can be located. timeoutset this property to the maximum time to wait for a response from the OCSP responder. The time is specified in milliseconds. A timeout of zero indicates that there is no timeout for requests. httpproxy (optional) set this property to the URL of the http proxy server used to connect to the OCSP responder. If this property is not set, connection will be attempted directly to the URL specified by the responder property. Trustedcert (optional) set this property to the name of a PEM format file containing a trusted certificate that can be used to verify the responders response.
77
The Provider Sections

Zero or more sections can be supplied to specify providers. Each section must be given a unique name that does not clash with one of the reserved section names, these being 'default' and 'ocsp'. Each provider section must include the properties: typethe type of interface used when communicating with this provider. The only value accepted in the current version is pkcs11. librarythe driver library to load when using this provider. If the value of this property does not include a fully qualified path name then the default system rules for locating driver libraries will be used to locate the library. Under Windows the most common form this driver library will take is a DLL. slotthe number of the slot that is managed by the specified library.
78
Chapter
Setting Up HSMs
eTrust PKI supports key generation and certificate storage on a range of HSMs. This chapter describes how to use eTrust PKI with: Eracom CSA7000 and CSA8000 HSMs GemPlus GemPKCS SDKv3Smartcard and GemSAFE Smartcard Rainbow iKey 2000 USB key token Datakey Smartcard Chrysalis-ITS Luna CA3 GemPlus GemSAFE Smartcard
Setting Up Eracom CSA7000 and CSA8000 HSMs

To set up a CSA7000 or CSA8000 HSM: 1. 2. 3. Install the Eracom CSA7000 or CSA8000 adapter. Install the drivers for the adapter. Use Windows Explorer to navigate to: E:\cprov_3_0_cdv1_10\Win32\Driver_8000\ (Where E: is the CD drive.) Double click csa8k_driver.exe and add csa8000 to the path. Use Windows Explorer to navigate to: E:\cprov_3_0_cdv1_10\Win32\CPROV_Runtim\ (Where E: is the CD drive.) Double click cprov_rt.exe. Follow the instructions in the custom install wizard. Include the CSA8000 and GUI tools.
4. 5.
6. 7.
Setting Up HSMs
81
Setting Up Eracom CSA7000 and CSA8000 HSMs
Saving a Certificate in the Adapter

To save certificates on the Eracom CSA Adapter, save the root on the Eracom CSA Adapter. Follow the configuration as normal until you reach Step 7 (Select keystore media). Choose via smartcard option and ensure that your setup matches the configuration: Field Vendor: DLL: Slot: Pin number: Alias: Value Eracom_CSA_7000_0 cryptoki 0 **** rsa1 Notes This is the vendor for Eracom drivers Leave as default Leave as default Default if this has been changed, change it here also Leave as default
To save a certificate to the Eracom CSA adapter through the RA client: 1. 2. 3. 4. 5. Click Issue a Certificate. Choose Profile of Certificate. Follow the Issue a Certificate instructions until Step 7. Choose Via Smartcard and the Eracom CSA7000 Vendor. Change the PIN field to your Eracom CSA Adapter passphrase.
82
Setting Up GemPlus GemPKCS SDKv3 Smartcards

The GemSAFE GemPKCS SDKv3 can only be used on WinNT systems. To install the GemPKCS SDKv3 drivers: 1. Navigate to: E:\GemPlus\GemPCKSv3\GemPlus\ (Where E: is the CD drive.) Double click setup.exe. Follow the install wizard through a custom install, choosing the correct reader and port number. Reboot your PC. Insert a GemPKCS card into the reader. Select Start, Programs, GemPKCS, Card Details Tool. The Card Details panel is displayed. Select Card, Examine. Read the card, if it is not empty select Card, Reinitialize.
2. 3. 4. 5. 6. 7. 8.
Saving a Certificate on the Smart Card

To save the root certificate on the smart card: 1. 2. 3. 4. Follow the configuration until you reach Step 4 (Choose a key size). Choose 512 or 1024 for the key size. (1024 is the maximum key length for the card.) Follow the configuration until you reach Step 7 (Select keystore media). Deselect the In Software option and choose the Via Smartcard option.
Setting Up HSMs
83
5.
Ensure that your setup matches the configuration: Value GEMPLUS_SmartCard ck2priv 0 **** rsa1 Notes This is the vendor for GemPKCS SDKv3 drivers Default Default Default if this has been changed, change it here also Default
Field Vendor: DLL: Slot: Pin number: Alias:
After you have saved the root on the smart card, do not save any more certificates on that card. To save a certificate to the smart card through the RA Client: 1. 2. 3. 4. 5. Click Issue a Certificate. Choose Profile of Certificate. Follow the Issue a Certificate instructions until Step 7. Choose Via Smartcard and the GEMPLUS_SmartCard Vendor. Change the PIN field to your Smart Card passphrase.
84
Setting Up GemPlus GemSAFE Smartcards

When installing the GemPlus drivers, the GemSAFE logon must not be installed. To install on Windows NT: 1. Follow the wizard for a typical install and deselect the GemSAFE logon.
Important! When installing the drivers for Windows 2000 do not use the complete installation the typical installation provides the correct functionality. 2. 3. 4. Choose the correct reader and port number. Insert a GemSAFE smart card into the card reader. Use the card details tool to check that you can talk to the card: NT: Start, Programs, GemSAFE, GEMSAFE Card Details Tool 2000: Start, Programs, GemSAFE Card Details Tool Enter the card passphrase. If you encounter any difficulties reading the card, reboot the PC and try again. Select Card, Information. Check that the card is empty.
5. 6. 7.
Saving the Root Certificate on the Smart Card

To save the root certificate on the smart card: 1. 2. 3. 4. Follow the configuration as normal until you reach Step 4 (Choose a key size). Choose a key size of 512 or 1024. (1024 is the maximum key length for the card.) Continue to follow the configuration as normal until you reach Step 7 (Select keystore media). Deselect the In Software option and choose the Via Smartcard option.
Setting Up HSMs
85
5.
Ensure that your setup matches the configuration: Value GEMPLUS_SmartCard ck2priv 0 **** rsa1 Notes This is the vendor for GemPLUS drivers Default Default Default if this has been changed, change it here also Default
After you save the root on the smart card, do not save any more certificates on that card. To save a certificate to the smart card through the RA Client: 1. 2. 3. 4. 5. Click on Issue a Certificate. Choose Profile of Certificate. Follow the Create a Certificate instructions until Step 7. Choose Via Smartcard and the GEMPLUS_SmartCard Vendor. Change the PIN field to your Smart Card passphrase.
86
Setting Up Rainbow iKey 2000 USB Key Tokens

Important! You may encounter problems if you have a Rainbow iKey Token and a Datakey smart card installed on the same computer. Only have one or the other plugged in when using eTrust PKI. To install the Rainbow iKey drivers: Double click on E:\Rainbow setup.exe, where E: is the CD drive. 1. 2. 3. 4. 5. 6. Follow the install wizard through a typical installation. Select Start, Programs, Rainbow Technologies, Token Manager. The Token manager dialog is displayed. Ensure that you can view the token. Use the Token Manager to check that the USB Reader is displayed as the current reader. Click Display Token Objects to see the information on the token. Open the Token drop down menu and selecting Initialize Token. The card is initialized.
Saving the Root Certificate in the Token

To save the root certificate to the token: 1. 2. 3. Follow the configuration as normal until you reach Step 4 (Choose a key size). Choose the key size as 512 or 1024. (2048 is too large for the token.) Continue to follow the configuration as normal until you reach Step 7 (Select keystore media).
Setting Up HSMs
87
4.
Uncheck the In Software option and choose the Via Smartcard option, ensuring that your setup matches the configuration: Value Rainbow_iKey dkck201 0 ******* rsa1 Notes This is the vendor for Rainbow iKey drivers Default Default Default if this has been changed, change it here also Default
After you have saved the root on the token, do not save any more certificates on that token. To save a certificate to the token through the RA Client: 1. 2. 3. 4. 5. Click Create a Certificate Request. Choose Profile of Certificate. Follow the Create a Certificate instructions until Step 7. Choose Via smartcard and the Rainbow_iKey Vendor. Change the PIN field to your tokens passphrase.
88
Setting Up Datakey Smartcards

Important! You may encounter problems if you have a Rainbow iKey Token and a Datakey smart card installed on the same computer. Only have one or the other plugged in when using eTrust PKI. The readers that can be used with the Datakey smart card are: DKR610 Serial Reader iKey 2000/2032 Datakey 10SR Serial DKR 630 USB Reader
When using the Datakey with eTrust PKI ensure that you have the right drivers for the reader you are using. To install the Datakey drivers: 1. 2. 3. 4. 5. 6. 7. 8. Follow the install wizard and choose the correct reader and port number. Insert a Datakey smartcard into the card reader. Select Start, Programs, Datakey, Token Utility. The Token Utility dialog is displayed. Check that you can talk to the card. Click Display Objects. The card information is displayed. Enter the card passphrase. Check the card for previous information and make sure that it is empty. Opening the Token drop down menu and select Initialize Token. The card is initialized.
Setting Up HSMs
89
Saving the Root Certificate to a Token

To save the root certificate to the token: 1. 2. Follow the configuration as normal until you reach Step 7 (Select keystore media). Choose the Via Smartcard option and ensure that your setup matches the configuration: Value Datakey dkck201 0 ******* rsa1 Notes This is the vendor for Datakey drivers Default Default Default if this has been changed, change it here also Default
After saving the root on the smart card, do not save any more certificates on that card. To save a certificate to the smart card through the RA Client: 1. 2. 3. 4. 5. Click on Create a Certificate Request. Choose Profile of Certificate. Follow the Create a Certificate instructions to Step 7. Choose Via Smartcard and the Datakey vendor. Change the PIN field to your smart card passphrase.
810
Setting up a Chrysalis HSM

Important! Install the software before inserting the controller card.
Task 1Installing the Software

To install the Chrysalis software: 1. 2. 3. Insert the Chrysalis CD-ROM and select the Luna CA3/Xplus install option. Restart the PC. Open C:\WINNT\crystoki.ini. The file contains the data:
[Chrystoki2] LibNT=C:\Program Files\Luna\cryst201.dll L-ibNT=C:\Program Files\Luna\lblib201.dll [Luna] DefaultTimeOut=500000 PEDTimeout1=100000 PEDTimeout2=100000 [CardReader] RemoteCommand=1 [LBLib2] L-ibNT=C:\Program Files\Luna\cryst201.dll E-nabled=1
4.
Change the data to:
[Chrystoki2] L-ibNT=C:\Program Files\Luna\cryst201.dll LibNT=C:\Program Files\Luna\lblib201.dll [Luna] DefaultTimeOut=500000 PEDTimeout1=100000 PEDTimeout2=100000 [CardReader] RemoteCommand=1 [LBLib2] LibNT=C:\Program Files\Luna\cryst201.dll Enabled=1
Setting Up HSMs
811
Task 2Installing the Hardware

1. 2. 3. 4. 5. 6. 7. 8. 9. Turn off the PC and insert the controller card. Use the MDR-26 cable to connect card port A to the dock reader. Connect the power cord to the controller. Turn on the PC. The Found new hardware wizard appears. Select Next. Check the Search for a suitable driver... option and click Next. Uncheck Floppy disk drives and CD-ROM drive and check Specify a location. Browse to C:\Program Files\Luna\oemsetup and click Open. Click OK.
10. When the window finds the driver click Next, then Finish.
Task 3Testing the Install

1. 2. Run C:\Program Files\Luna\lunadiag.exe Run menu options 2 - 3 and 4. If no errors are returned the installation is successful.
812
Task 4Enabling the Token and Setting Up the PED Keys

1. 2. 3. 4. 5. 6. 7. 8. 9. Run C:\Program Files\Luna\Enabler.exe. Select Initialize a Token. Enter the slot ID of the token and a label for the token. Type N for the M of N option. Insert the gray PED key into the reader and press Enter. Insert the blue PED key into the reader and press Enter. Type N when asked if this is a group PED key. Enter a PIN to protect the key. (This can be left blank.) Type N when asked if this is a duplicate PED key.
10. Insert the red PED key and press Enter. 11. Select No when asked to create a domain. 12. Select No when asked if this is a duplicate PED key. 13. Insert the blue and black PED keys. 14. Enter a PIN to protect the key. (This can be left blank.) 15. Type N when asked if this is a duplicate PED key. The initialization completes.
Setting Up HSMs
813
Saving the Root Certificate

To save the root certificate in the HSM: 1. 2. 3. Follow the configuration as normal until you reach step 7, Select keystore media. Deselect the In Software option and choose the Via Smartcard option. Ensure that your setup matches the configuration: Value Chrysalis-ITS lblib201 0 **** rsa1 Notes This is the vendor for Chrysalis-ITS Luna CA3 Default Default Default if this has been changed, change it here also Default
Saving a Certificate Through the RA Client

To save a certificate on the HSM through the RA client: 1. 2. 3. 4. 5. Click Issue a Certificate. Select Profile of certificate Follow the Create a Certificate instructions until step 7. Select Via Smartcard and the Chrysalis-ITS Vendor. Change the PIN field to your HSM passphrase.
814
Setting Up a GemPlus GemSAFE 3.0 Smartcard

Important! To install the GemPlus 3.0 drivers you must have Windows NT with service pack 6 applied or Windows 2000 with service pack 1 or higher applied. To set up the Smartcard: 1. 2. 3. 4. 5. 6. 7. Start the wizard and select a typical installation. Deselect the GemSafe Logon. Select your reader and port number. Insert the GemSAFE smart card into the card reader. Select Start, Programs, GemSAFE enterprise, Card Maintenance Tool to check that you can access the card. Enter the card PIN. The card is unblocked. Check the card for previous information such as certificates. The card must be clear before saving any certificates.
Saving the Root Certificate

To save a root certificate on the Smartcard. 1. 2. 3. 4. Follow the configuration as normal until you reach step 4, choose a key size. Choose a key length of 512 or 1024 (1024 is the maximum key length for the card). Follow the configuration until you reach Step 7 (Select keystore media). Deselect the In Software option and choose the Via Smartcard option.
Setting Up HSMs
815
5.
Ensure that your setup matches the configuration: Value GemPLUS3.0_ SmartCard GCLib 0 **** rsa1 Notes This is the vendor for GemPLUS 3.0 drivers Default Default Default if this has been changed, change it here also Default
Note: Do not save any other certificates on the card with the root certificate.
Saving a Certificate Through the RA Client

To save a certificate on the Smartcard through the RA client: 1. 2. 3. 4. 5. Click on Issue a Certificate. Select Profile of Certificate. Follow the Create a Certificate instructions until step 7. Choose Via Smartcard and the GemPLUS3.0_SmartCard vendor. Change the PIN field to your Smartcard passphrase.
816
Chapter
Cross Certification
Cross certification occurs where one CA certifies that another CA can be trusted. Cross certification can be used to verify third party CAs and their certificates. This can be important when you want your certificates to work with third party hardware or software that has fixed trusted root certificate stores.
Cross Certification Theory

CA1 generates a new certificate X that contains the subject name of the CA2 root certificate. The issuer is listed as CA1, and it is signed using the CA1 private key. Users of CA1 consider CA2 to be an intermediate CA subordinate to CA1. This is the minimum requirement to implement cross certification.
Publishing Cross Certificates

X.509 section 11.2.3 (and RFC 2587 section 3.2) describes how cross certificates should be published. It has provision for publishing cross certificates within other CA domains, for example publishing the above cross certificate in CA2s directory.
Cross Certification
91
Cross Certification Theory
Cross Certification Options

It is possible to specify policy mappings in the cross certificate. If CA2 has policies used in issued certificates, then the cross certificate should use the policy mapping extension to map the CA2 policies to equivalent policies. It may be required that additional constraints be placed on the certificates issued from CA2 that are to be trusted with the CA1 framework. Use the basic constraints to specify a maximum path length and mark the certificate as a CA certificate.
Possible Problems with Cross Certification

PKCS#12 files often contain all of the certificates in the path, including the root certificate. If a PKCS#12 file is provided by a CA2 user, it will include the CA2 root certificate. If a CA1 user is given the PKCS#12 file, it is possible that validation will fail, because the root certificate in the file may be used in preference to the cross certificate.
92
Cross Certifying with Another CA

Important! This procedure allows your CA to accept a third partys public certificate as legitimate. A user of your PKI will be able to verify that a certificate was generated by the third party CA. This process will verify, but not allow end users to validate. This will only allow end users to check that the certificate was originally created by the third party CA.
Task 1Copying the Public Key

To cross certify with another CA, you need a copy of its public key. You can: Apply to the CA for a copy Extract a copy from Internet Explorer if the CA is one of the CAs accepted by the MS certificate store
To copy a public key from the MS certificate store: 1. 2. 3. 4. 5. 6. 7. 8. 9. Open Internet Explorer. Select Tools, Internet Options. The Internet options dialog is displayed. Select the Contents tab and click Certificates. The Certificates Manager dialog is displayed. Select the Trusted Root Certification Authorities tab. Select the CA to cross certify with. Select Export. The Certificate Manager Export Wizard is displayed. Click Next twice, then enter the path and file name where the certificate is stored. Click Next, Finish. The completed dialog is displayed. Click OK and close Internet Explorer.
Cross Certification
93
Task 2Cross Certifying

To cross certify to another CA: 1. 2. If the CA/RA services are not running, select Start, Programs, eTrust PKI, Foreground CA/RA Services and click Start. Select Start, Programs, Computer Associates, eTrust PKI, Server Administrative Tools, Cross Certification Tool. The Cross Certification Logon Information dialog is displayed. Click Browse. The Load Key Store File dialog is displayed. Select the client keystore p12 certificate (the default is defaultRAC_crt.p12) and click Open. The Cross CA Certification Generation wizard is displayed. Select Load Cert and pick the certificate for the cross certification. Tip: Set Files of Type to All files. You may need to do this because some applications do not store certificates with a .DER extension.
3. 4. 5.
6. 7.
Select View Cert and check the details of the certificate. Note the Issued By field as this will be change when cross certification is finished. From the Cross CA Certificate Generation wizard, select Next to start updating the Certificate details. Name: The distinguished name (DN) of the CA root server Non-standard DN: The DN of the CA root server Ordered DN: This allows a DN to be specified in a structured manner Country: The two letter country code where the subject CA root server is located Organization: The organization that owns the subject CA root server Organization Unit: The office or group that controls the CA Root server Name: The name of the CA root server E-mail: The e-mail address of the CA root server
94
8. 9.
Enter the details for Valid Fromthe first date that the root CA certificate will be valid from. Enter the details for Valid Tothe last day that the root CA certificate will be valid.
10. Enter the details for Authority Info Accessthe host name and port number for the OCSP responder. Users of your new cross certificate will know where to check its online status. 11. Click Next to continue. 12. Enter the field Basic Constraints. These allow you to specify if the certificate being cross certified to is for a user or for a CA. In practice, it would be unusual to cross certify to an individuals certificate. It is expected that you would normally cross certify to another CA. 13. Enter the field Path Length. This specifies the number of certificates that can be chained from your cross certified CA. The options are: NoneYou do not trust any certificates that were issued by the cross certificate CA. You will only trust the exact certificate that is being cross certified. This may be useful if you want to certify a single user. Select Type = EE and Path Length Constraint = None. 1You only trust the certificates that were issued by the CA that you are cross certifying to. 2You trust the CA that you are cross certifying with, and also trust a certificate issued by a third CA who is trusted by the CA that you are cross certifying with.
Tip: You may not be fully aware of the issuance policies that are used by third parties. For this reason a path length of 1 is recommend.
14. Click Next to confirm your wizard selections. The new certificate is created. 15. Enter where to save copies of the new certificate.
Cross Certification
95
Glossary
Attribute Authority (AA) An authority trusted by one or more users to create and sign attribute certificates. It is important to note that the AA is responsible for the attribute certificates during their whole lifetime, not just for issuing them.* Attribute Certificate (AC) A data structure containing a set of attributes for an end-entity and some other information, which is digitally signed with the private key of the AA which issued it.* Certificate Can refer to either an AC or a public key certificate.* Certification Authority (CA) An authority trusted by one or more users to create and assign public key certificates. Optionally the CA may create the users keys. It is important to note that the CA is responsible for the public key certificates during their whole lifetime, not just for issuing them. Certificate Policy (CP) A named set of rules that indicates the applicability of a public key certificate to a particular community and/or class of application with common security requirements. For example, a particular certificate policy might indicate applicability of a type of public key certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range.* Certification Practice Statement (CPS) A statement of the practices which a CA employs in issuing public key certificates.*
Glossary1
Certificate Revocation Lists (CRL) A list of certificates that have been revoked before their scheduled expiration date. DER Distinguished Encoding Rules. DER is a component of the Abstract Syntax Notation (ASN.1) standard as defined by the International Standards Organization (ISO). It defines the format used to transfer data across a network. Directory Information Tree (DIT) The collection of entries within a directory organized in hierarchical fashion that reflects their inter-relationship. End-entity (EE) A subject of a certificate who is not a CA in the PKIX or an AA in the PMI. (An EE from the PKI can be an AA in the PMI).* HSM Hardware Security Module. HSMs are used to securely store private keys. When a document is to be signed, the document is sent to the HSM which then generates the signature. The important feature is that the private key never leaves the HSM. HSMs may be certified as resistant to various forms of electronic and physical attack, for example, FIPS 140-1 Level 3. Lightweight Directory Access Protocol (LDAP) A communications protocol that allows access to a directory service. Supports lightweight access to static directory services, allowing relatively fast search and update. Lightweight Directory Interchange Format (LDIF) An ASCII file format used to exchange data and enable the synchronization of that data between LDAP servers. Method Each policy consists of one or more methods, each of which perform a welldefined unit of work, e.g. set the status of the response, set the signature of the response, etc. OCSP Online Certificate Status Protocol.
Glossary2
PEM Privacy Enhanced Mail. The PEM application defines a file format for storing certificates, CRLs and private keys. This format has become popular and is now used by several other applications. Policy Each policy represents a personality or role that the responder takes on. Example roles in the Identris model are Relying Customer Role and Inter-participant Role. Privilege Management Infrastructure (PMI) A collection of ACs, with their issuing AAs, subjects, relying parties and repositories, is referred to as a Privilege Management Infrastructure.* Public Key Certificate (PKC) A data structure containing the public key of an end-entity and some other information, which is digitally signed with the private key of the CA which issued it.* PKCS Public Key Cryptography Standards. This is a series of standards defined by RSA Laboratories (http:// www.rsasecurity.com). eTrust OCSPro uses PKCS #11: Cryptographic Token Interface to access Hardware Security Modules (HSMs). Public Key Infrastructure (PKI) The set of hardware, software, people, policies and procedures needed to create, manage, store, distribute and revoke PKCs based on public-key cryptography.* Registration Authority (RA) An optional entity given responsibility for performing some of the administrative tasks necessary in the registration of subjects, such as: confirming the subjects identity; validating that the subject is entitled to have the values requested in the PKC and verifying that the subject has possession of the private key associated with the public key requested for a PKC.* Relative Distinguished Name (RDN) A name component that identifies an entry with respect to the entry just above in the hierarchy.
Glossary3
Relying Party (RP) A user or agent (for example, a client or server) who relies on the data in a certificate when making decisions.* Resco Responder Configuration. This is the tool which configures the OCSPro Responder. Root CA A CA that is directly trusted by an EE; that is, securely acquiring the value of a Root CA public key requires some out-of-band steps. this term is not meant to imply that a Root CA is necessarily at the top of any hierarchy, simply that the CA in question is trusted directly.* Selection Criteria Selection criteria are evaluated prior to the execution of each policy and method to determine whether the policy/method should be evaluated. Selection criteria are based on attributes of the request, the current state of the response and information stored in the directory. Subject Certificate The certificate identified in the CertId field of the OCSP request. Subordinate CA A "subordinate CA" is one that is not a Root CA for the EE in question. Often a subordinate CA will not be a Root CA for any entity, but this is not mandatory.* Top CA A CA that is at the top of a PKI hierarchy.
* Denotes that this definition has come from the IETF PKIX Roadmap, draft-ietf-pkixroadmap-04.txt, available from http://www.ietf.org.
Glossary4

Etrust PKI Admin Guide

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Etrust PKI Admin Guide

Uploaded by

Copyright:

Available Formats

eTrust PKI

2002 Computer Associates International, Inc.

Chapter 2: Setting Up eTrust PKI

Chapter 3: Using eTrust PKI

Chapter 4: Certification Authority Rollover

eTrust PKI Administrator Guide

Chapter 5: Web Enrolment

Chapter 6: Batch Processing

Chapter 7: Software Development Kit (SDK)

Chapter 8: Setting Up HSMs

eTrust PKI Administrator Guide

Chapter 9: Cross Certification

Certificate Authority (CA) Server

Registration Authority (RA) Server

eTrust PKI Administrator Guide

Web Enrolment Server

Registration Authority (RA) Client

End Entity Software

This information can be used to generate reports.

eTrust PKI Administrator Guide

Setting Up eTrust PKI

Scaling eTrust PKIthe Tiered CA Approach

Setting Up eTrust PKI

Setting Up a CA/RA Host

Setting Up a CA/RA Host

eTrust PKI Administrator Guide

Starting the CA/RA Servers

Starting the CA/RA Servers

Setting Up eTrust PKI

Starting the CA/RA Servers

Setting Up the Servers to Start Automatically

eTrust PKI Administrator Guide

Setting Up a Distributed RA Client

Setting Up a Distributed RA Client

Task 1Creating Remote RA Client Configuration Information

Setting Up eTrust PKI

Setting Up a Distributed RA Client

Task 2Deploying the RAC Operators

Task 3Installing the Remote RA Client

eTrust PKI Administrator Guide

Setting Up a Distributed RA Client

Task 4Loading the Remote RA Client onto a Machine

Setting Up eTrust PKI

Installing a Distributed End Entity Client

Installing a Distributed End Entity Client

Task 1Creating End Entity Configuration Information

eTrust PKI Administrator Guide

Installing a Distributed End Entity Client

Task 2Deployment of the End Entity Tier

Task 3Installing the End Entity Client on the Distributed Machine

Setting Up eTrust PKI

Installing a Distributed End Entity Client

eTrust PKI Administrator Guide

Installing a Subordinate CA/RA Tier

Installing a Subordinate CA/RA Tier

Task 1Creating Subordinate CA/RA Tier Configuration Information

Setting Up eTrust PKI

Installing a Subordinate CA/RA Tier

Task 2Deploying the Subordinate CA/RA Tier

Task 3Installing the Subordinate CA/RA Tier

eTrust PKI Administrator Guide

Installing a Subordinate CA/RA Tier