iPlanet Certificate Management System 4.2

Installation and Setup Guide
iPlanet Certificate Management System
Version 4.2 - Service Pack 2
March 2001
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape
Communications Corporation. All rights reserved.
Sun, Sun Microsystems, the Sun logo, iPlanet, the iPlanet logo, Java, and Solaris are trademarks or registered
trademarks of Sun Microsystems, Inc. in the United States and other countries.
Netscape and the Netscape N logo are registered trademarks of Netscape Communications Corporation in
the U.S. and other countries. Other Netscape logos, product names, and service names are also trademarks
of Netscape Communications Corporation, which may be registered in other countries.
Federal Acquisitions: Commercial Software—Government Users Subject to Standard License Terms and
Conditions
The product described in this document is distributed under licenses restricting its use, copying, distribution,
and decompilation. No part of the product or this document may be reproduced in any form by any means
without prior written authorization of the Sun-Netscape Alliance and its licensors, if any.
THIS DOCUMENTATION IS PROVIDED “AS IS” AND ALL EXPRESS OR IMPLIED CONDITIONS,
REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE
EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.
_____________________________________________________________________________________________
Copyright © 2001 Sun Microsystems, Inc. Pour certaines parties préexistantes, Copyright © 2001 Netscape
Communication Corp. Tous droits réservés.
Sun, Sun Microsystems, iPlanet, the iPlanet logo, Java, et Solaris sont des marques de fabrique ou des
marques déposées de Sun Microsystems, Inc. aux Etats-Unis et d’autre pays.
Netscape et the Netscape N logo sont des marques déposées de Netscape Communications Corporation aux
Etats-Unis et d’autre pays. Les autres logos, les noms de produit, et les noms de service de Netscape sont
des marques déposées de Netscape Communications Corporation dans certains autres pays.
Le produit décrit dans ce document est distribué selon des conditions de licence qui en restreignent
l'utilisation, la copie, la distribution et la décompilation. Aucune partie de ce produit ni de ce document ne
peut être reproduite sous quelque forme ou par quelque moyen que ce soit sans l’autorisation écrite
préalable de l’Alliance Sun-Netscape et, le cas échéant, de ses bailleurs de licence.
CETTE DOCUMENTATION EST FOURNIE “EN L'ÉTAT”, ET TOUTES CONDITIONS EXPRESSES OU
IMPLICITES, TOUTES REPRÉSENTATIONS ET TOUTES GARANTIES, Y COMPRIS TOUTE GARANTIE
IMPLICITE D'APTITUDE À LA VENTE, OU À UN BUT PARTICULIER OU DE NON CONTREFAÇON SONT
EXCLUES, EXCEPTÉ DANS LA MESURE OÙ DE TELLES EXCLUSIONS SERAIENT CONTRAIRES À LA LOI.
Contents
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
What’s in This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
What You Should Already Know . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Conventions Used in This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Where to Go for Related Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Part
1 Overview and Demo Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Chapter 1 Introduction to Certificate Management System . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Overview of Key Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Flexible end-entity registration services framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Public-Key Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
CMS Subsystems or Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Certificate Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Registration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Data Recovery Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Online Certificate Status Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Basic System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Plug-in Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Authentication Plug-in Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Policy Plug-in Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Job Plug-In Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Mapper and Publisher Plug-in Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Event-Driven Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Auxiliary Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Command-Line Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
CMS SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Entry Points for Various Types of Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3
Agent Services Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Certificate Manager Agent Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Registration Manager Agent Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Recovery Manager Agent Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Online Certificate Status Manager Agent Services Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
End-Entity Services Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PKCS #11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
JSS and the Java/JNI Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Middleware/Java 2 Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Authentication and Policy Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Standards Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Certificate Management Formats and Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Security and Directory Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
68
69
70
71
72
73
75
76
76
76
77
77
77
78
Chapter 2 Certificate Enrollment and Life-Cycle Management . . . . . . . . . . . . . . . . . . . . . . . 81
Steps in End-Entity Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Some Enrollment Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Firewall Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Extranet/E-Commerce: Acme Sales Corp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Enrolling Existing Customers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Enrolling New Customers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Enrolling Extranet Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
PIN Registration: Atlas Manufacturing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
VPN Client Enrollment and Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Router Enrollment and Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
End Entities and Life-Cycle Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Life-Cycle Management Formats and Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Access to Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
HTML Forms for End Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Netscape Personal Security Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Chapter 3 Default Demo Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operating System and Software Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Platform Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Overview of the Default Demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Demo Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing the Default Demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 1. Run the Installation Script — UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 1. Run the Installation Script—Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
iPlanet Certificate Management System Installation and Setup Guide • March 2001
105
106
106
106
109
112
113
113
115
Step 2. Run the Installation Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Step 3. Get the First User Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Enrolling for the First Agent Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
If You Need the First Agent Form Again . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Using the Default Demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Verify the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Viewing Issued Certificates From the Agent Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Enrolling for a Certificate From the End-Entity Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Finding and Approving a Certificate Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Setting Your Browser to Use the Agent Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Testing Your New Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Create a Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Configuring an RSA Key Length Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Use an LDAP Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Step 1. Enable Directory-Based Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Step 2. Add a User to the Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Step 3. Enroll with Directory-Based Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Publish Certificates to an LDAP Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Configure the Publishing Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Set Rules for Publishing Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Update the Publishing Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Send Renewal Reminders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Configuring a Mail Server for Certificate Management System . . . . . . . . . . . . . . . . . . . . . . . . . 159
Configuring Certificate Management System to Send Renewal Reminders . . . . . . . . . . . . . . . 159
Part
2 Planning and Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Chapter 4 Planning Your Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Topology Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Server Groups and CMS Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Single Certificate Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Certificate Manager and Registration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Certificate Manager and Data Recovery Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Certificate Manager, Data Recovery Manager, and Registration Manager . . . . . . . . . . . . . . . . . . . 172
Cloned Certificate Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Certificate Authority Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
CA’s Distinguished Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
CA Signing Key Type and Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
CA Signing Certificate’s Validity Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Self-Signed Root Versus Subordinate CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
CAs and Certificate Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
5
6
CA Certificate Renewal or Reissuance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cryptographic Token Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Publishing Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Publishing to Certificates and CRLs to Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Publishing to Certificates and CRLs to a Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Publishing CRLs to the Online Certificate Status Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Subsystem Certificate Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SSL Server Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Certificate Manager Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Registration Manager Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Recovery Manager Certificate and Storage Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Online Certificate Status Manager Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Authentication Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Policy Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deployment Strategy and Port Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
178
179
179
180
180
181
182
182
182
183
184
184
185
185
186
Chapter 5 Installation Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Information for UNIX Installation Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installation Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration Directory Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
User/Group Directory Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration Directory Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Administration Server Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Certificate Management System Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Information for NT Installation Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installation Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration Directory Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
User/Group Directory Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration Directory Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration Directory Server Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Directory Server Administration Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Directory Manager Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Administration Server Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Certificate Management System Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Initial Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Internal Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remote Certificate Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remote Data Recovery Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Certificate Manager Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CA Signing Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
189
190
190
190
191
191
192
193
193
193
193
194
195
195
195
195
196
196
196
197
197
197
198
198
199
199
199
iPlanet Certificate Management System Installation and Setup Guide • March 2001
CA’s Serial Number Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Key-Pair Information for CA Signing Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Subject Name for CA Signing Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Validity Period for CA Signing Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Extensions for CA Signing Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
CA Signing Certificate Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Registration Manager Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Registration Manager Signing Certificate Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Key-Pair Information for Registration Manager Signing Certificate . . . . . . . . . . . . . . . . . . . . . 203
Subject Name for Registration Manager Signing Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Registration Manager Signing Certificate Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Data Recovery Manager Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Transport Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Key-Pair Information for Transport Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Subject Name for Transport Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Validity Period for Transport Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Extensions for Transport Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Transport Certificate Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Storage Key and Recovery Agent Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Storage Key Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Data Recovery Scheme—1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Data Recovery Scheme—2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Online Certificate Status Manager Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Online Certificate Status Manager Signing Certificate Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Key-Pair Information for Online Certificate Status Manager Signing Certificate . . . . . . . . . . . 210
Subject Name for Online Certificate Status Manager Signing Certificate . . . . . . . . . . . . . . . . . 210
Online Certificate Status Manager Signing Certificate Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Cloned Certificate Manager Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
CA Signing Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
CA’s Serial Number Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Cloned Key and Certificate Material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
SSL Server Key and Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
SSL Server Certificate Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
SSL Server Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Key-Pair Information for SSL Server Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Subject Name for SSL Server Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Validity Period for SSL Server Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Extensions for SSL Server Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
SSL Certificate Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Single Sign-On Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Chapter 6 Installing Certificate Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Installation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
7
8
Installation Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Before You Begin the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Stage 1. Running the Installation Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Running the Installation Script on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Running the Installation Script on Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Stage 2. Running the Installation Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing the Certificate Manager as a Root CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing the Certificate Manager as a Subordinate CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing a Standalone Registration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing a Standalone Data Recovery Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing a Online Certificate Status Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Stage 3. Enrolling for Administrator/Agent Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Agent Certificate for a Certificate Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Agent Certificate for Other CMS Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Stage 4. Further Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Stage 5. Creating Additional Instances or CA Clones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
218
219
221
221
224
227
229
232
244
255
266
277
277
280
283
284
Chapter 7 Installing and Uninstalling CMS Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing Multiple CMS Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cloning a Certificate Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 1. Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 2. Create Instances for Clone CAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing Clone CA in Master CA’s Server Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing Clone CA in a Different Server Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing Clone CA on a Separate Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 3. Shutdown the Master CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 4. Copy Master CA’s Certificate and Key Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 5. Start the Master CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 6. Configure the Clone CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 8. Establish Trust Between Master CA and Clone CAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step A. Locate the Master CA’s SSL Server Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step B. Create a Privileged-User Entry for Clone CAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 9. Test Clone-Master Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step A. Request a Certificate from the Clone CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step B. Approve the Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step C. Download the Certificate to the Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step D. Revoke the Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step E. Check Master CA’s CRL for the Revoked Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 10. Use Master CA’s Agent Certificate in Clone CAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing Instance Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing the Name of an Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Removing an Instance From a System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Uninstalling Certificate Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
285
286
288
289
291
291
292
293
293
294
294
294
295
296
298
301
301
302
302
303
303
304
305
307
308
310
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Uninstalling From the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Uninstalling by Using the Windows NT Add/Remove Programs Utility . . . . . . . . . . . . . . . . . . . 310
Upgrading From a Previous CMS Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Chapter 8 Starting and Stopping CMS Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Starting Certificate Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Required Start-up Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Configuring the Server to Start Without the Single Sign-On Password . . . . . . . . . . . . . . . . . . . 317
Configuring the Server to Read the Single Sign-on Password From a File . . . . . . . . . . . . . . . . 318
Starting From Netscape Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Starting From the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Starting From the Windows NT Services Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Stopping Certificate Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Stopping From Netscape Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Stopping From the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Stopping From the Windows NT Services Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Restarting Certificate Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Restarting From the CMS Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Restarting From the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Checking System Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Attending to an Unresponsive Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
CMS Watchdog Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Password Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Password-Quality Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Part
3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Chapter 9 Administration Tasks and Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Netscape Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Console Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Users and Groups Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Netscape Administration Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Starting Administration Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Shutting Down Administration Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Logging In to Netscape Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
The CMS Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Tasks Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Configuration Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Status Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Logging In to the CMS Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
9
Chapter 10 CMS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Effects of Installation Type on Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Duplicating Configuration From One Instance to Another . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Locating the Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifying the Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing the Configuration From the CMS Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing the Configuration by Editing the Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Guidelines for Editing the Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sample Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Road Map to Configuring Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 1. Check Which Subsystems are Installed in the Instance . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 2. Check the Port Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 3. Verify Key Pair and Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 4. Set up Privileged Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 5. Customize End-Entity and Agent Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 6. Setup Authentication for End Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 7: Enable Event-Driven Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 8. Schedule Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 9. Set up Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 10. Set up Publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 11. Set up Key Archival and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 12. Set up Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 13. Plan for Backing up CMS Configuration and Data . . . . . . . . . . . . . . . . . . . . . . . . . . . .
349
349
351
352
353
353
353
354
357
370
370
370
370
371
371
371
372
372
372
373
373
373
374
Chapter 11 Setting Up Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CMS Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remote Administration Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Agent Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
End-Entity Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring Port Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 1. Specify the Port Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 2: Specify IP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
375
375
376
377
377
378
378
381
Chapter 12 Setting Up Internal Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Internal Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the Internal Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 1. Identify the Directory Server Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 2. Restrict Access to the Internal Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
383
383
384
385
386
Chapter 13 Managing Privileged Users and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Privileged-User Types and Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
10
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Agent’s Certificate for SSL Client Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Revocation Status Checking of Agent Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Trusted Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Subsystems That Can Function as Trusted Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Connectors for Linking Trusted Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Trusted Manager’s Certificate for SSL Client Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Groups and Their Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Group for Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Groups for Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Group for Certificate Manager Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Group for Registration Manager Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Group for Data Recovery Manager Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Group for Online Certificate Status Manager Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Group for Trusted Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Setting Up Privileged Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Setting Up Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Step 1. Find the Required Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Step 2. Add the Information to the Internal Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Setting Up Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Setting up Agents Using the Automated Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Setting up Agents Using the Manual Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Setting Up Trusted Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Setting up Trusted Managers Using the Automated Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Setting Up a Registration Manager as a Trusted Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Setting Up a Certificate Manager as a Trusted Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Changing Privileged-User Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Changing a Privileged User’s Login Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Changing a Privileged User’s Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Changing Members in a Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Deleting a Privileged User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Chapter 14 Managing CMS Keys and Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Keys and Certificates for the Main Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Certificate Manager’s Key Pairs and Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
CA Signing Key Pair and Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
wTLS CA Signing Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
OCSP Signing Key Pair and Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
CRL Signing Key Pair and Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
SSL Server Key Pair and Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Remote Administration Server Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Registration Manager’s Key Pairs and Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Signing Key Pair and Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
11
SSL Server Key Pair and Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remote Administration Server Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Recovery Manager’s Key Pairs and Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transport Key Pair and Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Storage Key Pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SSL Server Key Pair and Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remote Administration Server Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Online Certificate Status Manager’s Key Pairs and Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OCSP Signing Key Pair and Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SSL Server Key Pair and Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remote Administration Server Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tokens for Storing CMS Keys and Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Internal Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
External Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing External Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managing Tokens Used by the Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing a Token’s Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hardware Cryptographic Accelerators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Certificate Setup Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the Wizard to Request a Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 1. Select the Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 2. Choose the Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 3. Specify the Key-Pair Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 4. Specify the Subject Name for the Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 5. Specify the Validity Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 6. Specify Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 7. Copy the Certificate Signing Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 8. Check the Certificate Request Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the Wizard to Install a Certificate or Certificate Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Formats for Installing Certificates and Certificate Chains . . . . . . . . . . . . . . . . . . . . . . . . .
Step 1. Select the Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 2. Select the Certificate or Certificate Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 3. Specify the Location of the Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 4. View the Certificate or Certificate Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 5. Install the Certificate or Certificate Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 6. Verify the Certificate Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the Server’s Security Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the Server to Use Separate SSL Server Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 1. Get the Required SSL Server Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 2: Update the Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Getting an SSL Client Certificate for a Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting Up Cipher Preferences for SSL Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
iPlanet Certificate Management System Installation and Setup Guide • March 2001
449
450
450
451
451
452
452
453
453
453
454
454
455
455
455
458
458
458
459
459
460
461
462
464
466
467
468
470
474
475
476
477
478
479
481
481
482
482
482
483
483
484
486
SSL Ciphers Supported in Certificate Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
Configuring the Server to Use Specific Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Getting New Certificates for the Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Step 1. Plan for the New Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Step 2. Request the New Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Step 3. Install the New Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Step 4. Deploy the New Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Deploying Certificate Manager’s CA Signing Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Deploying Registration Manager’s Signing Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Deploying Data Recovery Manager’s Transport Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Deploying a Subsystem’s SSL Server Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Renewing Certificates for the Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Step 1. Plan for Certificate Renewal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
Step 2. Renew the Existing Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Step 3. Install the Renewed Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Step 4. Deploy the Renewed Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Deploying Certificate Manager’s Renewed CA Signing Certificate . . . . . . . . . . . . . . . . . . . . . . 501
Deploying Registration Manager’s Renewed Signing Certificate . . . . . . . . . . . . . . . . . . . . . . . . 501
Deploying Data Recovery Manager’s Renewed Transport Certificate . . . . . . . . . . . . . . . . . . . . 502
Deploying a Subsystem’s Renewed SSL Server Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
Step 5. Restart the Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
Managing the Certificate Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Viewing the Certificate Database Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Deleting a Certificate From the Certificate Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
Changing the Trust Settings of a CA Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
Installing a New CA Certificate in the Certificate Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
Installing a CA Certificate Chain in the Certificate Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Chapter 15 Setting Up End-User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Introduction to Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Privileged-User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Authentication of Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Authentication of Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
End-Entity Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Authentication of End Entities During Certificate Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Authentication of End Users During Certificate Renewal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Authentication of End Users During Certificate Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
Configuring Authentication for End-User Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
Step 1. Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
Step 2. Set Up the Directory for PIN-Based Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
Step A. Check the Directory for User Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
Step B. Update the Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
Step C. Prepare the Input File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
13
14
Step D. Run the Command Without the Write Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step E. Check the Output File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step F. Run the Command Again with the Write Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 3. Enable the AttributePresentConstraints Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 4: Add an Authentication Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 5. Set Up the Enrollment Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step A. Associate the Authentication Instance With the Enrollment Form . . . . . . . . . . . . . . . .
Step B. Customize the Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step C. Hook Up the Certificate-Based Enrollment Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step D. Remove Unwanted Enrollment Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 6. Enable End-Entity Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling End-Entity Interaction with a Certificate Manager . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling End-Entity Interaction with a Registration Manager . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 7. Turn on Automated Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 8. Test Your Authentication Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 9. Deliver PINs to End Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managing Authentication Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deleting an Authentication Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifying an Authentication Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managing Authentication Plug-in Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Registering an Authentication Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deleting an Authentication Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
529
530
530
530
533
538
538
539
539
542
543
543
545
546
546
548
548
548
549
551
551
553
Chapter 16 Setting Up Automated Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Automated Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Notifications of Certificate Issuance to End Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Notification of New Request in Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Customizing Notification Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Templates for Event-Triggered Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Customizing Message Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tokens Available in Message Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tokens for Certificate Issuance Notifications to End Entities . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tokens for Rejection Notifications to End Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tokens for Request In Queue Notification Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring a Subsytem to Send Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 1. Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 2. Turn On Certificate-Issuance Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 3. Turn on Request in Queue Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 4. Verify Mail Server Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 5. Test Your Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
555
555
556
557
558
558
560
561
561
562
563
563
564
564
565
566
567
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Chapter 17 Scheduling Automated Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
Configuring a Subsystem to Run Automated Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
Step 1. Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570
Step 2. Modify Existing Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570
Step 3. Delete Unwanted Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573
Step 4. Add New Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573
Step 5. Schedule the Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
Step 6. Verify Mail Server Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
Step 7. Test Your Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
Managing Job Plug-in Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
Registering a Job Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
Deleting a Job Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
Chapter 18 Setting Up Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Introduction to Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
What Is Policy? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Policy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Types of Policy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Using Predicates in Policy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Expression Support for Predicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Attributes for Predicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Policy Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Configuring Policy Rules for a Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Step 1. Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
Step 2. Modify Existing Policy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
Step 3. Delete Unwanted Policy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Step 4. Add New Policy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Step 5. Reorder Policy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Step 6. Restart the Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
Step 7. Test Policy Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
Step A. Enroll for a Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
Step B. Approve the Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
Step C. Check the Certificate Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
Using JavaScript for Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
Managing Policy Plug-in Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
Registering a Policy Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
Deleting a Policy Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
Chapter 19 Setting Up LDAP Publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
Publishing of Certificates to a Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
Timing of Directory Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
Directory Update Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
Directory Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
15
16
Publishing of CRLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
What’s a CRL? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reasons for Revoking a Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Revocation Checking by Netscape Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Revocation Checking by Netscape Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Publishing of CRLs to an LDAP Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CRL Issuing Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring a Certificate Manager to Publish Certificates and CRLs . . . . . . . . . . . . . . . . . . . . . . . . .
Step 1. Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 2. Set Up the Directory for Publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step A. Verify the Directory Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step B. Add an Entry for the CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step C. Identify an Entry That Has Write Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step D. Verify Entries for End Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step E. Specify the Directory Authentication Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step F. Modify the Certificate Mapping File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step G. Restart Directory Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 3. Configure the Certificate Manager to Publish Certificates . . . . . . . . . . . . . . . . . . . . . . . . . .
Step A. Modify the Default Mappers, Publishers, and Publishing Rules . . . . . . . . . . . . . . . . .
Step B. Add Mappers, Publishers, and Publishing Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 4. Configure the Certificate Manager to Publish CRLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step A. Specify CRL Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step B. Set the CRL Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step C. Create a Mapper for the CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step D. Create a Publisher for the CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step E. Create a Publishing Rule for the CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 5. Identify the Publishing Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 6. Test Certificate and CRL Publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step A. Decide a Directory Entry for Requesting a Certificate . . . . . . . . . . . . . . . . . . . . . . . . . .
Step B. Request a Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step C. Approve the Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step D. Download the Certificate to the Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step E. Check if the Directory Has the Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step F. Revoke the Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step G. Check the Directory for the CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manually Updating Certificates and CRLs in a Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manually Updating Certificates in the Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manually Updating the CRL in the Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
614
615
616
617
617
618
619
619
620
622
622
623
625
625
626
636
640
640
640
646
652
653
655
656
657
659
660
662
663
663
663
664
664
665
666
666
667
668
Chapter 20 Publishing Certificates and CRLs to a File . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring Certificate Manager to Publish to Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 1. Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 2. Configure the Certificate Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
671
671
672
673
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Step A. Create a Publisher for the File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step B. Create Publishing Rules for Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step C. Create a Publishing Rule for CRLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step D. Specify CRL Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step E. Set the CRL Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step F. Make Sure Publishing is Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 3. Test Publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step A. Request a Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step B. Approve the Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step C. Download the Certificate to the Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step D. Check the File for the Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step E. Revoke the Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step F. Check the File for the CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managing Mapper and Publisher Plug-in Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Registering a Mapper or Publisher Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deleting a Mapper or Publisher Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
673
675
677
678
680
682
682
682
683
684
684
686
687
689
689
691
Chapter 21 Setting Up an OCSP Responder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
What’s an OCSP-Compliant PKI Setup? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
How to Get an OCSP Responder? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696
How Certificate Manager’s OCSP-Service Feature Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696
How Online Certificate Status Manager Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
How to Get OCSP-Compliant Clients? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
Setting Up a Certificate Manager with OCSP Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
Step 1. Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
Step 2. Install OCSP-Compliant Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
Step 3. Enable Certificate Manager’s HTTP Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
Step 4. Enable Certificate Manager’s OCSP Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
Step 5. Configure Certificate Manager for Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
Step 6. Restart the Certificate Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
Step 7. Test Your CA’s OCSP Service Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Step A. Turn On Revocation Checking in the Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Step B. Request a Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
Step C. Approve the Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
Step D. Download the Certificate to the Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
Step E. Make Sure the CA is Trusted by the Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
Step F. Verify the Certificate in the Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
Step G. Check the Status of Certificate Manager’s OCSP Service . . . . . . . . . . . . . . . . . . . . . . . . 710
Step H. Revoke the Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
Step I. Verify the Certificate in the Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
Step J. Check the Certificate Manager’s OCSP Service Status Again . . . . . . . . . . . . . . . . . . . . . 711
Setting Up a Remote OCSP Responder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
Step 1. Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
17
18
Step 2. Install an OCSP-Compliant Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 3. Identify the CA to the OCSP Responder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 4. Configure the Certificate Manager to Publish CRLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step A. Specify CRL Format and Publishing Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step B. Set the CRL Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step C. Create a Publisher for the CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step D. Create a Publishing Rule for the CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step E. Make Sure Publishing is Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 5. Configure Certificate Manager for Required Extension Policies . . . . . . . . . . . . . . . . . . . . .
Step 6. Configure the Online Certificate Status Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 7. Restart the Certificate Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 8. Restart the Online Certificate Status Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 9. Verify Certificate Manager and Online Certificate Status Manager Connection . . . . . . .
Step 10. Test Your OCSP Responder Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step A. Turn On Revocation Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step B. Request a Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step C. Approve the Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step D. Download the Certificate to the Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step E. Make Sure the CA is Trusted by the Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step F. Verify the Certificate in the Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step G. Check the Status of Online Certificate Status Manager . . . . . . . . . . . . . . . . . . . . . . . . .
Step H. Revoke the Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step I. Verify the Certificate in the Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step J. Check the Online Certificate Status Manager Status Again . . . . . . . . . . . . . . . . . . . . . . .
714
715
717
717
719
720
722
724
725
727
731
732
732
733
733
734
734
735
735
736
736
737
737
737
Chapter 22 Setting Up Key Archival and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PKI Setup for Key Archival and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clients That Can Generate Dual Key Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Recovery Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Forms for Users and Key Recovery Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Key Archival Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Why You Should Archive Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Where the Keys are Stored . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How Key Archival Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Key Recovery Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Key Recovery Agents and Their Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Secret Sharing of Storage Key Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interface for the Key Recovery Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Local Versus Remote Key Recovery Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How Agent-Initiated Key Recovery Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Key Recovery Agent Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing the Key Recovery Agent Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing Key Recovery Agents’ Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
739
739
740
740
741
741
741
742
743
745
745
745
746
747
748
751
751
753
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Configuring Key Archival and Recovery Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755
Step 1. Set Up the Key Archival Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755
Step A. Deploy Clients That Can Generate Dual Key Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756
Step B. Connect the Enrollment Authority and the Data Recovery Manager . . . . . . . . . . . . . . 756
Step C. Customize the Certificate Enrollment Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
Step D. Configure Key Archival Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
Step 2. Set Up the Key Recovery Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
Step A. Verify the m of n Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
Step B. Facilitate the Key Recovery Agents to Change the Passwords . . . . . . . . . . . . . . . . . . . . 763
Step C. Determine the Authorization Mode for Key Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . 763
Step D. Customize the Key Recovery Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763
Step E. Configure Key Recovery Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
Step 3. Test Your Key Archival and Recovery Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
Step A. Test Your Key Archival Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
Step B. Verify the Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
Step C. Delete the Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
Step D. Test Your Key Recovery Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
Step D. Restore the Key in the Browser’s Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
Chapter 23 Managing CMS Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
Introduction to Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
Logs Maintained by the Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770
Services That Are Logged . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
Log Levels (Message Categories) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772
Log File Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
Log File Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774
Active Log File Naming Convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774
Rotated Log File Naming Convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774
Buffered Versus Unbuffered Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774
Rotation of Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
Timing of Log File Rotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
Location of Rotated Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776
Deletion of Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776
How to Conserve Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776
Timing of Log File Deletion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776
Configuring CMS Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
Step 1. Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
Step 2. Modify the Existing Listeners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
Step 3. Delete Unwanted Listeners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
Step 4. Create New Listeners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
Monitoring CMS Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783
Monitoring System Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
Monitoring Error Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786
19
Monitoring Audit Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using System Tools for Monitoring the Server (Windows NT Only) . . . . . . . . . . . . . . . . . . . . . . .
Logging to Windows NT Event Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Event Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Avoiding Event Log From Getting Filled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Archiving of Rotated Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Signing Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managing Log Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Registering a Log Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deleting a Log Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part
20
788
791
791
791
792
793
794
796
796
797
4 Issuing and Managing Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
Chapter 24 Issuing and Managing Server Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Certificate Issuance to Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How the Manual Server Enrollment Process Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Getting Server SSL Certificates for Netscape Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Getting Certificates for Version 3.x Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 1. Generate the Server Certificate Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 2. Submit the Server Certificate Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 3. Install Your Server’s SSL Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 4. Accept a CA as Trusted in Your Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 5. Verify Your Server’s SSL and CA Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Getting Certificates for Netscape Version 4.x Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Renewal of Server Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Revocation of Server Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
801
801
802
804
804
805
806
807
807
809
809
811
811
Chapter 25 Setting Up CEP Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CEP Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CEP Enrollment Using the Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting up CEP Enrollment Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 1. Set up the Directory for Publishing Certificates and CRLs . . . . . . . . . . . . . . . . . . . . . . . . .
Step 2. Configure the Certificate Manager for Publishing Certificates and CRLs . . . . . . . . . . . . .
Step 3. Set Up Automated Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 4. Set Up Multiple CEP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Certificate Issuance to Routers or VPN Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 1. Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 2. Generate the Key Pair for the Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 3. Request the CA’s Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 4. Submit the Certificate Request to the CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
813
813
814
815
816
817
820
824
825
826
827
828
828
829
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Part
5 Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831
Appendix A Certificate Download Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
Binary Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
Text Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834
Importing Certificate Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835
Importing Certificates into Netscape Communicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835
Importing Certificates into Netscape Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
Object Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
Appendix B Using SSL with iPlanet Web Server, Enterprise Edition 4.x . . . . . . . . . . . . . . 839
Creating a New Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840
Obtaining a Server Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841
Creating a Trust Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841
Submitting a Certificate Signing Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
Importing the Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
Enabling SSL on the Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846
Enabling Encryption on the Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847
Trusting the Root CA Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847
Enabling Client Authentication for All Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848
Specifying the Authentication Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849
Note for CGI Programmers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 850
Modifying the Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 850
Modifying the Access Control Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
Testing Client Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
Appendix C Export Control Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
Approved Export Operations and Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858
SSL Cipher Suite Profiles for Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 860
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 861
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
21
22
iPlanet Certificate Management System Installation and Setup Guide • March 2001
About This Guide
The Installation and Setup Guide explains how to install, configure, and maintain
iPlanet Certificate Management System (CMS), and use it for issuing and
managing certificates to various end entities, such as web browsers (users), servers,
Virtual Private Network (VPN) clients, and Cisco™ routers.
This preface has the following sections:
•
What’s in This Guide (page 23)
•
What You Should Already Know (page 26)
•
Conventions Used in This Guide (page 27)
•
Where to Go for Related Information (page 28)
What’s in This Guide
This guide covers topics that are listed below. You should use this guide in
conjunction with the other CMS documentation, such as the ones that explain all
the plug-ins and command-line tools that are provided for Certificate Management
System. For a complete list of CMS documentation, see section “Where to Go for
Related Information” on page 28.
•
“About This Guide” Describes what’s covered in this guide, what you should
already know, and where to look for more information.
Part 1, “Overview and Demo Installation”
•
Chapter 1, “Introduction to Certificate Management System” Provides an
overview of the Certificate Management System architecture for creating,
deploying, and managing certificates.
•
Chapter 2, “Certificate Enrollment and Life-Cycle Management” Provides
sample deployment scenarios.
•
Chapter 3, “Default Demo Installation” Describes how to set up a simple pilot
that demonstrates the basic capabilities of a Certificate Manager.
23
What’s in This Guide
Part 2, “Planning and Installation”
•
Chapter 4, “Planning Your Deployment” Reviews basic decisions you should
make as you plan your initial deployment.
•
Chapter 5, “Installation Worksheet” Provides a worksheet you can copy and
use to collect the detailed information that you will need to provide during
installation and configuration of individual subsystems.
•
Chapter 6, “Installing Certificate Management System” Describes the
procedure for installing CMS subsystems on the basis of the information
collected in Chapter 5.
•
Chapter 7, “Installing and Uninstalling CMS Instances” Describes how to
create multiple instances, delete unwanted instances, clone instances, upgrade
from a previous CMS version, and so on.
•
Chapter 8, “Starting and Stopping CMS Instances” Describes how to start,
restart, and stop CMS instances.
Part 3, “Configuration”
24
•
Chapter 9, “Administration Tasks and Tools” Explains the GUI-based
administration tools, Netscape Console and CMS window.
•
Chapter 10, “CMS Configuration” Shows a sample configuration file and
explains the rules for editing the configuration file.
•
Chapter 11, “Setting Up Ports” Describes various ports used by a CMS instance
and explains how to set up these ports.
•
Chapter 12, “Setting Up Internal Database” Describes the function of internal
database and explains how to set it up.
•
Chapter 13, “Managing Privileged Users and Groups” Describes privileged
users, their access rights, and how to create them for managing a CMS instance.
•
Chapter 14, “Managing CMS Keys and Certificates” Describes keys and
certificates used by a CMS instance and explains how to renew and reissue
them. Also provides information on installing hardware tokens.
•
Chapter 15, “Setting Up End-User Authentication” Describes authentication
methods for different types of CMS users, and explains how to configure a
Certificate Manager or Registration Manager to use a specific authentication
method for end-user enrollment.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
What’s in This Guide
•
Chapter 16, “Setting Up Automated Notifications” Describes how to enable the
automated notification feature—such as notifying agents when a request gets
queued and notifying users when their certificates are issued—to ease
administration overheads.
•
Chapter 17, “Scheduling Automated Jobs” Describes how to schedule jobs that
automatically perform certain certificate-related tasks at regular
intervals—such as removing expired certificates from the directory and
notifying users before their certificates expire—to ease administration
overheads.
•
Chapter 18, “Setting Up Policies” Describes how to configure a CMS manager
to use policy rules that govern the formulation and issuance of certificate
content, such as key size, signing algorithm, validity period, extensions, and so
on.
•
Chapter 19, “Setting Up LDAP Publishing” Provides an overview of LDAP
publishing and describes how to configure a Certificate Manager to publish
certificates and CRLs to an LDAP directory.
•
Chapter 20, “Publishing Certificates and CRLs to a File” Describes how to
configure a Certificate Manager to publish certificates and CRLs to files for
importing to other repositories.
•
Chapter 21, “Setting Up an OCSP Responder” Provides an overview of
OCSP-compliant PKI setup and describes how to set up an OCSP-compliant
PKI setup.
•
Chapter 22, “Setting Up Key Archival and Recovery” Describes how to archive
end users’ encryption private keys and recover them, if there’s a need.
•
Chapter 23, “Managing CMS Logs” Describes how to enable logging, use logs
to monitor the server’s activities, and archive log files.
Part 4, “Issuing and Managing Certificates”
•
Chapter 24, “Issuing and Managing Server Certificates” Describes how to issue
SSL server certificates to other servers and manage the certificates.
•
Chapter 25, “Setting Up CEP Enrollment” Describes how to configure the
server to issue router and VPN client certificates.
Part 5, “Appendixes”
•
Appendix A, “Certificate Download Specification” Describes the data formats
used by Netscape Communicator 4.x for installing certificates.
About This Guide
25
What You Should Already Know
•
Appendix B, “Using SSL with iPlanet Web Server, Enterprise Edition 4.x”
Explains how to set up client certificate authentication to work with Netscape
Enterprise Server 3.x.
•
Appendix C, “Export Control Information” Summarizes the cryptographic
operations, key lengths, and cipher suites that have received US government
approval for the export version of Certificate Management System.
Glossary
Summarizes terms used in this guide and other CMS documentation.
What You Should Already Know
This guide is intended for experienced system administrators who are planning to
deploy Certificate Management System. CMS agents should refer to iPlanet
Certificate Management System Agent’s Guide for information on how to perform
agent tasks, such as handling certificate requests and revoking certificates.
This guide assumes that you
•
•
26
Are familiar with the basic concepts of public-key cryptography and the Secure
Sockets Layer (SSL) protocol.
❍
SSL cipher suites
❍
The purpose of and major steps in the SSL handshake
Understand the concepts of intranet, extranet, and the Internet security and the
role of digital certificates in a secure enterprise. These include the following
topics:
❍
Encryption and decryption
❍
Public keys, private keys, and symmetric keys
❍
Significance of key lengths
❍
Digital signatures
❍
Digital certificates, including various types of digital certificates
❍
The role of digital certificates in a public-key infrastructure (PKI)
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Conventions Used in This Guide
❍
Certificate hierarchies
If you are new to these concepts, we recommend you read the security-related
documents available online at this URL:
http://docs.iplanet.com/docs/manuals/security.html
You may also refer to the security-related appendixes (Appendix D and
Appendix E) of the accompanying manual, Managing Servers with Netscape
Console.
•
Are familiar with the role of Netscape Console in managing Netscape version
4.x servers. Otherwise, see the accompanying manual, Managing Servers with
Netscape Console.
•
Are reading this guide in conjunction with the documentation listed in section
“Where to Go for Related Information” on page 28.
Conventions Used in This Guide
The following conventions are used in this guide:
•
Monospaced font—This typeface is used for any text that appears on the
computer screen or text that you should type. It’s also used for filenames,
functions, and examples.
Example: Server Root is the directory where the CMS binaries are kept.
•
Italic—Italic type is used for emphasis, book titles, and glossary terms.
Example: This control depends on the access permissions the superadministrator
has set up for you.
•
Text within “quotation marks”—Indicates cross-references to other topics
within this guide.
Example: For more information, see “Issuing a Certificate to a New User” on
page 154.
•
Boldface—Boldface type is used for various UI components such as captions
and field names, and the terminology explained in the glossary.
Example:
Rotation frequency. From the drop-down list, select the interval at which the
server should rotate the active error log file. The available choices are Hourly,
Daily, Weekly, Monthly, and Yearly. The default selection is Monthly.
About This Guide
27
Where to Go for Related Information
•
Monospaced [ ]—Square brackets enclose commands that are optional.
Example: PrettyPrintCert <input_file> [<output_file>]
<input_file> specifies the path to the file that contains the base-64
encoded certificate.
<output_file> specifies the path to the file to write the certificate. This
argument is optional; if you don’t specify an output file, the certificate
information is written to the standard output.
•
Monospaced <>—Angle brackets enclose variables or placeholders. When
following examples, replace the angle brackets and their text with text that
applies to your situation. For example, when path names appear in angle
brackets, substitute the path names used on your computer.
Example: Using Netscape Communicator 4.7 or later, enter the URL for the
administration server: http://<hostname>:<port_number>
•
/—A slash is used to separate directories in a path. If you use the Windows NT
operating system, you should replace / with \ in paths.
Example: Except for the Security Module Database Tool, you can find all the
other command-line utilities at this location: <server_root>/bin/cert/tools
•
Sidebar text—Sidebar text marks important information. Make sure you read
the information before continuing with a task.
Examples:
NOTE
CAUTION
You can use Netscape Console only when Administration Server is
up and running.
A caution note documents a potential risk of losing data, damaging
software or hardware, or otherwise disrupting system performance.
Where to Go for Related Information
This section summarizes the documentation that ships with Certificate
Management System, using these conventions:
•
28
<server_root> is the directory where the CMS binaries are kept (which you
specify during installation).
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Where to Go for Related Information
•
<instance_id> is the ID for this instance of Certificate Management System
(specified during installation).
The documentation set for Certificate Management System includes the following:
•
Managing Servers with Netscape Console
Provides background information on basic cryptography concepts and the role
of Netscape Console. To view the HTML version of this guide, open this file:
<server_root>/manual/en/admin/help/contents.htm
•
iPlanet Certificate Management System Installation and Setup Guide (this guide)
Describes how to plan for, install, and administer Certificate Management
System. To access the installation and configuration information from within
the CMS Installation Wizard or from the CMS window (within Netscape
Console), click any help button.
To view the HTML version of this guide, open this file:
<server_root>/manual/en/cert/setup_guide/contents.htm
To view the PDF version of this guide, open this file:
<server_root>/manual/en/cert/pdf/cms42sp2setup.pdf
•
iPlanet Certificate Management System Plug-ins Guide
Provides detailed reference information on CMS plug-ins. To access this
information from the CMS window within Netscape Console, click any help
button.
To view the HTML version of this guide, open this file:
<server_root>/manual/en/cert/plugin_guide/contents.htm
To view the PDF version of this guide, open this file:
<server_root>/manual/en/cert/pdf/cms42sp2plugin.pdf
•
iPlanet Certificate Management System Command-Line Tools Guide
Provides detailed reference information on CMS tools.
To view the HTML version of this guide, open this file:
<server_root>/manual/en/cert/tools_guide/contents.htm
To view the PDF version of this guide, open this file:
<server_root>/manual/en/cert/pdf/cms42sp2tools.pdf
•
iPlanet Certificate Management System Customization Guide
Provides detailed reference information on customizing the HTML-based
agent and end-entity interfaces.
About This Guide
29
Where to Go for Related Information
To view the HTML version of this guide, open this file:
<server_root>/manual/en/cert/custom_guide/contents.htm
To view the PDF version of this guide, open this file:
<server_root>/manual/en/cert/pdf/cms42sp2custom.pdf
•
iPlanet Certificate Management System Agent’s Guide
Provides detailed reference information on CMS agent interfaces. To access
this information from the Agent Services pages, click any help button.
To view the HTML version of this guide, open this file:
<server_root>/cert-<instance_id>/web/agent/manual/agent_guide/
contents.htm
To view the PDF version of this guide, open this file:
<server_root>/manual/en/cert/pdf/cms42sp2agent.pdf
•
End-entity help (online only, not printed)
Provides detailed reference information on CMS end-entity interfaces. To
access this information from the end-entity pages, click any help button.
To view the HTML version of this guide, open this file:
<server_root>/cert-<instance_id>/web/ee/manual/ee_guide/
contents.htm
NOTE
Do not change the default location of any of the HTML files; they
are used for online help. You may move the PDF files to another
location.
For a complete list of all documentation for Certificate Management System,
including documentation for Directory Server, see Documentation Summary,
located at: <server_root>/manual/index.html
For the latest information about Certificate Management System, including current
release notes, technical notes, and deployment information, check this site:
http://docs.iplanet.com/docs/manuals/cms.html
30
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Part
1
Overview and Demo Installation
Chapter 1, “Introduction to Certificate Management System”
Chapter 2, “Certificate Enrollment and Life-Cycle Management
Chapter 3, “Default Demo Installation”
31
32
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Chapter
1
Introduction to Certificate
Management System
This chapter introduces iPlanet Certificate Management System (CMS), a highly
configurable set of software components and tools for creating, deploying, and
managing certificates. Based on open standards for certificate management,
Certificate Management System leverages Netscape Directory Server and Netscape
Console to provide a complete, scalable, high-performance certificate management
solution for extranets and intranets.
Whether you are looking for a security solution for your enterprise or setting up an
independent certificate authority (CA) service, Certificate Management System
offers a robust, customizable, and scalable foundation for your public-key
infrastructure (PKI).
The chapter has the following sections:
•
Overview of Key Features (page 34)
•
System Overview (page 42)
•
Auxiliary Components (page 64)
•
Entry Points for Various Types of Users (page 66)
•
System Architecture (page 73)
•
Standards Summary (page 77)
This guide assumes that you are familiar with the concepts of public-key
cryptography and digital certificates. For a list of key concepts and information on
where to learn more about them, see “What You Should Already Know” on
page 26.
33
Overview of Key Features
Overview of Key Features
Certificate Management System has many core features:
Support for open standards
With its support for open standards, Certificate Management System gives
organizations confidence that they will be able to communicate within a
heterogeneous computing environment. Specifically, Certificate Management
System does the following:
•
Formulates, signs, and issues industry-standard X.509 version 3 public-key
certificates; version 3 certificates include extensions that make it easy to
include organization-defined attributes. This means that you can use these
certificates for extranet and Internet authentication as well.
For details on setting extensions in certificates, see Chapter 18, “Setting Up
Policies.”
34
•
Supports issuance of Wireless Transport Layer Security (wTLS)-compliant
certificates for use with wireless applications.
•
Supports RSA public-key algorithm for signing and encryption, DSA
public-key algorithm for signing, and MD2, MD5, and SHA-1 for hashing.
•
Supports signature key lengths of up to 1024 bits (DSA) and 4096 (RSA) on
both hardware and software tokens. For details, see Appendix C, “Export
Control Information.”
•
Supports multiple message formats, such as KEYGEN/SPAC, CRMF/CMMF,
CRS/CEP/SCEP, and PKCS #10 and CMC for certificate requests. All requests
are delivered to Certificate Management System over HTTP or HTTPS; in the
case of CRS/CEP/SCEP protocol, the delivery method is always over HTTP.
For a description of the acronyms, see “Standards Summary” on page 77.
•
Supports certificate formats that encompass certificates for SSL-based client
and server authentication, secure Multipurpose Internet Mail Extensions
(S/MIME) message signing and encryption, object signing, VPN clients, and
Cisco™ routers.
•
Supports generation and publication of CRLs conforming to X.509 version 1
and 2.
•
Publishes certificates and certificate revocation lists (CRLs) to the any
LDAP-compliant directory over LDAP and HTTP/HTTPS connections. For
more information, see Chapter 19, “Setting Up LDAP Publishing. ”
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Overview of Key Features
•
Publishes certificates and CRLs to a flat file for importing into other resources.
For example, the sample code for Flat File CRL and certificate publisher can be
customized to store certificates and CRLs in an Oracle RDBMSTM. For more
information, see Chapter 20, “Publishing Certificates and CRLs to a File.”
•
Publishes CRLs to an online validation authority (or OCSP responder),
enabling real-time verification of certificates by OCSP-compliant clients. For
more information, see Chapter 21, “Setting Up an OCSP Responder.”
Separate subsystems for certificate and key operations
Certificate Management System includes four servers, the Certificate Manager,
Registration Manager, Data Recovery Manager, and Online Certificate Status Manager.
•
The Certificate Manager functions as the certificate authority (CA); it is the
entity named in the issuer field of a certificate. The Certificate Manager can
sign and revoke certificates and generate CRLs. It can accept certificate
requests directly from end entities and via Registration Managers to which it
has delegated certain certificate management functions, such as authentication
of an end entity. The Certificate Manager also maintains a database of issued
certificates so that it can track renewal, expiration, and revocation.
•
The Registration Manager is an optional component in the PKI; it is a
subordinate server to which a Certificate Manager can delegate some
certificate management functions. For example, a Registration Manager may
act as a front end to a Certificate Manager, performing tasks such as end-entity
authentication and formulation of the certificate request for the Certificate
Manager.
•
The Data Recovery Manager is an optional component in the PKI. It provides
key archival and recovery services for end users’ encryption private keys.
•
The Online Certificate Status Manager is an optional, but important
component in the PKI. It enables real-time verification of certificates issued by
one or more Certificate Managers.
For an overview of these subsystems, see “CMS Subsystems or Managers” on
page 44.
Chapter 1
Introduction to Certificate Management System
35
Overview of Key Features
Single CA supports multiple registration authorities
Certificate Management System lets you separate the registration process from the
certificate-signing process with the help of Registration Managers. You can run
multiple Registration Managers remotely, all reporting to a single Certificate
Manager, to verify user identities and process certificate signing requests. The
remote Registration Managers forward their completed and approved requests to
the Certificate Manager for it to sign and issue the certificate automatically.
The Certificate Manager’s ability to support multiple Registration Managers makes
it more scalable and also adds an extra layer of security for the CA. For example,
you can set a policy that requires all clients to go through a remote Registration
Manager, and then have the remote Registration Manager route all client requests
to the Certificate Manager located inside a firewall.
For more information, see “Trusted Managers” on page 398.
Ability to function as both a root and a subordinate CA in a CA
hierarchy
Certificate Management System can function as a root or parent CA; in this case, the
server signs its own CA signing key as well as other CA signing keys, enabling you
to create your own CA hierarchy. You can also install the server to function as a
subordinate CA; in this case, the server gets its CA signing key signed by another CA
in an existing CA hierarchy.
For details on installing the Certificate Manager as a root or subordinate CA, see
Part 2, “Planning and Installation.”
Ability to function as a linked CA
Certificate Management System can function as a linked CA, chaining up to many
third-party or public CAs for validation; this provides cross-company trust, so
applications can verify certificate chains outside the company certificate hierarchy.
You chain a Certificate Manager to a third-party CA by requesting the Certificate
Manager’s CA signing certificate from the third-party CA.
For details on installing the Certificate Manager as a linked CA, see Part 2,
“Planning and Installation.”
36
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Overview of Key Features
CA scalability via cloning
If you don’t want to create a CA hierarchy comprising root and subordinate CAs,
you can create multiple clones of a Certificate Manager and configure each clone to
issue certificates that fall within a distinct range of serial numbers. Because clone
CAs use the same CA signing key and certificate (as that of the master CA) to sign
the certificates they issue, the issuer name in all the certificates in your PKI setup
would be the same (as if they’ve been issued by a single CA).
For details on cloning a Certificate Manager, see “Cloning a Certificate Manager”
on page 288.
PKCS #11 hardware support for smart cards and crypto accelerators
Certificate Management System supports smart cards and crypto accelerators
provided by various third-party vendors of PKCS #11 version 2.1-compliant
products. For a complete list of vendors, check this site:
http://www.iplanet.com/products/infrastructure/dir_security/cert_sy
s/index.html
You can configure the server to use different PKCS #11 modules to generate and
store key pairs (and certificates) for the Certificate Manager, Registration Manager,
and Data Recovery Manager. Using hardware for key storage (especially for
Certificate Manager and Data Recovery Manager key pairs) reduces the risk of key
compromise, because hardware tokens don’t reveal keys or provide means for
them to be revealed, once the keys are generated in the hardware. Note that
PKCS#11 hardware devices also provide key backup and recovery features for
backup and recovery of the key material stored on the hardware token. Be sure to
refer to the PKCS #11 vendor documentation on this subject.
For information on configuring Certificate Management System to use hardware
tokens for generating and storing its key pairs and certificates, see “Tokens for
Storing CMS Keys and Certificates” on page 454.
Support for Netscape client and server products; client independence
for non-Netscape products
Certificates issued by Certificate Management System work with existing Netscape
client and server products that support SSL. The certificates also work (out of the
box) with a variety of non-Netscape, standards-compliant applications. For a
complete list of these products, see the information available at this URL:
http://www.iplanet.com/products/infrastructure/dir_security/cert_sy
s/index.html
Chapter 1
Introduction to Certificate Management System
37
Overview of Key Features
Highly scalable certificate data store
Certificate Management System uses a highly scalable, high-performance
certificate storage facility—a preconfigured version of Netscape Directory Server
4.x that’s automatically installed with Certificate Management System—enabling
you to issue and manage a large number of certificates. For more information, see
Chapter 12, “Setting Up Internal Database.”
Flexible end-entity registration services framework
The registration services framework for end entities includes the most commonly
expected PKI features: manual, directory-based, directory- and PIN-based,
NIS-based, and portal enrollments; certificate-authenticated renewals and
revocations (based on SSL client authentication); certificate life-cycle operations
that include automated certificate renewal and expiration notifications. These
features are available out of the box for both Certificate Manager and Registration
Manager.
For information on enrollment, renewal, and revocation operations, see Chapter 15,
“Setting Up End-User Authentication.” For information on automated
notifications, see Chapter 16, “Setting Up Automated Notifications.”
Built-in plug-in modules for authentication, policy, job scheduling, and
publishing
Certificate Management System simplifies the details involved in certificate
issuance and management with its built-in, configurable, and extensible
authentication, policy, job scheduling, and publishing components. Each of these
components come with a set of default modules that enable you to configure
Certificate Management System for your PKI requirements. For example, you can
configure policy modules to determine the outcome of operations, such as
certificate formulation (extensions, signing algorithm, key length, validity period,
and so on), issuance, renewal, and revocation.
For information about all plug-in modules (such as authentication, job, policy, and
publishing modules) that are provided for Certificate Management System, see
“Plug-in Modules” on page 55.
38
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Overview of Key Features
Single administration point achieved via LDAP-compliant directory
integration
Certificate Management System works seamlessly with any LDAP-compliant
directory services for easy distribution of certificates and CRLs, thus lowering the
cost of information management. The shared directory architecture enables you to
manage users, including their security credentials and other shared data, at a single
place. Certificate Management System can do the following:
•
Authenticate users based on the information that exists in the LDAP directory.
•
Integrate certificate-related information with the user and group information
that exists in the LDAP directory.
•
Automatically publish certificates (when they are issued) and CRLs (when
created or on a periodic basis) to the LDAP directory, from which they can be
easily distributed to clients and servers.
•
Automatically delete expired and revoked certificates from the directory.
•
Connect to the directory using password-based (basic) or certificate-based (in
the context of LDAP over SSL) authentication using a digital certificate.
Supports many methods for verifying the revocation status of
certificates
Revocation status of a certificate can be made available to PKI entities by
publishing the CRL to various repositories. To aid you in this process, the
Certificate Manager supports publishing of CRLs to the following repositories:
•
An LDAP-compliant directory; see , “Setting Up LDAP Publishing.”
•
A flat file; see , “Publishing Certificates and CRLs to a File.”
•
An Online Certificate Status Protocol (OCSP)-compliant validation authority or
OCSP responder; see , “Setting Up an OCSP Responder.”
Applications in your enterprise may use any of these repositories to verify the
revocation status of a certificate.
Supports certificate generation for dual key pairs—separate key pairs
for signing and encrypting mail messages
To support separate key pairs for signing and encrypting data, Certificate
Management System supports generation of dual certificates for end entities
capable of generating dual key pairs. If a client makes a certificate request for dual
key pairs, the server issues two separate certificates.
For more information, see “Clients That Can Generate Dual Key Pairs” on
page 740.
Chapter 1
Introduction to Certificate Management System
39
Overview of Key Features
Works with Netscape Personal Security Manager, that can generate
dual key pairs
Certificate Management System works seamlessly with Netscape Personal Security
Manager, which when plugged into Netscape Communicator version 4.7x enables
it to support protocols such as OCSP and CMC and generation dual key pairs.
Personal Security Manager is a standards-based, client-independent application
that performs PKI operations on behalf of Communicator 4.7x and other
applications. For details, see “Netscape Personal Security Manager” on page 102.
Key archival and recovery for encryption private keys
If your organization uses S/MIME to encrypt mail messages, you can use the key
archival feature offered by Certificate Management System to back up users’
encryption private keys. This feature is useful when a key becomes
unavailable—as, for instance, in the following cases:
•
An employee loses an encryption private key (for example after a disk crash or
by forgetting the password to the key file) and is unable to read previously
encrypted data.
•
An employee leaves the company, and company officials need to perform an
audit that requires gaining access to the employee’s encrypted data.
For more information, see Chapter 22, “Setting Up Key Archival and Recovery.”
Encrypted key storage and password-protected recovery
Certificate Management System stores users’ encryption private keys in an
encrypted key repository. Keys can be retrieved only by authorized key recovery
agents. The key repository is encrypted using a Data Recovery Manager’s storage
private key, which is protected with one or more recovery agents’ passwords. Only
these designated recovery agents can authorize and initiate a key recovery process.
For more information, see “Where the Keys are Stored” on page 742.
Extensive audit and log records for detection of tampering
Certificate Management System maintains audit trails for all events—certificate
requests and issuance, revocation requests, CRL publication, and so on. These
audit records enable you to detect any unauthorized access or activity. In addition,
extensive system and error logs record various events and system errors so that
you can monitor and debug the system. All log records are stored in your local file
system for quick and easy retrieval.
For more information, see Chapter 23, “Managing CMS Logs.”
40
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Overview of Key Features
Supports signing of log files for tamper detection
Certificate Management System allows you to sign log files digitally before
archiving them or distributing them for audit purposes. This feature enables you to
check whether the log files were tampered with after being signed.
For more information, see “Signing Log Files” on page 794.
Java SDK extension mechanism for customization
The software development kit (SDK) provided with Certificate Management
System includes APIs and tutorials for customizing different aspects of the system.
You can write the following custom modules:
•
Authentication—for authenticating end entities during certificate enrollment.
•
Policy—for setting the rules applied by the individual subsystems.
•
Jobs—for PKI-related jobs that run with the individual systems.
•
Mapper and publisher classes—for publishing certificates and CRLs to an
LDAP-compliant directory, flat file, and an OCSP responder.
For information about writing custom plug-ins, see “CMS SDK” on page 65.
For information on customizing end-entity and agent interfaces (HTML forms and
templates), see CMS Customization Guide.
Easy upgrade from previous versions of Certificate Management
System
Certificate Management System provides an easy upgrade path from its previous
version. For more information, see “Upgrading From a Previous CMS Installation”
on page 312.
GUI-based server installation and management
An installation wizard automates the installation and initial configuration process,
helping you install Certificate Management System quickly and easily. Then after
installation, you can locally or remotely administer Certificate Management
System from various computers on your network (using the encryption, message
integrity, and authentication services of SSL) with the help of an administration
interface called the Certificate Management System window or the CMS window.
For more information, see “The CMS Window” on page 342.
Chapter 1
Introduction to Certificate Management System
41
System Overview
System Overview
Certificate Management System provides a highly scalable, easily deployable
certificate infrastructure for supporting encryption, authentication, tamper
detection, and digital signatures in networked communications. It is based on open
standards and protocols that include the following:
•
Public-Key Cryptography Standard (PKCS) #11
•
Secure Sockets Layer (SSL)
•
Lightweight Directory Access Protocol (LDAP)
•
Online Certificate Status Protocol (OCSP)
•
Wireless Transport Layer Security (wTLS)
•
X.509 certificate formats recommended by the International
Telecommunications Union (ITU)
•
Public-Key Infrastructure (X.509) (PKIX) standards proposed by the PKIX
working group of the Internet Engineering Task Force (IETF).
•
Federal Information Standards Publications (FIPS PUBS) 140-1.
Certificate Management System leverages Netscape Directory Server and Netscape
Console to provide a complete, scalable, high-performance certificate management
solution for extranets and intranets. Its strong support for existing and evolving
standards makes Certificate Management System especially well-suited for large
heterogeneous extranets that must support a variety of platforms, client and server
software, hardware devices such as routers and hardware tokens, virtual private
network (VPN) implementations, existing intranet security systems, wireless
applications, and so on. It can be customized and configured to fit widely varying
deployment scenarios, permitting rapid integration with existing client and server
software, customer databases, security systems, and authentication procedures.
You can use Certificate Management System to set up and manage your own
public-key infrastructure or to deploy a public certification authority. Certificate
Management System meets the needs of an enterprise, leveraging your existing
enterprise resources and services, and will grow with your business needs to meet
the demand of Internet-scale deployments.
42
iPlanet Certificate Management System Installation and Setup Guide • March 2001
System Overview
With Certificate Management System, you can do the following operations:
•
Process certificate requests from various end entities, such as web browsers,
servers, routers, and virtual private network (VPN) clients, and issue
certificates that conform to X.509 version 3 standard. The server can also
process certificate requests from wireless applications and issue certificates
that conform to wTLS standard.
•
Employ specific authentication methods for end-entity certificate enrollment,
renewal, and revocation.
•
Specify policy restrictions on certificate-related operations, such as certificate
formulation, issuance, renewal, and revocation.
•
Specify policy restrictions on key-related operations, such as archival and
recovery of end users’ encryption private keys.
•
Revoke certificates, and maintain and publish a list of revoked certificates.
•
Enable real-time verification of certificates by OCSP-compliant clients.
•
Search for certificates issued by the server.
•
Set up hierarchies of certificate authorities—multiple subordinate CAs chained
up to a root CA. (Certificate Management System can also chain under popular
public CAs that are already pretrust in popular client and server products.)
•
Publish certificate information to an LDAP-compliant directory, such as
Netscape Directory Server, and maintain this information. Publish the list of
revoked certificates (CRLs) to an LDAP-compliant directory, a flat file, and an
online-validation authority.
This chapter describes the basic features and capabilities of Certificate
Management System. Chapter 3, “Default Demo Installation” describes how to
install a simple demo that uses some of these features.
Public-Key Infrastructure
The standards and services that facilitate the use of public-key cryptography and
X.509 version 3 certificates in a networked environment are collectively called
public-key infrastructure (PKI). In any PKI, a certificate authority (CA) is a trusted
entity that issues, renews, and revokes certificates. An end entity (EE) is a person,
router, server, or other entity that uses a certificate to identify itself.
Chapter 1
Introduction to Certificate Management System
43
System Overview
To participate in a PKI, an end entity must enroll, or register, in the system. The end
entity typically initiates enrollment by giving the CA some form of identification
and a newly generated public key. The CA uses the information provided to
authenticate, or confirm, the identity. In some cases the CA may require human
intervention, such as an interview or examination of notarized documents, to
authenticate the end entity (manual approval). In other cases the information
provided may be sufficient (automatic approval). In addition to authenticating the
end entity, the CA uses the public key to ensure “proof of possession”—that is,
cryptographic evidence that the certificate request was signed by the holder of the
corresponding private key. Finally, the CA issues a certificate that associates the
end entity’s identity with the public key, and signs the certificate with the CA’s
own private signing key.
Certificate Management System dramatically simplifies the PKI enrollment
process. Before you deploy a PKI, however, you need to make many decisions
about the relationships between CAs and end entities and related policies and
procedures.
End entities and CAs may be in different geographic or organizational areas or in
completely different organizations that are linked through an extranet (that is, the
extension of a company’s internal network, or intranet) to selected customers,
suppliers, and mobile employees via the Internet. CAs may include third parties
that provide services through the Internet as well as the root CAs and subordinate
CAs for individual organizations. Policies and certificate content may vary from
one organization to another. For all these reasons and many others, the
deployment and long-term management of any large-scale PKI require careful
advance planning and custom configuration.
CMS Subsystems or Managers
Certificate Management System comprises four servers (also referred to as
subsystems or CMS managers) namely:
•
Certificate Manager
•
Registration Manager
•
Data Recovery Manager
•
Online Certificate Status Manager
To meet the widest possible range of configuration requirements, Certificate
Management System permits the independent installation of these four
subsystems, and each subsystem plays a distinct role in a PKI. Each subsystem
consists of built-in, system-level components such as authentication framework for
44
iPlanet Certificate Management System Installation and Setup Guide • March 2001
System Overview
various types of users, schedulable jobs for automating server functions, policy
framework for evaluating certificate requests and formulating certificate contents,
publishing framework for publishing certificates and CRLs to various repositories,
and logging framework for monitoring server’s activities. Certificate Management
System supports a plug-in architecture for authentication, policy, job, publishing,
and log components; for example, Java code modules can be plugged in to
authenticate user identities and to enforce certificate issuance policies.
The Certificate Manager, Registration Manager, Data Recovery Manager, and
Online Certificate Status Manager subsystems are all highly customizable and can
be installed in a variety of configurations and physical locations. Decisions about
the number of subsystems to install, where to install them, and the relationships
among them and one or more public directories affect all aspects of installation and
configuration. Some organizations may want to install a single Certificate Manager
on one machine inside the firewall and a single Registration Manager on a separate
machine outside the firewall. Others may have a single CA run by a single
Certificate Manager and hundreds of Registration Managers in different
geographic locations. Still others may have many different CAs or subordinate
CAs, and only a few Registration Managers.
The sections that follow explain each subsystem in detail. For descriptions of some
basic deployment options, see Chapter 4, “Planning Your Deployment”.
Certificate Manager
A Certificate Manager functions as a root or subordinate certificate authority. This
subsystem issues, renews, and revokes certificates, generates certificate revocation
lists (CRLs), and can publish certificates to an LDAP directory and a file, and CRLs
to an LDAP directory, a file, and an OCSP responder. The Certificate Manager can
be configured to accept requests from end entities, Registration Managers, or both,
and can process requests either manually (that is, with the aid of a person,
identified in this document as Certificate Manager agent) or automatically (based
entirely on customizable policies and procedures).
When set up to work with a separate Registration Manager, the Certificate
Manager processes requests and returns the signed certificates to the Registration
Manager for distribution to the end entities. (For an overview of the role of
certificate authorities and related concepts of public-key cryptography, see
Appendix D of Managing Servers with Netscape Console.
Basic capabilities of the Certificate Manager (as distinct from the Registration
Manager) include the following:
•
Can be configured as either a root CA or a subordinate CA
•
Can accept certificate requests from end entities and Registration Managers
Chapter 1
Introduction to Certificate Management System
45
System Overview
•
Can issue end-entity, Registration Manager, and Certificate Manager
certificates
•
Can issue single key-pair or dual key-pair certificates
•
Can notify users and administrators of approaching certificate expiration
•
Can notify agents of requests pending in the queue
•
Can renew certificates
•
Can revoke certificates
•
Can publish certificates to an LDAP directory (LDAP 2.0 or higher) and to files
•
Can publish CRLs to an LDAP directory (LDAP 2.0 or higher), a file, and the
Online Certificate Status Manager.
Note that the publishing tasks can be performed by the Certificate Manager only.
The Certificate Manager also has a built-in OCSP service, enabling
OCSP-compliant clients to directly query the Certificate Manager about the
revocation status of a certificate that it has issued. For example, if you plan to
deploy a PKI comprising a master CA and many clone CAs, you can enable the
OCSP service of the master CA. This way, all clients in your PKI setup can verify
the revocation status of a certificate by querying the master Certificate Manager.
The Certificate Manager can issue certificates with the following characteristics:
•
X.509 version 3
•
Internationalized subject names
•
Customized components in subject names
•
Customized extensions
The Certificate Manager supports the following signing algorithms for both
certificates and CRLs: RSA with MD2, RSA with MD5, RSA with SHA-1, and DSA
with SHA-1.
The Certificate Manager can issue X.509 v1 or v2 CRLs. A CRL can be
automatically updated whenever a certificate is revoked or at specified intervals.
CRL extensions supported include the following:
46
•
Authority key identifier. Identifies the public key to be used to validate the
digital signature on the certificate.
•
CRL number. A sequential number unique to each CRL issued by a given CRL
issuer. This number allows CRL-checking software to ensure that all previous
CRLs have been received.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
System Overview
•
Issuer alternative name. Associates the CRL issuer with an Internet style
identity, such as Internet electronic mail address, a DNS name, an IP address,
or a uniform resource indicator (URI).
•
Issuing distribution point. The URL at which this CRL is maintained.
The Delta CRL indicator extension is not supported.
CRL entry extensions supported include the following:
•
Hold instruction code. Indicates the action to be taken for an entry that
appears on the CRL because it has been placed on hold.
•
Reason code. Indicates the reason the certificate was revoked.
•
Invalidity date. Indicates the date on which the private key corresponding to
the public key certified by the certificate was (or is suspected to have been)
compromised.
Registration Manager
A Registration Manager is an optional component in the PKI, enabling you to
separate the registration process from the certificate-signing process. A
Registration Manager is typically installed on a different machine from the
Certificate Manager that it serves. During installation, you connect the Registration
Manager to a Certificate Manager and configure the Certificate Manager to trust
the Registration Manager. Once the trust is established, the Registration Manager
can perform a subset of the end-entity tasks performed by the Certificate Manager,
such as enrollment or renewal, on behalf of the Certificate Manager. A Registration
Manager cannot issue or revoke certificates by itself; instead, it evaluates
end-entity requests and forwards them to a Certificate Manager for action, such as
the issuing of a certificate. The Certificate Manager processes the requests and
issues the certificates. The Registration Manager then distributes the certificates to
the end entities.
Note that you can run multiple Registration Managers remotely, all reporting to a
single CA—a Certificate Manager—to verify user identities and process certificate
signing requests. The Certificate Manager’s ability to support multiple Registration
Managers makes it more scalable and also adds an extra layer of security for the
CA. For example, you can set a policy that requires all clients to go through a
remote Registration Manager, and then have the remote Registration Manager
route all client requests to the Certificate Manager located inside a firewall.
Chapter 1
Introduction to Certificate Management System
47
System Overview
The Registration Manager is designed to handle certificate life-cycle management
tasks—that is, the tasks required to maintain a certificate throughout its life cycle,
including the following:
•
Enrolling end entities (initial authentication and initiation to the PKI)
•
Enforcing policies such as request validation requirements, authentication
requirements, and certificate formulation
•
Distributing issued certificates
•
Coordinating certificate renewal
•
Coordinating storage of end users’ private encryption keys with a Data
Recovery Manager
A Registration Manager’s default forms for end-entity interactions can be used as is
or customized. For more information about default Registration Manager forms,
see “End Entities and Life-Cycle Management” on page 98.
Data Recovery Manager
A Data Recovery Manager performs the long-term archival and recovery of private
encryption keys for end entities. A Certificate Manager or Registration Manager
can be configured to archive end entities’ private encryption keys with a Data
Recovery Manager as part of the process of issuing new certificates. End-entities do
not have direct access to the Data Recovery Manager.
The Data Recovery Manager is useful only if end entities are encrypting data (using
applications such as S/MIME email) that the organization may need to recover
someday. It can be used only with client software that supports dual key
pairs—that is, two separate key pairs, one for encryption and one for digital
signatures. This service is available in newer clients only; for example,
Communicator versions 4.7x (with Personal Security Manager installed) and
Netscape 6 support generation of dual key pairs. Dual key pairs allow an end
entity to get a new signing certificate and signing key pair without changing the
encryption certificate or encryption key pair.
Note that the Data Recovery Manager archives encryption keys. It does not archive
signing keys, since such archival would undermine nonrepudiation properties of
dual-key certificates. This crucial element of a PKI allows an authorized
key-recovery agent to recover an encryption key that has been lost or corrupted
without changing the signing certificate or signing key pair. For example, if agents
or administrators are authorized to perform key recover operations, they can
48
iPlanet Certificate Management System Installation and Setup Guide • March 2001
System Overview
recover encryption keys for employees who have left the company or who are
unavailable for some other reason. In either case, once the encryption key has been
recovered, the user or administrator can use it to decrypt any data (such as saved
email messages) that was encrypted with that key.
The Data Recovery Manager uses two special key pairs in the process of archiving
an end entity’s encryption key: a transport key pair (and certificate) and a storage
key pair. The end entity must also have two key pairs: a signing key pair and an
encryption key pair. The roles of all these keys are summarized in Table 1-1.
Table 1-1
Key pairs used by end entities and key pairs used by the Data Recovery Manager
End-entity key pairs
Data Recovery Manager key pairs
Signing key pair
Encryption key pair
Transport key pair
Storage key pair
Public signing key:
Public encryption key:
Public transport key:
Public storage key:
used by recipients to
validate digital
signature
used by others to encrypt
messages sent to owner
used by end-entity
software to encrypt the
end entity’s private
encryption key before
sending it to Certificate
Management System for
storage.
used to decrypt an end
entity’s stored private
encryption key after m of
n recovery agents have
authorized the recovery
operation.
Private signing key:
Private encryption key:
Private transport key:
Private storage key:
used by owner to
digitally sign
messages
used by owner to decrypt
messages encrypted with
the public key
used by Data Recovery
Manager to decrypt an
end entity’s private
encryption key
used to encrypt an end
entity’s private
encryption key for
long-term storage
Online Certificate Status Manager
A Online Certificate Status Manager performs the task of an online certificate
validation authority, by enabling OCSP-compliant clients to do real-time
verification of certificates. The Online Certificate Status Manager can receive CRLs
from multiple Certificate Managers and clients can query the Online Certificate
Status Manager for the revocation status of certificates issued by all these
Certificate Managers. For example, if you plan to create a CA hierarchy comprising
a root CA and many subordinate CAs, you can configure each of these CAs to
publish their CRLs to the Online Certificate Status Manager. This way, all clients in
your PKI deployment can verify the revocation status of a certificate by querying
the Online Certificate Status Manager.
Note that an online certificate-validation authority is often referred to as OCSP
responder.
Chapter 1
Introduction to Certificate Management System
49
System Overview
Basic System Configuration
Figure 1-1 illustrates some of the data formats and protocols used among the four
independent CMS managers and various kinds of end entities. To keep things
simple, the figure assumes that each manager is installed in a different CMS
instance and on a different machine. The Registration Manager handles all
interactions with different kinds of end entities, using protocols appropriate for
each entity.
Figure 1-1
Basic CMS configuration and use of data formats and protocols
Publishing
directory
Routers
Data
formats:
VPN clients
LDAP or
LDAPS
CRMF
CMMF
Browsers
CEP
KEYGEN tag
SSL servers
PKCS #7
PKCS #10
HTTPS
Registration
Manager
Certificate
Manager
HTTPS
Database
clients and
servers
HTTPS
Transport
methods:
HTTP/
HTTPS
Data
Recovery
Manager
Other
products
50
iPlanet Certificate Management System Installation and Setup Guide • March 2001
System Overview
The end-entity data formats and transport methods shown in the figure are used to
send enrollment and other requests to the Registration Manager (indicated by a
right-pointing arrow) or to send responses back to the end entities (indicated by a
left-pointing arrow). The end-entity data formats can be summarized as follows:
•
Certificate Request Message Format (CRMF) and Certificate Management
Message Formats (CMMF). Proposed standards from the Internet Engineering
Task Force (IETF) PKIX working group that define message formats used to
convey requests to a Registration Manager or Certificate Manager and to
return information to end entities. CMMF will be subsumed by another
proposed standard, Certificate Management Messages over Cryptographic
Message Syntax (CMC), which is also supported by Certificate Management
System.
•
Certificate Enrollment Protocol (CEP). A certificate management protocol
jointly developed by Cisco Systems and VeriSign, Inc. CEP governs
communication between routers or VPN clients and a Registration Manager or
Certificate Manager.
•
KEYGEN tag. An HTML tag supported by Netscape browsers that generates a
key pair stored in the client and formats an HTTP GET string to send off to a
CA as part of the enrollment process.
•
Public-Key Cryptography Standard (PKCS) #7. An encrypted data and
message format developed by RSA Data Security to represent digital
signatures, certificate chains, and encrypted data. This format is used to deliver
certificates to end entities.
•
Public-Key Cryptography Standard (PKCS) #10. A message format developed
by RSA Data Security for certificate requests. This format is supported by
many server products and by Microsoft Internet Explorer.
These are the standard transport methods used for all of the data formats described
above:
•
Hypertext Transport Protocol (HTTP) and Hypertext Transport Protocol
Secure (HTTPS). Protocols used to communicate with web servers.
For more information about end-entity data formats and protocols used by
Certificate Management System, see “End Entities and Life-Cycle Management” on
page 98 and “Standards Summary” on page 77.
Chapter 1
Introduction to Certificate Management System
51
System Overview
The Registration Manager communicates with the Data Recovery Manager and the
Certificate Manager as necessary to facilitate certificate management operations
such as enrollment, renewal, or key storage. When the four subsystems are
installed in separate CMS instances (whether on the same machine or on different
machines), they use proprietary connectors to communicate with each other over
HTTPS—that is, HTTP over SSL, as shown in Figure 1-1. For information about the
connectors, see “Trusted Managers” on page 398.
The Certificate Manager maintains complete record of issued certificates and can
publish certificates and CRLs many repositories, such as a directory using LDAP or
LDAP over SSL (LDAPS), a file, or the Online Certificate Status Manager. If the
Certificate Manager and directory are inside the firewall and if it’s necessary for
some entries in a directory to be available outside the firewall, Netscape
recommends using the partial replication feature of Directory Server to replicate
the relevant portion of the directory to which the Certificate Manager publishes. In
this guide, a directory used for publishing certificates and CRLs is called a
publishing directory. Publishing directories can also be used for authentication to
implement an automated certificate enrollment method.
As mentioned earlier, the Data Recovery Manager performs the long-term archival
and recovery of end users’ private encryption keys. A Certificate Manager or
Registration Manager can be configured to archive end users’ private encryption
keys with a Data Recovery Manager as part of the process of issuing new
certificates. End-entities do not have direct access to the Data Recovery Manager.
The following steps summarize the key storage process during end-entity
enrollment through a Registration Manager. Figure 1-2 illustrates these steps.
52
1.
After the user completes and submits an enrollment form, the end entity
generates dual key pairs and sends two certificate requests to the Registration
Manager, which detects a request for key archival and requests the private
encryption key from the end entity. The end entity then encrypts (or “wraps”)
its newly minted private encryption key with the Data Recovery Manager’s
public transport key (obtained from a copy of the transport certificate
embedded in the enrollment form) and sends the wrapped private key to the
Registration Manager.
2.
The Registration Manager sends the end entity’s wrapped private encryption
key to the Data Recovery Manager as part of a key storage request (which also
includes the end entity’s public encryption key).
3.
The Data Recovery Manager uses its private transport key to decrypt the end
entity’s private encryption key. After confirming that the private encryption
key corresponds to the end entity's public encryption key, the Data Recovery
Manager encrypts the private encryption key with its private storage key and
stores the private encryption key in the CMS internal database.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
System Overview
Figure 1-2
4.
The Data Recovery Manager signs a proof-of-archival token with its private
transport key and sends the token to the Registration Manager.
5.
The Registration Manager verifies the token and sends the certificate requests
on to the Certificate Manager.
6.
The Certificate Manager issues the signing and encryption certificates and
sends them back to the Registration Manager.
7.
The Registration Manager delivers the certificates to the end entity.
Key storage process during end-entity enrollment
1 Request certificates/
send private key
End entity
Registration
Manager
5 Request
certificates
7 Deliver
certificates
6 Issue
certificates
2
Request
key
storage
Certificate
Manager
4
Send proofof-archival
token
Data
Recovery
Manager
3 Validate
and store
private key
Internal
database
Data encrypted with the storage key can be retrieved only if m of n “split keys” are
provided at the same time by m of n authorized recovery agents. By default, m and
n are 2 and 3, respectively. Both values can be changed, as long as m is less than or
equal to n.
Chapter 1
Introduction to Certificate Management System
53
System Overview
The Data Recovery Manager indexes stored keys by owner name and a hash of the
public key. This arrangement allows for highly efficient searching by name (all
stored keys belonging to that owner are returned) or by public key (only the
requested key is returned).
Each CMS manager has its own database for storing private information such as
certificate records, key archival records, and the request queue. This database is a
preconfigured Netscape Directory Server (version 4.x) installed transparently at the time of
CMS installation. In this guide, the Directory Server instance used by a subsystem for
storing its data is called an internal database. For example, the Certificate Manager
uses its internal database for storing certificates and certificate requests; the
Registration Manager uses its internal database for storing certificate requests (but
not certificates, which are stored by the Certificate Manager only); the Data
Recovery Manager uses its internal database for storing archived encryption keys;
and the Online Certificate Status Manager uses its internal database for storing
CRLs published by Certificate Managers. Using Netscape Directory Server as an
internal database allows Certificate Management System to leverage the scalability
and industry-leading performance of Directory Server, replacing the Relational
Database Management System (RDBMS) used in Certificate Server 1.0x.
Some deployments require installation of two subsystems in a single CMS instance
on a single machine, for example, Certificate Manager and Data Recovery
Manager, Registration Manager and Data Recovery Manager, or Data Recovery
Manager and Online Certificate Status Manager. In these dual-manager
installations, both subsystems use the same internal database for storing data and
communication between the two subsystems takes place internally (that is, within
the same running process) rather than via HTTPS. (Note that a Certificate Manager
performs all Registration Manager tasks, including end-entity interactions.
Registration Managers are required only for remote or delegated administration of
the CA.)
Throughout this guide, the term CMS administrator describes the person who
installs and configures one or more managers and sets up privileges for the users
who manage those subsystems. The users who manage day-to-day interactions of
end entities with each manager, as well as other aspects of the PKI, are called CMS
agents collectively, or the Certificate Manager agent, Registration Manager agent, and
Data Recovery Manager agent, and Online Certificate Status Manager agent. The role of
an agent is to approve, defer, or reject requests using Agent Services web pages
served by the CMS manager for which that agent has been assigned the necessary
privileges. The privileges of each agent can be confined to a specific manager or can
include several different managers.
54
iPlanet Certificate Management System Installation and Setup Guide • March 2001
System Overview
System administrators set up CMS subsystems through Netscape Console, and
agents manage end-entity requests and certificates through HTML pages. For more
information about facilities available to administrators and agents, see Chapter 13,
“Managing Privileged Users and Groups.”
Plug-in Modules
Certificate Management System includes a plug-in architecture for code modules
that authenticate user identities and code modules that enforce policies.
Each type of request from an end user—for certificate enrollment, renewal,
revocation, or retrieval—is handled by a different servlet, a piece of Java code
designed for that kind of request. Each servlet processes the request using the
appropriate protocols (such as the KEYGEN HTML tag or PKCS #10) for each type of
end entity. Additional servlets control interactions with administrators and agents.
The sections that follow provide an overview of the plug-in modules provided
with Certificate Management System. For detailed information about all the
plug-in modules, refer to CMS Plug-ins Guide. To locate this guide, see “Where to
Go for Related Information” on page 28.
Authentication Plug-in Modules
An authentication module is a set of rules (implemented as a Java class) for
authenticating an end user, server, or other entity that needs to interact with a CMS
manager. (Similar rules are used to authenticate agents and administrators, but
they are built into Certificate Management System instead of being implemented as
plug-in modules.) With a typical end-user enrollment, the user supplies the
information requested by the Registration Manager on an enrollment form, and
then the servlet uses an authentication module specified within the form to
validate the information and authenticate the user’s identity. This simple input
value makes it possible to use custom authentication for any form without
changing the corresponding servlet code.
Both the Certificate Manager and Registration Manager support client SSL
certificate-based authentication (for both agents and end entities). Netscape
Console supports user ID- and password-based authentication for administrators.
Registration Managers and Certificate Managers can also be configured to use any
of the authentication modules provided for authenticating end-users during
certificate enrollments; see Table 1-2.
Chapter 1
Introduction to Certificate Management System
55
System Overview
Table 1-2
Authentication plug-in modules for end-user enrollments
Plug-in module name
Description
Manual authentication
Requires manual approval by an agent. This authentication module is
hardwired; you cannot configure it. This ensures that when the server
receives requests that lack authentication credentials, it sends them to the
request queue for agent approval. It also means that if you don't configure
Certificate Management System for any other authentication mechanism,
the server automatically sends all certificate-related requests to a queue
where they await agent approval.
Directory-based
authentication
Checks a user’s name and password against the user’s entry in a specified
directory and uses the DN for that entry to formulate the subject name for
the certificate.
Directory-based PIN
authentication
Checks a user’s name, password, and a special one-time PIN against the
user’s entry in a specified directory and uses the DN for that entry to
formulate the subject name for the certificate. The PIN is stored in salted
and hashed form, and is removed after being used once to authenticate a
user during enrollment.
NIS-based authentication
Authenticates end users based on their user IDs and passwords stored in a
NIS server. Optionally, uses an LDAP directory for formulating certificate
subject names.
Portal-style authentication
Checks that a user’s name is unique in an LDAP directory.
When you configure a Registration Manager or Certificate Manager an
authentication module, you can specify how the DN should be used to formulate
the subject name. As a result, neither the user nor the agent needs to figure out or
enter the subject name—its formulation is entirely automated.
You can also write custom authentication modules, for example to authenticate end
entities by using existing customer databases or security systems.
Tutorials and sample code provided as a part of CMS software development kit
(SDK) demonstrate how to write a custom authentication module. For details, see
section “CMS SDK” on page 65.
For information about ways customized authentication modules can be used
during enrollment, see “Some Enrollment Scenarios” on page 84.
56
iPlanet Certificate Management System Installation and Setup Guide • March 2001
System Overview
Policy Plug-in Modules
A policy module is a rule (implemented as a Java class) that validates the contents
of a certificate request and formulates the contents of the certificate to be issued.
Policy modules are also responsible for accepting, rejecting, or deferring the
request. Certificate Management System policies have nothing to do with export
control policies or certificate usage policies.
After a Registration Manager or Certificate Manager has successfully authenticated
an end entity, the entity’s request is passed to a policy processor, which
sequentially applies a set of policy rules configured for that CMS manager. The
processor validates the contents of a certificate request for each rule and can add or
modify any part of a certificate’s contents, including validity dates, name
constraints, and extensions.
Here are three typical examples of the use of policies:
•
A name constraints extension policy checks that the subject name matches a
pattern, and it rejects, defers, or adjusts the subject name in the request
accordingly.
•
A validity constraints policy checks that the certificate validity period falls
within a specified period, and it rejects, defers, or adjusts the validity period in
the request accordingly.
•
An extensions policy checks that a request includes a specified extension and
adds the extension if it’s missing.
For an introduction to the role of policy modules in the enrollment process, see
“Authentication and Policy Modules” on page 77.
Certificate Management System supports the following constraints-specific policy
modules out of the box. These policies establish rules or constraints that Certificate
Management System must use to evaluate an incoming request. They can be used
with either a Certificate Manager or a Registration Manager.
Table 1-3
Policy plug-in modules for checking and formulating certificate contents
Plug-in module name
Description
AttributePresentConstraints
Rejects a request if an LDAP attribute is not present in the enrolling
user’s directory entry or if the attribute does not have a specified value.
DSAKeyConstraints
Allows the server to certify only DSA keys of specified lengths.
IssuerConstraints
Allows the server to check for certificates that have been issued by a
particular CA.
Chapter 1
Introduction to Certificate Management System
57
System Overview
Table 1-3
Policy plug-in modules for checking and formulating certificate contents (Continued)
Plug-in module name
Description
KeyAlgorithmConstraints
Allows the server to certify only those keys that are generated using one
of the specified algorithms, such as RSA or DSA.
RenewalConstraints
Allows or rejects requests for renewal of expired certificates.
RenewalValidityConstraints
Enforces the number of days before which a currently active certificate
can be renewed and a new validity period for the renewed certificate.
RevocationConstraints
Allows or rejects requests for revocation of expired certificates.
RSAKeyConstraints
Allows the server to certify only RSA keys of specified lengths.
SigningAlgorithmConstraints
Allows the server to specify the signature algorithm to be used by the
CA (a Certificate Manager) to sign certificates.
SubCANameConstraints
Allows the server to check for issuer name uniqueness and prevents
issuance of multiple subordinate CA certificates with same issuer
names.
UniqueSubjectNameConstraints
Allows the server to check for certificate subject name uniqueness and
prevents issuance of multiple certificates with same subject names.
ValidityConstraints
Causes the server to check whether the validity period of a certificate
falls within a specified period.
Certificate Management System supports the following policy modules out of the
box for formulating certificate extensions. They can be used with either a
Certificate Manager or a Registration Manager.
Table 1-4
Policy plug-in modules for setting extensions in certificates
Plug-in module name
Description
AuthInfoAccessExt
Adds the Authority Information Access extension to certificates. The
extension specifies how the application validating the certificate can
access information, such as on-line validation services and CA policy
statements, about the CA that has issued the certificate in which the
extension appears.
AuthorityKeyIdentifierExt
Adds the Authority Key Identifier extension to certificates of a specified
type. The Authority Key Identifier extension identifies the public key
corresponding to the private key used to sign a certificate. This extension
is useful when an issuer has multiple signing keys (for example, due to
CA certificate renewal).
58
iPlanet Certificate Management System Installation and Setup Guide • March 2001
System Overview
Table 1-4
Policy plug-in modules for setting extensions in certificates (Continued)
Plug-in module name
Description
BasicConstraintsExt
Adds the Basic Constraints extension to certificates of a specified type.
This extension is used during the certificate chain verification process to
identify CA certificates and to apply certificate chain path length
constraints.
CertificatePoliciesExt
Adds the Certificate Policies extension to certificates. The extension
contains a sequence of one or more policy statements, each indicating the
policy under which the certificate has been issued and identifying the
purposes for which the certificate may be used.
CertificateRenewalWindowExt
Adds the Certificate Renewal Window extension to certificates. The
extension specifies how to renew a certificate automatically and when
automatic renewal should be attempted.
CertificateScopeOfUseExt
Adds the Certificate Scope of Use extension to SSL client certificates. This
extension specifies Internet addresses where the certificate can be
presented for SSL client authentication. This restriction prevents any
private information that might be contained in the certificate from being
released to servers not explicitly contained in the scope of use.
CRLDistributionPointsExt
Adds the CRL Distribution Points extension to certificates. This extension
identifies one or more locations from where the application that is
validating the certificate can obtain the CRL information.
ExtendedKeyUsageExt
Adds the Extended Key Usage extension to certificates. The extension
identifies one or more purposes—in addition to or in place of the basic
purposes indicated in the key usage extension—for which the certified
public key may be used.
GenericASN1Ext
Adds ASN.1 type custom extension to certificates. This policy enables
you to configure Certificate Management System to add custom
extensions to certificates.
IssuerAltNameExt
Adds the Issuer Alternative Name extension to certificates. This
extension enables binding of or associating Internet style identities, such
as Internet electronic mail address, a DNS name, an IP address, and a
uniform resource indicator (URI), with the certificate issuer.
KeyUsageExt
Adds the Key Usage extension to certificates of a specified type. This
extension defines the purpose of the key contained in the certificate. The
Key Usage, Extended Key Usage, Basic Constraints, and Netscape
Certificate Type extensions act together to specify the purposes for which
a certificate can be used.
NameConstraintsExt
Adds the Name Constraints extension to certificates. The extension is
used in CA certificates to indicate a name space within which subject
names or subject alternative names in subsequent certificates in a
certification path or chain should be located.
Chapter 1
Introduction to Certificate Management System
59
System Overview
Table 1-4
Policy plug-in modules for setting extensions in certificates (Continued)
Plug-in module name
Description
NSCCommentExt
Adds the Netscape Certificate Comment extension to certificates. The
extension can be used to include textual comments in certificates.
NSCertTypeExt
Adds the Netscape Certificate Type extension to certificates of a specified
type. This extension can be used to limit the purposes for which a
certificate can be used. It has been replaced by the X.509 v3 extensions
extKeyUsage and basicConstraints, but must still be supported in
deployments that include Navigator 3.x clients.
OCSPNoCheckExt
Adds the OCSP No Check extension to certificates. The extension, which
should be used in OCSP responder certificates only, indicates how
OCSP-compliant applications can verify the revocation status of the
certificate an authorized OCSP responder uses to sign OCSP responses.
PolicyConstraintsExt
Adds the Policy Constraints extension to certificates. The extension,
which can be used in CA certificates only, constrains path validation in
two ways. It can be used to prohibit policy mapping or to require that
each certificate in a path contain an acceptable policy identifier.
PolicyMappingsExt
Adds the Policy Mappings extension to certificates. The extension lists
one or more pairs of OIDs, each pair identifying two policy statements of
two CAs. The pairing indicates that the corresponding policies of one CA
are equivalent to policies of another CA.
PrivateKeyUsagePeriodExt
Adds the Private Key Usage Period extension to certificates. The
extension allows the certificate issuer to specify a different validity period
for the private key than the one specified for the corresponding
certificate.
RemoveBasicConstraintsExt
Detects and removes the Basic Constraints extension in certificate
requests.
SubjectAltNameExt
Adds the Subject Alternative Name extension to certificates of a specified
type. This extension includes one or more alternative (non-X.500) names
for the identity bound by the CA to the certified public key. It may be
used in addition to the certificate's subject name or as a replacement for it.
SubjectDirectoryAttributesExt
Adds a Subject Directory Attributes extension to certificates. The
extension is used to specify any desired directory attribute values for the
subject of the certificate.
SubjectKeyIdentifierExt
Adds the Subject Key Identifier extension to certificates of a specified
type. This extension identifies the public key certified by this certificate. It
provides a way of distinguishing public keys if more than one is available
for a given subject name, for example after the certificate has been
renewed with a new key.
60
iPlanet Certificate Management System Installation and Setup Guide • March 2001
System Overview
In addition to the modules listed above, sample code provided with Certificate
Management System demonstrates how to support additional extensions. The
sample code is provided in the CMS Software Development Kit (SDK). For details,
see section “CMS SDK” on page 65.
For detailed information about using certificate extensions, see Appendix C,
“Certificate and CRL Extensions” of CMS Plug-ins Guide. To locate this guide, see
“Where to Go for Related Information” on page 28.
Job Plug-In Modules
The CMS Job Scheduler allows you to configure a Certificate Management System to
perform a specified action at a specified time, such as informing a user of the need
to renew a certificate or removing an expired certificate from the directory. The
scheduler checks at specified intervals for jobs waiting to be executed; if the
specified execution time has arrived, the scheduler initiates the job.
You can use standard CMS job plug-ins or write your own Java plug-in class in
much the same way that you can write your own authentication and policy
modules. Plug-in classes are provided out of the box for scheduling the following
jobs.
Table 1-5
Plug-in modules for schedulable jobs
Plug-in module name
Description
Renewal notification
Notifies end entities by email that their certificates are about to expire and
must be renewed. This job also sends a summary of such notices to agents.
Available for Certificate Manager only.
Request in queue
Notifies agents at regular intervals of the state of the request queue.
Alternatively, an event-driven notification can be sent whenever a request
has been added to the request queue; see the next section for details.
Available for Registration Manager or Certificate Manager.
Directory expiration update
Updates a specified LDAP publishing directory periodically by removing
expired certificates. This can be useful for end entities such as Netscape
Enterprise Server 3.x that rely on the presence or absence of the certificate
for authentication purposes, or if you wish to ensure that only current,
valid certificates can be found in the directory. This job also sends a
summary of removed certificates to agents or administrators. Available for
Certificate Manager only.
Chapter 1
Introduction to Certificate Management System
61
System Overview
Mapper and Publisher Plug-in Modules
Mapper and publisher plug-in modules enable Certificate Management System to
establish a connection with the configured repository and publish certificates and
CRLs. For example, LDAP-related mapper and publisher plug-in modules enable
Certificate Management System to function seamlessly with an LDAP-compliant
directory, such as Netscape Directory Server, that organizations typically use to
maintain corporatewide data about user and group accounts and other network
resources. You can set up Certificate Management System to automatically publish
certificate information and CRLs to a directory. The advantage of publishing
certificates and CRLs to the directory is multifold:
•
You can keep users’ certificate-related information with the rest of the user
information. This way, when you update the user information, the
certificate-related information automatically gets updated. For example, when
you delete a user entry, the security credentials of that user automatically gets
deleted from the directory.
•
If you are using S/MIME-enabled clients (for example, Netscape
Communicator), publishing all certificates to a central directory enables your
users to import others’ certificates from the global directory.
Figure 1-3
Seamless integration with any LDAP-compliant directory
Seamless integration with any LDAP-compliant directory (see Figure 1-3) makes
possible the following:
•
62
Corporate IS organizations can generate and manage certificates as an integral
part of their user and group management.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
System Overview
•
Independent CAs can issue and manage certificates to their users listed in any
LDAP-compliant directory.
For more information on setting up Certificate Management System to publish
certificates and CRLs, see Chapter 19 through Chapter 21.
Table 1-6 lists the mapper modules supported by Certificate Management System
out of the box. Mapper modules help you configure a Certificate Manager to use
specific rules to map or locate a specific entry, such as a CA’s entry or an
end-entity’s entry, in a specified LDAP directory; once the correct entry is located,
the server publishes the certificate or CRL to the correct attribute in the entry using
a publisher module (explained later in this section). Because it’s not required to
map entries in a file and in an online validation authority, no mapper modules are
provided for mapping objects in a file or a Online Certificate Status Manager.
Table 1-6
Default mapper plug-in modules for mapping certificates and CRLs
Plug-in module name
Function
LdapCaSimpleMap
Maps the CA certificate to the CA’s directory entry by formulating the entry’s DN
from components specified in the certificate’s issuer name and attribute variable
assertion (AVA) constants. Optionally, the plug-in can also create an entry for the
CA in the directory.
LdapDNCompsMap
Maps a certificate to a directory entry by formulating the entry’s DN from
components (such as CN, OU, O, and C) in the certificate’s subject name and using it
as the search DN to locate the entry in the directory.
LdapDNExactMap
Maps a certificate to a directory entry by searching for the entry whose DN exactly
matches the certificate subject name.
LdapSimpleMap
Maps a certificate to a directory entry by formulating the entry’s DN from
components specified in the certificate’s subject name and attribute variable
assertion (AVA) constants.
LdapSubjAttrMap
Maps a certificate to a directory entry by searching for the entry that contains the
LDAP attribute named certSubjNameAttr whose value exactly matches the
certificate subject name.
Table 1-7 lists the publisher modules supported by Certificate Management System
out of the box. Publisher modules help you configure a Certificate Manager to
publish certificates and CRLs to the mapped directory entries, to files, or to the
Online Certificate Status Manager.
Chapter 1
Introduction to Certificate Management System
63
Auxiliary Components
Table 1-7
Default publisher plug-in modules for publishing certificates and CRLs
Plug-in module name
Function
FileBasedPublisher
Publishes certificates and CRLs to a flat file (for exporting into other
repositories).
LdapCaCertPublisher
Publishes or unpublishes a certificate to the caCertificate;binary
attribute of the mapped directory entry as a DER encoded binary blob. Also
converts the object class to a certificationAuthority if it’s not one
already; similarly, removes the certificationAuthority object class
on unpublish if the CA has no other certificates.
LdapCrlPublisher
Publishes (replaces) a CRL to the
certificateRevocationList;binary attribute of the mapped
directory entry as a DER encoded binary blob. The entry should be a
certificationAuthority object class.
LdapUserCertPublisher
Publishes or unpublishes a certificate to the userCertificate;binary
attribute of the mapped directory entry as a DER encoded binary blob.
OCSPPublisher
Publishes CRLs to a Online Certificate Status Manager.
Event-Driven Notifications
The Certificate Manager and Registration Manager support two kinds of
event-driven notifications:
•
Request-completion status. Automatically notifies users by email that a
requested certificate has been issued or that a request has been deferred or
rejected. Available for Registration Manager or Certificate Manager.
•
Request-queue status. Automatically notifies agents by email when a request
has been added to the request queue. Available for Registration Manager or
Certificate Manager.
For more information, see Chapter 16, “Setting Up Automated Notifications.”
Auxiliary Components
In addition to the core components that are discussed in the preceding sections,
Certificate Management System also comes with command-line utilities or tools
and Software Development Kit.
64
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Auxiliary Components
Command-Line Utilities
A number of command-line utilities or tools are bundled with Certificate
Management System. These tools are useful for troubleshooting any problems that
you may encounter with Certificate Management System. The binaries for all the
utilities are located in this directory: <server_root>/bin/cert/tools
For detailed information about these utilities, see CMS Command-Line Tools Guide.
CMS SDK
CMS Software Development Kit (SDK) includes information that’s useful for
developing new plug-in modules and for customizing various aspects of
Certificate Management System. During installation, files for CMS SDK are copied
to this directory: <server_root>/cms_sdk/
Below is an overview of what’s contained in the above directory:
•
CMS JDK, which includes Javadocs, Samples, and Tutorials for developing
Java plug-ins:
Javadocs—complete javadoc specification of the CMS Application
Programming Interface (API).
Samples—sample source code of various plug-in modules that are included in
Certificate Management System out-of-the-box. This source code has been
included for reference purposes only, and is only used to demonstrate how a
particular CMS feature was implemented. Since a sample represents the actual
code currently present in Certificate Management System, it does not require
to be recompiled. You will find examples for the authentication, jobs, listeners,
mappers, passwords, policies, publishers, and servlets modules.
Tutorials—“How To” tutorial to help demonstrate how you can create your
own plug-in modules for Certificate Management System. Each tutorial
includes sample Java source code, environment and build scripts for both
UNIX and Windows NT, and a detailed “cookbook” describing how to build
and install these plug-in modules. Additionally, if necessary, some tutorials
may also contain sample configuration files. A tutorial has been included for
authentication, job, listener, mapper, password, policy, publisher, and servlet
modules.
•
White papers about HTTP-related abilities of Certificate Management System
including “How to add extra parameters to request from the Manual approval
page” and “The CMS 4.x Bulk Generation Interface Specification”.
Chapter 1
Introduction to Certificate Management System
65
Entry Points for Various Types of Users
•
Miscellaneous information about CMS features such as an AutoInstaller, an
AutoRestart, script for UNIX, and a large zip file containing a sophisticated
demonstration of ObjectSigning capabilities.
•
Examples of how to use Certificate Management System with some third-party
products.
Entry Points for Various Types of Users
Certificate Management System provides entry points for various kinds of user
interaction.
Figure 1-4
Entry points for different types of CMS users
As illustrated in Figure 1-4, the server provides three separate user entry points;
each entry point addresses the needs of a specific user type. This is explained in
Table 1-8.
66
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Entry Points for Various Types of Users
Table 1-8
Certificate Management System user entry points
User type
Component/Tool
CMS interface
End entity
Web browser
End Entity Services
This interface provides the general front end for end-entity
interactions with the server. Through this interface, the Certificate
Manager or Registration Manager serves the appropriate HTML
forms for end-entity operations (the Data Recovery Manager and
Online Certificate Status Manager do not have an end-entity
interface). These include forms for certificate enrollment, retrieval,
query, renewal, import, and revocation. For details, see
“End-Entity Services Interface” on page 72.
Agent
Web browser
Agent Services
This interface provides the general front end for agent interactions
with the server. Through this interface, a Certificate Manager,
Registration Manager, Data Recovery Manager, or Online
Certificate Status Manager serves the appropriate HTML forms for
agent tasks. For details, see “Agent Services Interface” on page 68.
Accessing Agent Services is a privileged operation; agents must use
designated certificates for SSL client authentication to Certificate
Management System.
Administrator
Netscape Console
(CMS window)
The remote administration interface supports a GUI-based
administration tool called Netscape Console that provides the
general administration and management interface for Certificate
Management System. For details, see Chapter 9, “Administration
Tasks and Tools.”
Administrators can use this tool to perform day-to-day operational
and managerial duties, such as changing the server configuration,
stopping and restarting the server, requesting and installing
certificates, managing resources (certificates and requests), and
setting up privileged-user information and associated access
controls.
The CMS window can only be launched from within Netscape
Console. Accessing this window is a privileged operation requiring
a password-based authentication to Certificate Management
System.
Chapter 1
Introduction to Certificate Management System
67
Entry Points for Various Types of Users
Agent Services Interface
As an administrator, you can designate privileged users, called agents, for each
subsystem. Agents are responsible for the day-to-day operation of requests from
end entities. For details, see “Agents” on page 391.
To enable agents to accomplish their duties, Certificate Management System
provides a set of HTML forms for Certificate Manager, Registration Manager, Data
Recovery Manager, and Online Certificate Status Manager agents. Collectively,
these forms are called the Agent Services interface.
Depending on the choices you made during installation, a combination of the
following agent services will be installed:
•
Certificate Manager Agent Services
•
Registration Manager Agent Services
•
Data Recovery Manager Agent Services
•
Online Certificate Status Manager Agent Services Interface
The sections that follow give an overview of these interfaces. For a complete list of
agent forms and output templates that come with Certificate Management System,
see CMS Customization Guide.
For tasks associated with Agent Services interface, see CMS Agent’s Guide. For
information on locating this guide, see “Where to Go for Related Information” on
page 28.
Certificate Manager Agent Services
The Certificate Manager Agent Services interface enables a Certificate Manager
agent to interact with the Certificate Manager (the server). Figure 1-5 shows the
Certificate Manager Agent Services interface.
68
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Entry Points for Various Types of Users
Figure 1-5
Certificate Manager Agent Services interface
Using the default forms, a Certificate Manager agent can accomplish tasks such as
these:
•
Listing deferred certificate requests from end entities and process them
•
Listing certificates issued by the server
•
Searching for certificates issued by the server
•
Revoking certificates issued by the server
•
Updating certificates and certificate revocation lists (CRLs) maintained in the
publishing directory
Registration Manager Agent Services
The Registration Manager Agent Services interface enables a Registration Manager
agent to interact with the Registration Manager (the server). Figure 1-6 shows the
Registration Manager Agent Services interface.
Chapter 1
Introduction to Certificate Management System
69
Entry Points for Various Types of Users
Figure 1-6
Registration Manager Agent Services interface
Using the default forms, a Registration Manager agent can list deferred certificate
requests from end entities and process them.
Data Recovery Manager Agent Services
The Data Recovery Manager Agent Services interface enables a Data Recovery
Manager agent to interact with the Data Recovery Manager (the server). Figure 1-7
shows the Data Recovery Manager Agent Services interface.
70
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Entry Points for Various Types of Users
Figure 1-7
Data Recovery Manager Agent Services interface
Using the default forms, a Data Recovery Manager agent can search for and
recover end users’ encryption private keys from the key archive. (Key recovery
requires authorization from key recovery agents; see “Key Recovery Process” on
page 745.)
Online Certificate Status Manager Agent Services Interface
The Online Certificate Status Manager Agent Services interface enables a Online
Certificate Status Manager agent to interact with the Online Certificate Status
Manager (the server). Figure 1-8 shows the Online Certificate Status Manager
Agent Services interface.
Chapter 1
Introduction to Certificate Management System
71
Entry Points for Various Types of Users
Figure 1-8
Online Certificate Status Manager Agent Services interface
Using the default forms, a Online Certificate Status Manager agent can perform
tasks such as checking which CAs are currently configured to publish their CRLs to
the Online Certificate Status Manager, identifying a Certificate Manager to the
Online Certificate Status Manager, adding CRLs directly to the Online Certificate
Status Manager, and viewing the status of OCSP service requests submitted by
OCSP-compliant clients.
End-Entity Services Interface
Certificate Management System provides HTML forms for various
entities—people, routers, servers, and others—that use certificates to identify
themselves and that need to be able to request certificate issuance and management
operations. These forms, collectively identified as End-Entity Services Interface, use
different protocols and life-cycle management procedures for different kinds of
end entities. For example, the Certificate Manager provides separate certificate
enrollment forms for clients such as Netscape Navigator 3.x, versions of Netscape
Communicator later than 4.5, and Microsoft Internet Explorer. The reason for this
is that end entities running Navigator 3.x and Communicator versions earlier than
4.5 present an enrollment form based on the use of the HTML tag KEYGEN to
generate keys; end entities running Internet Explorer present a form based on
PKCS #10, the RSA standard for certificate request syntax.
72
iPlanet Certificate Management System Installation and Setup Guide • March 2001
System Architecture
For a summary of the various end entities, protocols, cryptographic algorithms,
and key pairs (single or dual) supported by Certificate Management System, see
“End Entities and Life-Cycle Management” on page 98.
Figure 1-9 shows the end-entity services interface of a Certificate Manager.
Figure 1-9
End-entity services interface
Note that the Data Recovery Manager and Online Certificate Status Manager do
not provide end-entity interfaces because end entities do not directly interact with
these servers. For a complete list of the end-entity forms—for enrollment, renewal,
retrieval, revocation, and key recovery—that come with Certificate Management
System, see CMS Customization Guide.
System Architecture
Figure 1-10 shows the internal architecture of Certificate Management System. The
sections that follow describe the basic elements of this architecture, starting at the
bottom of the figure.
Chapter 1
Introduction to Certificate Management System
73
System Architecture
Figure 1-10
CMS architecture
Authentication and
policy modules
Exposed developer APIs
CMS
CAmanagers
Middleware
JSS (Java-JNI layer)
JDK 1.1.6 and 1.2
NSS
secmod.db
PKCS #11
PKCS #11 modules
Slots
Tokens
Hardware
accelerator module
Third-party
module
Crypto services token
Netscape internal
module
Certificate DB token
certX.db
Netscape
FIPS module
74
iPlanet Certificate Management System Installation and Setup Guide • March 2001
keyX.db
FIPS Certificate DB token
System Architecture
PKCS #11
Public-Key Cryptography Standard (PKCS) #11 specifies an API used to
communicate with devices that hold cryptographic information and perform
cryptographic operations. Because it supports PKCS #11, Certificate Management
System works with a wide range of hardware and software devices intended for
such purposes.
One or more PKCS #11 modules must be available to any CMS subsystem instance.
As shown in Figure 1-10, a PKCS #11 module (also called a cryptographic module or
cryptographic service provider) manages cryptographic services such as encryption
and decryption via the PKCS #11 interface. PKCS #11 modules can be thought of as
drivers for cryptographic devices that can be implemented in either hardware or
software. Netscape provides a built-in PKCS #11 module with Certificate
Management System; see “Installing External Tokens” on page 455.
A PKCS #11 module always has one or more slots, which can be implemented as
physical hardware slots in some form of physical reader (for example, for smart
cards) or as conceptual slots in software. Each slot for a PKCS #11 module can in
turn contain a token, which is the hardware or software device that actually
provides cryptographic services and optionally stores certificates and keys.
Netscape provides two built-in modules with Certificate Management System:
•
Default Netscape Internal PKCS #11 Module. This comes with two built-in
tokens:
❍
❍
•
The Internal Crypto Services token performs all cryptographic operations,
such as encryption, decryption, and hashing.
The Internal Key Storage token (“Certificate DB token” in Figure 1-10)
handles all communication with the certificate and key database files
(called certX.db and keyX.db, respectively, where X is a version number)
that store certificates and keys.
FIPS 140-1 module. This module complies with the FIPS 140-1 government
standard for implementations of cryptographic modules. Many products sold
to the US government must comply with one or more of the FIPS standards.
The FIPS 140-1 module includes a single, built-in FIPS 140-1 Certificate DB
token (see Figure 1-10), which handles both cryptographic operations and
communication with the certX.db and keyX.db files.
Chapter 1
Introduction to Certificate Management System
75
System Architecture
Any PKCS #11 module can be used with Certificate Management System. The
server uses a file called secmod.db to keep track of the modules that are available.
You can modify this file with the Security Module Database Tool explained in the
CMS Command-Line Tools Guide. For example, you need to modify secmod.db if
you are installing hardware accelerators for use in signing operations.
NSS
Network Security Services (NSS) is a set of libraries designed to support
cross-platform development of security-enabled communications applications.
Applications built with the NSS libraries support the SSL protocol for
authentication, tamper detection, and encryption as well as the PKCS #11 interface
for cryptographic token interfaces. Netscape uses NSS to support these features in
a wide range of products, including Certificate Management System.
For more information about NSS, check this site:
http://www.mozilla.org/projects/security/pki/nss/
As shown in Figure 1-10, NSS communicates with PKCS #11 modules through the
PKCS #11 interface and in turn provides the foundation for Java Security Services
and higher Java layers.
JSS and the Java/JNI Layer
Java Security Services (JSS) provides a Java interface for security operations
performed by NSS. JSS and higher levels of the Certificate Management System
architecture are built with the Java Native Interface (JNI), which provides binary
compatibility across different versions of the Java Virtual Machine (JVM). This
design allows customized subsystem services to be compiled and built just once
and run on a range of platforms.
Middleware/Java 2 Layers
A middleware layer above JSS and the Java/JNI layer provides a range of services
required by the Registration Manager, Certificate Manager, Data Recovery
Manager, and Online Certificate Status Manager. The middleware layer is based on
Java 2.0, SDK 1.3.0, and it underlies both the manager subsystems and the APIs
available to third-party developers for building custom authentication and policy
modules. The default authentication and policy modules provided with Certificate
Management System are built from the same Java classes.
76
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Standards Summary
Authentication and Policy Modules
The top layer of Figure 1-10 consists of authentication and policy modules. Several
default modules ship with Certificate Management System; third parties can create
their own custom modules using the APIs provided above the middleware and
subsystem layers. Modules for all three subsystems work the same way and are
interchangeable.
Standards Summary
This section summarizes the standard message formats and protocols supported
by Certificate Management System.
Certificate Management Formats and Protocols
Certificate Management System supports the following certificate management
formats and protocols. For more details about the proposed PKIX standards listed
here, see http://www.ietf.org/html.charters/pkix-charter.html (under
Internet Drafts).
•
Certificate Enrollment Protocol (CEP). A certificate management protocol
jointly developed by Cisco Systems and VeriSign, Inc. CEP is an early
implementation of CMC (described later in this list). CEP specifies how a
device communicates with a CA, including how to retrieve the CA’s public
key, how to enroll a device with the CA, and how to retrieve a CRL. CEP uses
PKCS #7 and PKCS #10.
•
Certificate Request Message Format (CRMF). A message format used to
convey a request for a certificate to a Registration Manager or Certificate
Manager. A proposed standard from the Internet Engineering Task Force
(IETF) PKIX working group.
•
Certificate Management Message Formats (CMMF). Message formats used to
convey certificate requests and revocation requests from end entities to a
Registration Manager or Certificate Manager and to send a variety of
information to end entities. A proposed standard from the IETF PKIX working
group. CMMF is subsumed by another proposed standard, CMC (next item).
Chapter 1
Introduction to Certificate Management System
77
Standards Summary
•
Certificate Management Messages over CMS (CMC). A general interface to
public-key certification products based on CMS and PKCS #10, including a
certificate enrollment protocol for DSA-signed certificates with Diffie-Hellman
public keys. A proposed standard from the IETF PKIX working group. CMC
incorporates CRMF and CMMF. Future versions of Certificate Management
System will support this standard as it is finalized.
•
Cryptographic Message Syntax (CMS). A superset of PKCS #7 syntax used for
digital signatures and encryption. A proposed standard from the IETF PKIX
working group.
•
PKIX Certificate and CRL Profile (PKIX Part 1). The first part of the four-part
standard under development by the IETF for a public-key infrastructure for the
Internet. Part 1 deals with specifications for certificates and CRLs. Certificate
Management System will support the other PKIX parts as they are finalized.
For more information about PKIX Part 1, see
ftp://ftp.isi.edu/in-notes/rfc2459.txt.
Security and Directory Protocols
Certificate Management System supports the following security and directory
protocols:
78
•
FIPS PUBS 140-1. Federal Information Standards Publications (FIPS PUBS)
140-1 is a US government standard for implementations of cryptographic
modules—that is, hardware or software that encrypts and decrypts data or
performs other cryptographic operations (such as creating or verifying digital
signatures).
•
Hypertext Transport Protocol (HTTP) and Hypertext Transport Protocol
Secure (HTTPS). Protocols used to communicate with web servers.
•
KEYGEN tag. An HTML tag supported by Netscape browsers that generates a
key pair for use with a certificate. For more information, see
http://www.netscape.com/eng/security/comm4-keygen.html.
•
Lightweight Directory Access Protocol (LDAP) v2, v3. A directory service
protocol designed to run over TCP/IP and across multiple platforms. LDAP is
a simplified version of Directory Access Protocol (DAP), used to access X.500
directories. LDAP is under IETF change control and has evolved to meet
Internet requirements.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Standards Summary
•
Public-Key Cryptography Standard (PKCS) #7. An encrypted data and
message format developed by RSA Data Security to represent digital
signatures, certificate chains, and encrypted data. This format is used to deliver
certificates to end entities.
•
Public-Key Cryptography Standard (PKCS) #10. A message format developed
by RSA Data Security for certificate requests. This format is supported by
many server products and by Microsoft Internet Explorer.
•
Public-Key Cryptography Standard (PKCS) #11. Specifies an API used to
communicate with devices such as hardware tokens that hold cryptographic
information and perform cryptographic operations.
•
X.509 v1, v3. Digital certificate formats recommended by the International
Telecommunications Union (ITU).
•
Secure Sockets Layer (SSL) 2.0, 3.0. A set of rules governing server
authentication, client authentication, and encrypted communication between
servers and clients.
Chapter 1
Introduction to Certificate Management System
79
Standards Summary
80
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Chapter
2
Certificate Enrollment and Life-Cycle
Management
This chapter explains how you can use iPlanet Certificate Management System
(CMS) for issuing certificates to end entities such as we browsers, servers, routers,
and so on.
The chapter has the following sections:
•
Steps in End-Entity Enrollment (page 81)
•
Some Enrollment Scenarios (page 84)
•
End Entities and Life-Cycle Management (page 98)
This chapter assumes that you’ve read the previous chapter, Chapter 1,
“Introduction to Certificate Management System.”
Steps in End-Entity Enrollment
The following steps take place when a Registration Manager or a Certificate
Manager handles an enrollment request from an end user. Figure 2-1 shows a
simplified view of how this works.
1.
Submit form. When the user first interacts with the CMS manager (either the
Registration Manager or the Certificate Manager), the user specifies the kind of
request to be made, fills in the form for that request, and submits it to the
servlet via HTTP or HTTPS. The servlet then processes the form. In the figure,
a certificate request is being sent to an enrollment servlet. It could also be a
renewal or revocation request being sent to one of the other servlets.
81
Steps in End-Entity Enrollment
2.
Authenticate user. Authentication can be either automatic or manual. If the
CMS manager is configured for automatic authentication, the servlet uses the
authentication module specified by the form to validate the information
provided by the user. For example, the directory authentication module that
comes with Certificate Management System validates the user ID and
password by comparing it to the user’s entry in an LDAP directory. Custom
authentication modules can be used to take advantage of existing databases,
security systems, or other methods of authentication. If the CMS manager is
configured for manual authentication, the servlet routes the request to the
request queue and informs the user (via a web page) that approval has been
deferred. The request remains in the queue until an agent approves it or rejects
it.
3.
Process policies. If authentication is successful, policies specified for this CMS
manager are applied to the request for the purpose of formulating the contents
of the certificate to be issued and to enforce certain rules, such as name
constraints. Custom policy modules can be used to enforce specialized
certificate extensions and other requirements.
4.
Service request. After policy processing, the servlet’s work is finished and the
CMS manager services the request (assuming that a policy has not triggered
deferral)—for example, by issuing a certificate.
5.
Notify user. If the CMS manager has been configured for automatic
authentication and issuance, the manager delivers the signed certificate to the
user via a web page. If the request has been deferred (for example, for manual
approval) or rejected, the user is informed of the request’s status. When the
request has been approved and the certificate issued, the CMS manager
notifies the user (for example, with an email) and provides a URL where the
certificate can be picked up.
Since all three CMS managers use the same architecture for authentication and
policy processing, it’s possible to reuse any authentication and policy modules
with any manager. For information on the relationship of policy modules to the
APIs exposed by Certificate Management System, see “System Architecture” on
page 73.
82
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Steps in End-Entity Enrollment
Figure 2-1
Roles of servlets, authentication modules, and policy modules in end-entity enrollment
End user
5 Notify user
1
Submit
form
Netscape
Certificate
Management
System
4 Service
request
Enrollment
servlet
2
Authenticate
automatically
Authentication
module
OR
Registration
Manager/
Certificate
Manager
services
3 Process
policies
Policy
modules
2
Authenticate
manually
Approve/reject
request
Request
queue
CMS
agent
Chapter
2
Certificate Enrollment and Life-Cycle Management
83
Some Enrollment Scenarios
Some Enrollment Scenarios
Successful PKI deployment requires flexible and easy enrollment for end entities as
well as ongoing support for certificate life-cycle management—that is, management of
each certificate from enrollment through encryption key storage (if necessary),
renewal, and revocation. The preceding section describes the internal flow of
control among servlets, authentication modules, and policy modules in a CMS
manager (see Figure 2-1 for a summary). The examples that follow illustrate the
flexibility that the CMS architecture supports among end entities, Registration
Managers, Certificate Managers, and existing customer databases, security
systems, and directories.
•
Firewall Considerations
•
Extranet/E-Commerce: Acme Sales Corp.
•
PIN Registration: Atlas Manufacturing
•
VPN Client Enrollment and Revocation
•
Router Enrollment and Revocation
For the sake of simplicity, these examples do not show the role of the Data
Recovery Manager. For more information about data recovery, see “Data Recovery
Manager”“Data Recovery Manager” on page 48.
For more information about certificate life-cycle management, see “End Entities
and Life-Cycle Management” on page 98.
Firewall Considerations
Most of the examples that follow show a Certificate Manager inside the firewall
and a Registration Manager outside the firewall. Other variations are possible, but
this arrangement is often appropriate. These are some of the advantages:
84
•
The most sensitive elements of the deployment—the Certificate Manager,
internal databases, directories, and so on—have the additional protection of
the firewall.
•
The Certificate Manager can have additional physical protection, if
desired—such as storage in a locked room and agent authentication by means
of smart cards.
•
All communication between the Registration Manager and the Certificate
Manager takes place over SSL with mutual authentication—that is, both client
and server authentication via X.509 v3 certificates.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Some Enrollment Scenarios
•
The Registration Manager provides only a subset of the capabilities of the
Certificate Manager—those required for processing end-user requests. If the
Registration Manager is compromised, the Certificate Manager can revoke its
signing certificate (thus invalidating all subsequent requests from that
Registration Manager) and issue a new one after the problem has been
addressed.
Administrative and physical arrangements are closely related to firewall issues.
The flexibility of CMS deployment options makes it possible to divide functions
among existing administrative groups or physical locations, requiring minimal
disruption for an organization.
The examples that follow do not address the role of the Data Recovery Manager or
the potential use of multiple Registration Managers and Certificate Managers. For
example, in some circumstances it might make sense to have some Registration
Managers outside the firewall and some inside; in other cases different CMS
subsystems might be located in entirely different physical locations, each with their
own firewalls.
In general, Netscape recommends that the Certificate Manager handle all certificate
and CRL publishing functions. If it’s necessary for some entries in a directory to be
available outside the firewall, Netscape recommends using the partial replication
feature of Directory Server to replicate the relevant portion of the directory.
Extranet/E-Commerce: Acme Sales Corp.
Acme Sales is a high-end mail-order catalog service that is launching an online
shopping service. Many of Acme’s affluent customers make very expensive
purchases, so Acme has decided to use certificate-based authentication for its new
web site.
Acme has 100,000 existing customers and expects to attract many new customers
through its online service. The company wants to use its existing relational
database to authenticate and enroll existing customers with minimal effort on their
part. For new customers, Acme wants to establish a manual process entailing
out-of-band credit checks (that is, checks that don’t involve an electronic network),
identity verification, and a personal phone call before an online certificate request
can be granted. In addition, Acme plans to issue certificates to contract workers,
suppliers, and employees who routinely access parts of the company’s internal
network by using Kerberos.
Chapter
2
Certificate Enrollment and Life-Cycle Management
85
Some Enrollment Scenarios
The sections that follow describe how Acme uses Certificate Management System
to achieve these goals:
•
Enrolling Existing Customers
•
Enrolling New Customers
•
Enrolling Extranet Users
In all cases, Acme has decided to place its Certificate Manager behind the firewall
and its Registration Manager outside the firewall, for reasons summarized in
“Firewall Considerations” on page 84.
Enrolling Existing Customers
Acme has decided on the following process for registering its existing customers,
as shown in Figure 2-2.
86
1.
Request certificate. The customer fills in and submits a form (over SSL) that
specifies account information and other personal details stored in the existing
customer database.
2.
Custom authentication. The Registration Manager uses a custom
authentication module to verify the customer’s account and status against the
existing customer database.
3.
Request certificate. If authentication against the customer database is
successful, the Registration Manager performs policy processing and, if
processing is successful, forwards the request to the Certificate Manager.
4.
Issue certificate. The Certificate Manager performs its own policy processing
and, if processing is successful, issues the certificate and delivers it to the
Registration Manager.
5.
Deliver certificate. If the Certificate Manager successfully issues the certificate,
the Registration Manager delivers it to the end user in the same session. If the
request is unsuccessful for any reason, the Registration Manager displays a
web page to the customer explaining the problem and what to do about it.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Some Enrollment Scenarios
Figure 2-2
Custom authentication against an existing customer database
2 Custom
authentication
Existing
customer
database
1 Request
certificate
Existing
customer
5 Deliver
certificate
3 Request
certificate
4 Issue
Certificate
certificate Manager
Registration
Manager
Firewall
Enrolling New Customers
The following process will be used for enrolling new Acme customers. In this case,
the Registration Manager uses manual authentication to validate every certificate
request personally before issuing the certificate. Figure 2-3 illustrates the steps in
this process.
1.
Request certificate. The customer fills in and submits a certificate request form
for new Acme customers.
2.
Deferral notice. The Registration Manager immediately informs the customer
(via a web page) that the request has been deferred and that Acme will be in
touch soon. Meanwhile, the certificate request waits in a queue for attention
from the Registration Manager agent.
Chapter
2
Certificate Enrollment and Life-Cycle Management
87
Some Enrollment Scenarios
88
3.
Manual approval. The Registration Manager administrator may configure the
Registration Manager to notify the agent via email whenever a new request is
added to the request queue. In any case, when the agent processes the requests
in the queue, he or she follows Acme’s procedure for processing credit checks
and validating other customer information, including making a personal
phone call. If all authentication procedures are successful, the agent approves
the request.
4.
Request certificate. The Registration Manager performs policy processing and,
if the processing is successful, sends the approved request to the Certificate
Manager.
5.
Issue certificate. The Certificate Manager performs its own policy processing
on the request and, if processing is successful, issues the certificate and delivers
it to the Registration Manager.
6.
Email notice of issuance. The Registration Manager sends an email containing
a URL to the new customer, asking the customer to pick up the certificate.
7.
Pick up certificate. The customer goes to the specified Registration Manager
URL and picks up the certificate.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Some Enrollment Scenarios
Figure 2-3
Manual authentication of new customers
3 Manual
approval
Registration
Manager agent
1 Request
certificate
New
customer
4 Request
certificate
2 Deferral notice
7 Pick up
certificate
Registration
Manager
5
Issue
certificate
Certificate
Manager
6 Email notice of
issuance
Firewall
Enrolling Extranet Users
Acme wants its new, certificate-enabled extranet applications to be available to
contract workers, suppliers, employees, and others who routinely access parts of
the company’s internal network. In general, this can be achieved by using Kerberos
or other non-PKI security systems as the authentication mechanism for requesting
a certificate. To authenticate them for the purposes of PKI enrollment, Acme uses a
third-party authentication module from DASCOM that takes advantage of its
existing Kerberos system without disturbing its current functions.
Chapter
2
Certificate Enrollment and Life-Cycle Management
89
Some Enrollment Scenarios
For example, to get a certificate, a contractor provides an ID and password to the
Registration Manager, which uses the Kerberos system to verify them before
passing on the certificate request to the Certificate Manager. This arrangement
involves the following steps, illustrated in Figure 2-4. (The details of the existing
security system don’t matter: third-party or custom CMS authentication modules
can be used for Kerberos, NIS, and many other security systems. Extranet users can
continue to use applications based on the old security systems while they use their
certificates to take advantage of new certificate-based applications.)
90
1.
Request certificate. A user of Acme’s existing extranet fills in and submits a
certificate request (over SSL) using a customized form that requires a Kerberos
ID and password.
2.
Authentication. The Registration Manager uses a third-party authentication
module to validate the user’s identity using the existing internal Kerberos
system.
3.
Request certificate. If authentication against Kerberos is successful, the
Registration Manager performs policy processing and, if processing is
successful, forwards the request to the Certificate Manager.
4.
Issue certificate. The Certificate Manager performs its own policy processing
on the request and, if processing is successful, issues the certificate and delivers
it to the Registration Manager.
5.
Deliver certificate. If the Certificate Manager issues the certificate, the
Registration Manager delivers it to the end user in the same session. If the
request is unsuccessful for any reason, the Registration Manager displays a
web page to the user explaining the problem and what to do about it.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Some Enrollment Scenarios
Figure 2-4
Custom authentication against an existing Kerberos security system
Authentication
2 (third-party
module)
Kerberos
1 Request
certificate
Extranet
user
5 Deliver
certificate
3 Request
certificate
4 Issue
Certificate
certificate Manager
Registration
Manager
Firewall
PIN Registration: Atlas Manufacturing
Atlas Manufacturing has decided to put information for its employees, suppliers,
dealers, and customers—a total of nearly 500,000 people, including individual
consumers and employees of several dozen other companies—on an extranet.
Atlas already uses Netscape Directory Server to store names, addresses, and other
information about the various groups of people who will need access to the
extranet. To register all these people at once, Atlas uses the directory-based PIN
Generator tool that comes with Certificate Management System to generate PINs in
bulk. The PINs are then stored in the directory and delivered to the end users via a
batch mailer program, an employee payroll stub, a customer invoice, or some other
means of physical delivery.
PINs are salted and hashed before storage in the directory. Salting refers to the
inclusion of additional information from the distinguished name (DN) with the
PIN to ensure unique hashing. Hashing, in this case, involves generating a number
of fixed length from the PIN and DN information. Even if the security of the
directory is breached, it is very difficult to reconstruct the PIN from the value that
Chapter
2
Certificate Enrollment and Life-Cycle Management
91
Some Enrollment Scenarios
results from salting and hashing. When customers use the PIN to enroll in the Atlas
PKI, the PIN is automatically removed from the directory. Enrollment PINs are
therefore more reliable than passwords, which must be protected over a long
period of time.
Acme’s process involves the following steps (illustrated in Figure 2-5):
92
1.
Generate PINs. The CMS administrator runs the CMS PIN Generator against
the existing directory, populating each entry with a unique PIN.
2.
Write out PIN records. The CMS administrator uses the CMS PIN Generator to
write out PIN records for use by an out-of-band delivery mechanism.
3.
Out-of-band delivery. The user receives the PIN via a batch mailing system,
payroll stub, invoice form, or other out-of-band delivery mechanism.
4.
Request certificate (using PIN). The user goes to a specified Registration
Manager URL, fills in name and PIN, and submits a certificate request.
5.
Authentication (using PIN). The Registration Manager uses the standard CMS
PIN-based directory authentication module to verify the PIN against the
directory.
6.
Request certificate. If authentication against the directory is successful, the
Registration Manager performs policy processing and, if this succeeds,
forwards the request to the Certificate Manager.
7.
Issue certificate. The Certificate Manager performs its own policy processing
and, if all goes well, issues the certificate.
8.
Deliver certificate. If the Certificate Manager issues the certificate, the
Registration Manager delivers it to the end user in the same session. If the
request is unsuccessful for any reason, the Registration Manager displays a
web page to the user explaining the problem and what to do about it.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Some Enrollment Scenarios
Figure 2-5
PIN-based enrollment
3 Out-of-band
delivery
2 Write out
PIN records
Batch mailer
Payroll stubs
Invoices
etc.
CMS PIN
Generator
1
Generate
PINs
5 Authentication
(using PIN)
Publishing
directory
4 Request
certificate
(using PIN)
Extranet
user
8 Deliver
certificate
6 Request
certificate
Registration
Manager
7 Issue
certificate
Certificate
Manager
Firewall
VPN Client Enrollment and Revocation
Virtual private network (VPN) client software runs on a user’s desktop, outside the
firewall, and uses the IP Key Management Protocol (IPKMP) or IP Security (IPSec)
protocol to establish encrypted communication with VPN hardware that straddles
the firewall. These protocols allow VPN hardware to authenticate VPN client
software using the client’s certificate, in much the same way that the SSL protocol
allows a server to authenticate client browser software.
Chapter
2
Certificate Enrollment and Life-Cycle Management
93
Some Enrollment Scenarios
VPN client software can use several different protocols over HTTP or HTTPS to
handle enrollment and other life-cycle management tasks. Certificate Management
System supports the Certificate Enrollment Protocol (CEP) used by Cisco routers.
CEP runs over HTTP and provides its own form of encryption.
The following steps explain how VPN client software can use the Registration
Manager and Certificate Manager to enroll in a PKI and what happens when the
client’s certificate is revoked. These steps are shown in Figure 2-6.
94
1.
Enroll in PKI. The VPN client sends a certificate request to the Registration
Manager via CEP, and the Registration Manager processes the request and
forwards it to the Certificate Manager inside the firewall. (Any of the
authentication methods discussed in the previous sections can be used during
enrollment to authenticate the client.)
2.
Issue certificate. The Certificate Manager issues the certificate, and the
Registration Manager delivers it to the VPN client. The VPN client can now
authenticate itself to the VPN hardware and establish an encrypted channel
using IPKMP or IPSec. All TCP/IP communication passes through this
encrypted channel. From the point of view of the VPN client, it appears to be
directly connected to the TCP/IP network inside the firewall.
3.
Publish certificate. The Certificate Manager publishes the certificate to a
directory (this is an optional step).
4.
Revoke certificate. After some time has passed, the Certificate Manager agent
revokes the certificate (for example, after the certificate owner leaves the
company).
5.
Publish CRL. The Certificate Manager publishes a new CRL to the directory
specified as the CRL distribution point in the original certificate.
6.
Verify certificate. The VPN hardware checks the CRL as part of its
authentication process. Certificates listed in the CRL are not authenticated, and
VPN clients presenting them cannot establish a connection.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Some Enrollment Scenarios
VPN client enrollment and revocation
Figure 2-6
Certificate
Manager agent
HTTPS
Revoke
certificate
4
2 Issue
certificate
HTTPS
Certificate
Manager
Registration
Manager
3 Publish
certificate
CEP
over
HTTP
LDAP or
LDAPS
5 Publish
CRL
Publishing
directory
LDAP or
LDAPS
1
Enroll
in PKI
6 Verify
certificate
IPKMP or IPSec
VPN
hardware
TCP/IP
VPN client
Internal
network
router
Firewall
The certificate includes information about a CRL distribution point, which is a
directory that the VPN hardware can check for the latest CRL published by the
Certificate Manager.
Chapter
2
Certificate Enrollment and Life-Cycle Management
95
Some Enrollment Scenarios
Router Enrollment and Revocation
Cisco routers support the use of certificates for authentication, encryption, and
tamper detection with the IP Security (IPSec) protocol. Cisco routers also support
CEP for certificate life-cycle management, as discussed in the previous section.
The following steps describe how two routers can use a Certificate Manager to
enroll in a PKI and what happens when a router’s certificate is revoked. These
steps are shown in Figure 2-7.
96
1.
Enroll in PKI. The routers each send a certificate request to the Certificate
Manager via CEP, and the Certificate Manager issues them certificates. (Any of
the authentication methods discussed in the previous section can be used
during enrollment to authenticate the client.)
2.
Publish certificates. As part of the issuing process, the Certificate Manager
publishes the certificates to the directory. (Publishing occurs only if the router’s
DN exists in the publishing directory. This is important for some Cisco routers
that must fetch their certificates from an LDAP directory because flash memory
is not large enough to hold them.) The routers can now authenticate each other
and establish an encrypted channel using IPSec. All TCP/IP communication
passes through this encrypted channel. From the point of view of other
connections to each router, they all appear to be sharing the same TCP/IP
network.
3.
Revoke a certificate. After some time has passed, the Certificate Manager
agent revokes one of the certificates (for example, after the certificate owner
leaves the company).
4.
Publish CRL. The Certificate Manager publishes the CRL to the directory.
5.
Verify certificate. The routers check the CRL as part of their mutual
authentication process. Certificates listed in the CRL are not authenticated, and
routers presenting them cannot establish a connection.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Some Enrollment Scenarios
Router enrollment and revocation
Figure 2-7
Certificate
Manager agent
3 Revoke
certificate
HTTPS
4 Publish CRL
1
Enroll
in PKI
LDAP or
LDAPS
Certificate
Manager
CEP
over
HTTP
2
Publish
certificate
CEP
over
HTTP
1
Enroll
in PKI
IPSec
5 Verify
certificate
Public
network
TCP/IP
Cisco
router
Publishing
directory
LDAP or
LDAPS
TCP/IP
Cisco
router
LDAP or
LDAPS
5 Verify certificate
Chapter
2
Certificate Enrollment and Life-Cycle Management
97
End Entities and Life-Cycle Management
End Entities and Life-Cycle Management
Certificate Management System provides default web forms for all end-entity
interactions involved in managing the life cycle of a certificate. It also provides
forms, collectively called Agent Services, for agent interactions. These forms can be
used as is or customized. The Netscape Personal Security Manager is a software
that improves the PKI abilities of Netscape Communicator 4.7x versions.
The sections that follow introduce the end-entity forms and protocols.
•
Life-Cycle Management Formats and Protocols
•
Access to Subsystems
•
HTML Forms for End Users
•
Netscape Personal Security Manager
Life-Cycle Management Formats and Protocols
The Registration Manager and Certificate Manager provide default HTML forms
that use different protocols and life-cycle management procedures for different
kinds of end entities. For example, end entities running Navigator 3.x and versions
of Communicator earlier than 4.5 need to be presented with an enrollment form
based on the use of the HTML tag KEYGEN to generate keys. End entities running
Microsoft Internet Explorer require a form containing VBScript XENROLL
commands. These various tags, scripts, and protocols result in enrollment
messages that are sent back to the Certificate Manager or Registration Manager in a
variety of nonstandard and standards-based formats.
Table 2-1 summarizes the message formats, cryptographic algorithms, and key
pairs (single or dual) supported by Certificate Management System for the main
categories of end-entity software. Note that, for the purposes of enrollment, CMS
managers are also end entities. CMS managers installed in different instances need
SSL client and SSL server certificates to identify themselves. For more information
about the standards listed in Table 2-1, see “Standards Summary” on page 77.
98
iPlanet Certificate Management System Installation and Setup Guide • March 2001
End Entities and Life-Cycle Management
Table 2-1
End entities, message formats, algorithms, and key pairs supported by Certificate Management
System
End entity software
Enrollment message
format over HTTP or
HTTPS
Cryptographic algorithms
No. of key pairs
Navigator 3.x
KEYGEN tag
Signing and encryption:
RSA
Single key pair
Communicator 4.0 to 4.5
Signing only: RSA, DSA
Internet Explorer 3.x and
4.x
PKCS #10
Signing and encryption:
RSA
Single key pair
Signing only: RSA
Internet Explorer 5.x
PKCS #10
Signing and encryption:
RSA
Single or dual key
pairs
Signing only: RSA, DSA
Communicator 4.7x and
later versions
CRMF and CMMF
based on new
JavaScript API
Signing and encryption:
RSA
Single or dual key
pairs
Netscape servers
(including CMS
managers) and other
servers
PKCS #10
Signing and encryption:
RSA
Single key pair
Cisco routers (version IOS
12.04) and VPN clients
CEP
Signing and encryption:
RSA
Single key pair
Signing only: RSA, DSA
Access to Subsystems
Three kinds of entities can access CMS subsystems: administrators, agents, and end
entities. Administrators are responsible for the initial setup and ongoing
maintenance of the subsystems. Agents manage the day-to-day operations of each
subsystem, such as responding to requests from end entities. End entities access
Registration Manager or Certificate Manager subsystems to enroll in a PKI and to
take part in other life-cycle management operations, such as renewal or revocation.
Figure 2-8 shows the ports used by administrators, agents, and end entities. All
agent and administrator interactions with CMS subsystems occur over HTTPS.
Chapter
2
Certificate Enrollment and Life-Cycle Management
99
End Entities and Life-Cycle Management
End-entity interactions can take place over HTTP or HTTPS. For example, routers
using CEP, which includes its own encryption scheme, uses HTTP rather than
HTTPS. For a more detailed discussion of these ports and examples of hands-on
use, see Chapter 3, “Default Demo Installation.”
Figure 2-8
Access ports for Certificate Management System
Certificate Management System
Agent
port
EE ports
HTTP
HTTPS
End-entity
registration
services
(HTML forms)
100
Administration
port
HTTPS
HTTPS
Netscape
Console/
CMS window
Agent services
(HTML forms)
Browsers and
other products
Browsers
Java
application
End entities
Agents
Administrators
iPlanet Certificate Management System Installation and Setup Guide • March 2001
End Entities and Life-Cycle Management
HTML Forms for End Users
Each type of end-entity form provided by a Registration Manager or Certificate
Manager determines the type of client, such as Communicator or Internet Explorer,
and presents the appropriate input page. Each form also specifies both an
authentication module and an output template. The authentication module is used
by the servlet to authenticate the end entity; the output template is an HTML page
that returns information from the servlet to the end entity.
Figure 2-9 shows the default manual enrollment form as it is presented to end users
running Communicator 4.5. Users can click items in the left menu and tabs to
access other HTML forms. Server administrators, including CMS administrators,
can also access forms for enrolling servers or subsystems. Any of these forms can
be customized to reflect an organization’s requirements.
Figure 2-9
Default manual enrollment form for end users
Chapter
2
Certificate Enrollment and Life-Cycle Management
101
End Entities and Life-Cycle Management
Table 2-2 shows the protocols supported by the default CMS life-cycle
management servlets. Any of the HTML forms and their HTML help text can be
customized. The Registration Manager also supports the creation of new forms.
Some output templates can also be customized.
Table 2-2
Default CMS life-cycle management servlets and supported protocols
Life-cycle management servlet
Message syntax/procedures for end entities
Certificate enrollment form
User certificates: KEYGEN for
Navigator/Communicator, VBScript/XENROLL and
PKCS #10 for Internet Explorer
Server certificates: PKCS #10 (cut and paste; also
URI for Administration Server 3.5 and 4.1)
Certificate renewal form
User certificates: SSL client authentication
Server certificates: PKCS #10 (cut and paste)
Certificate revocation form
User certificates: SSL client authentication
Server certificates: agent initiated
Encryption key storage and
recovery form
Not supported for Navigator/Communicator 4.x;
CRMF for Communicator 5.0 (based on new
JavaScript API).
For more information about the standards listed in Table 2-1, see “Standards
Summary” on page 77.
Netscape Personal Security Manager
Netscape Personal Security Manager is a standards-based, client-independent
application that performs PKI operations on behalf of Netscape Communicator 4.7
and other applications. Personal Security Manager provides advanced
cryptographic capabilities while at the same time hiding the complexity of PKI
operations from end users. In particular, Personal Security Manager simplifies
certificate deployment with Certificate Management System by taking advantage
of the following CMS features:
102
•
One-click issuance of certificates.
•
Forced certificate backup by end users after certificate issuance.
•
Issuance and management of separate signing and encryption certificates.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
End Entities and Life-Cycle Management
•
Automatic storage of encryption private keys with the Data Recovery Manager
at the time a certificate is issued, if requested by the Registration Manager.
•
Automatic revocation checking each time Personal Security Manager verifies a
certificate.
Behind the scenes, Personal Security Manager supports the following
cryptographic capabilities:
•
SSL v2 and v3. SSL authentication, encryption, and tamper detection.
•
S/MIME. Signed and encrypted email (using separate signing and encryption
keys if desired)
•
PKCS #5. Encryption for private key storage.
•
PKCS #7. Signing operations.
•
PKCS #11. Communication with PKCS #11 modules and associated
cryptographic tokens (such as smart cards).
•
PKCS #12. Export and import of certificates and associated private keys.
•
CRMF/CMMF. Direct commmunication between Personal Security Manager
and a CA, simplifying enrollment processes and making one-click issuance
possible.
•
Online Certificate Status Protocol (OCSP). Real-time revocation checking.
For more information or to download the latest version of Personal Security
Manager, check this site:
http://docs.iplanet.com/docs/manuals/psm.html
The above site also provides links to deployment information as it becomes
available, including details on how to set up Certificate Management System for
use with Personal Security Manager.
Keep in mind that Personal Security Manager works only with Netscape
Communicator, version 4.7x, which can be downloaded from this site:
http://home.netscape.com/download/
Chapter
2
Certificate Enrollment and Life-Cycle Management
103
End Entities and Life-Cycle Management
104
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Chapter
3
Default Demo Installation
This chapter describes how to set up a simple installation that demonstrates the
basic capabilities of a Certificate Manager with an integrated Registration
Manager. It is intended for administrators who are already familiar with PKI
concepts. An experienced administrator should be able to install and set up the
default demo in less than an hour, then use it to try out basic iPlanet Certificate
Management System (CMS) procedures.
CAUTION
This chapter describes how to install a Certificate Manager for
demonstration purposes only. The steps described require that you
accept most of the default values suggested at each stage of
installation and configuration. Before you attempt to install more
sophisticated pilots or a full-scale deployment, you should read
Chapter 4, “Planning Your Deployment” and the chapters that
follow.
This chapter has the following sections:
•
System Requirements (page 106)
•
Overview of the Default Demo (page 109)
•
Installing the Default Demo (page 113)
•
Using the Default Demo (page 140)
105
System Requirements
System Requirements
This section summarizes the basic software and hardware requirements for any
machine on which you intend to install Certificate Management System instances
and related software:
•
Operating System and Software Required
•
Platform Requirements
NOTE
Be sure to check the Release Notes that came with the product. It
would contain any last-minute changes to the information specified
in this section.
Operating System and Software Required
Operating systems supported:
•
Compaq Tru64 v4.0D
•
HP-UX B.11.00
•
IBM AIX 4.3.3
•
Sun Solaris 2.6, 2.7, and 8 (with relevant Java 2 patches)
•
Windows NT 4.0 with Service Pack 5 or 6
Other required software:
•
Netscape Administration Server 4.2 (included)
•
Netscape Directory Server 4.13 (included)
•
Browser software that supports SSL
Platform Requirements
Each platform has slightly different requirements. In addition to the requirements
listed in Table 3-1, make sure you have ample swap space or virtual memory
allocated for the system on which you intend to install Certificate Management
System.
106
iPlanet Certificate Management System Installation and Setup Guide • March 2001
System Requirements
Table 3-1
Software and hardware requirements
Compaq Tru64 Platform Requirements
OS Version
Compaq Tru64 v4.0D (with relevant Java 2 patches)
Machine
267MHz alpha or faster
RAM
256 MB
Hard disk storage space
requirements
Total required is approximately 400 MB, broken down as follows:
• Total transient space required during installation: 100 MB
• Hard disk storage space required for installation (approximate values):
Space required for setup, configuration, and running the server: 250 MB
Additional space to allow for database growth in pilot deployment: 50
MB
Total disk storage space for installation: 300 MB
HP-UX Platform Requirements
OS Version
HP-UX B.11.00 (with relevant Java 2 patches)
Machine
240MHz PA_RISC 9000/800 or faster
RAM
512 MB
Hard disk storage space
requirements
Total required is approximately 420 MB, broken down as follows:
• Total transient space required during installation: 120 MB
• Hard disk storage space required for installation (approximate values):
Space required for setup, configuration, and running the server: 250 MB
Additional space to allow for database growth in pilot deployment: 50
MB
Total disk storage space for installation: 300 MB
IBM AIX Platform Requirements
OS Version
AIX 4.3.3 (with relevant Java 2 patches)
Machine
PowerPC_604 or faster
RAM
1 GB
Hard disk storage space
requirements
Total required is approximately 400 MB, broken down as follows:
• Total transient space required during installation: 100 MB
• Hard disk storage space required for installation (approximate values):
Space required for setup, configuration, and running the server: 250 MB
Additional space to allow for database growth in pilot deployment: 50
MB
Total disk storage space for installation: 300 MB
Chapter
3
Default Demo Installation
107
System Requirements
Table 3-1
Software and hardware requirements (Continued)
Solaris Platform Requirements
OS Version
Solaris 2.6, 2.7, or 8 (with relevant Java 2 patches)
Machine
Ultra 1 or faster
RAM
128 MB (required)
Hard disk storage space
requirements
Total required is approximately 400 MB, broken down as follows:
• Total transient space required during installation: 100 MB
• Hard disk storage space required for installation (approximate values):
Space required for setup, configuration, and running the server: 250 MB
Additional space to allow for database growth in pilot deployment: 50
MB (this may be reduced to 10 MB for default demo installation)
Total disk storage space for installation: 300 MB
Windows NT Platform Requirements
OS Version
Windows NT 4.0 with Service Pack 5 or 6
Machine
Pentium 350 or faster
File system
NTFS or FAT
RAM
128 MB of RAM (recommended)
Hard disk storage space
requirements
Total required is approximately 350 MB, broken down as follows:
• Total transient space required during installation: 100 MB
• Hard disk storage space required for installation (approximate values):
Space required for setup, configuration, and running the server: 200 MB
Additional space to allow for database growth in pilot deployment: 50
MB (this may be reduced to 10 MB for default demo installation)
Total disk storage space for installation: 250 MB
Other Requirements
• On UNIX systems, you must install as root in order to use well-known
port numbers (such as 443) that are less than 1024. If you do not plan to
use port numbers less than 1024, you do not need to install as root. If you
plan to run the Administration Server as root, you should also install as
root and specify the default user and group, nobody, as the system ID
for other server processes.
• On a Windows NT system, you must install as Administrator or a
user with Administrator privileges (that is, the user must be in
the Administrators group).
108
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Overview of the Default Demo
Overview of the Default Demo
The default demo installation described in this chapter is intended to provide a
quick, hands-on experience of the basic Certificate Management System interfaces.
It is intended for demonstration purposes only and relies on a number of default
settings that may not be appropriate for a mission-critical installation. Before you
attempt to install more sophisticated pilots or a full-scale deployment, read
Chapter 4, “Planning Your Deployment” and the chapters that follow.
The default demo installation includes the following Netscape software:
•
Netscape Console. Netscape Console is described in a separate guide,
Managing Servers with Netscape Console. It is a standalone Java application used
to manage Netscape server instances with the aid of a configuration directory
and a user directory. For this demo, Netscape Console controls just the server
instances listed here; the configuration and user directories are combined in a
single Netscape Directory Server instance. In real deployments, Netscape
Console can be set up to control a variety of servers in different instances and
on different machines that are registered with a single configuration directory,
which could potentially be separate from the user directory.
•
Netscape Administration Server. This lightweight HTTP server acts as the
back end to Netscape Console. An instance of Administration Server manages
operation requests involving any Netscape servers installed in the same server
root, or server group, and invokes CGI programs to perform these operations.
For this demo, a single Administration Server instance provides administrative
access to the Directory Server instance and Certificate Manager instance listed
below—the only other server instances in the same server group.
•
Configuration and User Directory (Netscape Directory Server). This is an
instance of Netscape Directory Server with two subtrees. The user subtree
keeps track of users and groups and their privileges (for the Administration
Server, not for Certificate Management System). The configuration subtree
keeps track of the location on the network of Netscape servers. For this demo,
the configuration subtree keeps track of itself, the Administration Server
instance, the single instance of Certificate Management System, and a separate
instance of Netscape Directory Server that serves as the internal database for
Certificate Management System. For this demo, the user subtree is also used as
the user and group directory for directory-based authentication and
publishing.
•
Certificate Manager. For this demo, the single instance of Certificate
Management System contains a Certificate Manager that is configured to
perform registration tasks as well as CA tasks.
Chapter
3
Default Demo Installation
109
Overview of the Default Demo
•
Internal Database (Netscape Directory Server) for Certificate Management
System. For each instance of Certificate Management System you install an
instance of Netscape Directory Server that acts as the internal database for
certificate and request information.
You use the main window of Netscape Console to perform basic tasks such as
starting and stopping a server. To manage any server controlled by Netscape
Console (in this case, just Directory Server and the Certificate Manager), first locate
it on the left side of the main Netscape Console window, then double-click the icon
to open a separate administrative window for that server.
Netscape Console uses the configuration directory for information on the locations
and contents of server groups on the network. It also interacts with the
Administration Server for each server group to perform some tasks, such as
managing SSL encryption settings. However, to manage settings displayed in the
Netscape Console window for a particular Certificate Management System
instance, Netscape Console acts directly on a configuration file stored with that
instance. (For more information about the configuration file, see Chapter 10, “CMS
Configuration.”
As you proceed with the default demo installation and configuration, you will be
asked to assign several port numbers, names, and passwords. Figure 3-1 shows the
four main software elements of the demo and the port numbers and protocols they
use for different purposes. Using the default ports for the end-entity URLs helps
users because they will not need to remember port numbers; any HTTPS request
will try port 443 if no port is specified in the URL.
110
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Overview of the Default Demo
Figure 3-1
Software installed and port numbers assigned for the default demo
Server
software
installed . . .
Listening on
port # . . .
For these
protocols:
389*
LDAP or
LDAPS
Configuration
directory
Administration
Server
4444
Netscape
Console
HTTP
38900
LDAP
Certificate
Manager
Database
8200
Certificate
Manager
8100
443*
* = Standard port
for the given
protocol
80*
HTTPS
Certificate
Manager
agent
HTTPS
HTTPS
End entity
HTTP
End entity
You will also be asked to provide additional information, such as the name of each
server instance to be installed, the names and passwords of various types of
administrators, and information related to the CA signing certificate and SSL
server certificate that the Certificate Manager must have available before it can
begin operation.
Chapter
3
Default Demo Installation
111
Overview of the Default Demo
To keep things simple for the default demo, most of the information requested
during installation is set either to a default or to some arbitrary, convenient value.
Before you attempt to install more sophisticated pilots or a full-scale deployment,
you should read Chapter 4, “Planning Your Deployment” and the chapters that
follow to determine the precise names and settings that are appropriate for your
situation.
Another difference between the default demo and more sophisticated installations
is that the Directory Server instance, in addition to providing both the
configuration directory and the user directory, is also used to publish and test
certificates you issue with the Certificate Manager instance. In a real-world
deployment, the Directory Server Instance used for configuration and for users is
unlikely to be used for publishing.
Demo Passwords
The demo that you install is a real CA that can issue certificates. Even if you plan to
remove it after testing, you should maintain the security of the demo system. For
this reason, the installation procedure does not give specific passwords for each
administrative user. However, to avoid confusion, the passwords that you will
need are identified here and are later referred to by this identification. If you make
a list of the passwords you decide on, be sure to keep the list secure.
You will need to provide the following passwords during the installation process:
112
<admin password>
Administrator for both Administration Server and its
configuration directory. Use this password to start
Netscape Console and the Installation Wizard.
<dir mgr password>
Manager for the configuration directory. (This password
must be at least eight characters.)
<intdb password>
Administrator for the CMS internal database (an instance
of Directory Server). This password is kept and protected
in a special cache that you access with the
<single-signon password>.
<CMS password>
CMS administrator. Use this password to access Netscape
Console’s CMS window.
<token password>
Password for the CMS key database. This password is
kept and protected in a special cache that you access with
the <single-signon password>.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Installing the Default Demo
<single-signon
password>
This password protects the <intdb password> and
<token password>. Use this password to start
Certificate Management System.
Installing the Default Demo
The installation script installs and starts an Administration Server and a Directory
Server; the process is slightly different for Windows NT and UNIX systems. The
Installation Wizard, which is the same on both systems, installs Certificate
Management System itself and creates the system’s certificates. When you have
finished installing the files, you start Certificate Management System and enroll for
the initial administrator-agent certificate, which you then use to verify that the
system is properly installed and functions correctly.
The steps of this installation procedure are described in the following sections:
•
Step 1. Run the Installation Script — UNIX or
Step 1. Run the Installation Script—Windows NT
•
Step 2. Run the Installation Wizard
•
Step 3. Get the First User Certificate
Step 1. Run the Installation Script — UNIX
These instructions assume that you have the initial distribution of Certificate
Management System available, either on a CD or on your hard disk.
If you are using a Windows NT system, see “Step 1. Run the Installation
Script—Windows NT” on page 115.
To run the installation script, change to the distribution directory (where you have
downloaded the distribution files) and execute the file setup.
In the instructions that follow, the question that appears at the bottom of each
setup screen is in boldface, followed by the action you should take.
1.
Would you like to continue with setup? [Yes]: Press Enter.
2.
Do you agree to the license terms? [No]: Type yes and press Enter.
3.
Select the items you would like to install [1]: Press Enter.
Chapter
3
Default Demo Installation
113
Installing the Default Demo
4.
Server root [/usr/netscape/server4]: Press Enter to accept the default server
root directory. (If you are not installing as root, you probably will not have
permission to create directories in /usr so you will have to choose another
location.)
5.
Specify the components you wish to install [All]: Press Enter to accept the
default.
6.
Specify the components you wish to install [1,2,3]: Press Enter to accept the
default server product components.
7.
Specify the components you wish to install [1,2]: Press Enter to accept the
default Directory Suite components.
8.
Specify the components you wish to install [1,2]: Press Enter to accept the
default Administration Services components.
9.
Specify the components you wish to install [1, 2]: Press Enter to accept the
default CMS components.
10. Computer name [myhost.mydomain.com]: Press Enter to install on the local
machine.
11. System User [nobody]: Enter the user that the configuration/user Directory
Server process will run as. Where your system supports it, accept the default
user, nobody, creating that user as necessary.
12. System Group [nobody]: Enter the group that the configuration/user
Directory Server process will run as. Where your system supports it, accept the
default group, nobody, creating that group as necessary.
13. Do you want to register this software with an existing Netscape
configuration directory server? [No]: Press Enter to install a new configuration
directory.
14. Do you want to use another directory to store your data? [No]: Press Enter to
use the new configuration directory as your user/group directory.
15. Directory server network port [389]: Press enter to accept the default, 389. If
you are not installing as root or if 389 is in use, the default will be a random
number; you may want to change this number to something easy to remember,
such as 38989.
16. Directory server identifier [myhost]: Type configdir as the unique identifier
for the configuration directory, and press Enter.
17. Netscape configuration directory server administrator ID [admin]: Press
Enter to accept the default, then enter the <admin password>.
114
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Installing the Default Demo
18. Suffix [o=mydomain.com]: Press Enter to accept the default.
19. Directory Manager DN [cn=Directory Manager]: Press Enter to accept the
default, then enter the <dir mgr password>.
20. Administration Domain [mydomain.com]: Press Enter to accept the default.
21. Administration port [random #]: Type 4444 and press Enter.
22. Run Administration Server as [root]: Press Enter to accept the default.
23. Certificate Management System Server identifier [localhost]: Type demoCA
and press Enter. After the script copies the files and updates the system, which
may take a few minutes, press Enter to continue.
The first phase of the installation is now complete. The installation script has
installed Netscape Console, installed and started an Administration Server and its
configuration directory, and copied the files for Certificate Management System.
You are now ready to configure the Certificate Management System instance by
running the Installation Wizard.
Step 1. Run the Installation Script—Windows NT
These instructions assume that you have the initial distribution of Certificate
Management System available, either on a CD or on your hard disk.
If you are using a UNIX system, see “Step 1. Run the Installation Script — UNIX”
on page 113.
1.
To run the installation script, open the distribution directory for the system
software you are using and double-click the file setup.exe.
In the instructions that follow, the name that appears in the title bar of each
setup screen is in bold, followed by a description of the action you should take.
Chapter
3
Default Demo Installation
115
Installing the Default Demo
116
2.
Welcome. Click Next.
3.
Software License Agreement. Click Yes.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Installing the Default Demo
4.
Select Server or Console Installation. Leave the default setting (Netscape
Servers) selected and click Next.
5.
Choose the Installation Type. Leave the default setting (Typical) selected and
click Next.
Chapter
3
Default Demo Installation
117
Installing the Default Demo
118
6.
Choose Installation Directory. Leave the default setting
(C:\Netscape\Server4) selected and click Next.
7.
Select Products. Leave all four components selected and click Next.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Installing the Default Demo
8.
9.
Directory Server 4.13. Leave the default setting (This instance will be the
configuration directory server) selected and click Next.
Directory Server 4.13. Leave the default setting (Store data in this
directory server) selected and click Next.
10. Directory Server 4.13 Server Settings. Type the following values, then click
Next:
Chapter
3
Default Demo Installation
119
Installing the Default Demo
Server identifier: configdir
Server port: Accept the default, which should be 389
Suffix: Accept the default, which should be your company’s domain name, in
the form o=<your_domain>.<domain>.
11. Directory Server 4.13 Netscape Configuration Directory Server
Administrator. Type the following values, then click Next:
Configuration Directory Administrator ID: admin
Password: <admin password>
Password (again): <admin password>
120
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Installing the Default Demo
12. Directory Server 4.13 Administration Domain. Accept the default, which
should be your company’s domain name, in the form
<your_domain>.<domain>.
13. Directory Server 4.13 Directory Manager Settings. Type the following values,
then click Next:
Directory Manager DN: cn=Directory Manager
Password: <dir mgr password>
Password (again): <dir mgr password>
Chapter
3
Default Demo Installation
121
Installing the Default Demo
14. Administration Server Port Selection. Type the value 4444 and click Next.
15. Certificate Management System Server identifier. Type the value demoCA and
click Next.
122
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Installing the Default Demo
16. Configuration Summary. Click Next.
17. Setup. At this point, the installation script extracts and installs the binaries for
all of the servers in the server root directory and creates and starts instances of
the Administration Server and Directory Server. This process may take a few
minutes.
18. Setup Complete. Leave the default setting (Launch the Netscape Console)
and click Finish.
The first phase of the installation is now complete. The installation script has
installed Netscape Console, installed and started an Administration Server and its
configuration directory, and copied the files for Certificate Management System.
You are now ready to complete the installation of Certificate Management System
by running the Installation Wizard.
Chapter
3
Default Demo Installation
123
Installing the Default Demo
Step 2. Run the Installation Wizard
To begin running the Installation Wizard, follow these steps:
1.
If Netscape Console is not running, start it.
❍
❍
2.
On a Windows NT system, click Start, and then choose Programs,
Netscape Server Family, and Netscape Console 4.2, in that order.
Alternatively, click the Netscape Console shortcut in the Netscape Server
Family directory that opens on your desktop after setup completes.
On a Unix system, open a command shell, change to the directory
/usr/netscape/server4, and execute the file startconsole.
Log in as admin, giving the password <admin password>.
The main window of Netscape Console appears.
If the Administration URL is not filled in, enter http://<myhost>:4444
3.
124
In the navigation tree at the left, open your computer, then open Server Group.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Installing the Default Demo
4.
Select cert-demoCA and double-click it; alternatively, you can also click the
Open button on the Certificate Management System panel on the right.
After a few moments, the Installation Wizard appears. You use the wizard to
get the initial certificates and set the initial configuration for this demo instance
of Certificate Management System.
In the instructions that follow, the panel title that appears below the title bar for
each screen is in boldface, followed by the action you should take.
1.
Introduction. Click Next.
Chapter
3
Default Demo Installation
125
Installing the Default Demo
2.
Internal Database. Type the following values, then click Next:
Instance ID: Accept the default (demoCA-db).
Port number: Accept the default (38900).
Directory Manager DN: cn=Directory Manager
Password: <intdb password>
Password (again): <intdb password>
At this point the system creates the internal database, which can take some
time.
126
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Installing the Default Demo
3.
Administrator. Type the following values, then click Next:
Administrator ID: CMSadmin
Full name: Accept the default value.
Password: <CMS password>
Password (again): <CMS password>
4.
Subsystems. Click Next to accept the default selection (Certificate Manager
only).
Chapter
3
Default Demo Installation
127
Installing the Default Demo
5.
Remote Data Recovery Manager. Click Next to accept the default selection
(No).
At this point the system configures the internal database, which can take some
time.
128
6.
CA’s serial number range. Click Next to accept the default (start at 0x1 with no
upper limit).
7.
Internal OCSP Service. Click Next to accept the default (the option is selected).
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Installing the Default Demo
8.
Network Configuration. Select the Enable checkbox to enable the non-SSL
end-entity gateway, then accept the default values listed below. If one of the
default ports is unavailable, a different, randomly selected port will appear in
the form.
SSL administration port: 8200
SSL agent port: 8100
SSL end-entity port: 443
Enable: Select this checkbox to enable the non-SSL end-entity gateway.
Non-SSL end-entity port: 80
9.
CA Signing Certificate. Click Next to accept the default selection (Create
self-signed CA certificate).
Chapter
3
Default Demo Installation
129
Installing the Default Demo
10. Key-Pair Information for Certificate Manager CA Signing Certificate. Type
the following values, then click Next:
Token: Accept the default value (Internal).
Password: <token password>
Password (again): <token password>
Key type: Accept the default value (RSA).
Key length: Select 1024 and leave the custom key-length field blank.
11. Message Digest Algorithm. Click Next to accept the default (SHA1).
130
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Installing the Default Demo
12. Subject Name for Certificate Manager CA Signing Certificate. Type the
following values, then click Next:
Common name (CN=): Demo CA
Organization Unit (OU=): CMS Demo
Organization (O=): <name of your company>
Locality (L=): <name of your locality>
State (ST=): <name of your state, province, or territory>
Country (C=): <two-letter code for your country>
13. Validity Period for Certificate Manager CA Signing Certificate. Modify year
and month values of “Expire on” date to allow a validity period of one month
from the installation date, then click Next.
Chapter
3
Default Demo Installation
131
Installing the Default Demo
14. Certificate Extensions for Certificate Manager CA Signing Certificate. Click
Next to accept the default selections.
15. Certificate Manager CA Signing Certificate Creation. Click Next.
16. SSL Server Certificate. Click Next to accept the default selection (Sign SSL
certificate with my CA signing certificate selected.).
132
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Installing the Default Demo
17. Key-Pair Information for Server SSL Certificate. Change the Key length to
1024, accept the default values for other fields, then click Next.
18. Message Digest Algorithm. Click Next to accept the default (SHA1).
19. Subject Name for SSL Server Certificate. Type the following values, then click
Next.
Common name (CN=): <hostname, in the “machine.domain.com” form>
Organization Unit (OU=): CMS Demo
Organization (O=): <name of your company>
Locality (L=): <name of your locality>
State (ST=): <name of your state, province, or territory>
Country (C=): <two-letter code for your country>
Chapter
3
Default Demo Installation
133
Installing the Default Demo
20. Validity Period for SSL Server Certificate. Modify year and month values of
“Expire on” date to allow a validity period of one month from the installation
date, then click Next.
134
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Installing the Default Demo
21. Certificate Extensions for SSL Server Certificate. Click Next to accept the
default selections.
22. SSL Server Certificate Creation. Click Next.
The generation of the certificate can take some time.
23. Set Up Single Signon Password. Type the following values, then click Next.
Single signon password: <single-signon password>
Single signon password (again): <single-signon password>
Chapter
3
Default Demo Installation
135
Installing the Default Demo
24. Configuration Status. Click Done. Certificate Management System starts
automatically.
136
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Installing the Default Demo
The installation and configuration of Certificate Management System is now
complete, and the Certificate Manager is running.
The user interface of Certificate Management System is now available through the
web gateways whose ports you specified during installation. You can access them
directly in a web browser by going to those ports using the appropriate protocol.
•
The SSL agent gateway URL is:
https://<machine_name>.<your_domain>.<domain>:8100
•
The SSL end-user gateway URL is:
https://<machine_name>.<your_domain>.<domain>:443
•
The non-SSL end-user gateway URL is:
http://<machine_name>.<your_domain>.<domain>:80
Step 3. Get the First User Certificate
After you complete configuration of Certificate Management System with the
Installation Wizard, you must enroll for a certificate for the first agent. This is the
first user certificate that Certificate Management System issues.
The initial user is both an administrator and an agent. This person can use
Netscape Console to create additional agents with the appropriate user privileges
and use Agent Services to issue them certificates. Since there is no agent yet to
approve the request, a special enrollment form allows you to get this first certificate
automatically.
After you submit this initial Administrator/Agent Certificate Enrollment form, it is
automatically disabled, so that no one else can acquire a certificate without agent
approval or some form of automated authentication. The system automatically
adds the initial user to the list of agents.
Enrolling for the First Agent Certificate
To enroll for the first agent certificate, you should be working at the computer you
intend to use as the agent, so that the new certificate will be installed in the browser
you will be using to access the Agent Services pages. Follow these steps:
1.
Open a web browser window.
2.
Go to the URL for the SSL agent port (8100).
For example: https://d9816-nt.siroe.com:8100.
Chapter
3
Default Demo Installation
137
Installing the Default Demo
The first time you access this port, the system opens the Administrator/Agent
Certificate Enrollment form.
Because you have accessed an SSL port, Certificate Management System
presents its SSL server certificate to your browser for authentication. This is the
SSL server certificate that you just created during installation. Because you just
created it, it is not on your list of trusted certificates. A series of dialog boxes
now appears that lets you add the CMS server certificate to your list of trusted
certificates.
3.
Complete the dialog boxes as instructed (the exact procedure depends on the
browser you are using).
4.
In the Administrator/Agent Certificate Enrollment form, enroll for a client SSL
certificate as the system’s first privileged user by entering the following
information:
Authentication Information
User ID: CMSadmin
Password: <CMS password>
138
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Installing the Default Demo
Subject Name
Full name: CMS Administrator
Login name: CMSadmin
Email address: <your email address>
Organization unit: CMS Demo
Organization: <name of your company>
User’s Key Length Information
Key Length: Select 1024 (High Grade)
Note that the validity period of this initial agent certificate is hard-coded as one
year.
5.
Click Submit.
6.
Follow the instructions your browser presents as it generates a key pair.
If authentication is successful, the new certificate will be imported into your
browser. You should make a backup copy of the certificate.
Now you have a client authentication certificate in the name CMS Administrator.
This special user name, which you specified as the initial administrator for
Certificate Management System during installation, has now been designated as
the first agent. The certificate you just created allows you to access the Agent
Services pages. As an agent, you can approve enrollment requests and start issuing
new certificates. To access the CMS windows in Netscape Console, you use the
CMS administrator user ID and the CMS password.
If You Need the First Agent Form Again
After you submit the initial Administrator/Agent Certificate Enrollment form, it is
no longer available from the agent port. If something goes wrong and you are
unable to obtain the initial agent certificate, you must reset a parameter in the
configuration file to make the initial Administrator/Agent Certificate Enrollment
form available again. Follow these steps:
1.
In the left frame of Netscape Console, open cert-demoCA.
The server requests your <CMS password>.
2.
Click the icon labeled “Stop the Server”.
3.
Go to this directory: <server_root>/cert-demoCA/config
4.
Open the file CMS.cfg in a text editor, and find the following line:
agentGateway.enableAdminEnroll=false
Chapter
3
Default Demo Installation
139
Using the Default Demo
5.
Change false to true, and save the file.
6.
Start the server from the CMS window where you stopped it.
Alternatively, right-click on cert-demoCA in the left frame and choose Start
Server.
7.
Enter your <single-signon password>.
The next time you access https://<hostname>:8100, the
Administrative/Agent Enrollment form will be available again.
Using the Default Demo
You have now performed a basic installation and can use the installed demo
Certificate Manager to issue certificates. This section provides the following
exercises with which you can test the installation and practice using the system:
•
“Verify the Installation,” (page 140): Accessing the various web gateways and
using the default versions of the forms to enroll for and issue a certificate.
•
“Create a Policy,” (page 145): Configuring the Certificate Manager to reject
certificate requests that do not use at least 1024-bit key lengths.
•
“Use an LDAP Directory,” (page 147): Adding a user to the configuration
directory you just installed and using directory-based authentication to enroll
as that user.
•
“Publish Certificates to an LDAP Directory,” (page 152): Publishing client
certificates to the directory.
•
“Send Renewal Reminders,” (page 158): Configuring the Certificate Manager
to send out automatic renewal reminders to entities whose certificates will be
expiring soon.
Verify the Installation
To verify that the installation is correct and complete, you will access each of the
different gateways for the various user interface pages: the SSL and non-SSL
end-user pages, and the Agent Services pages for the Certificate Manager. You will
use each set of pages to perform a basic task.
•
140
In “Viewing Issued Certificates From the Agent Gateway,” you will view a list
of the certificates that the demo CA has issued so far.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Using the Default Demo
•
In “Enrolling for a Certificate From the End-Entity Gateway,” you will enroll
for a certificate by using the manual enrollment procedure.
•
In “Finding and Approving a Certificate Request,” you will approve the new
certificate enrollment request and issue a new agent certificate.
•
In “Testing Your New Certificate,” you will use the new agent certificate to
access the agent gateway.
NOTE
In a real installation, you would probably not give users access to
both gateways or to all the enrollment choices and other possible
actions in the pages. You access both end-user gateways here
simply for testing purposes, not because these particular actions
need to be performed from these locations.
Viewing Issued Certificates From the Agent Gateway
1.
In a web browser window, use HTTPS to go to the URL for the SSL agent port
that you specified. For example: https://<hostname>:8100
2.
Because this is an SSL connection, you are prompted to present your client SSL
certificate for authentication. Choose the certificate you received on initial
enrollment.
The Agent Services entry page appears.
3.
Click Services Summary.
The Services Summary page appears, giving you access to all the gateways.
Chapter
3
Default Demo Installation
141
Using the Default Demo
4.
Click End Users Services.
The Enrollment tab for the non-SSL end-entity gateway appears.
5.
Click the Retrieval tab.
The form that appears is for the first option, List Certificates.
6.
Type 0x0 into the field labeled “Lowest serial number,” then click Find to list
the certificates that the Certificate Manager has issued so far.
If you followed the instructions in this chapter exactly, you should see three
certificates listed: the CA signing certificate (CN=Demo CA), the Certificate
Manager SSL server certificate (CN=<your hostname>), and your initial agent
certificate (CN=CMS administrator).
7.
Use the browser’s Back button to go back to the Services Summary page. (For
example, when using Communicator, press and hold the mouse button while
it’s over the Back button, then choose Index from the pop-up menu.)
Enrolling for a Certificate From the End-Entity Gateway
After following the previous procedure, your browser will be at the Services
Summary page. Follow this procedure to submit an enrollment request through the
end-entity gateway.
1.
Click SSL End-Users Services.
The Enrollment tab for the SSL end-entity gateway appears.
2.
Use the Manual User Enrollment form that appears to enroll for a certificate.
For Full Name, type the name User1, so you will recognize this certificate as
distinct from your administrator’s certificate. When you have finished filling it
out, submit the form.
142
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Using the Default Demo
3.
Follow the instructions your browser presents as it generates a key pair.
After the key pair has been generated, the Certificate Manager displays a notice
that the certificate request has been submitted, including a request ID.
4.
Use the browser’s Back button to go back to the Services Summary page. (For
example, when using Communicator, press and hold the mouse button while
it’s over the Back button, then choose Index from the pop-up menu.)
Finding and Approving a Certificate Request
After following the previous procedure, your browser will be at the Services
Summary page. Follow this procedure to approve the enrollment request you just
submitted. This procedure will issue a certificate from the request that can be used
as an agent certificate.
1.
Click Agent Services, then click Certificate Manager Agent Services.
To access this page, your browser must present your client SSL certificate to
authenticate your identity.
2.
If a dialog box appears requesting that you select a certificate, select the
certificate name that begins with CMS Administrator.
The first form for the Agent Services gateway appears—the List Requests form.
3.
Select “Show enrollment requests” for Request Type.
4.
Select “Show Pending Requests” for Request status, and then click Find.
One request should be returned: the request you just made through the SSL
end-user gateway, which is marked as pending.
5.
Click the Details button next to the pending request.
6.
Scroll down to the last section of the Request Details form, labeled Privileges.
7.
Select the checkbox labeled “This certificate is for a Certificate Manager agent,”
then type a user ID for the new agent.
This user ID can be the same (User1) that you specified in the certificate
request, or it can be some other ID that you want to use to identify this agent in
the CMS window of Netscape Console, such as Agent1.
8.
At the bottom of the form, select “Accept this request” and click Do It.
The certificate is issued immediately. The Request Details form is replaced by a
form announcing that the certificate has been generated, along with its serial
number.
Chapter
3
Default Demo Installation
143
Using the Default Demo
9.
Click Show Certificate to view the new certificate.
At the bottom of the page is a button labeled Import Your Certificate.
Normally, you would mail this page to the requestor, or the Certificate
Manager would mail the requestor an automatic notification containing the
certificate and instructions.
10. Since you made the request yourself from this computer, go ahead and click
Import Your Certificate to import the certificate into your browser.
You have now designated User1 as an agent. Since you have already issued a
certificate in the name of User1, you can now present that certificate to access the
Agent Services pages. User1 is an agent, but not an administrator; as User1, you
can manage certificate requests, but you cannot access Netscape Console’s CMS
window to configure the system.
Setting Your Browser to Use the Agent Certificate
To verify that the User1 certificate really can access the agent pages, you must first
set your browser to use the User1 certificate to identify you to web sites. To do this
in Communicator 4.x, for example, follow these steps:
1.
Click the Security button in the Navigation toolbar near the top of the window.
2.
Click Navigator in the left-hand frame.
3.
From the drop-down list labeled “Certificate to identify you to a web site,”
select your User1 certificate.
4.
Click OK.
Testing Your New Certificate
Clear the browsers cached security information so that it will ask for a new
certificate when you view the agent gateway.
1.
Go to any other web page that is not part of Agent Services (such as
http://home.netscape.com).
2.
Return to the Agent Services pages at the URL for the SSL agent port that you
specified.
For example: https://myhost.mydomain.com:8100
You should be able to access the Agent Services pages without any difficulty,
as long as you are using the same computer from which you requested and
imported the User1 certificate.
144
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Using the Default Demo
Before you continue, you might want to try accessing the new installation from
another computer and with a different login. Try enrolling for user certificates from
there, using both the SSL and non-SSL end-user gateways. If you wish, you can
also enroll for additional agent certificates. You will have to return to the computer
from which you requested and imported your CMSAdmin and User1 certificates to
access the Agent Services pages and approve the requests.
Create a Policy
Policies are rules that you define that are applied to requests before a certificate is
issued. Certificate Management System provides configurable policies that allow
you to enforce your organization’s requirements for certificates. You can configure
different policies to be applied to different requests based on criteria such as the
type of request or which Registration Manager or Certificate Manager received the
request. You can find out more about policies in Chapter 18, “Setting Up Policies.”
In a real PKI deployment, you would probably formulate your policies before
installing any software, and configure how the policies will be implemented before
issuing any certificates. For this demonstration, you will implement a simple but
very useful rule before you start issuing certificates.
You will create a policy that requires all certificate requests use RSA key pairs that
are 1024-bit or longer. This ensures that all of the certificates you issue meet a
minimum level of security. Later, you will try to enroll for a certificate using a
shorter-length key pair (512 bits) to show how the request is rejected automatically
by the policy.
Policies do not always result in acceptance or rejection: they can also be used to
modify certificate attributes such as the validity period or certificate extensions. In
the “Create a Policy” exercise, you create a policy that will reject requests that do
not have at least 1024-bit keys. In the “Use an LDAP Directory” exercise, you will
try to enroll using a 512-bit key to see how the policy works.
Configuring an RSA Key Length Policy
1.
Start Netscape Console:
❍
❍
On a Windows NT system, click Start, then choose Programs, then
Netscape Server Family, then Netscape Console 4.2.
On a UNIX system, open a command shell, change to the directory
/usr/netscape/server4, and execute the file startconsole.
Chapter
3
Default Demo Installation
145
Using the Default Demo
2.
Log in as admin, giving the password <admin password>.
The main window of Netscape Console appears.
3.
In the navigation tree on the left, open your computer, then open Server
Group.
4.
Select the CMS instance (cert-demoCA).
5.
In the Certificate Management System panel at the right, click Open.
6.
Log in as CMSadmin, giving the password <CMS password>.
Netscape Console’s CMS window appears, showing the Tasks tab.
146
7.
In the CMS window, click the Configuration tab.
8.
In the navigation tree on the left, open the Certificate Manager folder and click
Policies.
9.
From the list of policies in the Policy Rules Management tab, select RSAKeyRule
(the second policy in the list) then click Edit/View.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Using the Default Demo
10. In the Policy Editor dialog box, provide the following information:
minSize: 1024
maxSize: 2048
exponents: accept the default setting
enable: true
predicate: HTTP_PARAMS.certType==client
The predicate indicates that this policy will be applied to certificate requests
for client certificates only. The minSize sets the minimum allowed length for
the RSA key pair used to generate the request; requests with shorter RSA keys
will be rejected. The policy is turned on for all requests to this Certificate
Manager by setting enabled to true.
11. Click OK to save the changes. The RSAKeyRule should now be listed as enabled
in the Policy Rules Management tab.
That is all you need to do. The policy will now be enforced on all requests for client
certificates. You will see how this policy works in the next part of the
demonstration when you enroll for a client certificate.
Use an LDAP Directory
To test using Certificate Management System with an LDAP directory, you will use
Netscape Console’s CMS window to enable directory-based authentication using
the configuration directory that you installed with the demo. You will add a user
(User2) to the directory, then enroll for a certificate as User2, using directory-based
enrollment.
Chapter
3
Default Demo Installation
147
Using the Default Demo
You will first try to enroll using 512-bit keys; the enrollment will fail because of the
policy requiring 1024-bit keys. After you submit a new request with a 1024-bit key,
Certificate Management System should authenticate the user information in the
directory and issue the certificate automatically.
To use directory-based authentication to enroll entities:
•
Step 1. Enable Directory-Based Authentication
•
Step 2. Add a User to the Directory
•
Step 3. Enroll with Directory-Based Authentication
You can find out more about authentication in Chapter 15, “Setting Up End-User
Authentication.”
Step 1. Enable Directory-Based Authentication
To enable directory-based authentication for the Certificate Manager:
1.
If the CMS console window is not still open, start Netscape Console again (or
go back to the main window) and open the window for Certificate
Management System.
2.
In the CMS console window, select the Configuration tab, then select
Authentication in the navigation tree.
3.
On the Authentication Instance tab, click Add.
4.
In the Select Authentication Plugin Implementation dialog box, select
UidPwdDirAuth and click Next.
5.
In the Authentication Instance Editor dialog box, provide the following
information:
Authentication Instance ID: UserDirEnrollment
dnpattern: cn=$attr.cn,c=US
ldapStringAttributes: Leave blank
ldapByteAttributes: Leave blank
ldap.ldapconn.host: <hostname>
ldap.ldapconn.port: 389
ldap.ldapconn.secureConn: false
148
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Using the Default Demo
ldap.ldapconn.version: 3
ldap.basedn: o=<your domain>.<domain>
ldap.minConns: 3
ldap.maxConns: 5
6.
Click OK.
NOTE
If you leave the dnpattern field blank, the dnpattern used by
default is E=$attr.mail,CN=$attr.cn,O=dn.o,C=$dn.c. This
pattern works well with Communicator and other browsers. For
the demo, you used a simpler dnpattern to avoid configuring other
things. The simpler pattern should not be used for a real
deployment. End-entity certificates for use with S/MIME may not
work correctly if the E attribute is not present. Certificate display
will not work correctly if the C and O attributes are left out.
Step 2. Add a User to the Directory
The users and groups of your organization are kept in the organization’s global
directory. Since you are using the configuration directory that you installed with
the demo to simulate such a global directory, you must add a user to the
configuration directory’s user and groups subtree. (Notice that this is a different
operation from adding a user or group to the Certificate Manager’s internal
database.)
Chapter
3
Default Demo Installation
149
Using the Default Demo
To add a user to the configuration directory’s subtree for users and groups:
1.
Start Netscape Console again, or go back to the main window.
2.
Select the Users and Groups tab and click Create (in the lower right corner).
3.
In the Select Organization Unit dialog box, select People and click OK.
4.
In the Create User dialog box fill out the required fields as follows:
First Name: User
Last Name: Two
Full Name: User Two
User ID: User2
Password: <User2 password>
Confirm password: <User2 password>
E-Mail: <your email address>
150
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Using the Default Demo
5.
Click OK.
You can see that User Two has been added to the list of users.
Step 3. Enroll with Directory-Based Authentication
Now that there is a user in the authentication directory, you can test
directory-based authentication. In order to show the key length policy working,
you will request the certificate using a 512-bit key first, then change the request to
use a 1024-bit key.
1.
Open a browser window and go to the Certificate Manager’s end-entity
interface: https://<machine_name>.<your_domain>.<domain>:444
2.
In the Enrollment panel under User Enrollment, click Directory-based.
3.
Fill out the enrollment form as follows:
User ID: User2
Password: <User2 password>
Key Length: Select 512 (Low Grade)
4.
Click Submit.
A dialog box asks whether to generate a private key.
Chapter
3
Default Demo Installation
151
Using the Default Demo
5.
Click OK, and provide your key database password if requested.
After the key is generated, your browser submits the certificate request to the
Certificate Manager. The Certificate Manager verifies the request against all
applicable policies (including the RSA key length policy for client certificates
you configured earlier). The response from the server will be a Request
Rejected page explaining that the request violated the RSAKeyRule policy.
6.
Use your browser’s Back button to return to the Directory-based enrollment
form. If the identity information is no longer present, enter the User ID and
Password again.
7.
Change the Key Length setting to 1024 (High Grade), and click Submit.
A dialog box asks whether to generate a private key.
8.
Click OK, and provide your key database password if requested.
The new certificate is issued immediately and installed in your browser.
Next, you will configure Certificate Management System to publish (in the
directory) the certificate you just issued.
Publish Certificates to an LDAP Directory
In any PKI there are things that you need to publish to make them available to
entities. Certificate revocation lists (CRLs), for example, can be made available at a
well known URL so that clients and servers can check them as needed instead of
fetching and storing the list every time it is updated. In a PKI where people need to
exchange encrypted files or email, you do not want each person to have to store
everyone else’s public key; instead, you can publish certificates to a directory or
database and allow users to look up public keys as needed.
In this example, you will configure a Certificate Manager to publish new
certificates to an existing directory (the configuration directory that Netscape
Console uses).
To publish certificates to a directory, you must configure information about the
destination directory, configure the rules for publishing to it, then update the
directory. Updating the directory publishes certificates that were issued before
publishing was enabled; certificates issued later will be published automatically as
they are issued.
Before you change the configuration you should understand the basics of the
flexible components that make up the Certificate Management System publishing
system: mappers, publishers, and rules.
152
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Using the Default Demo
Mappers translate objects (such as certificates) in the internal database into some
other form for publishing. You will configure an LDAP mapper to translate the
user name in a client certificate request to a distinguished name (DN) in the
publishing directory.
Publishers are objects that actually publish the data. You will not configure the
publisher here, but the LdapUserCertPublisher finds the DN that the mapper
produces and adds a certificate attribute to its entry. The value of the attribute,
of course, is the client certificate (in a binary form).
Rules coordinate the use of a mapper with a publisher for objects that meet certain
conditions. The conditions may simply require a certain type of object (such as a
client certificate). A condition may also assert some additional requirement (a
predicate) that must be true about that type of object in order to invoke the rule.
You will not configure any rules in this example. By default, the Certificate
Manager uses a rule to coordinate the LdapUserCertMap and the
LdapUserCertPublisher for publishing client certificates.
Configure the Publishing Destination
To enable publishing and configure the directory where certificates will be
published:
1.
If the CMS window is not still open, start Netscape Console again (or go back
to the main Console window) and open the window for Certificate
Management System.
2.
Open the Certificate Manager folder and select Publishing.
3.
Check the Enable Publishing checkbox then the Enable LDAP Publishing
checkbox.
The Destination area becomes editable.
Chapter
3
Default Demo Installation
153
Using the Default Demo
4.
Enter information in the Destination area to identify the directory to which you
want to publish (use the configuration directory, where User Two’s entry is
stored):
Host Name: <machine_name>.<your_domain>.<domain>
Port Number: 389
Directory Manager DN: cn=Directory Manager
Password: <dir mgr password>
Password (again): <dir mgr password>
Version: 3
Authentication: Basic authentication
5.
Click Save.
A dialog box appears that indicates whether Certificate Management System is
able to connect, authenticate, and bind to the directory.
If your configuration is not successful, make sure that the entries you make in
the Destination area correspond to how you configured the Configuration
Directory Server when you ran the setup program.
Directory publishing is now enabled. Certificate Management System will publish
any new certificates to the directory according to the publication rules. The next
step is to set those rules.
154
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Using the Default Demo
Set Rules for Publishing Certificates
In this section, you configure Certificate Management System to map client
certificates to People entries in the o=<your_domain.<domain> directory tree
using the user ID from the certificate request.
To configure Certificate Management System to publish user certificates to an
LDAP directory:
1.
Open the CMS console window and select the Configuration tab.
2.
Open the Certificate Manager folder and double-click Publishing.
3.
Below Publishing in the navigation tree, click Mappers.
4.
In the Mappers Management tab, select LdapUserCertMap and click
Edit/View.
Chapter
3
Default Demo Installation
155
Using the Default Demo
5.
Change the dnPattern parameter value to UID=$req.UID, OU=people,
O=<your domain>.<domain>
This pattern will cause the mapper to formulate a DN using the user ID from
the certificate request (the data entered in the User ID field on the end entity
enrollment form) and fixed values for OU and O.
6.
Click OK.
Certificate Management System can now publish user certificates in the
configuration directory. You do not need to configure the Publisher or Rule. If you
want to see more about how the rule works, look at the LdapUserCertRule under
Rules (using the Edit/View button) and the LdapUserCertPublisher under
Publishers.
Update the Publishing Directory
Your Certificate Manager is now configured to automatically publish newly issued
client certificates. If you want to experience this, you can follow the instructions in
“Step 2. Add a User to the Directory” and “Step 3. Enroll with Directory-Based
Authentication” again to add a new user and enroll for a certificate.
Use the procedure in this example to view the new user’s directory entry and see
the certificate published automatically (certificates are published every 20 minutes,
so you may need to wait a few minutes before a new certificate is published).
In the example here, you conclude by manually updating the directory with the
issued (but unpublished) certificate for User Two. You will look at User Two’s
directory entry before and after publishing to see how the entry changes.
156
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Using the Default Demo
To view the directory entry for User Two:
1.
Go to the Netscape Console main window, select the configuration directory
(configdir) in the navigation tree, and then click Open.
2.
Click the Directory tab.
The directory information trees are represented in the navigation tree on the
left.
3.
Open the entry for your domain (for example, siroe.com).
4.
Select the People node in the entry for your domain.
The right side of the window lists the People entries. (If you have followed the
examples, User Two will be the only entry.)
5.
Double-click the User Two entry to open the Edit Entry dialog box.
6.
Click Advanced at the bottom of the dialog box to see all of the attributes for
User Two in the Property Editor dialog box.
User Two has attributes for Email address, First name, etc., but no certificate.
7.
Click Cancel to close the Property Editor dialog box, but leave the Edit Entry
dialog box open if you can: you will open the Property Editor again after you
manually publish certificates.
To publish certificates to the directory manually:
1.
In a browser, go to the URL for the SSL agent port. For example:
https://myhost.mydomain.com:8100/
If you are asked to select a certificate for client authentication, be sure not to
choose the certificate for User Two since that user does not have administrative
privileges.
2.
Select Certificate Manager Agent Services.
3.
Select Update Directory Server from the list on the left.
4.
Check the first checkbox, labeled “Update everything in the database to the
directory,” then click Update Directory.
After a few seconds a results page displays. Most of the entries will indicate
failures because in this example you did not configure publishing rules for
most of the object types in the internal database.
The third item in the list should read “Valid certificates have been published in
the directory.” This means that publishing client certificates was successful.
Chapter
3
Default Demo Installation
157
Using the Default Demo
5.
Return to the Edit Entry dialog for User Two (repeat the previous procedure if
necessary) and click Advanced to open the Property Editor.
The first attribute listed is now the Certificate for User Two. The certificate is in
an unreadable binary form, so you do not see any actual data.
You have successfully configured the Certificate Manager to publish client
certificates to an LDAP directory.
Send Renewal Reminders
Certificate Management System provides a facility for scheduling automatic jobs.
The jobs facility can help you manage the certificate lifecycle by automating
processes such as removing revoked certificates from your data store or notifying
end-entities when their certificates are about to expire.
This exercise will show you how to use the jobs facility to send out automatic
renewal reminders to entities. You will configure Certificate Management System
to send email to entities starting 400 days before the certificate expires. In a real
deployment, of course, you would probably not start reminding certificate holders
to renew until 30 days before expiration. You will see the email that is sent to a
certificate holder and a summary report of all notices that can be sent to a CMS
agent.
To complete this exercise, you need to have access to a host that can receive Simple
Mail Transfer Protocol (SMTP) requests and send mail. By default, Certificate
Management System configures localhost (the machine on which it is running) as
the mail server. Many UNIX hosts run SMTP daemons (such as sendmail) in their
default configurations, so in UNIX you may not need to change the CMS defaults.
Windows NT systems, however, do not typically run SMTP daemons by default
and you will probably need to configure the SMTP settings in Certificate
Management System.
If you are sure that the machine on which Certificate Management System is
running is also capable of receiving SMTP requests on port 25, skip to
“Configuring Certificate Management System to Send Renewal Reminders.”
Otherwise, find out the name of host that can accept SMTP requests and follow the
next procedure, “Configuring a Mail Server for Certificate Management System,”
to configure Certificate Management System.
158
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Using the Default Demo
Configuring a Mail Server for Certificate Management System
To configure the server from which Certificate Management System can send mail:
1.
Open the CMS console window and select the Configuration tab.
2.
Click the SMTP tab.
3.
Type the hostname of your mail server in the “Server name” field.
4.
Enter the port number your server uses for SMTP in the Port Number field.
If you are certain that your server uses a port number other than 25 for SMTP,
enter it in the “Port number” field. However, it is unlikely that any server uses
a different number for the well-known SMTP service.
5.
Click Save.
Configuring Certificate Management System to Send Renewal
Reminders
To configure Certificate Management System to send renewal reminders:
1.
Open the CMS console window and select the Configuration tab.
2.
Open Job Scheduler in the navigation tree.
3.
Select Jobs.
4.
Select certRenewalNotifier in the Job Instance tab.
5.
Click Edit/View.
Chapter
3
Default Demo Installation
159
Using the Default Demo
The Job Instance Editor dialog box displays. By default this job is enabled and
scheduled to notify end-entities 30 days before their certificates expire. You
will change the settings so that renewal notices begin 400 days before the
certificate expires (so you will get notices for the certificates issued during this
demonstration). You will also send notices every minute (instead of every day)
so that you get an immediate message, and send a summary report to yourself.
6.
Make sure the following parameters have the listed values:
enabled: true
cron: * * * * * (include spaces between the asterisks)
notifyTriggerOffset: 400
senderEmail: <your email address>
summary.enabled: true
summary.recipientEmail: <your email address>
summary.senderEmail: <your email address>
7.
Click OK.
8.
Select Job Scheduler in the Configuration tab’s navigation tree.
The next step will turn on the Job Scheduler. Once the scheduler is enabled you
will receive at least two email messages every minute. Make sure you turn off
the Job Scheduler after a few minutes to avoid a flood of email messages.
160
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Using the Default Demo
9.
Select the Enable Jobs Scheduler checkbox.
10. Click Save.
You should begin receiving email after one minute.
11. After the scheduler has been running for a few minutes, deselect the Enable
Jobs Scheduler checkbox.
12. Click Save.
13. Check your email.
You will have at least two messages.
Messages with the subject “Certificate Renewal Notification” are examples of
notices sent to end entities. By default, these are sent to the address in the email
(E) attribute in the certificate subject. These messages explain that the
certificate is going to expire on a certain date, and they provide a URL for an
end-entity gateway where the certificate can be renewed.
Messages with the subject “Certificate Renewal Notification Summary” are
examples of the summary report sent to the address in the job’s
summaryRecipientEmail parameter (usually a CMS agent). These messages
list all of the certificates that are about to expire (according to the job’s
notifyTriggerOffset parameter) and whether or not the Certificate Manager
succeeded in sending a renewal notice.
Chapter
3
Default Demo Installation
161
Using the Default Demo
The message content, format, and subject are all customizable, so in a real
deployment you can create messages that better suit your organization.
You have now completed the default demo. Before you attempt to install more
sophisticated pilots or a full-scale deployment, you should read Chapter 4,
“Planning Your Deployment” and the chapters that follow.
After you are finished using the demonstration installation, remove it from your
system. For instructions, see “Uninstalling Certificate Management System” on
page 310.
162
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Part
2
Planning and Installation
Chapter 4, “Planning Your Deployment”
Chapter 5, “Installation Worksheet”
Chapter 6, “Installing Certificate Management System”
Chapter 7, “Installing and Uninstalling CMS Instances”
Chapter 8, “Starting and Stopping CMS Instances”
163
164
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Chapter
4
Planning Your Deployment
Before installing iPlanet Certificate Management System (CMS) in any real-life
deployment, you first need to plan all aspects of the proposed installation. It’s
important to consider all potential issues carefully before installation. Omissions or
faulty assumptions in the planning process can cause severe problems later.
This chapter provides an overview of the most important decisions you need to
make. Many of these decisions are interdependent; for example, the question of
whether a Certificate Manager is subordinate affects its distinguished name (DN)
as well as its validity period, extensions, and place in the CA hierarchy.
As you begin to make decisions about your deployment strategy, you can use
Chapter 5, “Installation Worksheet” to collect the detailed information you must
supply during the installation and configuration of individual subsystems.
This chapter has the following sections:
•
Topology Decisions (page 166)
•
Certificate Authority Decisions (page 175)
•
Cryptographic Token Decisions (page 179)
•
Publishing Decisions (page 179)
•
Subsystem Certificate Decisions (page 182)
•
Authentication Decisions (page 185)
•
Policy Decisions (page 185)
•
Deployment Strategy and Port Assignments (page 186)
165
Topology Decisions
Topology Decisions
Certificate Management System allows you to install the Certificate Manager,
Registration Manager, Data Recovery Manager, and Online Certificate Status
Manager in many different configurations.
Since CAs can delegate some responsibilities to subordinate CAs, a Certificate
Manager might delegate responsibilities to one or more levels of subordinate
Certificate Managers. Therefore many complex variations are possible. You should
carefully consider the appropriate topology for your deployment before you make
any other deployment plans.
The sections that follow describe the simplest arrangements:
•
Server Groups and CMS Instances (page 166)
•
Single Certificate Manager (page 167)
•
Certificate Manager and Registration Manager (page 168)
•
Certificate Manager and Data Recovery Manager (page 170)
•
Certificate Manager, Data Recovery Manager, and Registration Manager
(page 172)
•
Cloned Certificate Manager
Server Groups and CMS Instances
As described in Managing Servers with Netscape Console, Netscape servers installed
in a single server root directory are called a server group and are managed by a
single instance of Netscape Administration Server. As shown in Figure 4-1, a CMS
instance in a server group can contain a single subsystem of any kind, or either of
the following combinations:
•
One Certificate Manager and one Data Recovery Manager
•
One Registration Manager and one Data Recovery Manager
Other combinations are not permitted.
A Certificate Manager and a Registration Manager or Online Certificate Status
Manager are always permitted in separate instances, whether the instances are in
the same server group, in separate server groups on the same machine, or in
separate server groups on separate machines.
166
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Topology Decisions
Single Certificate Manager
Some deployments may require only a single Certificate Manager that handles all
end-entity interactions and provides no key archival and recovery capabilities. This
Certificate Manager can use a signing certificate issued by a public certificate
authority or its own self-signed CA signing certificate to sign all the certificates it
issues.
Figure 4-1 shows the relationships among a single Certificate Manager, end
entities, and a publishing directory. The Certificate Manager can publish both
end-entity certificates and CRLs to a directory.
Figure 4-1
Single root Certificate Manager
Publishing directory
CEP
CRMF
CMMF
End
entities
LDAP or
LDAPS
Certificates
and CRLs
KEYGEN tag
PKCS #7
PKCS #10
Certificate
Manager
HTTP/
HTTPS
The arrangement shown in Figure 4-1 is equivalent to the capabilities provided by
Netscape Certificate Server 1.x—with the addition of new Certificate Management
System features such as Digital Signature Algorithm (DSA) signing, support for
PKCS #11, and support for a wider variety of end-entity protocols.
Chapter
4
Planning Your Deployment
167
Topology Decisions
Certificate Manager and Registration Manager
Many organizations need to separate the role of the Registration Manager from the
role of the Certificate Manager. This separation can be useful, for example, if
different groups of end entities are subject to different authentication policies or
work in different geographic locations.
Each group of end entities interacts with a designated Registration Manager that
processes requests from end entities and sends them to a Certificate Manager. The
Certificate Manager can accept requests from both end entities and Registration
Managers. For example, end entities at the home office might deal directly with the
Certificate Manager, while end entities at a branch office might deal with their own
Registration Manager. Alternatively, the Certificate Manager might be configured
to accept requests only from Registration Managers, thus shielding the CA from
end entities.
As stated earlier, a single CMS instance cannot contain both a Certificate Manager
and a Registration Manager. A Certificate Manager that needs to interact with end
entities other than Registration Managers provides all Registration Manager
capabilities itself.
A Registration Manager can be installed in one CMS instance and its related
Certificate Manager in another CMS instance. The separate instances can be located
in the same server group, in different server groups on the same machine, or on
different machines.
Figure 4-2 shows a Registration Manager and its Certificate Manager in separate
instances on separate machines. All communication between the Certificate
Manager and the Registration Manager takes place over HTTPS.
168
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Topology Decisions
Figure 4-2
Certificate Manager and Registration Manager in different instances
Publishing directory
CEP
LDAP or
LDAPS
CRMF
Certificates
and CRLs
CMMF
End
entities
KEYGEN tag
HTTPS
PKCS #7
PKCS #10
Registration
Manager
Certificate
Manager
HTTP/
HTTPS
In many organizations, it may be desirable to deploy multiple Registration
Managers that all communicate with a single Certificate Manager. Each separate
Registration Manager, for example, might handle all end-entity interactions in a
particular geographic area or within an organizational group.
Decisions about the number of, locations of, and relationships among Certificate
Managers and Registration Managers depend on many factors. These include
firewall considerations, the physical security required for each subsystem, the
physical location of the end entities that the Registration Manager is intended to
serve, and the physical location of the Certificate Manager agent, Registration
Manager agent, and other persons responsible for administering the Certificate
Manager and Registration Manager.
Chapter
4
Planning Your Deployment
169
Topology Decisions
Certificate Manager and Data Recovery
Manager
If an organization requires key archival and recovery capabilities—for example, if
encrypted mail is widely used and the organization risks data loss if it is unable to
recover encryption keys—it can install a Data Recovery Manager. This can be done
without regard for the presence or absence of a separate Registration Manager.
For example, to add key storage and recovery to the scenario sketched in Figure
4-2, a Data Recovery Manager can be installed either in the same CMS instance in
which the Certificate Manager is installed or in a different CMS instance (which
can be located in the same server group on the same machine, in a different server
group on the same machine, or on a different machine.)
Figure 4-3 shows a Data Recovery Manager in a separate CMS instance. In this case
all communication between the Certificate Manager and the Data Recovery
Manager takes place over HTTPS. If the Data Recovery Manager and the Certificate
Manager are part of the same CMS instance, all communication takes place
internally and the two subsystems do not require separate host names or
additional configurations.
170
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Topology Decisions
Figure 4-3
Certificate Manager and Data Recovery Manager in different instances
Publishing
directory
CEP
LDAP or
LDAPS
CRMF
CMMF
End
entities
Certificates
and CRLs
KEYGEN tag
HTTPS
PKCS #7
PKCS #10
Data
Recovery
Manager
Certificate
Manager
HTTP/
HTTPS
The Data Recovery Manager is intended for archival and recovery of private
encryption keys only. Therefore end entities must be using either a browser that
supports dual-key generation or a browser that is using Netscape Personal Security
Manager, which supports dual keys.
The decision to keep the Data Recovery Manager in the same instance as the
Certificate Manager or in a different instance (most likely on a different machine)
depends on many factors. These include firewall considerations, the physical
security required for each subsystem, and the physical location of the Certificate
Manager agent, Data Recovery Manager agent, and other persons responsible for
administering the Certificate Manager and recovering keys.
Chapter
4
Planning Your Deployment
171
Topology Decisions
Like a Certificate Manager, a Data Recovery Manager has special physical security
requirements, since a compromised Data Recovery Manager would have
devastating security consequences for your entire PKI. You may therefore want to
keep the Data Recovery Manager in a special locked room or building, a choice that
can affect your deployment strategy.
Certificate Manager, Data Recovery Manager,
and Registration Manager
The three CMS subsystems can be deployed in many different relationships. Figure
4-4 illustrates some of the issues involved in deploying all three subsystems by
showing the relationships among a single Certificate Manager, a single
Registration Manager, and a single Data Recovery Manager, each installed in a
different CMS instance on a different machine.
The Registration Manager handles all end-entity interactions and communicates
with the Certificate Manager and the Data Recovery Manager over HTTPS. The
Registration Manager is configured to request the end entity’s private encryption
key (in encrypted form) and send it to the Data Recovery Manager during the
enrollment process. Before the Registration Manager sends the certificate request to
the Certificate Manager for processing, the Registration Manager must receive
verification from the Data Recovery Manager that the private key has been
received and stored and that it corresponds to the end entity’s public key.
Only the Certificate Manager can be configured to enable or disable LDAP
publishing or to publish to separate directories. The Certificate Manager also has
the complete record of issued certificates, so that it can perform the publishing
tasks, as shown in the figure.
Many other combinations are possible. For example, the Data Recovery Manager
and the Certificate Manager might be in the same instance; there might be multiple
Registration Managers in different instances, all dealing with the same Data
Recovery Manager and Certificate Manager; or the Certificate Manager might also
handle some end-entity interactions. It’s also possible to set up both Certificate
Managers and Registration Managers such that each has a hierarchy of subordinate
managers.
172
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Topology Decisions
Figure 4-4
Certificate Manager, Registration Manager, and Data Recovery Manager in
separate instances
Publishing directory
CEP
LDAP or
LDAPS
CRMF
Certificates
and CRLs
CMMF
End
entities
KEYGEN tag
HTTPS
PKCS #7
PKCS #10
Registration
Manager
Certificate
Manager
HTTP/
HTTPS
HTTPS
Data
Recovery
Manager
NOTE
The current design of Certificate Management System assumes that
most deployments will rely on a single Data Recovery Manager
(associated with either a Registration Manager or a Certificate
Manager). However, it is also possible to write custom policies that
support multiple Data Recovery Managers. This might be useful,
for example, for subordinate CAs that issue certificates for
completely independent organizations.
Chapter
4
Planning Your Deployment
173
Topology Decisions
You can choose to install either a Certificate Manager and Data Recovery Manager
or a Registration Manager and Data Recovery Manager in a single instance. There
is not need to install a Certificate Manager and Registration Manager in the same
instance; instead, a single Certificate Manager can be configured to perform all
Registration Manager functions.
When subsystems are installed in the same instance, the connections between them
are internal. Both subsystems must share the same host name, and the overall
number of SSL server certificates can be reduced (see “Subsystem Certificate
Decisions” on page 182).
Cloned Certificate Manager
A cloned Certificate Manager is a CMS server instance that uses the same CA
signing key and certificate as another Certificate Manager, identified as the master
Certificate Manager. Each Certificate Manager issues certificates with serial
numbers in a restricted range so that all of the servers together act as a single
Certificate Authority (operating in several server processes).
Cloning requires somewhat more management and administrative effort and it
creates more potential areas where the CA could become compromised, so it
should only be used when absolutely necessary.
The advantage of cloning is the ability to distribute the Certificate Manager’s load
across several processes or even several physical machines. For a CA that has high
enrollment demand, the distribution gained from cloning allows more certificates
to be signed and issued in a given time interval.
To create a cloned Certificate Manager, you must first install and configure at least
one Certificate Manager and specify a definite upper, but no lower bound for the
serial numbers it will use. You then install or create a new instance of a Certificate
Manager (but do not configure it). Before configuring the clone, you copy the
certificate and key database files from the original Certificate Manager to the new
Certificate Manager’s configuration
(<server_root>cert-<instance_id>/config) directory. If these databases are
present, the Configuration Wizard will recognize that you are creating a clone and
confirm that you want to reuse the CA’s signing key and certificate (if the clone is
on the same server, you can also reuse the SSL server certificate).
If you store the CA key material on a hardware token, you will have to follow the
hardware vendor’s instructions for copying the key material to a hardware device
accessible to the clone.
174
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Certificate Authority Decisions
A cloned Certificate Manager will have all the same features, agent gateway
functions, and end entity gateway functions that a normal Certificate Manager has.
You can then configure Registration Managers that point to different Certificate
Manager servers but that appear to be serviced by the same CA.
Certificate Authority Decisions
This section covers some of the critical decisions you need to make about your
certificate authority:
•
CA’s Distinguished Name
•
CA Signing Key Type and Length
•
CA Signing Certificate’s Validity Period
•
Self-Signed Root Versus Subordinate CA
•
CAs and Certificate Extensions
•
CA Certificate Renewal or Reissuance
CA’s Distinguished Name
The core elements of a CA consist of a signing unit and the Certificate Manager’s
own identity. The signing unit digitally signs certificates requested by end entities
that use a specified enrollment process to establish their identities. Regardless of
how related Registration Managers or Data Recovery Managers are configured,
any Certificate Manager must have its own distinguished name (DN), which is
listed in every certificate it issues.
Like any other X.509 version 3 certificate, a CA certificate binds a DN to a public
key. A DN is a series of name-value pairs that in combination uniquely identify an
entity. For example, the following DN might be used to identify a hypothetical
Certificate Manager for the Engineering department of a corporation named Siroe
Corp: cn=demoCA, o=Siroe Corp., ou=Engineering, c=US
Many combinations of name-value pairs are possible for the Certificate Manager’s
DN. The DN must be unique and readily identifiable, since any end entity can
examine it. For more information about DNs, see Managing Servers with Netscape
Console.
Chapter
4
Planning Your Deployment
175
Certificate Authority Decisions
CA Signing Key Type and Length
If you wish, you can import the signing key and certificate used in a previous
version of CMS installation rather than generating a new signing key pair. For
information on how to do this, see “Upgrading From a Previous CMS Installation”
on page 312.
If you decide to generate a new signing key, one of the first decisions you need to
make is whether to use the RSA or DSA algorithm. If you use DSA, the software
can generate and verify the PQG value. PQG values are used to create the DSA
signing key pair. For more information about the way they are used, check this
document: http://www.itl.nist.gov/div897/pubs/fip186.htm.
In general, longer keys are considered to be cryptographically stronger than
shorter keys. However, longer keys also require more time for signing operations.
(Certificate Manager CA signing keys up to 4096 bits in length are not subject to
export restrictions.)
Many people no longer consider an RSA key length of 512 bits to be
cryptographically strong. Export and other regulations permitting, it may be a
good rule of thumb to start with 1024 bits and consider increasing the length to
2048 bits for certificates that provide access to highly sensitive data or services.
However, the question of key length has no simple answers. Every organization
must make its own decision based on its own security requirements. For more
information on key length and encryption strength, see Appendix D of Managing
Servers with Netscape Console.
CA Signing Certificate’s Validity Period
Every certificate, including a Certificate Manager signing certificate, must have a
validity period. Certificate Management System does not restrict the validity
period you can specify. In general it’s a good idea to specify as long a validity
period as possible, depending on your plans for certificate renewal, the place of the
CA in the certificate hierarchy, and the requirements of any public CAs that you
may want to include in your PKI.
Self-Signed Root Versus Subordinate CA
For the purposes of an initial pilot, it is easiest to make the CA a self-signed root, so
that you won’t need to apply to a third party and wait for the certificate to be
issued. Before deploying a full-blown PKI, however, you will need to consider this
question carefully.
176
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Certificate Authority Decisions
If you want your CA to chain up to a third-party public CA, you must carefully
consider the restrictions that public CAs place on the kinds of certificates your CA
can issue and the nature of the certificate chain. For example, a CA that chains up
to a third-party CA might be restricted to issuing only Secure Multipurpose
Internet Mail Extensions (S/MIME) and SSL client authentication certificates—not
SSL server certificates. In addition, a CA that chains up to a third-party CA might
not be allowed to have any subordinate CAs and might have to obey certain
restrictions on its use of certificate extensions. These and other restrictions may be
acceptable for some PKI deployments but not for others.
One benefit of chaining up to a public CA is that the third party is responsible for
getting the root CA certificate into the browser or other end-entity software. This
can be a major advantage if you are deploying an extranet that involves certificates
used by different companies whose browsers you cannot control. Alternatively, if
you create your own CA hierarchy from scratch, you are responsible for getting
your root certificate into all the browsers used with the certificates you issue. If you
are using Netscape Communicator as your client, you can accomplish this task
within an intranet by using tools such as Mission Control Desktop or with the aid
of Personal Security Manager, but extranet deployments can be more complicated.
CAs and Certificate Extensions
An X.509 v3 certificate contains an extensions field that permits any number of
additional fields to be added to the certificate. Certificate extensions provide a way
of adding information such as alternative subject names, policy information, and
usage restrictions to certificates. The X.509 v3 standard defines a number of
extensions for various purposes. Certificate Management System provides policy
modules that you can use to set many of the standard extensions in the certificates
the server issues.
Before the X.509 v3 standard was finalized, Netscape and other companies had to
address certain issues, such as usage restrictions, with their own extension
definitions. Therefore, to maintain compatibility with older versions of browsers
that were released before the X.509 v3 specification was finalized, certain kinds of
certificates should include some of the Netscape extensions. Certificate
Management System provides policy modules that you can use to implement
essential Netscape extensions.
Chapter
4
Planning Your Deployment
177
Certificate Authority Decisions
The Internet Engineering Task Force (IETF), which controls many of the standards
that underlie the Internet, is currently developing public-key infrastructure X.509
(PKIX) standards. These proposed standards further refine the X.509 v3 approach
to extensions for use on the Internet. PKIX working group recommendations
should also be taken into account when planning extensions for CA certificates,
subordinate CA certificates, and end-entity certificates.
For more detailed information about extensions and recommendations for specific
types of certificates, see Appendix C, “Certificate and CRL Extensions” of CMS
Plug-ins Guide.
CA Certificate Renewal or Reissuance
When a CA signing certificate expires, all certificates signed with the CA’s
corresponding signing key become invalid. End entities use information in the CA
certificate to verify the certificate’s authenticity. If the CA certificate itself has
expired, applications cannot chain the certificate to a trusted CA.
There are two ways of dealing with CA certificate expiration:
•
Renewing a CA certificate involves issuing a new CA certificate with the same
subject name and public and private key material as the old CA certificate, but
with an extended validity period. As long as the new CA certificate is
distributed to all users well before the old CA certificate expires, this approach
allows certificates issued under the old CA certificate to continue working for
the full duration of their validity periods. However, because of potential
conflicts between the old CA certificate and the new CA certificate, this
approach requires special care with early versions of Communicator 4.x.
•
Reissuing a CA certificate involves issuing a new CA certificate with a new
name, public and private key material, and validity period. This approach
avoids some of the problems associated with renewing a CA certificate, but it
requires more work for both administrators and users to implement. All
certificates issued by the old CA, including those that have not yet expired,
must be renewed by the new CA.
There are advantages and disadvantages to each approach. Correct use of
extensions, for example the authorityKeyIdentifier extension, can also affect
the transition from an old CA certificate to a new one. You should begin planning
for CA renewal or reissuance before you install any CMS managers; consider any
ramifications your planned procedures may have for extensions, policies, and
other aspects of your initial PKI deployment.
178
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Cryptographic Token Decisions
For a discussion of CA certificate expiration issues in the context of Certificate
Server 1.x, see
http://help.netscape.com/products/server/certificate/cacertdoc/.
Many of the same issues apply to Certificate Management System.
For detailed information on certificate extensions, see Appendix C, “Certificate and
CRL Extensions” of CMS Plug-ins Guide.
Cryptographic Token Decisions
As explained in “PKCS #11” on page 75, one or more PKCS #11 modules must be
available to any CMS instance. A PKCS #11 module, which can be implemented in
either software or hardware, manages cryptographic services such as encryption
and decryption. Netscape provides a built-in PKCS #11 module with Certificate
Management System; see “Installing External Tokens” on page 455.
A PKCS #11 module always has one or more slots, which can be implemented as
physical hardware slots in some form of physical reader (for example, for smart
cards) or as conceptual slots in software. Each slot for a PKCS #11 module can in
turn contain a token, which is the hardware or software device that actually
provides cryptographic services and optionally stores certificates and keys.
As shown in Figure 1-10 on page 74, the built-in PKCS #11 module for Certificate
Management System includes two tokens, one for cryptographic operations and
one for manipulating the key and certificate databases. You can accelerate
cryptographic operations such as the signing of new certificates by using
third-party hardware tokens and accelerator boards. Certificate Management
System support for PKCS #11 also allows you to store critical keys, such as the root
CA signing key, on smart cards or other hardware tokens to facilitate strong
physical security measures.
Hardware products compatible with Certificate Management System are available
from nCipherTM (http://www.ncipher.com) and Chrysalis-ITSTM
(http://www.chrysalis-its.com).
If you decide to test or deploy hardware acceleration and storage devices, consult
the vendor’s installation instructions.
Publishing Decisions
A Certificate Manager can publish certificates to an LDAP directory and to files,
and CRLs to an LDAP directory, files, and the Online Certificate Status Manager.
Chapter
4
Planning Your Deployment
179
Publishing Decisions
Publishing to Certificates and CRLs to Files
Any Certificate Manager that publishes certificates or CRLs to files need to specify
the location for storing these files. There will be a file for each certificate and CRL,
so the specified location must have sufficient disk space for storing these files. For
detailed information on publishing certificates and CRLs to files, see Chapter 20,
“Publishing Certificates and CRLs to a File.”
Publishing to Certificates and CRLs to a
Directory
Any Certificate Manager that publishes certificates or CRLs to a directory must
specify the host name and port number for the directory and indicate whether
communication should take place over SSL. The Certificate Manager must also
specify how it should identify itself to the directory—by using password-based
authentication or SSL client authentication. Finally, the directory itself must be
configured (typically by the directory administrator) to authenticate the Certificate
Manager in the specified manner.
Note that it’s not possible to configure the Registration Manager to publish
certificates or CRLs. The Certificate Manager has the complete record of issued
certificates and that the publishing tasks be performed by the Certificate Manager
only. If it’s necessary for some entries in a directory to be available outside the
firewall, Netscape recommends using the partial replication feature of Directory
Server to replicate the relevant portion of the directory to which the Certificate
Manager publishes.
This guide assumes that you have already deployed an LDAP-compliant directory
server (LDAP 2.0 or higher) for your enterprise; it does not cover directory
planning and configuration. For information on Netscape Directory Server
deployment, see the documentation that comes with that product.
Configuration of the publishing or corporate directory should take place before
you install any Certificate Management System subsystems. Configuration details
that the directory administrator may need to take care of include the following:
•
180
If the authentication mechanism uses a DN (identifying the directory subtree in
which the subsystem can publish certificates) and password, the directory
administrator needs to set up a corresponding access control list (ACL).
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Publishing Decisions
•
If authentication is based on SSL client authentication, the directory
administrator needs to create an entry in the directory’s certmap.conf file.
The certmap.conf entry maps the DN in the subsystem’s client certificate to a
directory entry that specifies write permission to the appropriate portion of the
directory tree.
•
If you intend to publish certificates to the directory, the directory administrator
needs to have an entry for each user to whom you intend to issue a certificate,
and the directory schema must include a location to which the certificate
should be published. If you want to publish the CA certificate or CRL, you will
also need an entry for the CA.
If you intend to use SSL authentication, both the directory and the Certificate
Manager must be configured appropriately for SSL. For detailed information on
LDAP publishing, see Chapter 19, “Setting Up LDAP Publishing.”
Publishing CRLs to the Online Certificate Status
Manager
Certificate Management System supports the Online Certificate Status Protocol
(OCSP) as defined in the PKIX standard RFC 2560 (see
http://www.ietf.org/rfc/rfc2560.txt). The OCSP protocol enables
OCSP-compliant applications to determine the state of a certificate, including the
revocation status, without having to directly check a CRL published by a CA to the
validation authority. The validation authority, which is also called an OCSP
responder, does the checking for the application. For more information, see “What’s
an OCSP-Compliant PKI Setup?” on page 694.
To aid you in the process of setting up a OCSP-compliant PKI setup, Certificate
Management System provides two options:
•
Use the OCSP-service feature built into the Certificate Manager
•
Use the CMS OCSP responder, named Online Certificate Status Manager
Read section “How to Get an OCSP Responder?” on page 696 to decide which
method is suitable for your PKI setup.
Chapter
4
Planning Your Deployment
181
Subsystem Certificate Decisions
Subsystem Certificate Decisions
Using a self-signed signing certificate for the Certificate Manager simplifies the
deployment of an initial pilot. You can install the Certificate Manager without
having to apply to a public certificate authority and waiting for it to issue, sign, and
return your CA signing certificate. Your own Certificate Manager can then issue all
the other certificates required for your pilot. However, taking this approach means
that end entities outside your organization will not recognize your Certificate
Manager unless you distribute the root Certificate Manager certificate to them.
The certificates and keys you need for each subsystem depend in part on whether
the subsystems are in the same or different CMS instances. Subsystems installed
together in the same instance use internal connectors to communicate and therefore
don’t need separate SSL certificates to authenticate each other.
When two CMS subsystems are installed in a single instance, they normally share a
single SSL server certificate. If one or more subsystems are installed in a separate
instance from the other subsystems, each instance requires a separate SSL server
certificate.
In addition to any SSL server certificates, the Certificate Manager, Registration
Manager, and Online Certificate Status Manager each requires its own signing
certificate, and the Data Recovery Manager needs its own transport certificate and
storage key.
For more information about the key pairs and certificates used by the CMS
managers, see “Keys and Certificates for the Main Subsystems” on page 440.
SSL Server Certificates
Each CMS instance requires a single SSL server certificate. If you install two
managers in the same instance—that is, a Certificate Manager or Registration
Manager and a Data Recovery Manager—both managers share the same SSL server
certificate.
Certificate Manager Certificates
Every Certificate Manager must have a CA signing certificate whose public key
corresponds to the private key the Certificate Manager uses to sign the certificates
it issues. This certificate is also used for SSL client authentication to the publishing
directory (LDAP over SSL) if the Certificate Manager is set up to publish
certificates or CRLs.
182
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Subsystem Certificate Decisions
If the Certificate Manager is acting as a root CA, the CA certificate must be installed
and trusted by each client that needs to validate certificates issued by the root
Certificate Manager. In the context of a PKI, trust refers to the relationship between
the user of a certificate and the CA that issued the certificate. If you trust a CA, you
can generally trust valid certificates issued by that CA. It’s possible to control
which CAs the client or server software trusts and which it doesn't, and for what
kinds of certificates, by means of settings within the software.
The Certificate Manager also requires an SSL server certificate. The Certificate
Manager’s SSL server certificate (or certificates) can be unique to the Certificate
Manager or, if a Data Recovery Manager is installed in the same instance, shared
with it.
In addition to these certificates, the Certificate Manager also generates a few other
certificates transparently during installation. For details, see “Certificate Manager’s
Key Pairs and Certificates” on page 441.
Registration Manager Certificates
Every Registration Manager subsystem must have a signing certificate whose
public key corresponds to the private key the Registration Manager uses to sign
end-entity certificate requests before sending them to the Certificate Manager.
Signed requests give the Certificate Manager persistent proof that a particular
Registration Manager processed the request. If the Registration Manager is set up
to publish certificates or CRLs, its signing certificate is also used for SSL client
authentication to the publishing directory (LDAP over SSL).
The Registration Manager also requires at least one SSL server certificate. The
Registration Manager’s SSL server certificate (or certificates) can be unique to the
Registration Manager or, if a Data Recovery Manager is installed in the same
instance, shared with it.
For more information about the key pairs and certificates used by a Registration
Manager, see “Registration Manager’s Key Pairs and Certificates” on page 449.
Chapter
4
Planning Your Deployment
183
Subsystem Certificate Decisions
Data Recovery Manager Certificate and Storage
Key
The Data Recovery Manager needs a transport certificate and a storage key:
•
The Data Recovery Manager transport certificate has a public key used by
end-entity software to encrypt the private encryption key belonging to an end
entity so that it can be sent (via the Registration Manager) to the Data Recovery
Manager. The public key also corresponds to the private key used by the Data
Recovery Manager to sign the proof-of-archival token it sends to the
Registration Manager after storing an end entity’s encryption key.
•
The Data Recovery Manager storage key is used by the Data Recovery
Manager to encrypt the end entity’s encryption key (after it has been decrypted
with the Data Recovery Manager’s private transport key) before the Data
Recovery Manager stores the encryption key in the local directory. Data
encrypted with the storage key can be retrieved only if m of n “split keys” are
provided at the same time by m of n authorized agents.
The Data Recovery Manager also requires at least one SSL server certificate. The
Data Recovery Manager’s SSL server certificate (or certificates) can be unique to the
Data Recovery Manager or, if another subsystem are located in the same instance,
shared with that subsystem.
NOTE
If you want to use hardware tokens for generating and storing Data
Recovery Manager’s key pairs, you’ll need at least two tokens: one
exclusively for the storage key pair and the other for the remaining
key pairs. Be sure to install (and initialize, if required) these tokens
before you start the Data Recovery Manager installation.
For more information about the key pairs and certificates used by a Data Recovery
Manager, see “Data Recovery Manager’s Key Pairs and Certificates” on page 450.
Online Certificate Status Manager Certificates
Every Online Certificate Status Manager must have a signing certificate whose
public key corresponds to the private key the Online Certificate Status Manager
uses to sign OCSP responses before sending them to OCSP-compliant clients. The
Online Certificate Status Manager’s signature provides persistent proof to an
OCSP-compliant client that the Online Certificate Status Manager has processed
the request.
184
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Authentication Decisions
The Online Certificate Status Manager also requires at least one SSL server
certificate. For more information about the key pairs and certificates used by a
Online Certificate Status Manager, see “Online Certificate Status Manager’s Key
Pairs and Certificates” on page 453.
Authentication Decisions
CMS managers use authentication modules to verify the identity of a user
requesting a service, such as certificate enrollment. For example, a user can be
prompted to provide a name and password, and the authentication module can
check a directory entry to confirm that they are correct.
Authentication is one of the essential functions of Certificate Management System.
The main purpose of a certificate is to provide a trustworthy association between
the public key of the subject and the subject’s name and other attributes. Therefore
the manner in which administrators, agents, and end entities are authenticated,
especially for operations related to certificate enrollment, requires careful planning
and control throughout the lifetime of a PKI deployment.
For examples of some different approaches to authentication during certificate
enrollment, see Chapter 2, “Certificate Enrollment and Life-Cycle Management.”
For a detailed overview of authentication management using Certificate
Management System, see Chapter 15, “Setting Up End-User Authentication.”
Policy Decisions
CMS managers use policies to evaluate or verify incoming certificate enrollment or
management requests from end entities and to determine the outcome. For
example, in the case of certificate enrollment request, the outcome is the issued
certificate.
Decisions regarding policies depend on both the subsystem involved and your
overall topology. Whether your CA signing certificate is self-signed or not, it
represents part of a certificate hierarchy. For example, a CA may be a root CA for
subordinate CAs that issue certificates to different parts of a large organization, or
it may be one of the subordinate CAs that chain up to an internal root CA, or it may
be a linked CA that chains up to a third party.
Chapter
4
Planning Your Deployment
185
Deployment Strategy and Port Assignments
Policies configured for a Certificate Manager apply to all certificates issued by that
Certificate Manager or its subordinates. Policies configured for a Registration
Manager subsystem are local to the Registration Manager. This distinction can be
used to model the levels of authority within an organization. Enrollment can be
fully automated by means of custom policy and authentication subsystems at the
Registration Manager level.
Thus, a policy for a Certificate Manager might be that all subject names have to end
with o=Siroe Corp. Registration Managers for individual departments can enforce
this policy and can also define their own, local naming policies, such as
ou=Engineering.
Another variation is to have the Certificate Manager enforce the companywide
policies and have subordinate Certificate Managers, instead of Registration
Managers, enforce the names for individual departments. Each subordinate
Certificate Manager, in turn, can delegate enrollment responsibilities to multiple
Registration Managers, which can be configured to apply the policies uniformly in
different geographic locations.
For a detailed discussion of policy management, see Chapter 18, “Setting Up
Policies.”
Deployment Strategy and Port Assignments
Before you install any CMS instance, you should review the decisions described in
this chapter and work out the relationships between the Certificate Managers, Data
Recovery Managers, Registration Managers, and Online Certificate Status
Managers you want to deploy for your organization. Once you have decided which
subsystems to install and where, fill out a copy of the worksheet provided in
Chapter 5, “Installation Worksheet” for each separate installation.
You can create multiple instances of Certificate Management System in a single
server root directory, each containing either one or two CMS managers. If you
want to install CMS managers on different hosts, you must run the entire
installation on each host, specifying the services for each instance of Certificate
Management System. You can also perform additional complete installations on
the same host in a different server root directory.
Figure 4-5 shows an example of how several CMS instances can be installed on a
single host machine. (Note that on Windows NT, you can install a single server
root only; multiple server roots are not permitted.)
186
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Deployment Strategy and Port Assignments
Figure 4-5
Host
Deploying servers on a single host
Server root
directory
Server instances
Certificate
Management
System managers
Data Recovery
Manager
Admin Server
Configuration
directory
Certificate
Manager
CMS 1
Server root 1
CMS 1 internal db
directory
Registration
Manager
Machine 1
Registration
Manager
CMS 2
CMS 2 internal db
directory
Server root 2
Admin Server
Configuration
directory
Registration
Manager
CMS 1
CMS 1 internal db
directory
Server root N
Chapter
4
Planning Your Deployment
187
Deployment Strategy and Port Assignments
Each server root directory shown in Figure 4-5 has its own Administration Server
and Netscape Console and access to a configuration directory. Each CMS instance
has a corresponding instance of Directory Server that functions as the internal
database for that CMS instance. Each server root directory can have one or more
instances of Certificate Management System, each with its own set of one or two
subsystems and its own corresponding internal database.
Figure 3-1 on page 111 illustrates the ports used by a single CMS instance. You can
also install multiple instances on a single machine, either in the same server root or
as completely separate installations in separate server roots.
When you install additional CMS instances on a machine with a single IP address,
you are required to specify a different set of ports for each CMS instance to listen
on. That is, each CMS instance will require at least four unique ports:
•
Internal database port for communication with internal database
•
SSL administration port for communication with Netscape Console
•
SSL agent port for communication with designated agents
•
At least one of these ports:
❍
SSL user port for communication with end entities
❍
Non-SSL user port for communication with end entities
The ports shown above are required for each CMS instance. Each server root needs
two additional unique ports: one for the Directory Server being used as the
configuration directory and one for the Administration Server.
When you install additional CMS instances on a machine that has been set up with
more than one IP address, you can configure each instance to listen to a specific IP
address. If each instance has a different IP address, you can use the same port
numbers for additional CMS instances installed on the same machine—that is, you
can use one set of four or five ports for all the instances.
For more information about installing multiple CMS instances, see Chapter 7,
“Installing and Uninstalling CMS Instances.”
188
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Chapter
5
Installation Worksheet
This chapter provides a worksheet to help you prepare for installing a single
instance of iPlanet Certificate Management System (CMS). Print this chapter and
make as many copies as you need. Fill out one copy for each CMS instance you
plan to install and refer to it during the installation and configuration process. You
should fill it in after you have read Chapter 4, “Planning Your Deployment” It is
designed for easy reference while you are following the procedures described in
Chapter 6, “Installing Certificate Management System.”
CAUTION
Each completed worksheet contains sensitive information, such as
passwords, that could severely compromise the security of your
entire PKI if it falls into the wrong hands. Be sure to keep completed
worksheets physically protected.
This chapter has the following sections:
•
Information for UNIX Installation Script (page 190)
•
Information for NT Installation Script (page 193)
•
Initial Configuration (page 196)
•
Certificate Manager Configuration (page 199)
•
Registration Manager Configuration (page 203)
•
Data Recovery Manager Configuration (page 205)
•
Online Certificate Status Manager Configuration (page 209)
•
Cloned Certificate Manager Configuration (page 211)
•
SSL Server Certificate Configuration (page 213)
•
Single Sign-On Password (page 216)
189
Information for UNIX Installation Script
Information for UNIX Installation Script
The information summarized here must be provided once for each server root
installation on a UNIX system.
Installation Location
To install an instance of Certificate Management System, you must also install an
Administration Server and Netscape Console application and have access to a
configuration and user/group directory. For more information on the Netscape
server environment, see Managing Servers with Netscape Console.
•
Installation directory (Server root directory)_______________________________
Enter the full pathname for the existing server root directory or for a new
server root directory. For example, /usr/netscape/server4.
•
Computer name_____________________________________________
The default should be the fully qualified host name of the machine on which
the installation is taking place. For example, mydirectory.siroe.com. Do not
attempt to install remotely.
Configuration Directory Server
•
System user ID ________________________________
Enter the user ID that Directory Server will run as. The configuration directory
server process runs as this user. You should run the server as a user with
restricted access to other system files and resources. Where your system
supports it, accept the default user nobody, creating that user as necessary.
•
System group __________________________________________
Enter a group to which the System User ID belongs. The group should also
have limited access to system resources and files. Where your system supports
it, accept the default user nobody, creating that group as necessary.
Do you want to register this software with an existing Netscape configuration
directory server?
•
Yes or No._______________
If you choose No, the Installation Wizard will create a new instance of
Directory Server for use as the configuration directory for this server root.
190
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Information for UNIX Installation Script
If you choose Yes, you must also supply the following information about the
existing configuration directory:
•
Computer name_____________________________________________
The default should be the fully qualified host name of the machine on which
the configuration directory is located. For example, mydirectory.siroe.com.
User/Group Directory Server
Do you want to use another directory to store your data?
•
Yes or No._______________
If you choose No, the installation script either adds a user/group directory to the
newly installed instance of Directory Server (if you answered no to the preceding
question) or installs a new instance of Directory Server for use as a user/group
directory.
If you choose Yes, you must also supply the following information:
•
User directory host name___________________________________________
•
User directory port_____________________________________________
•
Bind as_____________________________________________
•
User directory server suffix_____________________________________________
•
User directory administrator ID_____________________________________
Configuration Directory Settings
You need to provide the following information about the configuration directory,
whether it is an existing one or a new one to be created by the Installation Wizard:
•
Directory Server network port ________________________
Enter the port number for the Directory Server instance. The default is 389, if it
is available, or a randomly selected number. The port number you specify
must not be used for any other purpose.
•
Directory Server identifier______________________________________
This unique identifier is required for each instance of a Directory Server. For
example, configdir.
Chapter
5
Installation Worksheet
191
Information for UNIX Installation Script
•
Configuration Directory Server Administrator ID________________________
The ID for the user who will authenticate to Netscape Console with full
privileges. For example, diradmin1.
•
Configuration Directory Server Administrator Password___________________
The password must be at least eight characters long.
•
Suffix ____________________________________
Enter the domain name of the current host. For example, o=siroe.com.
•
Directory Manager DN ________________________
Enter the distinguished name (DN) of the directory manager for the
configuration directory.
This DN can be short and does not need to conform to any suffix configured for
your directory. It also should not correspond to an actual entry stored in your
directory. For example, cn=Directory Manager.
•
Directory Manager password ________________________
The password must be at least eight characters long.
•
Administration domain ________________________________________
This domain name identifies the collection of servers that use the same
configuration directory. For example, siroe.com
Administration Server Information
•
Administration Port___________________________________________
The default Administration Port is randomly generated. Pick a port number
between 1024 and 65535 on which to run your Administration Server, or accept
the default number.
•
Run Administration Server as _____________________________
Run the Administration Server as root if you want to be able to start and stop
services and use port numbers below 1024 (for example to use port 80 for the
HTTP end entity gateway).
192
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Information for NT Installation Script
Certificate Management System Identifier
You must specify a unique identifier for the CMS server instance that you are
installing.
•
Certificate Management System server identifier___________________________
Enter a unique identifier. For the name, you can use any combination of letters
(aA to zZ), digits (0 to 9), an underscore (_), and a hyphen (-); other characters
and spaces are not allowed. For example, you can type pilotCA , pilot_CA, or
pilot-CA as the instance name, but not pilot CA.
Information for NT Installation Script
The information summarized here must be provided once for each server root
installation.
Installation Directory
To install an instance of Certificate Management System, you must also install an
Administration Server and Netscape Console application and have access to a
configuration and user/group directory. For more information on the Netscape
server environment, see Managing Servers with Netscape Console.
•
Installation directory (Server root directory)_______________________________
The default installation directory is C:\Netscape\Server4. If you want to use
a different directory, enter the full pathname for the existing server root
directory or for a new server root directory.
You cannot install more than one server root directory on a Windows NT
system.
Configuration Directory Server
Choose one of these options:
•
This instance will be the configuration directory server._____________________
If you choose the above option, the Installation Wizard will create a new
instance of Directory Server for use as the configuration directory for this
server root.
Chapter
5
Installation Worksheet
193
Information for NT Installation Script
•
Use existing configuration directory server._______________________________
If you choose to use an existing configuration directory, you must supply the
following information:
❍
Host name___________________________________________
❍
Port________________________________________________
❍
Bind as______________________________________________
❍
Password____________________________________________
User/Group Directory Server
Choose one of these options:
•
Store data in this directory server._______________________________________
If you choose this option, the installation script either adds a user/group
directory to the newly installed instance of Directory Server (if you have
already decided to install a new configuration directory) or installs a new
instance of Directory Server for use as a user/group directory.
•
Store data in an existing directory server._________________________________
If you choose to use an existing directory, you must supply the following
information:
194
❍
Host name_____________________________________________
❍
Port__________________________________________________
❍
Bind as________________________________________________
❍
Password______________________________________________
❍
Suffix_________________________________________________
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Information for NT Installation Script
Configuration Directory Settings
You need to provide the following information about the configuration directory,
whether it is an existing one or a new one to be created by the Installation Wizard:
•
Directory Server identifier_______________________________________
This unique identifier is required for each instance of a Directory Server. For
example, configdir.
•
Directory Server network port (default is 389)________________________
Enter the port number for the Directory Server instance. The default is 389, if it
is available, or a randomly selected number. The port number you specify
must not be used for any other purpose.
•
Suffix ____________________________________
If you are creating a new directory, this should be the domain name of the
current host. For example, o=siroe.com.
Configuration Directory Server Administrator
•
Configuration Directory Server Administrator ID________________________
For example, diradmin1.
•
Configuration Directory Server Administrator Password___________________
The password must be at least eight characters long.
Directory Server Administration Domain
•
Administration domain ________________________________________
This domain name identifies the collection of servers that use the same
configuration directory. For example, siroe.com.
Directory Manager Settings
•
Directory manager DN ________________________
Enter the distinguished name (DN) of the directory manager for the
configuration directory.
Chapter
5
Installation Worksheet
195
Initial Configuration
This DN can be short and does not need to conform to any suffix configured for
your directory. It also should not correspond to an actual entry stored in your
directory. For example, cn=Directory Manager.
•
Directory Manager password ________________________
The password must be at least eight characters in length.
Administration Server Port
•
Administration Port___________________________________________
Pick a port number between 1024 and 65535 on which to run your
Administration Server, or accept the default number.
Certificate Management System Identifier
You must specify a unique identifier for the CMS server instance that you are
installing.
•
Certificate Management System server identifier___________________________
Enter a unique identifier. For the name, you can use any combination of letters
(aA to zZ), digits (0 to 9), an underscore (_), and a hyphen (-); other characters
and spaces are not allowed. For example, you can type cmsdemo, cms_demo, or
cms-demo as the instance name, but not cms demo.
Initial Configuration
For each instance of Certificate Management System that you create, you use the
Installation Wizard to supply information about that instance’s configuration. The
information described in this section is required for each CMS instance, regardless
of which subsystems you decide to install.
196
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Initial Configuration
Internal Database
For each instance of Certificate Management System, a new instance of Netscape
Directory Server is created on the local host to act as the internal (local) database.
Each subsystem must have access to this local database to store certificates,
certificate requests, keys, and other information. Certificate Management System
uses LDAP to communicate with its local database.
•
Certificate Management System internal database instance ID_______________
The default provided by the system is the CMS server identifier with the suffix
-db; for example, cmsdemo-db.
•
Port number_______________
The default is 38900, but you may choose any value less than 65535. On UNIX,
you must choose a port greater than 1024 if you are not logged in as root.
•
Directory Manager DN ____________________________________________
The default is CN=Directory Manager. You can enter something more
meaningful, such as CN=Internal Directory Manager.
•
Internal database password_______________________________
Administrator
Specify the CMS administrator. This person will be able to access the CMS window
of Netscape Console and approve the first agent certificate.
•
CMS Administrator ID_____________________________________________
For example, CMSadmin.
•
CMS Administrator full name________________________________
For example, Certificate Management System Administrator.
•
CMS Administrator password________________________________
Subsystems
Choose the subsystems you will install in this instance. You can choose to install
any individual manager, Certificate Manager and Data Recovery Manager
together, or Registration Manager and Data Recovery Manager together. Other
combinations are not allowed, for example, you cannot install a Certificate
Chapter
5
Installation Worksheet
197
Initial Configuration
Manager and Registration Manager together or Certificate Manager and Online
Certificate Status Manager together. The Certificate Manager can be configured to
perform all Registration Manager functions, so it’s not necessary or possible to
install both managers in the same instance.
In addition to x.509 certificates, the Certificate Manager can also issue Wireless
Transport Layer Security (wTLS)-compliant certificates for wireless applications. If
you want this feature, you must choose the appropriate option. If you enable
issuance of wTLS certificates, the Certificate Manager generates a wTLS CA
signing certificate and installs the approriate HTML interfaces for users to request
certificates for wireless applications.
•
Certificate Manager___________________________________
Enable issuance of wTLS certificates? _____________________
•
Registration Manager__________________________________
•
Data Recovery Manager________________________________
•
Online Certificate Status Manager_________________________
Remote Certificate Manager
If you are installing a Registration Manager, you need to provide the following
information about the Certificate Manager to which the Registration Manager
sends certificate requests:
•
Host name for remote Certificate Manager_____________________________
•
SSL agent port for remote Certificate Manager__________________________
Remote Data Recovery Manager
If you are installing a standalone Certificate Manager or Registration Manager, and
if you have already installed a remote Data Recovery Manager that you want the
new manager to use, you need to provide the following information about the Data
Recovery Manager:
198
•
Host name for remote Data Recovery Manager_________________________
•
SSL agent port for remote Data Recovery Manager______________________
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Certificate Manager Configuration
Network Configuration
Enter numbers for the ports to be used for various kinds of communications. On
UNIX, you must be root to assign ports less than 1024. The default values are
well-known ports, which are used only if they are not already in use. If these
defaults are not available, a randomly chosen port number is given as the default.
For a discussion of port assignments, see “Deployment Strategy and Port
Assignments” on page 186.
•
SSL administration port (HTTPS) (default is 8200)___________
•
SSL agent port (HTTPS) (default is 8100)__________________
•
SSL end-entity port (HTTPS) (default 443)_________________
•
Non-SSL end-entity port (HTTP) (default 80)_______________
Certificate Manager Configuration
This section summarizes information required to configure a Certificate Manager
as a root or subordinate CA (either by itself or as part of a joint installation with a
Data Recovery Manager).
CA Signing Certificate
When you install the Certificate Manager, you must supply information for the CA
certificate that the Certificate Manager will use to sign the certificates it issues. This
certificate also functions as the Certificate Manager’s SSL client certificate.
CA’s Serial Number Range
For most CAs, you only need to enter the starting serial number. When you
configure cloned CAs, you must specify upper and lower bounds for the serial
numbers on all CAs and you must make sure the ranges do not overlap.
•
CA’s starting serial number _____________________
Enter the lowest serial number available for this CA to assign to certificates it
creates. You can enter the number in decimal or hexadecimal (0xnn). The
default is 0x1.
Chapter
5
Installation Worksheet
199
Certificate Manager Configuration
•
CA’s ending serial number __________________________
Enter the highest serial number available for this CA. You can enter the
number in decimal or hexadecimal (0xnn). The default is no upper limit
(blank).
Key-Pair Information for CA Signing Certificate
For a discussion of related issues, see “CA Signing Key Type and Length” on
page 176.
•
Token for storing the Certificate Manager CA signing certificate and private
key____________________________________
Enter either internal (if you plan to use the internal/software token) or the
name of an external token. If you are using an external token, you will need to
install it before you run the Installation Wizard. In the wizard, you can select
from a list of already installed and available tokens. For example, SmartCard.
For installation instructions, see “Installing External Tokens” on page 455.
•
Token password_________________________________________________
The password for the token must be at least eight character long.
•
Key type_________________________________________________
RSA or DSA.
•
Key length_______________________________________________
Available key sizes for RSA are 512, 1024, 2048, 4096, or custom. Available key
sizes for DSA are 512, 1024, or custom (must be in increments of 64 bit).
In general, longer keys are considered to be cryptographically stronger than
shorter keys. However, longer keys also require more time for signing
operations.
•
Message Digest Algortihm (select one): SHA1___ MD2___ MD5_____
Select the message digest algorithm to use for generating digital signatures on
certificates.
Subject Name for CA Signing Certificate
For a discussion of issues related to the subject name, see “CA’s Distinguished
Name” on page 175.
You may fill in the attribute template or simply enter the DN as a string of
attribute-value pairs.
200
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Certificate Manager Configuration
•
Common Name (CN=) _____________________________________
•
Organizational Unit (OU=) ___________________________________
•
Organization (O=) ________________________________________
•
Locality (L=) _____________________________________________
•
State (ST=) ______________________________________________
•
Country (C=) ____________________________________________
A DN is a series of name-value pairs that in combination uniquely identify an
entity. The subject DN identifies the CA signing certificate. You are not
required to enter all the values, but must enter the Organization (O), such as
the name of your company. The Organization is required because its absence
causes Netscape Communicator (version 4.6 or below) to crash. For more
information about distinguished names, see Apendix A, “Distinguished
Names,” in CMS Plug-ins Guide. To locate this guide, see “Where to Go for
Related Information” on page 28.
Validity Period for CA Signing Certificate
You can specify the validity period for a self-signed CA signing certificate only.
The validity period for a subordinate CA signing certificate is determined by the
issuing CA.
•
Validity period_________________________ to __________________________
Enter beginning and ending dates for the certificate’s validity period. The
validity period for the CA signing certificate determines how soon you will
have to renew the certificate, which can be a complex procedure. The default
validity period is two years.
Extensions for CA Signing Certificate
You can specify the extensions for a self-signed CA signing certificate only.
Extensions for a subordinate CA signing certificate are specified by the issuing CA.
The default settings should work for most deployments. If necessary, you can add
and additional/custom extension by pasting its base-64 encoding in the space
provided on this screen. For more information about extensions, see Appendix C,
“Certificate and CRL Extensions” of CMS Plug-ins Guide.
Confirm that you want to include the following extensions. Check off all that
apply; defaults are indicated in parentheses.
•
Basic constraints (Yes)_____________
Chapter
5
Installation Worksheet
201
Certificate Manager Configuration
❍
CA (Yes)_________
❍
Certification path length (Null)_______________________
The certificate chain path length, if specified, determines the maximum
number of certificates in a chain, starting with the end-entity certificate. If you
do not specify this attribute, the length of the chain is unlimited.
•
Netscape certificate type (Yes)_____________
❍
SSL client (No)_________
❍
Object-signing (No)_________
❍
SSL server (No)_________
❍
S/MIME CA (Yes)_________
❍
S/MIME (No)_________
❍
Object-signing CA (Yes)_________
❍
SSL CA (Yes)_________
•
Authority Key Identifier (Yes) ________________
•
Subject Key Identifier (Yes) ________________
•
Key usage (No)_____________
If you decide to include the key usage extension, the following key usage bits
are set by default:
•
❍
digitalSignature
❍
keyCertSign
❍
CRLSign
Additional Extension (No)___________________________
To add extensions not included by default by Certificate Management System,
you will need to paste the base-64 encoding of a sequence of extensions into the
wizard.
CA Signing Certificate Request
If you are installing a subordinate CA, you need to specify where to send your
request for a CA signing certificate.
202
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Registration Manager Configuration
If you are submitting your certificate request to a third-party CA, follow the
instructions provided by that CA.
If you are submitting your certificate request to another Certificate Manager, you
need to know its URL:
•
End-entity URL for issuing Certificate Manager___________________________
Enter the URL for the end-entity gateway of the Certificate Manager that will
issue the subordinate CA’s signing certificate. For example,
https://hostname:443/.
Registration Manager Configuration
This section summarizes information required to configure a Registration Manager
(either by itself or as part of a joint installation with a Data Recovery Manager).
Registration Manager Signing Certificate
Request
When you install a Registration Manager, you must supply information for the
certificate that the Registration Manager will use to sign certificate requests. This
certificate also functions as the Registration Manager’s SSL client certificate. The
Installation Wizard formulates a certificate request on the basis of information you
provide. It is possible for the CA that issues the certificate to overrule some of your
decisions.
Key-Pair Information for Registration Manager Signing Certificate
•
Token for storing the Registration Manager signing certificate and private
key____________________________________
Enter either internal (if you plan to use the internal token) or the name of an
external token. If you are using an external token, you will need to install it
before you run the Installation Wizard. In the wizard, you can select from a list
of already installed and available tokens. For example, SmartCard. For
installation instructions, see “Installing External Tokens” on page 455.
•
Token password_________________________________________________
The password for the token must be at least one character long.
Chapter
5
Installation Worksheet
203
Registration Manager Configuration
•
Key type_________________________________________________
RSA or DSA.
•
Key length_______________________________________________
Available key sizes for RSA are 512, 1024, 2048, 4096, or custom. Available key
sizes for DSA are 512, 1024, or custom (in increments of 64 bits only).
In general, longer keys are considered to be cryptographically stronger than
shorter keys. However, longer keys also require more time for signing
operations.
•
Message Digest Algortihm (select one): SHA1___ MD2___ MD5___
Select the message digest algorithm to use for generating digital signatures on
certificates.
Subject Name for Registration Manager Signing Certificate
•
Common Name (CN=) _____________________________________
•
Organizational Unit (OU=) ___________________________________
•
Organization (O=) ________________________________________
•
Locality (L=) _____________________________________________
•
State (ST=) ______________________________________________
•
Country (C=) ____________________________________________
A DN is a series of name-value pairs that in combination uniquely identify an
entity. The subject DN identifies the Registration Manager signing certificate.
You are not required to enter all the values, but must enter the Organization
(O), such as your company name. The Organization is required because its
absence causes Netscape Communicator (version 4.6 or below) to crash. For
more information about distinguished names, see Apendix A, “Distinguished
Names,” in CMS Plug-ins Guide.
Registration Manager Signing Certificate Issuer
If you are submitting your certificate request to a third-party CA, follow the
instructions provided by that CA.
204
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Data Recovery Manager Configuration
If you are submitting your certificate request to another Certificate Manager, you
need to know its URL:
•
End-entity URL for issuing a Certificate Manager__________________________
Enter the URL for the end-entity gateway of the Certificate Manager that will issue
the Registration Manager’s signing certificate. For example,
http://hostname:17006.
Data Recovery Manager Configuration
This section summarizes information required to configure a Data Recovery
Manager (either by itself or as part of a joint installation with a Certificate Manager
or Registration Manager).
NOTE
If you want to use hardware tokens for generating and storing Data
Recovery Manager’s key pairs, you’ll need at least two tokens: one
exclusively for the storage key pair and the other for the remaining
key pairs. Be sure to install (and initialize, if required) these tokens
before you start the Data Recovery Manager installation.
Transport Certificate
Key-Pair Information for Transport Certificate
For a discussion of issues related to key type and length, see “CA Signing Key Type
and Length” on page 176.
•
Token for storing the transport certificate signing certificate and private
key________________________________________
Enter either internal (if you plan to use the internal token) or the name of an
external token. If you are using an external token, you will need to install it
before you run the Installation Wizard. In the wizard, you can select from a list
of already installed and available tokens. For example, SmartCard. For
installation instructions, see “Installing External Tokens” on page 455.
•
Token password_________________________________________________
The password for the token must be at least one character long.
Chapter
5
Installation Worksheet
205
Data Recovery Manager Configuration
•
Key type_________________________________________________
RSA or DSA.
•
Key length_______________________________________________
Available key sizes for RSA are 512, 1024, 2048, 4096, or custom. Available key
sizes for DSA are 512, 1024, or custom (in increments of 64 bits only).
In general, longer keys are considered to be cryptographically stronger than
shorter keys. However, longer keys also require more time for signing
operations.
•
Message Digest Algortihm (select one): SHA1___ MD2___ MD5___
Select the message digest algorithm to use for generating digital signatures on
certificates.
Subject Name for Transport Certificate
•
Common Name (CN=) _____________________________________
•
Organizational Unit (OU=) ___________________________________
•
Organization (O=) ________________________________________
•
Locality (L=) _____________________________________________
•
State (ST=) ______________________________________________
•
Country (C=) ____________________________________________
A DN is a series of name-value pairs that in combination uniquely identify an
entity. The subject DN identifies the transport certificate. You are not required
to enter all the values, but must enter the Organization (O), such as your
company name. The Organization is required because its absence causes
Netscape Communicator (version 4.6 or below) to crash. For more information
about distinguished names, see Apendix A, “Distinguished Names,” in CMS
Plug-ins Guide.
Validity Period for Transport Certificate
You can specify the validity period for a transport certificate only if you are
installing the Certificate Manager and Data Recovery Manager at the same time
and you want the Certificate Manager that you just installed issue the transport
certificate. If the transport certificate is issued by a remote CA, its validity period is
determined by the issuing CA.
206
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Data Recovery Manager Configuration
•
Validity period______________________ to _______________________
Enter beginning and ending dates for the transport certificate’s validity period.
Extensions for Transport Certificate
You can specify the extensions for a transport certificate only if you are installing
the Certificate Manager and Data Recovery Manager at the same time and you
have decided to have the Certificate Manager that you just installed issue the
certificate. If the transport certificate is issued by a remote CA, its extensions are
determined by the issuing CA.
The default settings should work for most deployments. If necessary, you can add
an additional extension by pasting its base-64 encoding in the space provided on
this screen. For more information about extensions, see Appendix C, “Certificate
and CRL Extensions” of CMS Plug-ins Guide.
Confirm that you want to include the following extensions. Check off all that
apply; defaults are indicated in parentheses.
•
Basic constraints (No)_____________
❍
CA (No)_________
❍
Certification path length (No)_______________________
The certificate chain path length, if specified, determines the maximum
number of certificates in a chain, starting with the end-entity certificate. If you
do not specify this attribute, the length of the chain is unlimited.
•
Netscape certificate type ((No)_____________
❍
SSL client (No)_________
❍
Object-signing (No)_________
❍
SSL server (No)_________
❍
S/MIME CA ((No)_________
❍
S?MIME (No)_________
❍
Object-signing CA ((No)_________
❍
SSL CA ((No)_________
•
Authority Key Identifier (Yes) ________________
•
Subject Key Identifier (No)
Chapter
5
Installation Worksheet
207
Data Recovery Manager Configuration
•
Key usage (No)_____________
If you decide to include the key usage extension, the keyEncipherment key
usage bit is set by default.
•
Additional Extension (No)___________________________
To add extensions not included by default by Certificate Management System,
you will need to paste the base64 encoding of a sequence of extensions into the
wizard.
Transport Certificate Request
If you are obtaining your transport certificate from a remote CA, you need to know
where to submit your certificate request.
If you are submitting your transport certificate request to a third-party CA, follow
the instructions provided by that CA.
If you are submitting your certificate request to a Certificate Manager, you need to
know its URL:
•
End-entity URL for issuing Certificate Manager___________________________
Enter the URL for the end-entity gateway of the Certificate Manager that will
issue the transport certificate. For example, http://hostname:17006.
Storage Key and Recovery Agent Configuration
Storage Key Creation
Specify the length of the key that the Data Recovery Manager uses to encrypt
end-entity encryption keys for storage.
•
Storage key length___________________
The options available are 512, 1024, 2048, or 4096.
Data Recovery Scheme—1
The number of agents you enter here is determined by your organization’s policies
with respect to data recovery. If you enter a larger number than the default of 2 for
the number of recovery agents required to recover a key, you’re reducing the
chances of inappropriate recovery but increasing the complexity of the recovery
process.
208
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Online Certificate Status Manager Configuration
Decide how you want to set up your m of n data recovery scheme (n > m):
•
Number of recovery agents
required to recover a key (m, default 2)
_______________________________________
•
Total number of designated
recovery agents (n, default 3)_______________________________________
Data Recovery Scheme—2
Specify user IDs and passwords for the total number of designated recovery agents
(see preceding section):
•
User ID______________________ Password_________________________
•
User ID______________________ Password_________________________
•
User ID______________________ Password_________________________
•
User ID______________________ Password_________________________
•
User ID______________________ Password_________________________
•
User ID______________________ Password_________________________
•
User ID______________________ Password_________________________
•
User ID______________________ Password_________________________
Online Certificate Status Manager Configuration
This section summarizes information required to configure a Online Certificate
Status Manager.
Online Certificate Status Manager Signing
Certificate Request
When you install a Online Certificate Status Manager, you must supply
information for the certificate that the Online Certificate Status Manager will use to
sign OCSP responses. The Installation Wizard formulates a certificate request on
the basis of information you provide. It is possible for the CA that issues the
certificate to overrule some of your decisions.
Chapter
5
Installation Worksheet
209
Online Certificate Status Manager Configuration
Key-Pair Information for Online Certificate Status Manager Signing
Certificate
•
Token for storing the Online Certificate Status Manager signing certificate and
private key____________________________________
Enter either internal (if you plan to use the internal token) or the name of an
external token. If you are using an external token, you will need to install it
before you run the Installation Wizard. In the wizard, you can select from a list
of already installed and available tokens. For example, SmartCard. For
installation instructions, see “Installing External Tokens” on page 455.
•
Token password_________________________________________________
The password for the token must be at least one character long.
•
Key type_________________________________________________
RSA or DSA.
•
Key length_______________________________________________
Available key sizes for RSA are 512, 1024, 2048, 4096, or custom. Available key
sizes for DSA are 512, 1024, or custom (in increments of 64 bits only).
In general, longer keys are considered to be cryptographically stronger than
shorter keys. However, longer keys also require more time for signing
operations.
•
Message Digest Algortihm (select one): SHA1___ MD2___ MD5___
Select the message digest algorithm to use for generating digital signatures on
certificates.
Subject Name for Online Certificate Status Manager Signing
Certificate
210
•
Common Name (CN=) _____________________________________
•
Organizational Unit (OU=) ___________________________________
•
Organization (O=) ________________________________________
•
Locality (L=) _____________________________________________
•
State (ST=) ______________________________________________
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Cloned Certificate Manager Configuration
•
Country (C=) ____________________________________________
A DN is a series of name-value pairs that in combination uniquely identify an
entity. The subject DN identifies the Online Certificate Status Manager signing
certificate. For more information about distinguished names, see Apendix A,
“Distinguished Names,” in CMS Plug-ins Guide.
Online Certificate Status Manager Signing
Certificate Issuer
If you are submitting your certificate request to a third-party CA, follow the
instructions provided by that CA.
If you are submitting your certificate request to another Certificate Manager, you
need to know its URL:
•
End-entity URL for issuing a Certificate Manager__________________________
Enter the URL for the end-entity gateway of the Certificate Manager that will issue
the Online Certificate Status Manager’s signing certificate. For example,
http://hostname:17006.
Cloned Certificate Manager Configuration
This section summarizes information required to configure a clone of a Certificate
Manager. You must have installed the original Certificate Manager and installed or
created a new CMS instance. You must copy the key3.db and cert7.db files from
the config directory of the original server to the config directory of the cloned
server. If you use a hardware token for key and certificate storage, you must copy
any key or certificate data from the original token to a new token accessible to the
cloned Certificate Manager.
You can clone a Certificate Manager instance to have two server processes
perfoming the same CA functions using the same keys and certificates. Each cloned
Certificate Manager, including the original, must only issue certificates with serial
numbers that do not conflict with the serial numbers issued by other clones. Use
the CA serial number range to make sure that the serial numbers used by a clone
do not overlap with the serial number range of another clone (or the original
server).
Chapter
5
Installation Worksheet
211
Cloned Certificate Manager Configuration
If the cloned Certificate Manager has the same hostname as the original server, the
clone can use the same SSL server certificate. The SSL server certificate DN contains
the hostname as the common name (CN) attribute, so a clone with a different
hostname must enroll for a new SSL server certificate.
CA Signing Certificate
When you install the Certificate Manager, you must supply information for the CA
certificate that the Certificate Manager will use to sign the certificates it issues. This
certificate can also function as the Certificate Manager’s SSL client certificate. If the
clone uses a different hostname than the original CA, you will need to generate a
new SSL server certificate.
CA’s Serial Number Range
For most CAs, you only need to enter the starting serial number. When you
configure cloned CAs, you must specify upper and lower bounds for the serial
numbers on all CAs and you must make sure the ranges do not overlap.
•
CA’s starting serial number __________________
Enter the lowest serial number available for this CA to assign to certificates it
creates. You can enter the number in decimal or hexadecimal (0xnn). The
default is 0x1.
•
CA’s ending serial number ____________________
Enter the highest serial number available for this CA. You can enter the
number in decimal or hexadecimal (0xnn). The default is no upper limit
(blank).
Cloned Key and Certificate Material
If you do not use the copied key and certificate databases, the Certificate Manager
will need to generate a new signing key and certificate; consequently, it will not be
a clone.
•
Use existing key and certificate? ___________________
Answer yes, otherwise you are creating a new Certificate Manager and not a
clone.
212
•
Instance name of the original server ____________________________
•
Token name where copied keys are stored _______________________
iPlanet Certificate Management System Installation and Setup Guide • March 2001
SSL Server Certificate Configuration
•
Token password ___________________________________________
SSL Server Key and Certificate
If the clone uses the same hostname, you can use the same SSL server certificate
and key copied from the original server. Otherwise, answer no and continue with
the next section, “SSL Server Certificate Configuration.”
•
Use existing SSL server key and certificate? Yes____ No______
•
Instance name of the original server ____________________________
•
Token name where copied keys are stored _______________________
•
Token password ___________________________________________
SSL Server Certificate Configuration
When you install an instance of iPlanet Certificate Management System, you must
supply information for the SSL server certificate used by that instance to identify
itself. The same SSL certificate is shared by all subsystems installed in that instance.
SSL Server Certificate
Key-Pair Information for SSL Server Certificate
•
Token for storing the SSL server certificate and private key__________________
Enter either internal (if you plan to use the internal token) or the name of an
external token. If you are using an external token, you will need to install it
before you run the Installation Wizard. In the wizard, you can select from a list
of already installed and available tokens. For example, SmartCard. For
installation instructions, see “Installing External Tokens” on page 455.
•
Token password_________________________________________________
The password for the token must be at least one character long.
•
Key type_________________________________________________
RSA or DSA.
Chapter
5
Installation Worksheet
213
SSL Server Certificate Configuration
•
Key length_______________________________________________
For domestic versions of iPlanet Certificate Management System, available
settings for RSA are 512, 1024, 2048, 4096, or custom, and available settings for
DSA are 512, 1024, or custom (in increments of 64 bits only).
•
Message Digest Algortihm (select one): SHA1___ MD2___ MD5___
Select the message digest algorithm to use for generating digital signatures on
certificates.
Subject Name for SSL Server Certificate
•
Common Name (CN=) _____________________________________
•
Organizational Unit (OU=) ___________________________________
•
Organization (O=) ________________________________________
•
Locality (L=) _____________________________________________
•
State (ST=) ______________________________________________
•
Country (C=) ____________________________________________
A DN is a series of name-value pairs that in combination uniquely identify an
entity. The subject DN identifies the CA signing certificate. You are not
required to enter all the values, but must enter the Organization (O), such as
your company name. The Organization is required because its absence causes
Netscape Communicator (version 4.6 or below) to crash. For more information
about distinguished names, see Apendix A, “Distinguished Names,” in CMS
Plug-ins Guide.
Validity Period for SSL Server Certificate
You can specify the validity period for an SSL server certificate only if you are
installing a Certificate Manager and you have decided to have that the Certificate
Manager issue the certificate. If the SSL server certificate is issued by a remote CA,
its validity period is determined by the issuing CA.
•
Validity period___________________ to __________________________
Enter beginning and ending dates for the certificate’s validity period.
214
iPlanet Certificate Management System Installation and Setup Guide • March 2001
SSL Server Certificate Configuration
Extensions for SSL Server Certificate
You can specify the extensions for an SSL server certificate only if you are installing
a Certificate Manager and you have decided to have that local Certificate Manager
issue the certificate. If the SSL server certificate is issued by a remote CA, its
extensions are determined by the issuing CA.
The default settings should work for most deployments. If necessary, you can add
an additional extension by pasting its base-64 encoding in the space provided on
this screen. For more information about extensions, see Appendix C, “Certificate
and CRL Extensions” of CMS Plug-ins Guide.
Confirm that you want to include the following extensions. Check off all that
apply; defaults are indicated in parentheses.
•
Basic constraints (No)_____________
❍
CA (Nos)_________
❍
Certification path length (No)_______________________
The certificate chain path length, if specified, determines the maximum
number of certificates in a chain, starting with the end-entity certificate. If you
do not specify this attribute, the length of the chain is unlimited.
•
Netscape certificate type (Yes)_____________
❍
SSL client (Yes)_________
❍
Object-signing (No)_________
❍
SSL server (Yes)_________
❍
S/MIME CA (No)_________
❍
S?MIME (No)_________
❍
Object-signing CA (No)_________
❍
SSL CA (No)_________
•
Authority Key Identifier (Yes) ________________
•
Subject Key Identifier (No)
•
Key usage (No)_____________
If you decide to include the key usage extension, the following key usage bits
are set by default:
❍
digitalSignature
Chapter
5
Installation Worksheet
215
Single Sign-On Password
❍
•
keyEncipherment
Additional Extension (No)___________________________
To add extensions not included by default by Certificate Management System,
you will need to paste the base64 encoding of a sequence of extensions into the
wizard.
SSL Certificate Request
If you are obtaining your SSL server certificate from another CA, you need to know
where to submit your certificate request.
If you are submitting your certificate request to a third-party CA, follow the
instructions provided by that CA.
If you are submitting your certificate request to another Certificate Manager, you
need to know its URL.
•
End-entity URL for issuing Certificate Manager___________________________
Enter the URL for the end-entity gateway of the Certificate Manager that will
issue the SSL server certificate. For example, http://hostname:17006.
Single Sign-On Password
Before you exit the Installation Wizard, it asks you to specify a single signon
password. This password simplifies the way you subsequently sign on to iPlanet
Certificate Management System by storing the passwords for the internal database
and tokens. Each time you log on, you’re required to enter just this single
password.
•
216
Single signon password__________________________________________
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Chapter
6
Installing Certificate Management
System
This chapter describes the procedure for installing a iPlanet Certificate
Management System (CMS) instance. Before you use this chapter to guide you
through an installation, you should have read Chapter 1 through Chapter 5 and
filled out the worksheet provided by Chapter 5, “Installation Worksheet.”
This chapter contains the following sections:
•
Installation Overview (page 218)
•
Stage 1. Running the Installation Script (page 221)
•
Stage 2. Running the Installation Wizard (page 227)
•
Stage 3. Enrolling for Administrator/Agent Certificate (page 277)
•
Stage 4. Further Configuration Options (page 283)
•
Stage 5. Creating Additional Instances or CA Clones (page 284)
NOTE
For upgrading Certificate Management System from a previous
version, see “Upgrading From a Previous CMS Installation” on
page 312.
Installation Overview
Before you begin installation, make sure your system meets the requirements listed
in the Release Notes for the product version at:
http://docs.iplanet.com/docs/manuals/cms.html
217
Installation Overview
The installation process installs the Netscape Administration Server, Netscape
Console, and Netscape Directory Server, as well as Certificate Management
System. You typically create two instances of Directory Server: the first is for the
configuration directory used by the local Administration Server; the second is used
by Certificate Management System itself for its internal database.
You must have an Administration Server in each server root directory.
Administration Server can use a local configuration directory or refer to an existing
configuration directory installed elsewhere. You must install the Certificate
Management System internal database directory locally.
The initial installation script installs Netscape Console and the binaries for the
servers, and it creates and starts instances of Administration Server and Directory
Server. After running the initial script, you use the Installation Wizard to create
and configure instances of Certificate Management System. The wizard helps you
through the configuration process of choosing subsystems and creating the
necessary keys and certificates.
Installation Stages
Installing Certificate Management System in a single server root directory involves
four stages:
218
•
Stage 1: Run the installation script (setup on UNIX, setup.exe on NT) to
install Administration Server and Directory Server as necessary and perform
the initial phase of CMS installation. These procedures are described in “Stage
1. Running the Installation Script” on page 221.
•
Stage 2: Run the Installation Wizard to set up the initial configuration of the
CMS instance. In this stage you specify which subsystems are to be part of this
instance and generate the SSL client and server certificates for each subsystem.
These procedures are described in “Stage 2. Running the Installation Wizard”
on page 227.
•
Stage 3: Use Netscape Console to further configure the new Certificate
Management System instance, as needed. See “Stage 4. Further Configuration
Options” on page 283.
•
Stage 4 (optional): Use Netscape Console to create additional instances of the
Certificate Management System in the same server root directory, and use the
Installation Wizard to configure them. For a summary, see “Stage 5. Creating
Additional Instances or CA Clones” on page 284.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Installation Overview
Before You Begin the Installation
Before you start installing Certificate Management System, follow these
instructions:
•
If you’re not familiar with Certificate Management System, you might find it
useful to run a demo installation first; see Chapter 3, “Default Demo
Installation.”
•
If you want to install the Certificate Manager as a root CA:
❍
❍
•
❍
❍
❍
Read and fill in the information requested in the Certificate Manager
installation worksheet; see “Certificate Manager Configuration” on
page 199.
Identify the CA to which you’ll submit the subordinate CA’s CA signing
certificate and SSL server certificate requests. Make sure the CA is running
and, if required, identify the forms you’ll use to submit these requests.
If the CA is a third-party CA, familiarize with the enrollment interface of
that CA and check how long does the CA take to send you the certificates.
Decide whether you want to create clones of the CA. If you do, determine
the serial number ranges for each CA.
If you want to install a standalone Registration Manager, do this:
❍
❍
•
Decide whether you want to create clones of the CA. If you do, determine
the serial number ranges for each CA.
If you want to install the Certificate Manager as a subordinate CA:
❍
•
Read and fill in the information requested in the Certificate Manager
installation worksheet; see “Certificate Manager Configuration” on
page 199.
Read and fill in the information requested in the Registration Manager
installation worksheet; see “Registration Manager Configuration” on
page 203.
Identify the CA to which you’ll submit the Registration Manager’s signing
certificate and SSL server certificate requests. Make sure the CA is running
and, if required, identify the forms you’ll use to submit these requests.
If you want to install a standalone Data Recovery Manager:
❍
Read and fill in the information requested in the Data Recovery Manager
installation worksheet; see “Data Recovery Manager Configuration” on
page 205.
Chapter
6
Installing Certificate Management System
219
Installation Overview
❍
❍
•
Identify the CA to which you’ll submit the Data Recovery Manager’s
transport certificate and SSL server certificate requests. Make sure the CA is
running and, if required, identify the forms you’ll use to submit these
requests.
If you plan to use hardware tokens for generating and storing Data
Recovery Manager’s key pairs, you’ll need at least two tokens: one
exclusively for the storage key pair and the other for the remaining key
pairs. Be sure to install (and initialize, if required) these tokens before you
start the Data Recovery Manager installation. For installation instructions,
see “Installing External Tokens” on page 455.
If you want to install a standalone Online Certificate Status Manager:
❍
❍
Read and fill in the information requested in the Online Certificate Status
Manager installation worksheet; see “Online Certificate Status Manager
Configuration” on page 209.
Identify the CA to which you’ll submit the Online Certificate Status
Manager’s signing certificate and SSL server certificate requests. Make sure
the CA is running and, if required, identify the forms you’ll use to submit
these requests. For Online Certificate Status Manager’s signing certificate
to work properly, it must contain the following extensions:
OCSPNoCheck extension—Presence of this extension indicates that an OCSP
client should not use OCSP to check the revocation status of the OCSP
responder certificate, because the certificate is only used to identify the
responder that does the checking. (This extension is required to avoid a
circular reference.) For details about this extension, see section
“OCSPNoCheckExt Plug-in Module” of CMS Plug-ins Guide.
OCSPSigning extension—This is an Extended Key Usage extension with a
unique value, OCSPSigning. Presence of this extension indicates that the
key pair that corresponds to the certificate used by the OCSP responder
can be used for signing OCSP responses. For details about this extension,
see section “OCSPSigningExt Rule” of CMS Plug-ins Guide.
Make sure the Certificate Manager to which you’ll submit the Online
Certificate Status Manager’s signing certificate request has these policies
enabled.
•
220
If you want to install two subsystems in a CMS instance, for example, a
Certificate Manager along with a Data Recovery Manager, collect the
information for both the subsystems.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 1. Running the Installation Script
Stage 1. Running the Installation Script
The setup program extracts files for the Administration Server, Directory Server,
Netscape Console, and Certificate Management System and installs the binaries
under the server root directory you have specified. It creates one instance of the
Administration Server, one instance of the Directory Server, and one instance of the
Certificate Management System, which is not yet configured. The setup program
also installs Netscape Console and automatically starts the Administration Server
and Directory Server.
As you run the initial installation script, the program stores your configuration
choices and generates a initialization file, or installation cache. As installation
proceeds, the stored initialization file states information about your choices so far.
As a result, you can stop the installation process and restart it as necessary. Your
choices to the point at which you stopped the installation are automatically
restored by the initialization file, and the installation prompts resume at the point
in which you left off.
This initialization file applies only to the installation of the Administration Server
and Directory Server. If you want to use the file to do additional “silent”
installations, see the documentation for these servers.
Running the Installation Script on UNIX
To run the installation script on UNIX, follow these steps:
1.
Log in as root to install the servers on a UNIX system. This is recommended,
but not required. If you are not root, you can install only a local version in a
directory to which you have write access, using ports higher than 1024, for
which you are the administrator for all services.
2.
Change to the directory on the distribution CD, and run the setup program.
3.
Answer the questions that the script asks. You should have previously
collected the requested information in the section “Information for UNIX
Installation Script” of Chapter 5, “Installation Worksheet.” Most questions
have a default answer shown in square brackets before the prompt. To accept
the default answer, press Enter at the prompt.
Answer the questions for a typical installation as follows:
1.
Would you like to continue with setup? [Yes]: Press Enter.
2.
Do you agree to the license terms? [No]: Type yes and press Enter.
Chapter
6
Installing Certificate Management System
221
Stage 1. Running the Installation Script
3.
Select the items you would like to install [1]: Accept the default to install the
Netscape servers.
4.
Install location [/usr/netscape/server4]: Enter a full pathname to the location
where you want to install the servers. The location that you enter must be
different from the directory from which you are running the setup program.
You must have write access to the directory. If the directory that you specify
does not exist, the setup program creates it for you.
5.
Specify the components you wish to install [All]: Accept the default value,
All, to accept the default server product components.
6.
Specify the components you wish to install [1,2,3]: Enter the numbers
corresponding to the server product components you wish to install, or press
Enter to accept the default components.
7.
Specify the components you wish to install [1,2]: Enter the numbers
corresponding to the Directory Suite components you wish to install, or press
Enter to accept the default components.
8.
Specify the components you wish to install [1,2]: Enter the numbers
corresponding to the Administration Services components you wish to install,
or press Enter to accept the default components.
9.
Specify the components you wish to install [1,2]: Enter the numbers
corresponding to the CMS components you wish to install, or press Enter to
accept the default components.
10. Computer name [myhost.mydomain.com]: Accept the default value to install
on the local machine. Do not attempt to install remotely.
11. System User [nobody]: Enter the user ID that configuration directory will run
as. Where your system supports it, accept the default user nobody, creating that
user as necessary.
12. System Group [nobody]: Enter the group that the configuration directory will
run as. Where your system supports it, accept the default group, nobody,
creating that group as necessary.
13. Do you want to register this software with an existing Netscape
configuration directory server? [No]: If you accept the default setting, the
installation script installs a new instance of Directory Server for use as a
configuration directory.
You can also choose to use a previously installed configuration directory. In
this case, select “Use existing configuration directory server,” then fill in the
values that identify and provide access to the previously installed directory.
222
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 1. Running the Installation Script
14. Do you want to use another directory to store your data? [No]: If you accept
the default setting, the installation script either adds a user/group directory to
the newly installed instance of Directory Server (if you accepted the default in
step 13) or installs a new instance of Directory Server for use as a user/group
directory.
You can also choose to use a previously installed user/group directory. In this
case, enter Yes, then fill in the values that identify and provide access to the
previously installed directory.
15. Directory server network port [random #]: Accept the default, which is either
389 or a randomly generated number, or enter any port number that is not and
will not be used for another purpose.
If you are using an existing configuration directory, enter its port number.
16. Directory server identifier [myhost]: Enter a unique identifier for the new
instance of the configuration directory.
If you are using an existing configuration directory, enter its identifier.
17. Netscape configuration directory server administrator ID [admin]: Enter the
name and password of the user who will authenticate to Netscape Console
with full privileges. The password must be at least eight characters long.
If you are using an existing configuration directory, enter its administrator ID
and password.
18. Suffix [o=mydomain.com]: Accept the default value for the suffix, or base DN,
to be used for the directory tree.
19. Directory Manager DN [cn=Directory Manager]: Enter the distinguished
name (DN) and password of the directory manager for the configuration
directory. The password must be at least eight characters long.
This DN can be short and does not need to conform to any suffix configured for
your directory. It also should not correspond to an actual entry stored in your
directory.
20. Administration Domain [mydomain.com]: Accept the default value. This
domain name identifies the collection of servers that use the same
configuration directory.
21. Administration port [random #]: Accept the default port number, which is
randomly generated, or enter any port number that is not and will not be used
for another purpose.
Chapter
6
Installing Certificate Management System
223
Stage 1. Running the Installation Script
22. Run Administration Server as [current login]: Enter the user ID for the
Administration Server process. If you are running as root, you can accept the
default to run the server as root.
23. Certificate Management System identifier [certificate]: Enter a unique
identifier for the new instance of Certificate Management System.
The script extracts and installs the binaries for all of the servers in the server
root directory and creates and starts instances of the Administration Server
and Directory Server.
When you have completed the installation script, you can complete the installation
and configuration of the CMS instance by running the Installation Wizard. See
“Stage 2. Running the Installation Wizard” on page 227.
Running the Installation Script on Windows NT
The setup.exe program extracts files for the Administration Server, Directory
Server, Netscape Console, and Certificate Management System and installs the
binaries under the server root directory you have specified. It creates one instance
of Administration Server, one instance of Directory Server, and one instance of
Certificate Management System, which is as yet unconfigured. The program
installs Netscape Console, and automatically starts the Administration Server and
Directory Server.
To run the installation script, follow these steps:
1.
Double click setup.exe to run the installation program.
2.
The installation dialog boxes prompt you to type in answers or make
selections.
3.
Answer the questions that the script asks. You should have previously
collected the requested information in the section “Information for NT
Installation Script” of Chapter 5, “Installation Worksheet.”
In the instructions that follow, the name that appears in the title bar of each setup
screen is in boldface, followed by a description of the action you should take.
Answer the questions for a typical installation as follows:
224
1.
Welcome. Click Next.
2.
Software License Agreement. If you agree to all the terms of the License
Agreement, click Yes.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 1. Running the Installation Script
3.
Select Server or Console Installation. “Netscape Servers” is selected by
default. Click Next to accept the default selection.
4.
Choose Installation Directory. The default installation directory is
C:\Netscape\Server4. To specify a server root directory different from the
default, click Browse. Enter a full pathname, or navigate to the location where
you want to install the servers, then click OK.
The location that you enter must be different from the directory from which
you are running the setup program. You must have write access to the
directory. If the directory that you specify does not exist, the program can
create it for you.
Click Next to continue.
5.
Select Products. Four components are selected by default:
❍
Netscape Server Products Core Components.
❍
Netscape Directory Suite
❍
Administration Services
❍
Netscape Certificate Management System
You don’t need to select the fifth component, Netscape Directory Server 4.1
Synch Service, unless you want to set up the Directory Server Synchronization
Service. Click Next to accept the default selection.
6.
Directory Server 4.13. “This instance will be the configuration directory
server” is selected by default. If you accept the default setting, the installation
script installs a new instance of Directory Server for use as a configuration
directory.
You can also choose to use a previously installed configuration directory. In
this case, select “Use existing configuration directory server,” then fill in the
values that identify and provide access to the previously installed directory.
Click Next to continue.
7.
Directory Server 4.13. “Store data in this directory server” is selected by
default. If you accept the default setting, the installation script either adds a
user/group directory to the newly installed instance of Directory Server (if you
accepted the default in step 7) or installs a new instance of Directory Server for
use as a user/group directory.
You can also choose to use a previously installed user/group directory. In this
case, select “Store data in an existing directory server,” then fill in the values
that identify and provide access to the previously installed directory. Click
Next to continue.
Chapter
6
Installing Certificate Management System
225
Stage 1. Running the Installation Script
8.
Directory Server 4.13 Server Settings
❍
❍
❍
Server Identifier. Enter a unique identifier for the new instance of the
configuration directory. If you are using an existing configuration
directory, enter its identifier.
Server Port. Accept the default, or enter any port number that is not and
will not be used for another purpose. The default is 389 if that port is not
already used; otherwise, it is a randomly selected port number. If you are
using an existing configuration directory, enter its port number.
Suffix. Accept the default value for the suffix, or base DN, to be used for
the directory tree.
When all three values are correct, click Next.
9.
Directory Server 4.13 Netscape Configuration Directory Server
Administrator. Enter the administrator ID and password of the user who will
authenticate to the directory console with full privileges. (Think of this as the
root or superuser identity for Directory Server.) The password must be at least
one character long. If you are using an existing configuration directory, enter
its administrator ID and password. Click Next to continue.
10. Directory Server 4.13 Administration Domain. Click Next to accept the
default value. This name, which should be your organization’s domain name,
will be used for the collection of servers that use the same configuration
directory.
11. Directory Server 4.13 Directory Manager Settings. Enter the distinguished
name and password of the directory manager for the configuration directory.
The password must be at least eight characters long.
This DN can be short and does not need to conform to any suffix configured for
your directory. It also should not correspond to an actual entry stored in your
directory. Click Next to continue.
12. Administration Server Port Selection. A randomly selected port number will
be shown. Accept the default port number, or enter any port number that is not
and will not be used for another purpose. Click Next to continue.
13. Netscape Certificate Management System Server Identifier. Enter a unique
identifier for the new instance of Certificate Management System. Click Next to
continue.
14. Configuration Summary. This screen shows all of the components you are
installing and the choices you have made for their configuration. Click Next to
continue.
226
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
15. Setup. At this point, the installation script extracts and installs the binaries for
all of the servers in the server root directory, and creates and starts instances of
the Administration Server and Directory Server.
16. Setup Complete. “Restart my computer now” is selected by default. Click
finish to accept the default. After the computer has rebooted, you’ll note that
the Netscape Console window is displayed with its associated icons.
When you have completed the installation script, you can complete the installation
and configuration of the CMS instance by running the Installation Wizard. See
“Stage 2. Running the Installation Wizard” on page 227.
Stage 2. Running the Installation Wizard
After you have finished running the installation script, you use the Installation
Wizard to create and configure an instance of Certificate Management System—
you use the wizard to get the initial certificates and set the initial configuration for
this instance of Certificate Management System. The Installation Wizard is the
same for both UNIX and Windows NT.
In the last step of the installation script, you were given an opportunity to specify
whether to launch Netscape Console. If you chose to launch Netscape Console,
you’ll see Netscape Console open automatically. Otherwise, you need to open it
manually. To bring up Netscape Console and launch the Installation Wizard,
follow these steps:
1.
Start Netscape Console:
On a Windows NT system, click Start, and then choose Programs, Netscape
Server Family, and Netscape Console 4.2, in that order. Alternatively, click the
corresponding shortcut in the Netscape Server Products directory window
displayed after setup completes.
On a UNIX system, open a command shell, change to the directory
/usr/netscape/server4, and execute the file startconsole.
2.
Log in as the administrator. On UNIX systems, you will also need to specify
the Administration Server URL that you specified during the installation
script.
The main window of Netscape Console appears.
3.
In the navigation tree at the left, open your computer, then open Server Group.
4.
Select the CMS instance that you named while running the installation script.
Chapter
6
Installing Certificate Management System
227
Stage 2. Running the Installation Wizard
5.
In the Certificate Management System panel at the right, click Open.
After a few moments, the Introduction screen for the Installation Wizard
appears.
Click Next to continue. The Internal Database screen appears.
6.
In the Internal Database screen, specify the Directory Server instance that
Certificate Management System should use as its internal database—you may
choose to create a new Directory Server instance or use an existing Directory
Server instance. The Directory Server instance you choose will be used as a
database to store information (such as certificates and certificate requests) used
by all the subsystems you will be installing in this CMS instance. It’s
recommended that you do not use this Directory Server instance for any other
purposes; the directory schema will be configured for storing CMS data.
Click Next to continue. The wizard sets up the new internal database, which
takes some time.
(If you have previously installed an internal database for this instance, the
Recreate Internal Database screen appears. In the Recreate Internal Database,
specify whether you want to remove the existing database in order to create a
new internal database, or use the existing internal database.
A special screen, Internal Database password, comes up only if you stop the
configuration process partway through and then start over again, in which
case the wizard needs to ask for the internal database password again.)
7.
In the Administrator screen, type the ID, name and password for the CMS
administrator. This is the administrator who can access the CMS window and
control all CMS settings.
Click Next to continue.
The “Subsystems” screen appears. This screen enables you to choose a
subsystem or the permitted combinations of subsystems you want to install.
Depending on what you want to install, follow the appropriate instructions.
228
❍
Installing the Certificate Manager as a Root CA
❍
Installing the Certificate Manager as a Subordinate CA
❍
Installing a Standalone Registration Manager
❍
Installing a Standalone Data Recovery Manager
❍
Installing a Online Certificate Status Manager
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
Installing the Certificate Manager as a Root CA
To install the Certificate Manager as a root CA:
1.
Subsystems. Select Certificate Manager. If you want the Certificate Manager to
issue certificates for wireless applications, select the “In addition to X.509 v3
certificates, do you want the Certificate Manager to support issuance of
Wireless Transport Layer Support (wTLS)-compliant certificates” option.
Otherwise, leave the option unchecked. (If you select the option, the end-entity
interface will include two forms for requesting certificates for wireless
applications and an option for downloading the wireless CA certificate.)
Click Next to continue.
2.
Remote Data Recovery Manager. Select the appropriate options:
❍
❍
Select No, if you don’t want to connect the Certificate Manager to a remote
Data Recovery Manager.
If you have already installed a remote Data Recovery Manager that you
want the Certificate Manager to use for archiving end users’ encryption
private keys, select Yes. Then, enter the remote Data Recovery Manager’s
host name and agent SSL port number in the associated fields.
Click Next to continue.
3.
Network Configuration. Type the port numbers for the ports to be used by the
CMS instance. If you want to enable the non-SSL end-entity port, be sure to
check the “Enable” checkbox.
Click Next to continue.
4.
CA’s Serial Number Range. Specify range for the serial numbers. In the
“Starting serial number” field, type the lowest serial number the CA should
assign to a certificate. If you plan to only use one CA server, you can leave the
“Ending serial number” field blank to indicate no upper limit. If you plan to
clone the CA to distribute load, you must specify an upper limit. (For cloned
CAs, you must make sure that the range of serial numbers does not overlap
with any other CA server.)
Click Next to continue.
5.
CA Signing Certificate. Select the “Create self-signed CA certificate” option.
Click Next to continue.
Chapter
6
Installing Certificate Management System
229
Stage 2. Running the Installation Wizard
6.
Key-Pair Information for Certificate Manager CA Signing Certificate. Select
the token to store the root CA signing certificate and key pair. If you have not
previously initialized the token’s password, you must do so in this screen. Also
specify the key type and length.
Click Next to continue.
7.
Message Digest Algorithm. Select the algorithm to use for computing the
certificate signature. The choices are: MD2, MD5, or SHA-1.
Click Next to continue.
8.
Subject Name for Certificate Manager CA Signing Certificate. Type values
for the subject DN components; these values identify the root CA signing
certificate.
Click Next to continue.
9.
Validity Period for Certificate Manager CA Signing Certificate. Select the
validity period for the CA signing certificate. The default validity is two years.
The validity period determines how soon you will have to renew the
certificate, which can be a complex procedure.
Click Next to continue.
10. Certificate Extensions for Certificate Manager CA Signing Certificate. Select
the required extensions. The default settings should work for most
deployments. If necessary, you can add an additional extension by pasting its
base-64 encoding in the space provided on this screen.
Certificate Management System provides command-line tools for generating
extensions to include in CA and other certificate requests. For details about
these tools, check this directory: <server_root>/bin/cert/tools
Note that the certificate extension text field accepts a single extension blob. If
you want to add multiple extensions, you should use the ExtJoiner program,
which is also provided in the tools directory. For details on using the
ExtJoiner program, see Chapter 5, “Extension Joiner Tool” of CMS
Command-Line Tools Guide.
Click Next to continue.
11. Certificate Manager CA Signing Certificate Creation. Click Next to generate
and install the certificate.
230
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
12. SSL Server Certificate. Select the “Sign SSL certificate with my CA signing
certificate” option. This option enables the wizard to generate an SSL Server
Certificate signed with the local CA signing certificate, the root Certificate
Manager’s CA signing certificate you just created.
Click Next to continue.
13. Key-Pair Information for SSL Server Certificate. Select the token to store the
SSL server certificate and key pair. If you have not previously initialized the
token’s password, you must do so in this screen. Also specify the key type and
length.
Click Next to continue.
14. Message Digest Algorithm. Select the algorithm to use for computing the
certificate signature. The choices are: SHA-1, MD2, or MD5.
Click Next to continue.
15. Subject Name for SSL Server Certificate. Type the values for the subject DN
components; these values identify the root CA’s SSL server certificate. The CN
must be the fully-qualified host name of the machine on which you’re
installing the Certificate Manager.
Click Next to continue.
16. Validity Period for SSL Server Certificate. Select the validity period for the
SSL server certificate. The validity period determines how soon you will have
to renew the certificate.
Click Next to continue.
17. Certificate Extensions for SSL Server Certificate. Select the required
extensions. The default settings should work for most deployments. If
necessary, you can add an additional extension by pasting its base-64 encoding
in the space provided on this screen (see Step 10).
Click Next to continue.
18. SSL Server Certificate Creation. This information screen tells you that the
configuration wizard has all the required information to generate a key pair
and its corresponding certificate.
Click Next to generate the certificate.
Chapter
6
Installing Certificate Management System
231
Stage 2. Running the Installation Wizard
19. Create Single Signon Password. Type the single signon password.
The single signon password simplifies the way you subsequently sign on to
Certificate Management System by storing the passwords for the internal
database, tokens, publishing directory, and so on. Each time you log on, you’re
only required to enter this single password. (For details, see “Required Start-up
Information” on page 316.)
Click Next to continue.
20. Configuration Status. This screen should indicate that your configuration has
been successful.
Click Done to exit the Installation Wizard.
21. Proceed to the next step, “Stage 3. Enrolling for Administrator/Agent
Certificate” on page 277, to create the first agent user for the Certificate
Manager.
Installing the Certificate Manager as a
Subordinate CA
To install the Certificate Manager as a subordinate CA:
1.
Subsystems. Select Certificate Manager. If you want the Certificate Manager to
issue certificates for wireless applications, select the “In addition to X.509 v3
certificates, do you want the Certificate Manager to support issuance of
Wireless Transport Layer Support (wTLS)-compliant certificates” option.
Otherwise, leave the option unchecked. (If you select the option, the end-entity
interface will include two forms for requesting certificates for wireless
applications and an option for downloading the wireless CA certificate.)
Click Next to continue.
2.
Remote Data Recovery Manager. Select the appropriate options:
❍
❍
If you don’t want to connect the Certificate Manager to a remote Data
Recovery Manager, select No.
If you have already installed a remote Data Recovery Manager that you
want the Certificate Manager to use for archiving end users’ encryption
private keys, select Yes. Then, enter the remote Data Recovery Manager’s
host name and agent SSL port number in the associated fields.
Click Next to continue.
232
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
3.
Network Configuration. Type the port numbers for the ports to be used by the
CMS instance. If you want to enable the non-SSL end-entity port, be sure to
check the “Enable” checkbox.
Click Next to continue.
4.
CA’s serial number range. Specify range for the serial numbers. In the
“Starting serial number” field, type the lowest serial number the CA should
assign to a certificate. If you only use one CA server, you can leave the “Ending
serial number” field blank to indicate no upper limit. If you plan to clone the
CA to distribute load, you must specify an upper limit. (For cloned CAs, you
must make sure that the range of serial numbers does not overlap with any
other CA server.)
Click Next to continue.
5.
CA Signing Certificate. Select the “Create subordinate CA certificate request”
option.
Click Next to continue.
6.
Key-Pair Information for Certificate Manager CA signing certificate. Select
the token to store the CA signing certificate and key pair. If you have not
previously initialized the token’s password, you must do so in this screen. Also
specify the key type and length.
Click Next to continue.
7.
Message Digest Algorithm. Select the algorithm to use for computing the
certificate signature. The choices are: MD2, MD5, or SHA-1.
Click Next to continue.
8.
Subject Name for Certificate Manager CA Signing Certificate. Type values
for the subject DN components; these values identify the subordinate CA
signing certificate.
Click Next to continue.
9.
Validity Period for Certificate Manager CA Signing Certificate. Select the
validity period for the subordinate CA signing certificate. The default validity
is two years. The validity period determines how soon you will have to renew
the certificate, which can be a complex procedure.
Click Next to continue.
Chapter
6
Installing Certificate Management System
233
Stage 2. Running the Installation Wizard
10. Certificate Extensions for Certificate Manager CA Signing Certificate. Select
the required extensions. The default settings should work for most
deployments. If necessary, you can add an additional extension by pasting its
base-64 encoding in the space provided on this screen.
Certificate Management System provides command-line tools for generating
extensions to include in CA and other certificate requests. For details about
these tools, check this directory: <server_root>/bin/cert/tools
Note that the certificate extension text field accepts a single extension blob. If
you want to add multiple extensions, you should use the ExtJoiner program,
which is also provided in the tools directory. For details about using the
ExtJoiner program, see Chapter 5, “Extension Joiner Tool” of CMS
Command-Line Tools Guide.
Click Next to continue.
11. Certificate Manager CA Signing Certificate Creation. This is an informational
screen that tells you that the wizard has all the information required to
generate the key pair and certificate request. In the previous screen, if you
chose to include the Subject Key Identifier extension in the certificate, you’ll be
given the choice to select the format for the certificate request. Otherwise, the
request format will be PKCS #10.
❍
❍
If you want the wizard to generate the certificate request in PKCS #10
format, select the “Generate PKCS10 request” option.
If you want the wizard to generate the certificate request in CMC format,
select the “Generate CMC full enrollment request” option.
Click Next to generate the request. The wizard creates a certificate request that
you must submit to another CA.
12. Submission of Request. Select whether you want to submit the request
manually or send the request to a remote Certificate Manager automatically.
To automatically submit the request to a remote Certificate Manager (or for
automatic enrollment), follow these steps:
234
a.
Select the “Send the request to a remote CMS now” option.
b.
Enter the host name and end-entity port number of the remote Certificate
Manager, and select whether this end-entity port is SSL enabled.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
c.
Click Next to submit the request.
The Certificate Request Result screen appears, confirming that the request
has been submitted. Note the request ID provided in the response
message. (You can use it later to retrieve the certificate, once it has been
issued, from the end-entity port.)
Note that the request you submitted gets added to the agent queue of the
remote Certificate Manager for approval by that Certificate Manager’s
agent. If you’ve permission to access that Certificate Manager’s Agent
interface, you can follow the instructions below to issue the certificate.
Otherwise, you should wait for the other agent to approve your request
and issue the certificate.
d.
Open a web browser window.
e.
Enter the URL for the remote Certificate Manager’s Agent Services page.
(You must use the same computer where you got your agent certificate.)
f.
Select List Requests, then click Show Pending Requests and click Find. The
pending request list is displayed.
g.
Locate your request, click Details to see it, and make any changes. Then,
scroll down to the bottom of the form and click Do It.
h.
After the certificate is generated, click Show Certificate.
i.
When the certificate is displayed, scroll down to the base-64 encoded
version of the certificate, highlight all the text (including -----BEGIN
CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to
the clipboard or to a text file.
Be sure to not make any changes to the certificate. You’re required to paste
the encoded certificate into the Installation Wizard screen next. So, once
you’ve copied the certificate, go back to the wizard screen (Step 13).
To submit your certificate request manually to a remote Certificate Manager,
follow these steps:
a.
Open a web browser window.
b.
Go to the end-entity URL for the remote Certificate Manager that will issue
the subordinate CA’s signing certificate.
For example, if you assigned the port number 17006 to the non-SSL
end-entity port for your root CA, you would go to the URL
http://hostname.17006 to bring up the Certificate Manager page for end
entities.
Chapter
6
Installing Certificate Management System
235
Stage 2. Running the Installation Wizard
c.
In the left-hand frame of the Enrollment tab, choose the form appropriate
for the request type:
If the request is in the PKCS #10 format, under Server, click Certificate
Manager. In the resulting form, paste the request from the clipboard into
the text area and fill in any other required information.
If the request is in the CMC format, click CMC Enrollment. In the resulting
form, paste the request from the clipboard into the text area and fill in any
other required information. Be sure to select CA Signing Certificate as
the certificate type.
d.
Click Submit.
e.
The request gets added to the agent queue of the remote Certificate
Manager for approval by that Certificate Manager’s agent. If you’ve
permission to access that Certificate Manager’s Agent interface, you can
follow the instructions below to issue the certificate. Otherwise, you’ll have
to wait till the remote Certificate Manager’s agent approves your request.
f.
In the web browser window, enter the URL for the remote Certificate
Manager’s Agent Services page. (You must use the same computer where
you got your agent certificate.)
g.
Select List Requests, then click Show Pending Requests and click Find.
h.
In the pending request list, locate your request, click Details to see the
request, and make any changes. Then, scroll down to the bottom of the
form, and click Do It.
i.
After the certificate is generated, click Show Certificate.
j.
When the certificate is displayed, scroll down to the base-64 encoded
version of the certificate, highlight all the text (including -----BEGIN
CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to
the clipboard or to a text file.
Be sure to not make any changes to the certificate. You’re required to paste
the encoded certificate into the Installation Wizard next. So, once you’ve
copied the certificate, go back to the wizard screen (Step 13).
236
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
To submit your certificate request manually to a third-party CA, follow these
steps:
a.
Make sure that the certificate request (including -----BEGIN NEW
CERTIFICATE REQUEST ----- and -----END NEW CERTIFICATE
REQUEST -----) is highlighted, and click the Copy to Clipboard button.
This action copies the certificate request to the clipboard. In addition to the
copy on the clipboard, the screen informs you that the certificate request
has been saved to a file. You can use either the copy on the clipboard or the
copy in the file to transfer your request to the CA that will issue the
subordinate CA’s signing certificate.
b.
Submit your certificate request to a third-party CA, following the
instructions provided by that CA.
Click Next when you are ready to proceed.
13. CA Signing Certificate Installation. Depending on whether you have the
certificate ready for pasting into the Installation Wizard screen, click Yes or No.
❍
❍
If you have submitted your request to a third-party CA or to a remote
Certificate Manager for which you do not have agent privileges, you may
have to wait days or weeks before you receive the certificate. In this case,
you should click No, continue as far as you can with the configuration, and
resume after you receive the certificate. The default selection is No.
Select Yes, only if you have the certificate ready in its base-64 encoded
format.
Click Next to continue.
❍
❍
If you selected No, you will be presented with the “SSL Server Certificate”
screen (Step 17).
If you selected Yes, the “Location of Certificate” screen appears (Step 14).
14. Location of Certificate. Specify the location of the certificate. You can use any
of these options:
❍
❍
If you copied the encoded certificate to a file, select the “The certificate is
located in this file” option and then type the file path, including the
filename, in the text field.
If you copied the certificate to the clipboard, select the “The certificate is
located in the text area below” option and then paste in a base-64 encoded
certificate (including the header and footer) in the text area provided.
Chapter
6
Installing Certificate Management System
237
Stage 2. Running the Installation Wizard
❍
If you noted the request ID of your request and know the host name and
end-entity port number of the remote Certificate Manager that issued the
certificate, select the “The certificate is at the CMS server where the request
was sent” option and then specify the required details.
Click Next to continue.
15. Certificate Details. This is an informational screen that shows the certificate so
you can inspect its contents. Notice the nickname assigned to the certificate
and verify that you’re installing the correct certificate.
Click Next to continue.
16. Import Certificate Chain. This screen appears only if you need to import the
CA certificate chain. If the CA that issued the certificate is a Certificate
Manager, follow these steps:
a.
Go to the end-entity URL for the Certificate Manager that issued the
subordinate CA’s signing certificate.
b.
Select the Retrieval tab, and then choose Import CA Certificate Chain.
c.
Select the “Display the CA certificate chain in PKCS#7 for importing into a
server” option, and then click Submit.
d.
Copy the certificate chain to the clipboard.
e.
Return to the Installation Wizard.
f.
Paste the certificate chain into the text box.
Click Next to continue.
17. SSL Server Certificate. Select the appropriate option:
❍
❍
If you want to get the SSL server certificate signed by the subordinate CA
itself, select the “Sign SSL certificate with my CA signing certificate”
option.
If you want to submit the SSL server certificate request to another CA, for
example to the CA that signed the subordinate CA’s signing certificate,
select the “Create request for submission to another CA” option.
Click Next to continue.
238
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
18. Key-Pair Information for SSL Server Certificate. Select the token to store the
SSL server certificate and key pair. If you have not previously initialized the
token’s password, you must do so in this screen. Also specify the key type and
length.
Click Next to continue.
19. Message Digest Algorithm. Select the algorithm to use for computing the
certificate signature. The choices are: SHA-1, MD2, or MD5.
Click Next to continue.
20. Subject Name for SSL Server Certificate. Type the values for the subject DN
components; these values identify the subordinate CA’s SSL server certificate.
The CN must be the fully-qualified host name of the machine on which you’re
installing the Certificate Manager.
Click Next to continue.
21. Certificate Extensions for SSL Server Certificate. Select the required
extensions. The default settings should work for most deployments. If
necessary, you can add an additional extension by pasting its base-64 encoding
in the space provided on this screen. (For details, see Step 10 of this section.)
Click Next to continue.
22. SSL Server Certificate Request Creation. This is an informational screen that
tells you that the wizard has all the information required to generate the key
pair and certificate request. In the previous screens, if you chose to generate a
certificate request and include the Subject Key Identifier extension in the
certificate, you’ll be given the choice to select the format for the certificate
request. Otherwise, the request format will be PKCS #10.
❍
❍
If you want the wizard to generate the certificate request in PKCS #10
format, select the “Generate PKCS10 request” option.
If you want the wizard to generate the certificate request in CMC format,
select the “Generate CMC full enrollment request” option.
Click Next to generate the certificate or the request:
❍
❍
If you chose to get the certificate signed by the subordinate CA itself, the
wizard generates the SSL server certificate. You’ll be presented with the
“Create Single Signon Password” screen (Step 28).
If you chose to generate a request for submission to another CA, the
wizard generates an SSL server certificate request that you must submit to
another CA. You’ll be presented with the “Submission of Request” screen
(Step 23).
Chapter
6
Installing Certificate Management System
239
Stage 2. Running the Installation Wizard
23. Submission of Request. Select whether you want to submit the request
manually or send the request automatically to a remote Certificate Manager.
To automatically submit the request to a remote Certificate Manager (or for
automatic enrollment), follow these steps:
a.
Select the “Send the request to a remote CMS now” option.
b.
Enter the host name and end-entity port number of the remote Certificate
Manager, and specify whether the end-entity port is SSL enabled.
c.
Click Next to submit the request.
The Certificate Request Result screen appears, confirming that the request
has been submitted. Note the request ID provided in the response
message. (You can use it later to retrieve the certificate, once it has been
issued, from the end-entity port.)
Note that the request gets added to the agent queue of the remote
Certificate Manager for approval by that Certificate Manager’s agent. If
you’ve permission to access that Certificate Manager’s Agent interface,
you can follow the instructions below to issue the certificate. Otherwise,
you should wait for the remote Certificate Manager’s agent to approve
your request and issue the certificate.
d.
Open a web browser window.
e.
Enter the URL for the remote Certificate Manager’s Agent Services page.
(You must use the same computer where you got your agent certificate.)
f.
Select List Requests, click Show Pending Requests, and then click Find.
g.
In the pending request list, locate your request, click Details to see the
request, and make any changes. Then, scroll down to the bottom of the
form, and click Do It.
h.
After the certificate is generated, click Show Certificate.
i.
When the certificate is displayed, scroll down to the base-64 encoded
version of the certificate, highlight all the text (including -----BEGIN
CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to
the clipboard or to a text file.
Be sure to not make any changes to the certificate. You’re required to paste
the encoded certificate into the Installation Wizard next. So, once you’ve
copied the certificate, go back to the wizard screen (Step 24).
240
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
To submit your certificate request manually to a remote Certificate Manager,
follow these steps:
a.
Open a web browser window.
b.
Go to the end-entity URL for the remote Certificate Manager that will issue
the subordinate CA’s SSL server certificate.
For example, if you assigned the port number 17006 to the non-SSL
end-entity port for your root CA, you would go to the URL
http://hostname.17006 to bring up the Certificate Manager page for end
entities.
c.
In the left-hand frame of the Enrollment tab, choose the form appropriate
for the request type:
If the request is in the PKCS #10 format, under Server, click SSL Server. In
the resulting form, paste the request from the clipboard into the text area
and fill in any other required information.
If the request is in the CMC format, click CMC Enrollment. In the resulting
form, paste the request from the clipboard into the text area and fill in any
other required information. Be sure to select Server SSL Certificate as
the certificate type.
d.
Click Submit.
e.
The request gets added to the agent queue of the remote Certificate
Manager for approval by that Certificate Manager’s agent. If you’ve
permission to access that Certificate Manager’s Agent interface, you can
follow the instructions below to issue the certificate. Otherwise, you’ll have
to wait till the remote Certificate Manager’s agent approves your request.
f.
In the web browser window, enter the URL for the remote Certificate
Manager’s Agent Services page. (You must use the same computer where
you got your agent certificate.)
g.
Select List Requests, click Show Pending Requests, and click Find.
h.
In the pending request list, locate your request, click Details to see it, and
make any changes. Then, scroll down to the bottom of the form and click
Do It.
i.
After the certificate is generated, click Show Certificate.
Chapter
6
Installing Certificate Management System
241
Stage 2. Running the Installation Wizard
j.
When the certificate is displayed, scroll down to the base-64 encoded
version of the certificate, highlight all the text (including -----BEGIN
CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to
the clipboard or to a text file.
Be sure to not make any changes to the certificate. You’re required to paste
the encoded certificate into the Installation Wizard next. So, once you’ve
copied the certificate, go back to the wizard screen (Step 24 below).
To submit your certificate request manually to a third-party CA, follow these
steps:
a.
Make sure that the certificate request (including -----BEGIN NEW
CERTIFICATE REQUEST ----- and -----END NEW CERTIFICATE
REQUEST -----) is highlighted, and click the Copy to Clipboard button.
This action copies the certificate request to the clipboard. In addition to the
copy on the clipboard, the screen informs you that the certificate request
has been saved to a file. You can use either the copy on the clipboard or the
copy in the file to transfer your request to the CA that will issue the
subordinate CA’s SSL server certificate.
b.
Submit your certificate request to a third-party CA, following the
instructions provided by that CA.
Click Next when you are ready to proceed to the next screen.
24. SSL Server Certificate Installation. Depending on whether you have the
certificate ready for pasting into the Installation Wizard screen, click Yes or No.
❍
❍
If you have submitted your request to a third-party CA or to a remote
Certificate Manager for which you do not have agent privileges, you may
have to wait days or weeks before you receive the certificate. In this case,
you should click No, continue as far as you can with the configuration, and
resume after you receive the certificate. The default is No. If you selected
No, you will be presented with the “Create Single Signon Password”
screen.
Select Yes, only if you have the certificate ready in its base-64 encoded
format.
Click Next to continue.
❍
❍
242
If you selected Yes, the “Location of Certificate” screen appears (Step 25).
If you selected No, you will be presented with the “Create Single Signon
Password” screen (Step 28).
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
25. Location of Certificate. Specify the location of the certificate. You can use any
of these options:
❍
❍
❍
If you copied the encoded certificate to a file, select the “The certificate is
located in this file” option and then type the file path, including the
filename, in the text field.
If you copied the certificate to the clipboard, select the “The certificate is
located in the text area below” option and then paste in a base-64 encoded
certificate (including the header and footer) in the text area provided.
If you noted the request ID of your request and know the host name and
end-entity port number of the remote Certificate Manager that issued the
certificate, select the “The certificate is at the CMS server where the request
was sent” option and then specify the required details.
Click Next to continue.
26. Certificate Details. This is an informational screen that displays the certificate
so you can inspect its contents. Notice the nickname assigned to the certificate
and verify that you’re installing the correct certificate.
Click Next to continue.
27. Import Certificate Chain. This screen appears only if you need to import the
CA certificate chain. If the CA that issued the certificate is a Certificate
Manager, follow these steps:
a.
Go to the end-entity URL for the remote Certificate Manager that issued
the SSL server certificate.
b.
Select the Retrieval tab, and then in the left-hand frame, click Import CA
Certificate Chain.
c.
Select the “Display the CA certificate chain in PKCS#7 for importing into a
server” option, and then click Submit.
d.
In the resulting form, locate the CA certificate chain, in its base-64 encoded
format, to the clipboard.
e.
Return to the Installation Wizard.
f.
Paste the certificate chain into the text box.
Click Next to continue.
Chapter
6
Installing Certificate Management System
243
Stage 2. Running the Installation Wizard
28. Create Single Signon Password. Type the single signon password. The single
signon password simplifies the way you subsequently sign on to Certificate
Management System by storing the passwords for the internal database,
tokens, publishing directory, and so on. Each time you log on, you’re only
required to enter this single password. (For details, see “Required Start-up
Information” on page 316.)
Click Next to continue.
29. Configuration Status. This screen should indicate that your configuration has
been successful.
Click Done to exit the Installation Wizard.
30. Proceed to the next step, “Stage 3. Enrolling for Administrator/Agent
Certificate” on page 277, to create the first agent user for the Certificate
Manager.
Installing a Standalone Registration Manager
To install a standalone Registration Manager:
1.
Subsystems. Select Registration Manager.
Click Next to continue.
2.
Remote Certificate Manager. Type the host name and agent port number of
the remote Certificate Manager to which you want to connect this Registration
Manager.
Click Next to continue.
3.
Remote Data Recovery Manager. Select the appropriate options:
❍
❍
Select No, if you don’t want to connect the Registration Manager to a
remote Data Recovery Manager.
If you have already installed a remote Data Recovery Manager that you
want the Registration Manager to use for archiving end users’ encryption
private keys, select Yes. Then, enter the remote Data Recovery Manager’s
host name and agent port number in the associated fields.
Click Next to continue.
244
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
4.
Network Configuration. Type the numbers for the ports to be used by the
CMS instance. If you want to enable the non-SSL end-entity port, be sure to
check the “Enable” checkbox.
Click Next to continue.
5.
Key-Pair Information for Registration Manager Signing Certificate. Select
the token to store the Registration Manager signing certificate and key pair. If
you have not previously initialized the token’s password, you must do so in
this screen. Also specify the key type and length.
Click Next to continue.
6.
Message Digest Algorithm. Select the algorithm to use for computing the
certificate signature. The choices are: SHA-1, MD2, or MD5.
Click Next to continue.
7.
Subject Name for Registration Manager Signing Certificate. Type the values
for the subject DN components; these values identify the Registration
Manager’s signing certificate.
Click Next to continue.
8.
Certificate Extensions for Registration Manager Signing Certificate. Select
the required extensions. The default settings should work for most
deployments. If necessary, you can add an additional extension by pasting its
base-64 encoding in the space provided on this screen.
Certificate Management System provides command-line tools for generating
extensions to include in CA and other certificate requests. For details about
these tools, check this directory: <server_root>/bin/cert/tools
Note that the certificate extension text field accepts a single extension blob. If
you want to add multiple extensions, you should use the ExtJoiner program,
which is also provided in the tools directory. For details on using the
ExtJoiner program, see Chapter 5, “Extension Joiner Tool” of CMS
Command-Line Tools Guide.
Click Next to continue.
9.
Registration Manager Signing Certificate Request Creation. This
informational screen tells you that the wizard has all the information required
to generate the key pair and certificate request. In the previous screen, if you
chose to include the Subject Key Identifier extension in the certificate, you’ll be
given the choice to select the format for the certificate request. Otherwise, the
request format will be PKCS #10.
Chapter
6
Installing Certificate Management System
245
Stage 2. Running the Installation Wizard
❍
❍
If you want the wizard to generate the certificate request in PKCS #10
format, select the “Generate PKCS10 request” option.
If you want the wizard to generate the certificate request in CMC format,
select the “Generate CMC full enrollment request” option. (This option is
available only if you selected to add the Subject Key Identifier extension to
the certificate in the previous.)
Click Next. The wizard creates a certificate request that you must submit to a
CA, which could be a remote Certificate Manager or a third-party CA.
10. Submission of Request. Select whether you want to submit the request
manually or send the request automatically to a remote Certificate Manager.
To automatically submit the request to a remote Certificate Manager (or for
automatic enrollment), follow these steps:
a.
Select the “Send the request to a remote CMS now” option.
b.
Enter the host name and end-entity port number of the remote Certificate
Manager, and specify whether the end-entity port is SSL enabled.
c.
Click Next to submit the request.
The Certificate Request Result screen appears, confirming that the request
has been submitted. Note the request ID provided in the response
message. (You can use it later to retrieve the certificate, once it has been
issued, from the end-entity port.)
Note that your request gets added to the agent queue of the remote
Certificate Manager for approval by that Certificate Manager’s agent. If
you’ve permission to access that Certificate Manager’s Agent interface,
you can follow the instructions below to issue the certificate. Otherwise,
you should wait for the remote Certificate Manager’s agent to approve
your request.
246
d.
Open a web browser window.
e.
Enter the URL for the remote Certificate Manager’s Agent Services page.
(You must use the same computer where you got your agent certificate.)
f.
Select List Requests, click Show Pending Requests, and click Find.
g.
In the pending request list, locate your request, click Details to see the
request, and make any changes. Then, scroll down to the bottom of the
form and click Do It.
h.
After the certificate is generated, click Show Certificate.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
i.
When the certificate is displayed, scroll down to the base-64 encoded
version of the certificate, highlight all the text (including -----BEGIN
CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to
the clipboard or to a text file.
Be sure to not make any changes to the certificate. You’re required to paste
the encoded certificate into the Installation Wizard next. So, once you’ve
copied the certificate, go back to the wizard screen (Step 11).
To submit your certificate request manually to a remote Certificate Manager,
follow these steps:
a.
Open a web browser window.
b.
Go to the end-entity URL of the remote Certificate Manager that will issue
the Registration Manager’s signing certificate.
For example, if you assigned the port number 17006 to the non-SSL
end-entity port for your root CA, you would go to the URL
http://hostname.17006 to bring up the Certificate Manager page for end
entities.
c.
In the left-hand frame of the Enrollment tab, choose the form appropriate
for the request type:
If the request is in the PKCS #10 format, under Server, click Registration
Manager. In the resulting form, paste the request from the clipboard into
the text area and fill in any other required information.
If the request is in the CMC format, click CMC Enrollment. In the resulting
form, paste the request from the clipboard into the text area and fill in any
other required information. Be sure to select RA Signing Certificate as
the certificate type.
d.
Click Submit.
e.
The request gets added to the agent queue of the remote Certificate
Manager for approval by that Certificate Manager’s agent. If you’ve
permission to access that Certificate Manager’s Agent interface, you can
follow the instructions below to issue the certificate. Otherwise, you’ll have
to wait till the remote Certificate Manager’s agent approves your request.
f.
In the web browser window, enter the URL for the remote Certificate
Manager’s Agent Services page. (You must use the same computer where
you got your agent certificate.)
g.
Select List Requests, click Show Pending Requests, and click Find.
Chapter
6
Installing Certificate Management System
247
Stage 2. Running the Installation Wizard
h.
In the pending request list, locate your request, click Details to see it. After
checking the certificate request and making required changes, scroll down
to the last section, labeled Privileges.
i.
Select the checkbox labeled “This certificate is for a Trusted Manager.”
(Note that you must be a designated CMS administrator as well as an
agent for this option to work correctly.)
j.
Type a user ID for the new Registration Manager. This user ID can be the
same that you specified in the certificate request, or it can be some other ID
that you want to use to identify this manager in the CMS window of
Netscape Console, such as RMEng.
k.
Scroll to the bottom and click Do It.
l.
After the certificate is generated, click Show Certificate.
m. When the certificate is displayed, scroll down to the base-64 encoded
version of the certificate, highlight all the text (including -----BEGIN
CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to
the clipboard or to a text file.
Be sure to not make any changes to the certificate. You’re required to paste
the encoded certificate into the Installation Wizard next. So, once you’ve
copied the certificate, go back to the wizard screen (Step 11).
To submit your certificate request manually to a third-party CA, follow these
steps:
a.
Make sure that the certificate request (including -----BEGIN NEW
CERTIFICATE REQUEST ----- and -----END NEW CERTIFICATE
REQUEST -----) is highlighted, and click the Copy to Clipboard button.
This action copies the certificate request to the clipboard. In addition to the
copy on the clipboard, the screen informs you that the certificate request
has been saved to a file. You can use either the copy on the clipboard or the
copy in the file to transfer your request to the CA that will issue the
Registration Manager’s signing certificate.
b.
Submit your certificate request to a third-party CA, following the
instructions provided by that CA.
Click Next when you are ready to proceed.
11. Registration Manager Signing Certificate Installation. Depending on
whether you have the certificate ready for pasting into the Installation Wizard
screen, click Yes or No.
248
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
❍
❍
If you have submitted your request to a third-party CA or to a remote
Certificate Manager for which you do not have agent privileges, you may
have to wait days or weeks before you receive the certificate. In this case,
you should click No, continue as far as you can with the configuration, and
resume after you receive the certificate. The default selection is No.
Select Yes, only if you have the certificate ready in its base-64 encoded
format.
Click Next to continue.
❍
❍
If you selected Yes, the “Location of Certificate” screen appears (Step 12).
If you selected No, you will be presented with the “Key-Pair Information
for SSL Server Certificate” screen (Step 15).
12. Location of Certificate. Specify the location of the certificate. You can use any
of these options:
❍
❍
❍
If you copied the encoded certificate to a file, select the “The certificate is
located in this file” option and then type the file path, including the
filename, in the text field.
If you copied the certificate to the clipboard, select the “The certificate is
located in the text area below” option and then paste in a base-64 encoded
certificate (including the header and footer) in the text area provided.
If you noted the request ID of your request and know the host name and
end-entity port number of the remote Certificate Manager that issued the
certificate, select the “The certificate is at the CMS server where the request
was sent” option and then specify the required details.
Click Next to continue.
13. Certificate Details. This is an informational screen that displays the certificate
so you can inspect its contents. Notice the nickname assigned to the certificate
and verify that you’re installing the correct certificate.
Click Next to continue.
14. Import Certificate Chain. This screen appears only if you need to import the
CA certificate chain. If the CA that issued the certificate is a Certificate
Manager, follow these steps:
a.
Go to the end-entity URL for the remote Certificate Manager that issued
the Registration Manager’s signing certificate.
b.
Select the Retrieval tab, and in the left-hand frame, click Import CA
Certificate Chain.
Chapter
6
Installing Certificate Management System
249
Stage 2. Running the Installation Wizard
c.
In the resulting form, select the “Display the CA certificate chain in
PKCS#7 for importing into a server” option, and then click Submit.
d.
In the resulting page, locate the CA certificate chain in its base-64 encoded
format, and copy the certificate chain to the clipboard.
e.
Return to the Installation Wizard.
f.
Paste the certificate chain into the text box.
Click Next to continue.
15. Key-Pair Information for SSL Server Certificate. Select the token to store the
SSL server certificate and key pair. If you have not previously initialized the
token’s password, you must do so in this screen. Also specify the key type and
length.
Click Next to continue.
16. Message Digest Algorithm. Select the algorithm to use for computing the
certificate signature. The choices are: SHA-1, MD2, or MD5.
Click Next to continue.
17. Subject Name for SSL Server Certificate. Type the values for the subject DN
components; these values identify the Registration Manager’s SSL server
certificate. The CN must be the fully-qualified host name of the machine on
which you’re installing the Registration Manager.
Click Next to continue.
18. Certificate Extensions for SSL Server Certificate. Select the required
extensions. The default settings should work for most deployments. If
necessary, you can add an additional extension by pasting its base-64 encoding
in the space provided on this screen. (For details, see Step 8 of this section.)
Click Next to continue.
19. SSL Server Certificate Request Creation. This is an informational screen that
tells you that the wizard has all the information required to generate the key
pair and certificate request. In the previous screen, if you chose to include the
Subject Key Identifier extension in the certificate, you’ll be given the choice to
select the format for the certificate request. Otherwise, the request format will
be PKCS #10.
❍
250
If you want the wizard to generate the certificate request in PKCS #10
format, select the “Generate PKCS10 request” option.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
❍
If you want the wizard to generate the certificate request in CMC format,
select the “Generate CMC full enrollment request” option.
Click Next. The wizard creates the certificate request that you must submit to
another CA.
20. Submission of Request. Select whether you want to submit the request
manually or send the request automatically to a remote Certificate Manager.
To automatically submit the request to a remote Certificate Manager (or for
automatic enrollment), follow these steps:
a.
Select the “Send the request to a remote CMS now” option.
b.
Enter the host name and end-entity port number of the remote Certificate
Manager, and select whether the end-entity port is SSL enabled.
c.
Click Next to submit the request.
The Certificate Request Result screen appears, confirming that the request
has been submitted. Note the request ID provided in the response
message. (You can use it later to retrieve the certificate, once it has been
issued, from the end-entity port.)
Note that your request gets added to the agent queue of the remote
Certificate Manager for approval by that Certificate Manager’s agent. If
you’ve permission to access that Certificate Manager’s Agent interface,
you can follow the instructions below to issue the certificate. Otherwise,
you should wait for the remote Certificate Manager’s agent to approve
your request.
d.
In the web browser window, enter the URL for the remote Certificate
Manager’s Agent Services page. (You must use the same computer where
you got your agent certificate.)
e.
Select List Requests, click Show Pending Requests, and click Find.
f.
In the pending request list, locate your request, click Details to see it, and
make any changes. Then, scroll down to the bottom of the form, and click
Do It.
g.
After the certificate is generated, click Show Certificate.
Chapter
6
Installing Certificate Management System
251
Stage 2. Running the Installation Wizard
h.
When the certificate is displayed, scroll down to the base-64 encoded
version of the certificate, highlight all the text (including -----BEGIN
CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to
the clipboard or to a text file.
Be sure to not make any changes to the certificate. You’re required to paste
the encoded certificate into the Installation Wizard next. So, once you’ve
copied the certificate, go back to the wizard screen (Step 21).
To submit your certificate request manually to a remote Certificate Manager,
follow these steps:
a.
Open a web browser window.
b.
Go to the end-entity URL for the remote Certificate Manager that will issue
the SSL server certificate.
For example, if you assigned the port number 17006 to the non-SSL
end-entity port for your root CA, you would go to the URL
http://hostname.17006 to bring up the Certificate Manager page for end
entities.
c.
In the left-hand frame of the Enrollment tab, choose the form appropriate
for the request type:
If the request is in the PKCS #10 format, under Server, click SSL Server. In
the resulting form, paste the request from the clipboard into the text area
and fill in any other required information.
If the request is in the CMC format, click CMC Enrollment. In the resulting
form, paste the request from the clipboard into the text area and fill in any
other required information. Be sure to select Server SSL Certificate as
the certificate type.
252
d.
Click Submit.
e.
The request gets added to the agent queue of the remote Certificate
Manager for approval by that Certificate Manager’s agent. If you’ve
permission to access that Certificate Manager’s Agent interface, you can
follow the instructions below to issue the certificate. Otherwise, you’ll have
to wait till the remote Certificate Manager’s agent approves your request.
f.
In the web browser window, enter the URL for the remote Certificate
Manager’s Agent Services page. (You must use the same computer where
you got your agent certificate.)
g.
Select List Requests, click Show Pending Requests, and click Find. The
pending request list is displayed.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
h.
Locate your request, click Details to see it, and make any changes. Then,
scroll down to the bottom of the form and click Do It.
i.
After the certificate is generated, click Show Certificate.
j.
When the certificate is displayed, scroll down to the base-64 encoded
version of the certificate, highlight all the text (including -----BEGIN
CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to
the clipboard or to a text file.
Be sure to not make any changes to the certificate. You’re required to paste
the encoded certificate into the Installation Wizard next. So, once you’ve
copied the certificate, go back to the wizard screen (Step 21).
To submit your certificate request manually to a third-party CA, follow these
steps:
a.
Make sure that the certificate request (including -----BEGIN NEW
CERTIFICATE REQUEST ----- and -----END NEW CERTIFICATE
REQUEST -----) is highlighted, and click the Copy to Clipboard button.
This action copies the certificate request to the clipboard. In addition to the
copy on the clipboard, the screen informs you that the certificate request
has been saved to a file. You can use either the copy on the clipboard or the
copy in the file to transfer your request to the CA that will issue the
Registration Manager’s SSL server certificate.
b.
Submit your certificate request to a third-party CA, following the
instructions provided by that CA.
Click Next when you are ready to proceed to the next screen.
21. SSL Server Certificate Installation. Depending on whether you have the
certificate ready for pasting into the Installation Wizard screen, click Yes or No.
❍
❍
If you have submitted your request to a third-party CA or to a remote
Certificate Manager for which you do not have agent privileges, you may
have to wait days or weeks before you receive the certificate. In this case,
you should click No, continue as far as you can with the configuration, and
resume after you receive the certificate. The default is No.
Select Yes, only if you have the certificate ready in its base-64 encoded
format.
Click Next to continue.
❍
If you selected Yes, the “Location of Certificate” screen appears (Step 22).
Chapter
6
Installing Certificate Management System
253
Stage 2. Running the Installation Wizard
❍
If you selected No, you will be presented with the “Create Single Signon
Password” screen (Step 25).
22. Location of Certificate. Specify the location of the certificate. You can use any
of these options:
❍
❍
❍
If you copied the encoded certificate to a file, select the “The certificate is
located in this file” option and then type the file path, including the
filename, in the text field.
If you copied the certificate to the clipboard, select the “The certificate is
located in the text area below” option and then paste in a base-64 encoded
certificate (including the header and footer) in the text area provided.
If you noted the request ID of your request and know the host name and
end-entity port number of the Certificate Manager that issued the
certificate, select the “The certificate is at the CMS server where the request
was sent” option and then specify the required details.
Click Next to continue.
23. Certificate Details. This is an informational screen that displays the certificate
so you can inspect its contents. Notice the nickname assigned to the certificate
and verify that you’re installing the correct certificate.
Click Next to continue.
24. Import Certificate Chain. This screen appears only if you need to import the
CA certificate chain again; for example, if you requested the SSL certificate
from a different CA than the one from which you requested the singing
certificate.
Follow these steps to import the remote Certificate Manager’s CA chain:
254
a.
Go to the web browser window.
b.
Enter the end-entity URL for the remote Certificate Manager that issued
the SSL server certificate.
c.
Select the Retrieval tab, and in the left-hand frame, click Import CA
Certificate Chain.
d.
Select the “Display the CA certificate chain in PKCS#7 for importing into a
server” option, and then click Submit.
e.
In the resulting page, locate the CA certificate chain in its base-64 encoded
format, and copy it to the clipboard.
f.
Return to the Installation Wizard.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
g.
Paste the CA certificate chain into the text box.
Click Next to continue.
25. Create Single Signon Password. Type the single signon password. The single
signon password simplifies the way you subsequently sign on to Certificate
Management System by storing the passwords for the internal database,
tokens, and so on. Each time you log on, you’re only required to enter this
single password. (For details, see “Required Start-up Information” on
page 316.)
Click Next to continue.
26. Configuration Status. This screen should indicate that your configuration has
been successful.
Click Done to exit the Installation Wizard.
27. Proceed to the next step, “Stage 3. Enrolling for Administrator/Agent
Certificate” on page 277, to create the first agent user for the Registration
Manager.
Installing a Standalone Data Recovery Manager
To install a standalone Data Recovery Manager:
1.
Subsystems. Select Data Recovery Manager.
Click Next to continue.
2.
Network Configuration. Type the numbers for the ports to be used by the
CMS instance. If you want to enable the non-SSL end-entity port, be sure to
check the “Enable” checkbox.
Click Next to continue.
3.
Key-Pair Information for Data Recovery Manager Transport Certificate.
Select the token to store the transport certificate and key pair. If you have not
previously initialized the token’s password, you must do so in this screen. Also
specify the key type and length.
Click Next to continue.
4.
Message Digest Algorithm. Select the algorithm to use for computing the
certificate signature. The choices are: SHA-1, MD2, or MD5.
Click Next to continue.
Chapter
6
Installing Certificate Management System
255
Stage 2. Running the Installation Wizard
5.
Subject Name for Data Recovery Manager Transport Certificate. Type the
values for the subject DN components; these values identify the transport
certificate.
Click Next to continue.
6.
Certificate Extensions for Data Recovery Manager Transport Certificate.
Select the required extensions. The default settings should work for most
deployments. If necessary, you can add an additional extension by pasting its
base-64 encoding in the space provided on this screen.
Certificate Management System provides command-line tools for generating
extensions to include in CA and other certificate requests. For details about
these tools, check this directory: <server_root>/bin/cert/tools
Note that the certificate extension text field accepts a single extension blob. If
you want to add multiple extensions, you should use the ExtJoiner program,
which is also provided in the tools directory. For details on using the
ExtJoiner program, see Chapter 5, “Extension Joiner Tool” of CMS
Command-Line Tools Guide.
Click Next to continue.
7.
Data Recovery Manager Transport Certificate Request Creation. This
informational screen tells you that the wizard has all the information required
to generate the key pair and certificate request. In the previous screen, if you
chose to include the Subject Key Identifier extension in the certificate, you’ll be
given the choice to select the format for the certificate request. Otherwise, the
request format will be PKCS #10.
❍
❍
If you want the wizard to generate the certificate request in PKCS #10
format, select the “Generate PKCS10 request” option.
If you want the wizard to generate the certificate request in CMC format,
select the “Generate CMC full enrollment request” option.
Click Next. The wizard generates the certificate request that you must submit
to a CA, which could be a remote Certificate Manager or a third-party CA.
8.
Submission of Request. Specify whether you want to submit the request
automatically or manually.
To automatically submit the request to a remote Certificate Manager (or for
automatic enrollment), follow these steps:
256
a.
Select the “Send the request to a remote CMS now” option.
b.
Enter the host name and end-entity port number, and specify whether the
end-entity port is SSL enabled.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
c.
Click Next to submit the request.
The Certificate Request Result screen appears, confirming that the request
has been submitted. Note the request ID provided in the response
message. (You can use it later to retrieve the certificate, once it has been
issued, from the end-entity port.)
Note that your request gets added to the agent queue of the remote
Certificate Manager for approval by that Certificate Manager’s agent. If
you’ve permission to access that Certificate Manager’s Agent interface,
you can follow the instructions below to issue the certificate. Otherwise,
you should wait for the remote Certificate Manager’s agent to approve
your request.
d.
Open a web browser window.
e.
Enter the URL for the remote Certificate Manager’s Agent Services page.
(You must use the same computer where you got your agent certificate.)
f.
Select List Requests, click Show Pending Requests, and click Find.
g.
In the pending request list, locate your request, click Details to see the
request, and make any changes. Then, scroll down to the bottom of the
form, and click Do It.
h.
After the certificate is generated, click Show Certificate.
i.
When the certificate is displayed, scroll down to the base-64 encoded
version of the certificate, highlight all the text (including -----BEGIN
CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to
the clipboard or to a text file.
Be sure to not make any changes to the certificate. You’re required to paste
the encoded certificate into the Installation Wizard next. So, once you’ve
copied the certificate, go back to the wizard screen (Step 9).
To submit your certificate request manually to a remote Certificate Manager,
follow these steps:
a.
Open a web browser window.
b.
Go to the end-entity URL for the remote Certificate Manager that will issue
the Data Recovery Manager’s transport certificate.
For example, if you assigned the port number 17006 to the non-SSL
end-entity port for your root CA, you would go to the URL
http://hostname.17006 to bring up the Certificate Manager page for end
entities.
Chapter
6
Installing Certificate Management System
257
Stage 2. Running the Installation Wizard
c.
In the left-hand frame of the Enrollment tab, choose the form appropriate
for the request type:
If the request is in the PKCS #10 format, under Server, click SSL Server. In
the resulting form, paste the request from the clipboard into the text area
and fill in any other required information.
If the request is in the CMC format, click CMC Enrollment. In the resulting
form, paste the request from the clipboard into the text area and fill in any
other required information. Be sure to select Server SSL Certificate as
the certificate type.
d.
Click Submit.
e.
The request gets added to the agent queue of the remote Certificate
Manager for approval by that Certificate Manager’s agent. If you’ve
permission to access that Certificate Manager’s Agent interface, you can
follow the instructions below to issue the certificate.
f.
In the web browser window, enter the URL for the remote Certificate
Manager’s Agent Services page. (You must use the same computer where
you got your agent certificate.)
g.
Select List Requests, click Show Pending Requests, and click Find.
h.
In the pending request list, locate your request, then click Details to see the
request. After checking the rest of the certificate request, scroll down to the
end of the form and click Do It.
i.
After the certificate is generated, click Show Certificate.
j.
When the certificate is displayed, scroll down to the base-64 encoded
version of the certificate, highlight all the text (including -----BEGIN
CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to
the clipboard or to a text file.
Be sure to not make any changes to the certificate. You’re required to paste
the encoded certificate into the Installation Wizard next. So, once you’ve
copied the certificate, go back to the wizard screen (Step 9).
258
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
To submit the transport certificate request manually to a third-party CA,
follow these steps:
a.
Make sure that the certificate request (including -----BEGIN NEW
CERTIFICATE REQUEST ----- and -----END NEW CERTIFICATE
REQUEST -----) is highlighted, and click the Copy to Clipboard button.
This action copies the certificate request to the clipboard. In addition to the
copy on the clipboard, the screen informs you that the certificate request
has been saved to a file. You can use either the copy on the clipboard or the
copy in the file to transfer your request to the CA that will issue the Data
Recovery Manager’s transport certificate.
b.
Submit your certificate request to a third-party CA, following the
instructions provided by that CA.
Click Next when you are ready to proceed.
9.
Data Recovery Manager Transport Certificate Installation. Depending on
whether you have the certificate ready for pasting into the Installation Wizard
screen, click Yes or No.
❍
❍
If you have submitted your request to a third-party CA or to a remote
Certificate Manager for which you do not have agent privileges, you may
have to wait days or weeks before you receive the certificate. In this case,
you should click No, continue as far as you can with the configuration, and
resume after you receive the certificate. The default is No.
Select Yes, only if you have the certificate ready in its base-64 encoded
format.
Click Next to continue.
❍
❍
If you selected Yes, the “Location of Certificate” screen appears (Step 10).
If you selected No, you will be presented with the “Storage Key Creation
for Data Recovery Manager” screen (Step 13).
10. Location of Certificate. Specify the location of the certificate. You can use any
of these options:
❍
❍
If you copied the encoded certificate to a file, select the “The certificate is
located in this file” option and then type the file path, including the
filename, in the text field.
If you copied the certificate to the clipboard, select the “The certificate is
located in the text area below” option and then paste in a base-64 encoded
certificate (including the header and footer) in the text area provided.
Chapter
6
Installing Certificate Management System
259
Stage 2. Running the Installation Wizard
❍
If you noted the request ID of your request and know the host name and
end-entity port number of the remote Certificate Manager that issued the
certificate, select the “The certificate is at the CMS server where the request
was sent” option and then specify the required details.
Click Next to continue.
11. Certificate Details. This informational screen displays the certificate so you
can inspect its contents. Notice the nickname assigned to the certificate and
verify that you’re installing the correct certificate.
Click Next to continue.
12. Import Certificate Chain. This screen appears only if you need to import the
CA certificate chain. Follow these steps to import the CA chain of the remote
Certificate Manager:
a.
Go to the web browser window.
b.
Enter the end-entity URL for the remote Certificate Manager that issued
the transport certificate.
c.
Select the Retrieval tab, and then in the left-hand frame, click Import CA
Certificate Chain.
d.
In the resulting form, select the “Display the CA certificate chain in
PKCS#7 for importing into a server” option, and click Submit.
e.
In the resulting page, locate the CA certificate chain in its base-64 encoded
format, and copy it to the clipboard.
f.
Return to the Installation Wizard.
g.
Paste the CA certificate chain into the text box.
Click Next to continue.
The screens that follow let you configure the storage key and recovery schemes
for the Data Recovery Manager.
13. Storage Key Creation for Data Recovery Manager. Select the length you have
decided on for your storage key.
Click Next to continue.
14. Data Recovery Key Scheme - 1. Type the both the required number of
recovery agents and the total number of recovery agents.
Click Next to continue.
260
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
15. Data Recovery Key Scheme - 2. The number of table rows correspond to the
total number of agents you specified in the previous screen. Type the user ID
and password for each agent in the table.
Click Next to continue. The screens that follow let you request an SSL server
certificate for the Data Recovery Manager.
16. Key-Pair Information for SSL Server Certificate. Select the token to store the
SSL server certificate and key pair. If you have not previously initialized the
token’s password, you must do so in this screen. Also specify the key type and
length.
Click Next to continue.
17. Message Digest Algorithm. Select the algorithm to use for computing the
certificate signature. The choices are: SHA-1, MD2, or MD5.
Click Next to continue.
18. Subject Name for SSL Server Certificate. Type the values for the subject DN
components; these values the Data Recovery Manager’s SSL server certificate.
The CN must be the fully-qualified host name of the machine on which you’re
installing the Data Recovery Manager.
Click Next to continue.
19. Certificate Extensions for SSL Server Certificate. Select the required
extensions. The default settings should work for most deployments. If
necessary, you can add an additional extension by pasting its base-64 encoding
in the space provided on this screen. (For details, see Step 6 of this section.)
Click Next to continue.
20. SSL Server Certificate Request Creation. This is an informational screen that
tells you that the wizard has all the information required to generate the key
pair and certificate request. In the previous screen, if you chose to include the
Subject Key Identifier extension in the certificate, you’ll be given the choice to
select the format for the certificate request. Otherwise, the request format will
be PKCS #10.
❍
❍
If you want the wizard to generate the certificate request in PKCS #10
format, select the “Generate PKCS10 request” option.
If you want the wizard to generate the certificate request in CMC format,
select the “Generate CMC full enrollment request” option.
Click Next. The wizard generates a certificate request that you must submit to
a CA.
Chapter
6
Installing Certificate Management System
261
Stage 2. Running the Installation Wizard
21. Submission of Request. Select whether you want to submit the request
manually or send the request automatically to a remote Certificate Manager.
To automatically submit the request to a remote Certificate Manager (or for
automatic enrollment), follow these steps:
a.
Select the “Send the request to a remote CMS now” option.
b.
Enter the host name and end-entity port number of the remote Certificate
Manager, and specify whether the end-entity port is SSL enabled.
c.
Click Next to submit the request.
The Certificate Request Result screen appears, confirming that the request
has been submitted. Note the request ID provided in the response
message. (You can use it later to retrieve the certificate, once it has been
issued, from the end-entity port.)
Note that your request gets added to the agent queue of the remote
Certificate Manager for approval by that Certificate Manager’s agent. If
you’ve permission to access that Certificate Manager’s Agent interface,
you can follow the instructions below to issue the certificate. Otherwise,
you should wait for the remote Certificate Manager’s agent to approve
your request and issue the certificate.
d.
In the web browser window, enter the URL for the remote Certificate
Manager’s Agent Services page. (You must use the same computer where
you got your agent certificate.)
e.
Select List Requests, click Show Pending Requests, and click Find.
f.
In the pending request list, locate your request, click Details to see the
request, and make any changes. Then, scroll down to the bottom of the
form and click Do It.
g.
After the certificate is generated, click Show Certificate.
h.
When the certificate is displayed, scroll down to the base-64 encoded
version of the certificate, highlight all the text (including -----BEGIN
CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to
the clipboard or to a text file.
Be sure to not make any changes to the certificate. You’re required to paste
the encoded certificate into the Installation Wizard next. So, once you’ve
copied the certificate, go back to the wizard screen (Step 22).
262
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
To submit your certificate request manually to a Certificate Manager, follow
these steps:
a.
Open a web browser window.
b.
Go to the end-entity URL for the Certificate Manager that will issue the SSL
server certificate.
For example, if you assigned the port number 17006 to the non-SSL
end-entity port for your root CA, you would go to the URL
http://hostname.17006 to bring up the Certificate Manager page for end
entities.
c.
In the left-hand frame of the Enrollment tab, choose the form appropriate
for the request type:
If the request is in the PKCS #10 format, under Server, click SSL Server. In
the resulting form, paste the request from the clipboard into the text area
and fill in any other required information.
If the request is in the CMC format, click CMC Enrollment. In the resulting
form, paste the request from the clipboard into the text area and fill in any
other required information. Be sure to select Server SSL Certificate as
the certificate type.
d.
Click Submit.
The request gets added to the agent queue of that Certificate Manager for
approval by that Certificate Manager’s agent. If you’ve permission to
access that Certificate Manager’s Agent interface, you can follow the
instructions below to issue the certificate.
e.
In the web browser window, enter the URL for the Certificate Manager’s
Agent Services page. (You must use the same computer where you got
your agent certificate.)
f.
Select List Requests, then click Show Pending Requests and click Find. The
pending request list is displayed.
g.
Locate your request, click Details to see it, and make any changes. Then,
scroll down to the bottom of the form and click Do It.
h.
After the certificate is generated, click Show Certificate.
Chapter
6
Installing Certificate Management System
263
Stage 2. Running the Installation Wizard
i.
When the certificate is displayed, scroll down to the base-64 encoded
version of the certificate, highlight all the text (including -----BEGIN
CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to
the clipboard or to a text file.
Be sure to not make any changes to the certificate. You’re required to paste
the encoded certificate into the Installation Wizard next. So, once you’ve
copied the certificate, go back to the wizard screen (Step 22).
To submit your certificate request manually to a third-party CA, follow these
steps:
a.
Make sure that the certificate request (including -----BEGIN NEW
CERTIFICATE REQUEST ----- and -----END NEW CERTIFICATE
REQUEST -----) is highlighted, and click the Copy to Clipboard button.
This action copies the certificate request to the clipboard. In addition to the
copy on the clipboard, the screen informs you that the certificate request
has been saved to a file. You can use either the copy on the clipboard or the
copy in the file to transfer your request to the CA that will issue the
subordinate CA’s signing certificate.
b.
Submit your certificate request to a third-party CA, following the
instructions provided by that CA.
Click Next when you are ready to proceed to the next screen.
22. SSL Server Certificate Installation. Depending on whether you have the
certificate ready for pasting into the Installation Wizard screen, click Yes or No.
❍
❍
If you have submitted your request to a third-party CA or to a remote
Certificate Manager for which you do not have agent privileges, you may
have to wait days or weeks before you receive the certificate. In this case,
you should click No, continue as far as you can with the configuration, and
resume after you receive the certificate. The default is No.
Select Yes, only if you have the certificate ready in its base-64 encoded
format.
Click Next to continue.
❍
❍
264
If you selected Yes, the “Location of Certificate” screen appears (Step 23).
If you selected No, you will be presented with the “Create Single Signon
Password” screen (Step 26).
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
23. Location of Certificate. Specify the location of the certificate. You can use any
of these options:
❍
❍
❍
If you copied the encoded certificate to a file, select the “The certificate is
located in this file” option and then type the file path, including the
filename, in the text field.
If you copied the certificate to the clipboard, select the “The certificate is
located in the text area below” option and then paste in a base-64 encoded
certificate (including the header and footer) in the text area provided.
If you noted the request ID of your request and know the host name and
end-entity port number of the remote Certificate Manager that issued the
certificate, select the “The certificate is at the CMS server where the request
was sent” option and then specify the required details.
Click Next to continue.
24. Certificate Details. This is an informational screen that displays the certificate
so you can inspect its contents. Notice the nickname assigned to the certificate
and verify that you’re installing the correct certificate.
Click Next to continue.
25. Import Certificate Chain. This screen appears only if you need to import the
CA certificate chain again. Follow these steps to import the CA chain of a
remote Certificate Manager:
a.
Go to the web browser window.
b.
Enter the end-entity URL for the remote Certificate Manager that issued
the SSL server certificate.
c.
Select the Retrieval tab, and then in the left-hand frame, select Import CA
Certificate Chain.
d.
In the resulting form, select the “Display the CA certificate chain in
PKCS#7 for importing into a server” option, and click Submit.
e.
In the resulting page, locate the CA certificate chain in its base-64 encoded
format and copy it to the clipboard.
f.
Return to the Installation Wizard.
g.
Paste the CA certificate chain into the text box.
Click Next to continue.
Chapter
6
Installing Certificate Management System
265
Stage 2. Running the Installation Wizard
26. Create Single Signon Password. Type the single signon password. The single
signon password simplifies the way you subsequently sign on to Certificate
Management System by storing the passwords for the internal database,
tokens, and so on. Each time you log on, you’re only required to enter this
single password. (For details, see “Required Start-up Information” on
page 316.)
Click Next to continue.
27. Configuration Status. This screen should indicate that your configuration has
been successful.
Click Done to exit the Installation Wizard.
28. Proceed to the next step, “Stage 3. Enrolling for Administrator/Agent
Certificate” on page 277, to create the first agent for the Data Recovery
Manager.
Installing a Online Certificate Status Manager
To install a standalone Online Certificate Status Manager:
1.
Subsystems. Select Online Certificate Status Manager.
Click Next to continue.
2.
Network Configuration. Type the numbers for the ports to be used by the
CMS instance. Be sure to leave the “Enable” checkbox for the non-SSL
end-entity port selected. The OCSP-compliant clients will use this port to
communicate with the Online Certificate Status Manager.
Click Next to continue.
3.
Key-Pair Information for Online Certificate Status Manager Signing
Certificate. Select the token to store the Online Certificate Status Manager
signing certificate and key pair. If you have not previously initialized the
token’s password, you must do so in this screen. Also specify the key type and
length.
Click Next to continue.
4.
Subject Name for Online Certificate Status Manager Signing Certificate.
Type the values for the subject DN components; these values identify the
Online Certificate Status Manager’s signing certificate.
Click Next to continue.
266
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
5.
Online Certificate Status Manager Signing Certificate Request Creation.
This informational screen tells you that the wizard has all the information
required to generate the key pair and certificate request.
Click Next to generate them.
6.
Submission of Request. Select whether you want to submit the request
manually or send the request to a remote CMS manager (Certificate Manager
or Registration Manager) automatically. The wizard creates a certificate
request that you must submit to a CA.
To automatically submit the request to a remote Certificate Manager (or for
automatic enrollment), follow these steps:
a.
Select the “Send the request to a remote CMS now” option.
b.
Enter the host name (for example, host.domain.com) and end-entity port
number of the Certificate Manager, then specify whether this end-entity
port uses SSL.
c.
Click Next to submit the request.
The Certificate Request Result screen appears, confirming that the request
has been submitted. Note the request ID provided in the response
message. (You can use it later to retrieve the certificate, once the certificate
has been issued, from the end-entity port.)
Note that your request gets added to the agent queue of the Certificate
Manager for approval by that Certificate Manager’s agent. If you’ve
permission to access that Certificate Manager’s Agent interface, you can
follow the instructions below to issue the certificate. Otherwise, you
should wait for the other agent to approve the request you submitted and
issue the certificate.
d.
Open a web browser window.
e.
Enter the URL for the Certificate Manager’s Agent Services page. (You
must use the same computer where you got your agent certificate.)
f.
Select List Requests, then click Show Pending Requests and click Find. The
pending request list is displayed.
g.
Locate your request, click Details to see it, and make any changes. Then,
scroll down to the bottom of the form and click Do It.
h.
After the certificate is generated, click Show Certificate.
Chapter
6
Installing Certificate Management System
267
Stage 2. Running the Installation Wizard
i.
When the certificate is displayed, scroll down to the base-64 encoded
version of the certificate, highlight all the text (including -----BEGIN
CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to
the clipboard or to a text file.
Be sure to not make any changes to the certificate. You’re required to paste
the encoded certificate into the Installation Wizard next. So, once you’ve
copied the certificate, go back to the wizard screen (Step 7).
Also note that you might be required to paste the CA certificate chain in
the Installation Wizard. So, keep the browser window open.
To submit your certificate request manually to a Certificate Manager, follow
these steps:
a.
Open a web browser window.
b.
Go to the end-entity URL for the Certificate Manager that will issue the
Online Certificate Status Manager’s signing certificate.
For example, if you assigned the port number 17006 to the non-SSL
end-entity port for your CA, you would go to the URL
http://hostname.17006 to bring up the Certificate Manager page for end
entities.
268
c.
In the left-hand frame, under Server, click OCSP Responder.
d.
In the OCSP Responder Enrollment page that appears, paste the request
from the clipboard into the field labeled PKCS #10 Request and fill in any
other required information.
e.
Click Submit.
f.
If the request contains all the required information, you’ll get a notification
of request being successfully added to the agent queue of that Certificate
Manager for approval by that Certificate Manager’s agent. If you’ve
permission to access that Certificate Manager’s Agent interface, you can
follow the instructions below to issue the certificate.
g.
In the web browser window, enter the URL for the Certificate Manager’s
Agent Services page. (You must use the same computer where you got
your agent certificate.)
h.
Select List Requests, then click Show Pending Requests and click Find. The
pending request list is displayed.
i.
Locate your request, click Details to see it.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
j.
After checking the rest of the certificate request and making any changes,
scroll to the bottom, and click Do It.
k.
After the certificate is generated, click Show Certificate.
l.
When the certificate is displayed, scroll down to the base-64 encoded
version of the certificate, highlight all the text (including -----BEGIN
CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to
the clipboard or to a text file.
Be sure to not make any changes to the certificate. You’re required to paste
the encoded certificate into the Installation Wizard next. So, once you’ve
copied the certificate, go back to the wizard screen (Step 7).
Also note that you might be required to paste the CA certificate chain in
the Installation Wizard. So, keep the browser window open.
To submit your certificate request manually to a third-party CA, follow these
steps:
a.
Make sure that the certificate request (including -----BEGIN NEW
CERTIFICATE REQUEST ----- and -----END NEW CERTIFICATE
REQUEST -----) is highlighted, and click the Copy to Clipboard button.
This action copies the certificate request to the clipboard. In addition to the
copy on the clipboard, the screen informs you that the certificate request
has been saved to a file. You can use either the copy on the clipboard or the
copy in the file to transfer your request to the CA that will issue the Online
Certificate Status Manager’s signing certificate.
b.
Submit your certificate request to a third-party CA, following the
instructions provided by that CA.
Click Next when you are ready to proceed.
7.
Online Certificate Status Manager Signing Certificate Installation.
Depending on whether you have the certificate ready for pasting into the
Installation Wizard screen, click Yes or No.
❍
❍
If you have submitted your request to a third-party CA or to a remote
Certificate Manager for which you do not have agent privileges, you may
have to wait days or weeks before you receive the certificate. In this case,
you should click No, continue as far as you can with the configuration, and
resume after you receive the certificate. The default selection is No.
Select Yes, only if you have the certificate ready in its base-64 encoded
format.
Click Next to continue.
Chapter
6
Installing Certificate Management System
269
Stage 2. Running the Installation Wizard
❍
❍
8.
If you selected Yes, the “Location of Certificate” screen appears (Step 8).
If you selected No, you will be presented with the “Key-Pair Information
for SSL Server Certificate” screen (Step 11).
Location of Certificate. Specify the location of the certificate. You can use one
of these options:
❍
❍
❍
If you noted the file path to the file that contains the certificate (in its base
64-encoded format), select the “The certificate is located in this file” option
and type the file path, including the filename, in the text field.
If you copied the certificate (in its base 64-encoded format) to the
clipboard, select the “The certificate is located in the text area below”
option and paste the certificate (including the header and footer) in the text
area provided.
If you want the wizard to retrieve the certificate from the remote CMS
manager to which you submitted the request, select the “The certificate is
at the CMS where the request was sent” option and supply the host name,
end-entity port number, and request ID.
Click Next to continue.
9.
Certificate Details. This is an informational screen that displays the certificate
so you can inspect its contents. Notice the nickname assigned to the certificate
and verify that you’re installing the correct certificate.
Click Next to continue.
10. Import Certificate Chain. This screen appears only if you need to import the
CA certificate chain. Follow these steps to import the CA chain of a Certificate
Manager:
a.
Go back to the web browser window from which you copied the Online
Certificate Status Manager’s signing certificate (in its base-64 encoded
format).
b.
Scroll down to the part that says “Base 64 encoded certificate with CA
certificate chain in pkcs7 format” and shows the CA certificate chain in its
PKCS#7 format.
c.
Highlight all the encoded blob (including -----BEGIN CERTIFICATE
----- and -----END CERTIFICATE-----), and copy it to the clipboard or
to a text file.
Be sure to not make any changes to the certificate. You’re required to paste
the encoded certificate into the Installation Wizard next. So, once you’ve
copied the certificate, go back to the wizard screen.
270
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
d.
Paste the certificate chain into the text box.
e.
Click Next to continue.
If you closed the end-entity interface, you can get the CA certificate chain this
way:
a.
Open a web browser window.
b.
Go to the end-entity URL for the Certificate Manager that issued the
Online Certificate Status Manager’s signing certificate.
c.
Select the Retrieval tab, and then choose Import CA Certificate Chain.
d.
Select the “Display the CA certificate chain in PKCS#7 for importing into a
server” option, and then click Submit.
e.
Copy the certificate chain to the clipboard.
f.
Return to the Installation Wizard.
g.
Paste the certificate chain into the text box.
h.
Click Next to continue.
11. Key-Pair Information for SSL Server Certificate. Select the token to store the
SSL server certificate and key pair. If you have not previously initialized the
token’s password, you must do so in this screen. Also specify the key type and
length.
Click Next to continue.
12. Subject Name for SSL Server Certificate. Type the values for the subject DN
components; these values identify the Online Certificate Status Manager’s SSL
server certificate. The CN must be the fully-qualified host name of the machine
on which you’re installing the Online Certificate Status Manager.
Click Next to continue.
13. Certificate Extensions for SSL Server Certificate. Select the required
extensions. The default settings should work for most deployments. If
necessary, you can add an additional extension by pasting its base-64 encoding
in the space provided on this screen.
Certificate Management System provides command-line tools for generating
extensions to include in CA and other certificate requests. For details about
these tools, check this directory: <server_root>/bin/cert/tools
Chapter
6
Installing Certificate Management System
271
Stage 2. Running the Installation Wizard
Note that the certificate extension text field accepts a single extension blob. If
you want to add multiple extensions, you should use the ExtJoiner program,
which is also provided in the tools directory. For details on using the
ExtJoiner program, see Chapter 5, “Extension Joiner Tool” of CMS
Command-Line Tools Guide.
Click Next to continue.
14. SSL Server Certificate Request Creation. This is an informational screen that
tells you that the wizard has all the information required to generate the key
pair and certificate request. In the previous screen, if you chose to include the
Subject Key Identifier extension in the certificate, you’ll be given the choice to
select the format for the certificate request. Otherwise, the request format will
be PKCS #10.
❍
❍
If you want the wizard to generate the certificate request in PKCS #10
format, select the “Generate PKCS10 request” option.
If you want the wizard to generate the certificate request in CMC format,
select the “Generate CMC full enrollment request” option.
Click Next. The wizard generates the certificate request that you must submit
to a CA.
15. Submission of Request. Select whether you want to submit the request
manually or send the request to a remote CMS server (Certificate Manager or
Registration Manager) automatically.
To automatically submit the request to a remote Certificate Manager (or for
automatic enrollment), follow these steps:
272
a.
Select the “Send the request to a remote CMS now” option.
b.
Enter the host name and end-entity port number of the Certificate
Manager, and select whether this end-entity port uses SSL.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
c.
Click Next to submit the request.
The Certificate Request Result screen appears, confirming that the request
has been submitted. Note the request ID provided in the response
message. (You can use it later to retrieve the certificate, once it has been
issued, from the end-entity port.)
Note that your request gets added to the agent queue of the Certificate
Manager for approval by that Certificate Manager’s agent. If you’ve
permission to access that Certificate Manager’s Agent interface, you can
follow the instructions below to issue the certificate. Otherwise, you
should wait for the other agent to approve your request and issue the
certificate.
d.
In the web browser window, enter the URL for the Certificate Manager’s
Agent Services page. (You must use the same computer where you got
your agent certificate.)
e.
Select List Requests, then click Show Pending Requests and click Find. The
pending request list is displayed.
f.
Locate your request, click Details to see it, and make any changes. Then
scroll down to the bottom of the form and click Do It.
g.
After the certificate is generated, click Show Certificate.
h.
When the certificate is displayed, scroll down to the base-64 encoded
version of the certificate, highlight all the text (including -----BEGIN
CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to
the clipboard or to a text file.
Be sure to not make any changes to the certificate. You’re required to paste
the encoded certificate into the Installation Wizard next. So, once you’ve
copied the certificate, go back to the wizard screen (Step 16).
To submit your certificate request manually to a Certificate Manager, follow
these steps:
a.
Open a web browser window.
b.
Go to the end-entity URL for the Certificate Manager that will issue the SSL
server certificate.
For example, if you assigned the port number 17006 to the non-SSL
end-entity port for your root CA, you would go to the URL
http://hostname.17006 to bring up the Certificate Manager page for end
entities.
Chapter
6
Installing Certificate Management System
273
Stage 2. Running the Installation Wizard
c.
In the left-hand frame of the Enrollment tab, choose the form appropriate
for the request type:
If the request is in the PKCS #10 format, under Server, click SSL Server. In
the resulting form, paste the request from the clipboard into the text area
and fill in any other required information.
If the request is in the CMC format, click CMC Enrollment. In the resulting
form, paste the request from the clipboard into the text area and fill in any
other required information. Be sure to select Server SSL Certificate as
the certificate type.
d.
Click Submit.
e.
The request gets added to the agent queue of that Certificate Manager for
approval by that Certificate Manager’s agent. If you’ve permission to
access that Certificate Manager’s Agent interface, you can follow the
instructions below to issue the certificate. Otherwise, you’ll have to wait
for the Certificate Manager’s agent to approve your request and issue the
certificate.
f.
In the web browser window, enter the URL for the Certificate Manager’s
Agent Services page. (You must use the same computer where you got
your agent certificate.)
g.
Select List Requests, then click Show Pending Requests and click Find. The
pending request list is displayed.
h.
Locate your request, click Details to see it, and make any changes. Then,
scroll down to the bottom of the form and click Do It.
i.
After the certificate is generated, click Show Certificate.
j.
When the certificate is displayed, scroll down to the base-64 encoded
version of the certificate, highlight all the text (including -----BEGIN
CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to
the clipboard or to a text file.
Be sure to not make any changes to the certificate. You’re required to paste
the encoded certificate into the Installation Wizard next. So, once you’ve
copied the certificate, go back to the wizard screen (Step 16).
274
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 2. Running the Installation Wizard
To submit your certificate request manually to a third-party CA, follow these
steps:
a.
Make sure that the certificate request (including -----BEGIN NEW
CERTIFICATE REQUEST ----- and -----END NEW CERTIFICATE
REQUEST -----) is highlighted, and click the Copy to Clipboard button.
This action copies the certificate request to the clipboard. In addition to the
copy on the clipboard, the screen informs you that the certificate request
has been saved to a file. You can use either the copy on the clipboard or the
copy in the file to transfer your request to the CA that will issue the
subordinate CA’s signing certificate.
b.
Submit your certificate request to a third-party CA, following the
instructions provided by that CA.
Click Next when you are ready to proceed to the next screen.
16. SSL Server Certificate Installation. Depending on whether you have the
certificate ready for pasting into the Installation Wizard screen, click Yes or No.
❍
❍
If you have submitted your request to a third-party CA or to a remote
Certificate Manager for which you do not have agent privileges, you may
have to wait days or weeks before you receive the certificate. In this case,
you should click No, continue as far as you can with the configuration, and
resume after you receive the certificate. The default is No.
Select Yes, only if you have the certificate ready in its base-64 encoded
format.
Click Next to continue.
❍
❍
If you selected Yes, the “Location of Certificate” screen appears (Step 17).
If you selected No, you will be presented with the “Create Single Signon
Password” screen (Step 20).
17. Location of Certificate. Specify the location of the certificate. You can use one
of these options:
❍
❍
If you copied the encoded certificate to a file, select the “The certificate is
located in this file” option and type the file path, including the filename, in
the text field.
If you copied the certificate to the clipboard, select the “The certificate is
located in the text area below” option and then paste in a base-64 encoded
certificate (including the header and footer) in the text area provided.
Chapter
6
Installing Certificate Management System
275
Stage 2. Running the Installation Wizard
❍
If you know the request ID of your request and the host name and
end-entity port number of the Certificate Manager that issued the SSL
server certificate, select the “The certificate is at the CMS server where the
request was sent” option and then specify the required details.
Click Next to continue.
18. Certificate Details. This is an informational screen that displays the certificate
so you can inspect its contents. Notice the nickname assigned to the certificate
and verify that you’re installing the correct certificate.
Click Next to continue.
19. Import Certificate Chain. This screen appears only if you need to import the
CA certificate chain. Follow these steps to import the CA chain of a Certificate
Manager:
a.
Go to the web browser window.
b.
Enter the end-entity URL for the Certificate Manager that issued the SSL
server certificate.
c.
Select the Retrieval tab, and then choose Import CA Certificate Chain.
d.
Select the “Display the CA certificate chain in PKCS#7 for importing into a
server” option, and then click Submit.
e.
Copy the certificate chain to the clipboard.
f.
Return to the Installation Wizard.
g.
Paste the certificate chain into the text box.
h.
Click Next to continue.
20. Create Single Signon Password. Type the single signon password. The single
signon password simplifies the way you subsequently sign on to Certificate
Management System by storing the passwords for the internal database,
tokens, and so on. Each time you log on, you’re only required to enter this
single password. (For details, see “Required Start-up Information” on
page 316.)
Click Next to continue.
21. Configuration Status. This screen should indicate that your configuration has
been successful and that you need to create an agent for the Online Certificate
Status Manager.
Click Done to exit the Installation Wizard.
276
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 3. Enrolling for Administrator/Agent Certificate
22. Proceed to the next step, “Stage 3. Enrolling for Administrator/Agent
Certificate” on page 277, to create an agent user for the Online Certificate Status
Manager.
Stage 3. Enrolling for Administrator/Agent
Certificate
Immediately after installing any CMS instance, the administrator must enroll for
the initial administrator/agent certificate. This is the first user (agent) certificate
that Certificate Management System issues.
The initial user is both an administrator and an agent. This person can create
additional agents with the appropriate user privileges and issue them certificates.
Since there is no agent yet to approve the request, a special enrollment form allows
you to get this first certificate automatically.
Follow the appropriate procedure for the subsystem you installed:
•
Agent Certificate for a Certificate Manager
•
Agent Certificate for Other CMS Managers
For more information about setting up and managing agents, see “Agents” on
page 391.
Agent Certificate for a Certificate Manager
If the CMS instance you installed contains a Certificate Manager, a special
enrollment form, Administrator/Agent Certificate Enrollment Form, allows you to
get this first certificate automatically. After you submit this initial form, it is
automatically disabled, so that no one else can acquire a certificate without agent
approval or some form of automated authentication. The system automatically
adds the initial user to the list of agents.
To enroll for the first agent certificate, you should be working at the computer you
intend to use as the agent, so that the new certificate will be installed in the browser
you will be using to access the Agent Services pages. Follow these steps:
1.
Open a web browser window.
Chapter
6
Installing Certificate Management System
277
Stage 3. Enrolling for Administrator/Agent Certificate
2.
Go to the URL for the SSL agent port.
By default, this is a URL of the following form:
https://<hostname>:<agent_port>
❍
❍
For <hostname>, provide the fully qualified name of the machine on which
Certificate Management System is installed; for example,
CAmachine.siroe.com.
The <agent_port> is the TCP port specified during installation for agent
communications over SSL.
The first time you access this port, the system opens the Administrator/Agent
Certificate Enrollment form.
Because you have accessed an SSL port, Certificate Management System
presents its server SSL certificate to your browser for authentication. This is the
server SSL certificate that you created during installation. Because you just
created it, it is not on your browser’s list of trusted certificates. Before you see
the Administrator/Agent Certificate Enrollment form, a series of dialog boxes
appears that lets you add the CMS server certificate to your list of trusted
certificates.
3.
Complete the dialog boxes as instructed (the exact procedure depends on the
browser you are using).
4.
In the Administrator/Agent Certificate Enrollment form, enroll for a client SSL
certificate as the system’s first privileged user by entering the following
information:
Authentication Information
User ID. Type the ID you entered for the CMS administrator during
installation.
Password. Type the password you specified for the CMS administrator
during installation.
Subject Name
The subject name is the distinguished name (DN) that identifies the certified
owner of the certificate.
Full name. Type the name of administrator/agent.
Login name. Type the user ID of administrator/agent.
Email address. Type the email address of administrator/agent.
278
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 3. Enrolling for Administrator/Agent Certificate
Organization unit. Type the name of the organization unit to which the
administrator/agent belongs.
Organization. Type the name of the company or organization the
administrator/agent works for.
Country. Type the two-letter code for the administrator/agent’s country.
User’s Key Length Information
Key Length. Type the length of the private key that will be generated by
your browser. This key corresponds to the public key that is part of the
administrator/agent certificate.
Note that the validity period of this initial agent certificate is hard-coded as one
year.
5.
Click Submit.
6.
Follow the instructions your browser presents as it generates a key pair.
7.
If authentication is successful, the new certificate will be imported into your
browser, and you will be given an opportunity to make a backup copy.
Now you have a client authentication certificate in the name you specified. This
special user, who was named as the initial administrator for Certificate
Management System during installation, has been automatically designated as the
first agent. This certificate allows you to access the Agent Services pages. As an
agent, you can approve enrollment requests and start issuing new certificates. To
access the CMS windows in Netscape Console, you use the user ID that you
specified for the certificate and the corresponding password—both of which must
correspond to the values you specified for the CMS administrator during
installation.
Important
After you submit the initial Administrative Enrollment form, it is no longer
available from the agent port. If something goes wrong and you are unable to
obtain the administrator/agent certificate, you must reset a parameter in the
configuration file to make the initial administrative enrollment form available
again. Here’s how you can do this:
1.
In the left frame of Netscape Console, open the CMS instance for which you
want to display the Administrator/Agent Certificate Enrollment form.
The server requests the password for the CMS administrator.
2.
Click the icon labeled “Stop the Server.”
3.
Go to this directory: <server_root>/cert-<instance_id>/config
Chapter
6
Installing Certificate Management System
279
Stage 3. Enrolling for Administrator/Agent Certificate
4.
Open the configuration file (CMS.cfg) in a text editor.
5.
Locate the following line: agentGateway.enableAdminEnroll=false
6.
Change false to true, and save the file.
7.
Start the server from the CMS window where you stopped it. (Alternatively,
right-click on the name of the instance in the left frame and choose Start
Server.) At this point, the server asks you for the single signon password you
specified during installation.
8.
The next time you access the SSL agent port, the Administrator/Agent
Certificate Enrollment form will be available again.
Agent Certificate for Other CMS Managers
If the CMS instance you installed doesn’t include a Certificate Manager—for
example, if it’s a standalone Registration Manager, Data Recovery Manager, or
Online Certificate Status Manager—you need to manually submit a client
certificate request to the CA and then install the certificate in the certificate
database of the CMS instance. Alternatively, if you have agent privileges to any of
the CMS managers, for example to a Certificate Manager, you can use the same
agent certificate for performing agent tasks of another CMS manager. This you can
do by storing a copy of the agent’s SSL client certificate in the internal database of
the newly-installed CMS manager.
The instructions below assume that you already have a client certificate for a
Certificate Manager (whether the original administrator/agent certificate or a new
agent certificate) and want to use the same certificate for agent operations of
another CMS manager.
280
1.
Make sure the Certificate Manager is started.
2.
Open a web browser window.
3.
Go to the end-entity interface of the Certificate Manager that issued the
certificate you want to use.
4.
Select the Retrieval tab
5.
Click List Certificates or Search for Certificates and locate the certificate (check
the subject name of the certificate).
6.
Copy the certificate in its base-64 encoded format (or keep the browser
window open so that you can copy the certificate later in this procedure).
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 3. Enrolling for Administrator/Agent Certificate
7.
Log in to Netscape Console (see “Logging In to Netscape Console” on
page 340).
8.
In the navigation tree, locate the CMS instance for which you want to create the
agent user, and double-click the icon.
The login screen for the CMS window appears.
9.
Enter your administrator ID and password.
The CMS window for the subsystem opens.
10. In the navigation tree, select Users and Groups.
The Users tab appears.
11. Select the user ID for the administrator, the one created during installation, and
click Certificates.
The Manage User Certificates window appears.
Chapter
6
Installing Certificate Management System
281
Stage 3. Enrolling for Administrator/Agent Certificate
12. Click Import.
The Import Certificate window appears.
13. Click inside the text area, and paste the agent’s certificate in base-64 encoded
form. (If you haven’t copied the certificate, go back to the browser window,
copy the certificate, and then paste the certificate here.)
Be sure to include the -----BEGIN CERTIFICATE----- and -----END
CERTIFICATE----- marker lines.
14. Click OK.
You are returned to the Manage User Certificates window. The certificate you
imported should now be listed in this window.
282
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stage 4. Further Configuration Options
15. To view the certificate you imported, select it and click View.
The certificate information appears.
16. Click Done.
You are returned to the Users tab.
17. Click Refresh to view the updated configuration.
You have now designated an agent for the specified manager. You can now
present the certificate you installed for that agent to access the Agent Services
pages for that manager in the new instance.
For more information about setting up and managing agents, see “Agents” on
page 391.
Stage 4. Further Configuration Options
When you have completed the initial configuration and installation of a CMS
instance, you use the CMS window for that instance within Netscape Console to
further configure the system as necessary. For example, you may want to configure
LDAP publishing, authentication modules, and policy modules, and customize
end-entity forms and other aspects of the system’s operation. If you installed a
Data Recovery Manager, you may want to configure your Certificate Manager or
Registration Manager to archive end users’ encryption private keys with the Data
Recovery Manager.
Chapter
6
Installing Certificate Management System
283
Stage 5. Creating Additional Instances or CA Clones
For detailed information about the many CMS configuration options available,
check the chapters in Part 3, “Configuration.” You might find it useful to read
“Road Map to Configuring Subsystems” on page 370.
Stage 5. Creating Additional Instances or CA
Clones
After the initial installation, you can use Netscape Console to create additional
instances of Certificate Management System in the same server root directory. Once
you have a new instance, you can use the Installation Wizard and CMS window to
configure any new instances.
284
•
For instructions to create an additional instance of Certificate Management
System, see “Installing Multiple CMS Instances” on page 286.
•
For instructions to clone a Certificate Manager (CA), see “Cloning a Certificate
Manager” on page 288.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Chapter
7
Installing and Uninstalling CMS
Instances
After the initial installation of iPlanet Certificate Management System (CMS), you
may need to install additional instances, remove unwanted instances, or duplicate
configuration in multiple instances. This chapter describes how to manage these
tasks by using Netscape Console, the single, unified administration interface for
your network.
You can use Netscape Console only when Netscape Administration Server is
running. During CMS installation, you specified a port number for the
Administration Server instance you will use to administer Certificate Management
System. If Administration Server is shut down, be sure to start it at this port. To
minimize security risks, shut down the Administration Server when you have
finished using Netscape Console. For more information about Netscape Console,
see , “Administration Tasks and Tools.”
The chapter has the following sections:
•
Installing Multiple CMS Instances (page 286)
•
Cloning a Certificate Manager (page 288)
•
Viewing Instance Information (page 305)
•
Changing the Name of an Instance (page 307)
•
Removing an Instance From a System (page 308)
•
Uninstalling Certificate Management System (page 310)
•
Upgrading From a Previous CMS Installation (page 312)
285
Installing Multiple CMS Instances
Installing Multiple CMS Instances
Multiple instances of Certificate Management System can run on the same
machine. You might, for example, install multiple Registration Managers, all
reporting to the same Certificate Manager, to handle requests from different types
of users (end users, servers, and routers) or from users from different domains. For
example deployment scenarios, see Chapter 4, “Planning Your Deployment.”
Once Certificate Management System is installed on a machine, you can use that
CMS installation to create multiple instances of the server on the same machine.
Administration Server contains all the files necessary to install another instance of
Certificate Management System on the same machine; you don’t have to run the
complete installation (setup) program again. However, you do need to run the
CMS installation wizard each time you create an instance, so that you can
configure the server and generate the required certificates. So, before attempting to
create another instance of Certificate Management System, be sure to read about
the installation wizard explained in Chapter 6, “Installing Certificate Management
System.”
When you install additional CMS instances on the same machine, you are required
to specify different ports for each CMS instance to listen on. For example, you will
have to set up one server to listen on port 443 and another server to listen on port
4430. However, if you install multiple CMS instances on a machine that has been
set up with more than one IP addresses, you can configure each instance to listen to
a specific IP address—this enables you to use same the port numbers for different
CMS instances installed on the same machine.
Keep in mind that when you create a new instance, you’ll be required to specify
different port numbers; the installation wizard allows you to specify the port
numbers only, not IP addresses. After you have successfully created the instance,
you can edit the CMS configuration file to specify the IP addresses for individual
CMS ports and then change the port numbers. For details on editing the
configuration file to include the IP addresses, see “Step 2: Specify IP Addresses” on
page 381. For details on changing the port numbers, see “Configuring Port
Numbers” on page 378.
To create another instance of Certificate Management System with a separate
configuration file (and certificates):
286
1.
Log in to Netscape Console (see “Logging In to Netscape Console” on
page 340).
2.
In the navigation tree at the left, expand the icon for your computer, then select
the server group that contains the CMS instance you want to use as your
source.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Installing Multiple CMS Instances
3.
From the Object menu, choose the Create Instance Of option and, in the pop-up
menu that appears, choose Certificate Management System.
As shown in this figure, you can also right-click to choose this option from the
pop-up menu.
The Create Server Instance dialog box appears.
4.
Type a unique name or identifier for the new instance.
For the name, you can use any combination of letters (aA to zZ), digits (0 to 9),
an underscore (_), and a hyphen (-); other characters and spaces are not
allowed. For example, you can type Siroe_root-CA as the instance name, but
not Siroe root CA.
5.
Click OK.
The instance you created appears in the navigation tree. Note that the instance
name appears in the CMS (cert-<instance_id>) form, where <instance_id>
is the name you specified for the new CMS instance. For example, if you
named the instance Marketing_CA, the instance name in the navigation tree
will be CMS (cert-Marketing_CA).
Chapter 7
Installing and Uninstalling CMS Instances
287
Cloning a Certificate Manager
6.
To start the installation wizard, double-click the new instance in the navigation
tree, and then use the installation wizard to finish configuring the new
instance.
7.
Create the first agent for the new CMS instance.
When you have finished setting up an additional CMS instance, you need to
create at least one agent for that instance. If the new instance includes a
Certificate Manager, you can create the administrator/agent as described in
“Agent Certificate for a Certificate Manager” on page 277 as you did for the
first instance in the server root. If the new instance does not include a
Certificate Manager—that is, if it contains a Registration Manager, Data
Recovery Manager, Online Certificate Status Manager, Registration Manager
and Data Recovery Manager, or Online Certificate Status Manager and Data
Recovery Manager—you will need to use the CMS window to create a new
agent. This is described in section “Agent Certificate for Other CMS Managers”
on page 280.
Cloning a Certificate Manager
Cloning a Certificate Manager refers to the process of creating two server processes
performing the same CA functions: you create another instance of a Certificate
Manager and configure it to use the same CA signing key and certificate and issue
certificates with serial numbers that do not conflict or overlap with the serial
numbers of the Certificate Manager that’s being cloned or with the serial numbers
of any other clones. The Certificate Manager that’s being cloned is called the master
Certificate Manager or master CA in this document.
You can use the cloning feature for CA scalability and for setting up a PKI with
CAs organized in a flat structure as opposed to a hierarchical structure. For
example, if you don’t want your PKI to be a CA hierarchy comprising root and
subordinate CAs, you can create multiple clones of a Certificate Manager and
configure each clone to issue certificates that fall within a distinct range of serial
numbers. Because clone CAs use the same CA signing key and certificate (as that of
the master CA) to sign the certificates they issue, the issuer name in all the
certificates in your PKI setup would be the same, as if they’ve been issued by a
single CA.
The other advantage of cloning is that when you setup a clone Certificate Manager,
it automatically sends the revocation status of the certificates it has issued to the
master Certificate Manager. The clone Certificate Manager uses the master
Certificate Manager’s agent port to communicate this information; the
288
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Cloning a Certificate Manager
communication is SSL-client authenticated. This way, the master Certificate
Manager has the complete list of certificates revoked by all clone Certificate
Managers and is able to generate a consolidated list of revoked certificates or a
complete CRL.
Because the master Certificate Manager has the complete CRL, if you enable the
OCSP-service feature built into the Certificate Manager, it can function as a
full-fledged OCSP responder for your PKI—that is, irrespective of which clone
Certificate Manager has issued the certificate, OCSP-compliant clients can directly
query the master Certificate Manager for the revocation status of a certificate. (For
information on enabling a Certificate Manager’s OCSP service, see “Setting Up a
Certificate Manager with OCSP Service” on page 699.) So, CAs organized in a flat
structure using the cloning method eliminate the need for you to install the
standalone OCSP responder, the Online Certificate Status Manager, and configure
each Certificate Manager to publish its CRL to the Online Certificate Status
Manager.
To setup a clone a Certificate Manager (or a CA), follow these steps:
•
Step 1. Before You Begin
•
Step 2. Create Instances for Clone CAs
•
Step 3. Shutdown the Master CA
•
Step 4. Copy Master CA’s Certificate and Key Database
•
Step 5. Start the Master CA
•
Step 6. Configure the Clone CA
•
Step 8. Establish Trust Between Master CA and Clone CAs
•
Step 9. Test Clone-Master Connection
•
Step 10. Use Master CA’s Agent Certificate in Clone CAs
Step 1. Before You Begin
Before you start cloning a Certificate Manager:
•
Verify that the master Certificate Manager is installed and configured
properly, and is started.
Chapter 7
Installing and Uninstalling CMS Instances
289
Cloning a Certificate Manager
•
Check the master Certificate Manager’s serial number range. The “Next serial
number” field should be set to the next serial number of the certificate the CA
will issue and the “Last serial number” field must be blank. To locate the panel
that enables you to do this, see “Enabling End-Entity Interaction with a
Certificate Manager” on page 543.
•
If the master Certificate Manager’s keys and certificates are stored in a
hardware token, check the token vendor’s documentation for copying the keys
and certificates (from the original token to a new token accessible to the clone
Certificate Manager). Keep the relevant instructions handy.
•
Decide how many clone CAs you need to deploy, and note the following for
each clone CA.
❍
CA’s serial number range—Each clone Certificate Manager must be
configured to issue certificates with unique serial numbers. Which means,
when you configure a clone Certificate Manager, you must specify upper
and lower bounds for the serial numbers and make sure that the
serial-number range does not overlap with the one specified for another
clone Certificate Manager.
When specifying the serial number range for the first clone Certificate
Manager, it’s recommended that you start with, say, 0x100, as the
starting/lowest serial number. This will ensure that the master Certificate
Manager has sufficient serial numbers for its own certificates, such as the
CA signing certificate, SSL server certificate, agent’s certificate, and so on.
The master Certificate Manager will also need distinct serial numbers in
the future, for example, when you renew its certificates in the future. Any
subsequent clone Certificate Manager does not need to make such a
provision; its serial numbers only need to not overlap with the ones
assigned to the previous clones.
❍
❍
290
CA’s signing key and certificate—You must use the master Certificate
Manager’s signing key and certificate. If you do not use the master
Certificate Manager’s key and certificate databases, the clone Certificate
Manager will need to generate a new signing key and certificate;
consequently, it will not be a clone.
CA’s SSL server key and certificate—This depends on the hostname of the
clone Certificate Manager. If the clone Certificate Manager uses the same
hostname as that of the master Certificate Manager, you can use the same
SSL server certificate and key copied from the master Certificate Manager.
If the hostnames are different, you must generate a new SSL server
certificate for the clone Certificate Manager; the SSL server certificate DN
contains the hostname as the common name (CN) attribute, so a clone with
a different hostname must enroll for a new SSL server certificate.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Cloning a Certificate Manager
During the cloning process, the master Certificate Manager’s SSL server
certificate is automatically copied to the certificate database of the clone
Certificate Manager. The clone Certificate Manager uses this certificate for
SSL-client-authenticated communication with the master Certificate
Manager. Don’t be alarmed when you see the certificate in clone Certificate
Managers’ certificate databases. Also, be sure not to remove them from the
master and clone Certificate Managers’ databases.
If you want to note the details such as the serial numbers and ports used by the
clone CAs, use the section “Cloned Certificate Manager Configuration” in
Chapter 5, “Installation Worksheet.”
Step 2. Create Instances for Clone CAs
Depending on how many clone CAs you want to deploy, follow the appropriate
instructions in this step to create that many CMS instances.
Depending on your master Certificate Manager’s installation, there are three
possible scenarios to install a clone Certificate Manager:
•
Installing Clone CA in Master CA’s Server Group—In this case, you install the
clone Certificate Manager in the same server group in which the master
Certificate Manager is installed.
•
Installing Clone CA in a Different Server Group—In this case, you install the
clone Certificate Manager on the same host on which the master Certificate
Manager is installed, but in a different server group.
•
Installing Clone CA on a Separate Host—In this case, you install the clone
Certificate Manager on a different host than the one on which the master
Certificate Manager is installed.
Installing Clone CA in Master CA’s Server Group
If you want to install your clone Certificate Manager in the same server group as
that of the Certificate Manager:
1.
Log in to Netscape Console of the master Certificate Manager (see “Logging In
to Netscape Console” on page 340).
2.
In the navigation tree at the left, expand the icon for your computer, then select
the server group that contains the CMS instance you want to use as your
master.
Chapter 7
Installing and Uninstalling CMS Instances
291
Cloning a Certificate Manager
3.
From the Object menu, choose the Create Instance Of option and, in the pop-up
menu that appears, choose Certificate Management System.
As shown in this figure, you can also right-click to choose this option from the
pop-up menu.
The Create Server Instance dialog box appears.
4.
Type a unique name or identifier for the new instance.
For the name, you can use any combination of letters (aA to zZ), digits (0 to 9),
an underscore (_), and a hyphen (-); other characters and spaces are not
allowed. For example, you can type Clone1_of_root-CA as the instance name,
but not Clone1 of root-CA.
5.
Click OK.
The instance you created appears in the navigation tree. Note that the instance
name appears in the CMS (cert-<instance_id>) form, where <instance_id>
is the name you specified for the new CMS instance. For example, if you
named the instance Clone1_of_root-CA, the instance name in the navigation
tree will be CMS (cert-Clone1_of_root-CA).
Installing Clone CA in a Different Server Group
In a Windows NT installation of Certificate Management System, you cannot create
more than one server group. In a Unix installation, you can create multiple server
groups. For more information, see section “The Administration Server” of
Managing Servers with Netscape Console.
292
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Cloning a Certificate Manager
If you want to install your clone Certificate Manager on the same host on which the
master Certificate Manager is installed, but in a different server group:
1.
In the master Certificate Manager host machine, go to the directory that
contains the CMS setup program.
2.
Run the setup program. For instructions, see “Stage 1. Running the Installation
Script” on page 221. Be sure to follow these guidelines:
❍
❍
❍
When prompted to chose a server root or the location for the installation,
specify a different directory/folder (than the one where the master
Certificate Manager is installed). For example, if your master Certificate
Manager is installed at /u/netscape/server4, you can specify
/u/netscape/server4_clone1 as the server root for the clone instance.
When prompted to specify a configuration directory, select the option for an
existing directory and specify the host name and port number of the
Directory Server instance used by the master Certificate Manager.
When prompted to specify a port number for the Administration Server,
be sure to specify distinct port number; each server group is managed by a
separate Administration Server. Note the port number as you will need
this later to log in to Netscape Console.
Installing Clone CA on a Separate Host
If you want to install your clone Certificate Manager on a different host than the
one on which the master Certificate Manager is installed, you should run the CMS
setup program on that host. For instructions, see “Stage 1. Running the Installation
Script” on page 221. (Note that you only need to complete Stage 1 and then proceed
to “Step 3. Shutdown the Master CA” below.)
Step 3. Shutdown the Master CA
Stop the master Certificate Manager. If you need instructions, see “Stopping
Certificate Management System” on page 324.
Chapter 7
Installing and Uninstalling CMS Instances
293
Cloning a Certificate Manager
Step 4. Copy Master CA’s Certificate and Key
Database
Because you want the clone Certificate Manager to own the same keys and
certificates as that of the master Certificate Manager, you need to make available
the keys and certificates used by the master Certificate Manager to each clone
Certificate Manager.
•
If the master Certificate Manager’s keys and certificates are stored in the
internal/software token, you need to copy the key3.db and cert7.db files
from the config directory of the master Certificate Manager to the config
directory of each clone Certificate Manager. Here’s how you do this:
a.
In the master Certificate Manager’s host machine, go to this directory:
<server_root>/cert-<instance_id>/config
b.
Locate files named cert7.db and key3.db.
c.
In the clone Certificate Manager’s host machine, go to this directory:
<server_root>/cert-<instance_id>/config
•
d.
Copy the cert7.db and key3.db files from master Certificate Manager to
the clone.
e.
Repeat steps c and d to copy the master Certificate Manager’s key3.db and
cert7.db files to the config directory of each clone Certificate Manager.
If the master Certificate Manager’s keys and certificates are stored in the
hardware token, you need to copy the keys and certificates following the
instructions provided by the hardware-token vendor.
Step 5. Start the Master CA
Start the master Certificate Manager. If you need instructions, see “Starting
Certificate Management System” on page 316.
Step 6. Configure the Clone CA
Depending on how many CMS instances you’ve created for clone Certificate
Managers, you should repeat the instructions in this step to configure each clone
Certificate Manager.
294
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Cloning a Certificate Manager
To configure a clone Certificate Manager:
1.
Log in to or go to Netscape Console that shows the clone Certificate Manager
instance.
2.
In the navigation tree, locate the instance ID for the clone you created, and
double-click the instance.
The CMS Installation Wizard starts.
3.
Follow the on-screen instructions to finish configuring the clone CA. During
configuration, be sure to follow these:
❍
❍
❍
4.
Clone key and certificate materials—On this screen, click Yes to reuse the
certificate and key material in the database files you copied from the
master Certificate Manager. In the Instance Name field enter the instance
ID of the master Certificate Manager. Select the token name where the keys
and certificate are stored and enter the token’s password, if required.
Clone key and certificate materials—On this screen, you choose whether
to reuse the master Certificate Manager’s SSL server certificate or create a
new one. If you created the clone Certificate Manager on the same host as
the master Certificate Manager, you can reuse the SSL server certificate. To
reuse the SSL server certificate, select Yes, enter the instance ID of the
master Certificate Manager, select a token, and enter the token password.
If you do not or cannot reuse the SSL server certificate, select No and
follow the screens that enable you to generate a new SSL server certificate.
CA’s serial number range—On this screen, specify the lowest serial
number the CA should assign to certificates it creates in the “Starting serial
number” field. In the “Ending serial number” field, specify the highest
serial number available for this CA. For both the fields, you can enter the
number in decimal or hexadecimal (0xnn).
Repeat steps 1 through 3 for each clone Certificate Manager.
Step 8. Establish Trust Between Master CA and
Clone CAs
For the master Certificate Manager to trust the clone Certificate Manager, you
associate the clone Certificate Manager as a trusted manager to the master Certificate
Manager. For details about trusted managers, see “Trusted Managers” on page 398.
Chapter 7
Installing and Uninstalling CMS Instances
295
Cloning a Certificate Manager
The setup process involves the following steps:
•
Step A. Locate the Master CA’s SSL Server Certificate
•
Step B. Create a Privileged-User Entry for Clone CAs
Step A. Locate the Master CA’s SSL Server Certificate
Depending on which CA issued/signed the master Certificate Manager’s SSL
server certificate, you can locate the certificate in either the internal database or the
certificate database (cert7.db file).
•
If the issuer of the SSL server certificate is the master Certificate Manager itself,
you can locate the certificate in the internal database by going to the Retrieval
tab of the master Certificate Manager’s end-entity interface.
•
If the issuer of the SSL server certificate is another CA, for example, a
third-party CA, you can locate the certificate in the certificate database by
using the certutil command-line tool. For more information about this tool,
see Chapter 11 , “Certificate Database Tool” of CMS Command-Line Tools Guide.
Follow the instructions that’s appropriate for you.
To locate the certificate in the Retrieval tab of the end-entity interface:
1.
Open web browser window.
2.
Go the master Certificate Manager’s end-entity interface. The URL is in
https://<hostname>:<SSL_port> or http://<hostname>:<port> format.
3.
Select the Retrieval tab, and in the left frame, click List Certificates.
4.
In the resulting form, click List.
A list of certificates appear.
5.
Locate the Certificate Manager’s SSL server certificate by looking at the subject
name of the certificate.
Typically, the SSL server certificate would be the second certificate.
296
6.
Click Details.
7.
In the resulting page, scroll to the section that says “Base 64 encoded
certificate” and shows the certificate in its base-64 encoded format.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Cloning a Certificate Manager
8.
Copy the base-64 encoded certificate, including the -----BEGIN
CERTIFICATE----- and -----END CERTIFICATE----- marker lines, to the
clipboard or a text file. (Alternatively, you can keep the browser window open
and copy the certificate later in the procedure.)
The copied information should look similar to the following example:
-----BEGIN CERTIFICATE----MIICJzCCAZCgAwIBAgIBAzANBgkqhkiG9w0BAQQFADBCMSAwHgYDVQQKExdOZXRzY2FwZSBDb21tdW5pYF
0aW9uczngjhnMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyNzE5MDAwMFoXDTk5MDIyMzE5MDAw
MnbjdgngYoxIDAeBgNVBAoTF05ldHNjYXBlIENvbW11bmljYXRpb25zMQ8wDQYDVQQLEwZQZW9wbGUxFzA
VBgoJkiaJkIsZAEBEwdzdXByaXlhMRcwFQYDVQQDEw5TdXByaXlhIFNoZXR0eTEjMCEGCSqGSIb3DbndgJ
ARYUc3Vwcml5YUBuZXRzY2FwZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBIAkEAoYiYgthgtbbnjfngjn
jgnagwJjAOBgNVHQ8BAf8EBAMCBLAwFAYJYIZIAYb4QgEBAQHBAQDAgCAMA0GCSqGSIb3DQEBBAUAA4GBA
Fi9FzyJlLmS+kzsue0kTXawbwamGdYql2w4hIBgdR+jWeLmD4CP4xzmKdvQ6IqD2q8DBs9lRQu9
-----END CERTIFICATE-----
To locate the SSL server certificate in the master Certificate Manager’s certificate
database using the certutil tool:
1.
Open a terminal window in the system that hosts the master Certificate
Manager.
2.
Go to this directory: <server_root>/cert-<instance_id>/config
3.
Next, run this command:
<server_root>/bin/cert/tools/certutil -L -d <certdir>
-n <certname> cert-<instance_id> -a
replacing <certdir> with the directory containing a certificate database file,
<certname> with the nickname of the SSL server certificate, and
<instance_id> with the ID assigned to the master Certificate Manager
instance.
For example, your command might look like this:
<server_root>/bin/cert/tools/certutil -L -d . -n Server-Cert
cert-masterCA -a
The SSL server certificate appears.
4.
View the certificate information. Make sure that the certificate you are looking
at is the correct one; the certificate shows the DN that was specified for the
certificate during the installation.
Chapter 7
Installing and Uninstalling CMS Instances
297
Cloning a Certificate Manager
5.
Copy the base-64 encoded certificate, including the marker lines -----BEGIN
CERTIFICATE----- and -----END CERTIFICATE-----, to the clipboard or to a
text file. The copied information should look like the example below:
-----BEGIN CERTIFICATE----MIICJzCCAZCgAwIBAgIBAzANBgkqhkiG9w0BAQQFADBCMSAwHgYDVQQKExdOZXRzY2FwZSBDb21tdW5pYF
0aW9uczngjhnMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyNzE5MDAwMFoXDTk5MDIyMzE5MDAw
MnbjdgngYoxIDAeBgNVBAoTF05ldHNjYXBlIENvbW11bmljYXRpb25zMQ8wDQYDVQQLEwZQZW9wbGUxFzA
VBgoJkiaJkIsZAEBEwdzdXByaXlhMRcwFQYDVQQDEw5TdXByaXlhIFNoZXR0eTEjMCEGCSqGSIb3DbndgJ
ARYUc3Vwcml5YUBuZXRzY2FwZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBIAkEAoYiYgthgtbbnjfngjn
jgnagwJjAOBgNVHQ8BAf8EBAMCBLAwFAYJYIZIAYb4QgEBAQHBAQDAgCAMA0GCSqGSIb3DQEBBAUAA4GBA
Fi9FzyJlLmS+kzsue0kTXawbwamGdYql2w4hIBgdR+jWeLmD4CP4xzmKdvQ6IqD2q8DBs9lRQu9JYg129o
-----END CERTIFICATE-----
Step B. Create a Privileged-User Entry for Clone CAs
In this step, you create a privileged-user entry for all clone Certificate Managers in
the internal database of the master Certificate Manager. As a part of creating this
entry, you also add the new user entry to the Trusted Managers group in order to
give the entry access privileges to the agent port of the master Certificate Manager.
To create a user entry with appropriate access privileges:
1.
Log in to or go to the CMS window for the master Certificate Manager (see
“Logging In to the CMS Window” on page 347).
2.
In the navigation tree, select Users and Groups.
The Users tab appears in the right pane.
298
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Cloning a Certificate Manager
3.
Click Add.
The Select User Type window appears.
4.
Select Trusted Manager and click OK.
The Edit User Information window appears.
5.
Specify information as appropriate.
The information you enter here is to help you keep track of the clone Certificate
Managers. The master Certificate Manager relies solely on its SSL server
certificate (which you will add in Step 3) for authentication.
User ID. Type an ID that will help you identify this user in the list of privileged
users. The ID can be an alphanumeric string of up to 255 characters.
Description. Type a description to identify that the user entry is for the clone
Certificate Managers. The description can be an alphanumeric string of up to
255 characters.
Group. Select Trusted Managers. For more information about this group, see
“Group for Trusted Managers” on page 406.
Chapter 7
Installing and Uninstalling CMS Instances
299
Cloning a Certificate Manager
6.
Click OK.
You are returned to the Users tab. The user you just added is displayed in the
list of users.
7.
Select the user entry you just added for the clone Certificate Managers and
click Certificates.
The Manage User Certificates window appears.
8.
Click Import.
The Import Certificate window appears.
9.
Click inside the text area, and paste the master Certificate Manager’s SSL
server certificate in its base-64 encoded form.
Be sure to include the -----BEGIN CERTIFICATE----- and -----END
CERTIFICATE----- marker lines.
10. Click OK.
You are returned to the Manage User Certificates window. The certificate you
imported should now be listed in this window.
300
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Cloning a Certificate Manager
11. To view the certificate you imported, select it and click View.
The certificate information appears. Verify that the certificate you added is the
correct one.
12. Click Done.
You are returned to the Users tab.
13. Click Refresh.
Step 9. Test Clone-Master Connection
To test whether your clone-master CA setup is complete and functional, repeat
these steps for each clone Certificate Manager.
•
Step A. Request a Certificate from the Clone CA
•
Step B. Approve the Request
•
Step C. Download the Certificate to the Browser
•
Step D. Revoke the Certificate
•
Step E. Check Master CA’s CRL for the Revoked Certificate
Step A. Request a Certificate from the Clone CA
The steps outlined below explain how to request a client certificate from the clone
Certificate Manager using the manual enrollment method. If you’ve configured the
clone Certificate Manager for automated certificate issuance, for example for
directory-based enrollment, you may use the appropriate form and request a
certificate.
To request a client or personal certificate from the clone Certificate Manager:
1.
Open a web browser window.
2.
Go to the end-entity interface of the Certificate Manager you configured (or to
the Registration Manager that’s connected to this Certificate Manager).
The URL is in this form: https://<hostname>:<end_entity_HTTPS_port> or
http://<hostname>:<end_entity_HTTP_port>
3.
In the left frame, under Browser, click Manual.
This opens the manual enrollment form.
Chapter 7
Installing and Uninstalling CMS Instances
301
Cloning a Certificate Manager
4.
Fill in all the values and submit the request.
The client prompts you to enter the password for your key database.
5.
When you enter the correct password, the client generates the key pairs.
Do not interrupt the key-generation process.
Step B. Approve the Request
Skip this step if you requested the certificate using any of the automated
enrollment methods. Complete this step if you used the manual enrollment form
for requesting the certificate; the request you submitted is waiting in the agent
queue for approval by an agent.
To approve the request:
1.
Go to the clone Certificate Manager’s Agent Services interface.
The URL is in this format: https://<hostname>:<agent_port>
2.
In the left frame, click List Requests.
3.
In the form that appears, select the “Show pending requests” option and click
Find.
4.
In the list of pending requests, identify the request you submitted and click
Details.
5.
Check the request to make sure that it has all the required attributes of a client
certificate.
6.
Scroll to the bottom of the request form, and approve the request.
You should see a confirmation page indicating that the certificate has been
issued. If you’re using the same browser for requesting the certificate and for
agent operations, don’t close the page until after you complete the next step.
Step C. Download the Certificate to the Browser
If you’re using the same browser, to download the certificate into the certificate
database of the browser:
302
1.
In the confirmation page, scroll down to the section that says “Installing this
certificate in a client.”
2.
Check the certificate details for the required extensions.
3.
Follow the on-screen instructions and download the certificate to your
browser’s certificate database.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Cloning a Certificate Manager
If you’re using a different browser, to download the certificate:
1.
Go to the end-entity interface of the Certificate Manager that issued the
certificate.
2.
Select the Retrieval tab.
3.
Search for the certificate; it will be the last certificate.
4.
Click Details.
5.
Scroll to down to the section that enables you to download the certificate to the
browser, and download the certificate.
Step D. Revoke the Certificate
To revoke the certificate you issued:
1.
Go to the end-entity interface for the Certificate Manager.
2.
Select the Revocation tab.
3.
In the left frame, click User Certificate.
The User Certificate Revocation form appears.
4.
In the Revocation Reason section, select Unspecified and click Submit.
The browser shows the “Select a Certificate” dialog box and prompts you to
choose the certificate you want to revoke.
5.
Select the certificate you downloaded and click OK.
The clone Certificate Manager revokes the certificate, updates the certificate
status in its internal database, and sends details about the revoked certificate to
the master Certificate Manager.
Step E. Check Master CA’s CRL for the Revoked Certificate
To verify that the revoked certificate has been included in the master Certificate
Manager’s CRL:
1.
Go to the master Certificate Manager’s Agent Services interface.
The URL is in this format: https://<hostname>:<agent_port>
2.
In the left frame, click Update Certificate Revocation List.
Chapter 7
Installing and Uninstalling CMS Instances
303
Cloning a Certificate Manager
3.
In the form that appears, select the algorithm that you want to use to sign the
new CRL.
❍
❍
❍
MD5 with RSA generates a 128-bit message digest. Most existing software
applications that handle certificates support only MD5. This is the default
algorithm.
SHA-1 with RSA generates a 160-bit message digest. Before choosing
SHA-1 with RSA, make sure your applications support it. Netscape
Navigator 3.0 (or later) and Enterprise Server 2.01 (or later) support SHA-1.
SHA-1 with DSA generates a 160-bit message digest. Before choosing
SHA-1 with DSA, make sure your applications support it. Communicator
4.0 (or later) and Netscape server products with a version number greater
than 4.0 support it.
Before selecting an algorithm, make sure that Certificate Manager has the
algorithm enabled.
4.
Click Display to examine the CRL (before updating it).
The CRL appears in the browser window. In the list, look for the certificate
revoked by the clone Certificate Manager. If you don’t see the certificate, check
logs to resolve the problem.
5.
If you want to update the CRL with the latest certificate revocation
information, use the browser’s Back button to return to the previous page and
click Update.
Step 10. Use Master CA’s Agent Certificate in
Clone CAs
This step is optional.
The procedure below explains how to use the master Certificate Manager’s agent
certificate for a clone Certificate Manager (instead of creating a new agent
certificates for clone CAs).
1.
Go to the configuration directory of a cloned CA:
<server_root>/cert-<instance_id>config
304
2.
Open the configuration file (CMS.cfg) in a text editor.
3.
Locate this line: agentgateway.enableAdminEnroll=true
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Viewing Instance Information
4.
Change the value to false: agentgateway.enableAdminEnroll=false
This configures the cloned CA in to a mode where it expects a certificate (that
was already issued and chains properly) to be presented when you access its
agent interface.
5.
Restart the clone CA.
6.
Use Netscape Console and open the CMS window for the clone CA instance.
7.
Go to the “Users and Groups” section, create a new agent user, and add the
master CA’s agent certificate to the clone CA’s certificate database.
To add the correct certificate, check the serial number of the master CA’s agent
certificate; this certificate should already exist in one of the browsers that you
use to access the master CA’s agent interface. Use the serial number to search
for the certificate in the master CA’s certificate repository. Once you locate the
certificate, look for its base-64 encoded form, copy it, and then paste it as the
agent certificate in the clone CA.
For step-by-step instructions to create an agent user, see “Setting up Agents
Using the Manual Process” on page 411.
8.
After creating the agent entry for the clone CA, go to https://<cloneCA
hostname>:<agent_port> to verify that you can access its agent interface
successfully.
9.
Repeat the above steps for other clone CAs.
Viewing Instance Information
In Netscape Console, you can view some of the basic information—the name and
version number of the server, the directory in which it’s installed, and date it was
installed—about a CMS instance.
To view information pertaining to a specific CMS instance:
1.
Log in to Netscape Console (see “Logging In to Netscape Console” on
page 340).
2.
In the Console tab, double-click the server group that contains the CMS
instance you want to view.
Chapter 7
Installing and Uninstalling CMS Instances
305
Viewing Instance Information
3.
In the list of server instances, select the CMS instance you want to view.
The right pane shows information about the selected CMS instance.
The information displayed includes the following:
Server Name. A descriptive name of the CMS instance. You can change this
name; see “Changing the Name of an Instance” on page 307).
Description. Additional information that helps you identify the CMS instance.
You can change this description; see “Changing the Name of an Instance” on
page 307.
Installation Date. The date the server was installed.
Server Root. The directory that holds all the files for the selected CMS instance,
the files of its Administration Server, and the files of any other Netscape
servers in the same server group (that is, administered by that Administration
Server). A host typically has only one server root, but more than one is
possible, especially if different version numbers of the same server are installed
on a single host.
The default server root in Unix is usr/netscape/server4/ and in Windows
NT is C:\Netscape\Server4.
Product Name. The complete product name.
Vendor. The name of the vendor.
Version. The version number.
306
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Changing the Name of an Instance
Build Number. The number that identifies the build that was used for this
installation.
Security Level. The server’s security level—whether the server is meant for use
in the United States and Canada (domestic) or any other part of the world
(export). (See “Configuring the Server’s Security Preferences” on page 482.)
Server Status. The server’s status—whether it is started, stopped, or
unknown; normally, unknown indicates that the server hasn’t been configured
properly.
Changing the Name of an Instance
Following installation, the name of a CMS instance is in the form:
CMS (cert-<instance_id>)
<instance_id> is the ID for this instance of Certificate Management System.
You first specified this when you installed this server.
For example, if you installed an instance of Certificate Management System with
an ID of testCA, the instance name will be cert-testCA.
You can change the instance name to a more descriptive one later. If you change
the instance name, Certificate Management System uses the new name as a
descriptive nickname for the instance. It shows the new name in Netscape Console
only; it does not change the original instance ID in the configuration.
To change the name of a particular CMS instance:
1.
Log in to Netscape Console (see “Logging In to Netscape Console” on
page 340).
2.
In the Console tab, select the CMS instance you want to rename.
Chapter 7
Installing and Uninstalling CMS Instances
307
Removing an Instance From a System
3.
Click Edit.
Details about the selected CMS instance appear in the right pane.
Specify the appropriate information:
Server Name. Type a descriptive name for the server.
Description. Type any additional description for the server. For example, you
may want to type information that will help you identify this instance of
Certificate Management System.
4.
Click OK.
You are returned to the previous screen. The new name appears in the right
pane.
Removing an Instance From a System
If you are sure you won’t need a particular CMS instance anymore, you can use
Netscape Console to remove the server instance from your machine. Removing a
CMS instance is not the same as uninstalling Certificate Management System;
when you uninstall Certificate Management System, its program files are deleted
from the host machine. (For instructions, see “Uninstalling Certificate Management
System” on page 310.)
308
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Removing an Instance From a System
To remove a CMS instance from your machine:
1.
Log in to Netscape Console (see “Logging In to Netscape Console” on
page 340).
2.
In the Console tab, select the CMS instance you want to remove.
3.
From the Object menu, choose Stop; you can also right-click to choose this
option from the pop-up menu (see the figure below).
4.
When the server has stopped, from the Object menu, choose Remove Server.
As shown in the figure below, you can also right-click to choose this option
from the pop-up menu.
5.
When prompted, confirm that you want to remove the server instance.
The selected CMS instance is removed. The corresponding internal database is
not removed. If you want to remove it, select the instance, and repeat steps 3
through 5.
The Directory Server (configuration directory) and Administration Server
binaries are also not removed; you require these to administer the remaining
servers installed in the same server group.
Chapter 7
Installing and Uninstalling CMS Instances
309
Uninstalling Certificate Management System
Uninstalling Certificate Management System
To remove files pertaining to Certificate Management System from a host system,
run the uninstallation program. Uninstalling Certificate Management System
removes all the corresponding CMS instances from the navigation tree of Netscape
Console. To remove a specific CMS instance, follow the instructions provided in
“Removing an Instance From a System” on page 308.
You can uninstall Certificate Management System in two ways:
•
From the command line (locally only)
•
On a Windows NT system, by using the Windows NT Add/Remove Programs
Utility
Uninstalling From the Command Line
To uninstall Certificate Management System from the command line:
1.
Open a terminal window to your server.
2.
In a Unix system, log in either as root or using the server’s user account (if that
is how you started the server).
3.
At the command-line prompt, enter the following line:
On Windows NT, enter <server_root>\uninst.
On Unix, enter <server_root>/uninstall.
The uninstallation program starts.
Uninstalling by Using the Windows NT
Add/Remove Programs Utility
To remove Certificate Management System by using the Windows NT
Add/Remove Programs utility:
310
1.
From the Start menu, choose Settings, then Control Panel.
2.
In the Control Panel, choose Add/Remove Programs.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Uninstalling Certificate Management System
3.
In the Add/Remove Programs Properties window, choose Netscape Server
Products 4.2 <server_root>, and click Add/Remove.
4.
In the Netscape Server Uninstall window, make sure all the components are
selected, and click Uninstall.
The uninstallation program starts.
Chapter 7
Installing and Uninstalling CMS Instances
311
Upgrading From a Previous CMS Installation
Upgrading From a Previous CMS Installation
If you have an existing installation of Certificate Management System version 4.2,
you can upgrade to Certificate Management System 4.2, Service Pack 2 (SP2), by
installing CMS 4.2-SP2 into the same server root as that of CMS 4.2. When
prompted to specify the instance name, you must enter the name of the CMS
instance that you want to upgrade. If the specified CMS instance exists in the
selected server root, the installation program recognizes the instance and updates
the existing configuration automatically. Note that during installation, you must
specify the same port numbers that are in use by existing services, such as the
Administration Server port for Netscape Console. If you have multiple CMS
instances under the same server root, you must run the installation program for
each instance.
Note the following:
•
Prior to attempting any upgrade from CMS 4.2 to CMS 4.2-SP2, always
remember to shutdown all instances of the Console, as these clients are never
shutdown by the upgrade process, and therefore, may not be correctly
updated.
•
Only the CMS instance you specify in the upgrade panel is updated, although
all of the global files are restored upon updating each and every instance.
Therefore, you must perform the upgrade process for each and every CMS
instance individually.
•
All CMS instances are shutdown each time so that any global CMS information
may be updated.
•
Backup copies of the following list of original files and directories are saved
with an underscore and timestamp appended (for example, classes/ becomes
classes_20000506035603Z/) before the new file or directory replaces them:
- Instance Specific:
- classes/
- emails/
- restart-cert[.bat]
- start-cert[.bat]
- stop-cert[.bat]
- web/
(directory)
(directory)
(file)
(file)
(file)
(directory)
- Globally Specific: (backed up for each instance)
- bin/cert/classes/ (directory)
•
312
Since the start and restart scripts are always replaced on a per instance basis,
any changes you have made will be backed up, and you must manually edit
these scripts to put back your customizations.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Upgrading From a Previous CMS Installation
•
All CMS instances are restarted. During restart, you are prompted for the
single sign-on password, if automatic restart has not already been
configured/reconfigured ahead of time.
•
There should be no reason to configure an updated instance (by running the
CMS Installation Wizard), as there is on a first-time installation.
•
You may upgrade an instance numerous times to restore any corrupted global
binaries. However, backup copies of the files and directories detailed above
will be created upon each update.
•
Occasionally, upgrade does not allow you to specify the port number for the
console to be reused. It is okay to use a different port number for the console,
however, you must remember to use this new port number the next time that
you login to Netscape Console.
•
Since upgrades must be done on a per instance basis, if you have two instances,
and if you upgrade the first and then launch the console, you may notice that
the instance that has not been upgraded will be displayed out of alignment
within the GUI. You can consider this as a visual clue that you need to upgrade
this instance as well. After upgrading this, the instance will appear aligned
correctly within the GUI.
Follow the procedure below to upgrade a CMS instance:
1.
Identify the CMS 4.2 instance that you want to upgrade and note the
corresponding server root and instance ID.
2.
Prior to attempting any upgrade, shutdown all instances of the Console, as
these clients are never shutdown by the upgrade process, and therefore, may
not be correctly updated.
3.
Extract files from the CMS archive; you can get the archive from the product
CD or from the iPlanet download site (at http://www.iplanet.com).
4.
In the list of extracted files, locate this file: ns-certsrv4_2SP2.conf
5.
Go to the file structure of the CMS instance that you want upgrade, and
navigate to the configuration directory of the internal database (the Directory
Server instance used for storing CMS data):
<server_root>/slapd-<cms_instance_id>-db/config
6.
Copy the ns-certsrv4_2SP2.conf file to this directory.
Chapter 7
Installing and Uninstalling CMS Instances
313
Upgrading From a Previous CMS Installation
7.
Run the setup program.
When you run the installation program for upgrading a CMS 4.2 instance, you
will be presented with a series of screens or panels; the example below lists the
panels on UNIX. Follow the on-screen prompts and complete the upgrade
process.
❍
Welcome
❍
License
❍
Product Selection
❍
Location (You must specify the same server root or installation directory
that was used for your 4.2 Console.)
-
Server Products Components
Core Components
Directory Suite Components
Administration Service Components
Certificate Server Components
❍
Fully qualified domain name of machine
❍
User and Group
- System User
- System Group
❍
Configuration Directory Server Administration Identifier
- Administrator ID
- Password
❍
Administration Server Port for Console (You must enter the same
port number that was used for your 4.2 Console.)
- Administration Server User
- Certificate Server Identifier (The CMS instance name that you
enter in this panel must exist.)
314
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Chapter
8
Starting and Stopping CMS Instances
This chapter describes how to start, stop, and restart iPlanet Certificate
Management System (CMS) and how to check its current status. The chapter also
explains the CMS watchdog process, a native bootstrapping program that enables
Certificate Management System to start up with a single password instead of
multiple ones.
The chapter has the following sections:
•
Starting Certificate Management System (page 316)
•
Stopping Certificate Management System (page 324)
•
Restarting Certificate Management System (page 326)
•
Checking System Status (page 328)
•
Attending to an Unresponsive Server (page 329)
•
CMS Watchdog Process (page 329)
•
Password-Quality Checker (page 331)
NOTE
You can use the CMS window only when the appropriate
Administration Server is running. Be sure to start Administration
Server at the port you specified during CMS installation. To
minimize security risks, shut down Administration Server when
you have finished using Netscape Console. For instructions on
starting and shutting down Administration Server, see “Netscape
Administration Server” on page 338.
315
Starting Certificate Management System
Starting Certificate Management System
Once Certificate Management System is installed, it runs constantly, listening for
and accepting requests. You can start Certificate Management System in several
ways:
•
From Netscape Console (locally and remotely)
•
From the command line (locally only)
•
On a Windows NT system, from the Windows NT Services panel
Required Start-up Information
When you start Certificate Management System, you are prompted to enter the
single sign-on password you specified during installation. This password enables
the CMS watchdog (see “CMS Watchdog Process” on page 329) to retrieve all the
passwords required by the server to start. These include the following:
316
•
Passwords for the internal or external (if any are currently installed) tokens;
these tokens contain certificates and corresponding public and private key
pairs for the server.
•
The bind password used by Certificate Management System to access and
update the internal database.
•
The bind password used by Certificate Management System to access and
remove PINs from the authentication directory, if you’ve configured
Certificate Management System to remove PINs from the authentication
directory. (See the description for the ldap.ldapauthbindDN and
ldap.ldapauth.bindPWPrompt parameters of the UidPwdPinDirAuth plug-in
module, which explained in the CMS Plug-ins Guide).
•
The bind password used by Certificate Management System to access and
create/modify user entries in the directory used for portal registration, if
you’ve configured Certificate Management System for portal enrollment. (See
the description for the ldap.ldapauthbindDN and
ldap.ldapauth.bindPWPrompt parameters of the PortalEnroll plug-in
module, which explained in the CMS Plug-ins Guide).
•
The bind password used by Certificate Management System to access and
update the LDAP directory; this is required only if you have configured
Certificate Management System for publishing certificates and CRLs to an
LDAP-compliant directory.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Starting Certificate Management System
You first specified these passwords when you installed Certificate Management
System. Keep in mind that the passwords you provide for the tokens unlock a
combination of the following private keys:
•
If you have installed a Certificate Manager in the currently selected CMS
instance, the token password unlocks the private keys for the Certificate
Manager’s CA signing and SSL server certificates.
•
If you have installed a Registration Manager in the currently selected CMS
instance, the token password unlocks the private keys for the Registration
Manager’s signing and SSL server certificates.
•
If you have installed a Data Recovery Manager in the currently selected CMS
instance, the token password unlocks the private keys for the Data Recovery
Manager’s storage keys and transport and SSL server certificates.
•
If you have installed a Online Certificate Status Manager in the currently
selected CMS instance, the token password unlocks the private keys for the
Online Certificate Status Manager’s signing and SSL server certificates.
For more information about the CMS keys and certificates, see Chapter 14,
“Managing CMS Keys and Certificates.”
Note that during CMS installation, the watchdog stores all the passwords, required
by the server for starting up, in a password cache. The cache is maintained in a file
encrypted using the single sign-on password you specify during installation. When
you change any of the required passwords or provide new passwords, you must
start the server from the command-line (see “Starting From the Command Line” on
page 322) so that the watchdog can prompt you for the new passwords in order to
update the cache.
The single sign-on password eliminates the need for you to enter the various
password when starting up Certificate Management System. As a security
measure, you should consider changing the single sign-on password periodically.
For instructions, see “Password Cache” on page 330.
Also note that all passwords used in Certificate Management System are checked
by a built-in password-quality checker; for details, see “Password-Quality
Checker” on page 331.
Configuring the Server to Start Without the Single Sign-On Password
If you prefer to start up Certificate Management System by entering all the
required passwords, instead of just the single sign-on password, you can do so by
either deleting or renaming the password cache file, pwcache.p12 (notice the .p12
extension).
Chapter
8
Starting and Stopping CMS Instances
317
Starting Certificate Management System
Here’s how you can do it:
1.
Go to this directory: <server_root>/cert-<instance_id>/config
2.
Locate the pwcache.p12 file.
3.
Either rename or delete the file.
4.
Start the server from the command line; see “Starting From the Command
Line” on page 322.
You are prompted for all the required passwords.
Later, if you want to revert back to starting the server using the single sign-on
password:
1.
Create a password cache and then create entries for all the required passwords.
For instructions on creating a new password cache and adding new entries to
the password cache, see Chapter 2, “Password Cache Utility” of CMS
Command-Line Tools Guide.
2.
Copy the file to the <server_root>/cert-<instance_id>/config directory.
3.
Start the server from the command line; see “Starting From the Command
Line” on page 322.
You are prompted for the single sign-on password.
Configuring the Server to Read the Single Sign-on Password From a
File
Every time you start Certificate Management System, you are required to enter
either the single sign-on password or all the passwords required by the server to
startup (see “Required Start-up Information” on page 316 and “Configuring the
Server to Start Without the Single Sign-On Password” on page 317). By default,
there is no way to start Certificate Management System non-interactively; the
startcert script requires you to enter a password.
If it is inconvenient for you to start the server this way, you can store the single
sign-on password in a file and edit the startcert script to use this file to start
without any prompts. Configuring the server this way eliminates the need for you
to enter the single sign-on password every time you start the server—it can be
useful on UNIX machines to have the server automatically started if the machine
reboots for any reason, and it can be useful on Windows NT to be able to start the
server without having to be at the system console. Note that there is no way to
make the edited startcert script a service that is automatically started by Windows
NT at startup, so if the machine reboots due to a power failure, Certificate
Management System will not start automatically.
318
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Starting Certificate Management System
CAUTION
The instructions that follow explain how to configure Certificate
Management System to start by reading the single sign-on password
from a file. Note that the password is stored in a plain text file and
you must use your operating system’s security feature to secure this
file. Failing to do so poses a security risk, as anyone who has access
to the host system will be able to get hold of the single sign-on
password.
To configure the server to start by reading the single sign-on password from a file:
1.
Create a file named pwfile.
2.
Put the single sign-on password in the file.
3.
Copy the file to this directory: <server_root>/cert-<instance_id>/config
4.
Edit the start-cert script.
To edit the start-cert script in Unix, follow these steps:
a.
Open a command-line window.
b.
Go to the CMS-instance directory.
For example, /usr/netscape/server4/cert-testCA.
c.
Enter the following line at the prompt:
cat start-cert
You should see something similar to this:
#!/bin/sh
/usr/netscape/server4/bin/cert/admin/bin/start -i testCA
-r /usr/netscape/server4 -e -classpath
/usr/netscape/server4/bin/cert/classes:/usr/netscape/
server4/bin/cert/jars/jss.jar:/usr/netscape/server4/bin/
cert/jars/certsrv.jar:usr/netscape/server4/java/
ldapjdk.jar:/usr/netscape/server4/bin/cert/jre/lib/
rt.jar:/usr/netscape/server4/bin/cert/jre/lib/i18n.jar:/
usr/netscape/server4/bin/cert/jars/jssjdk12.jar
Chapter
8
Starting and Stopping CMS Instances
319
Starting Certificate Management System
d.
Edit the script to include the file path to the pwfile file: to the end of the
line that begins $NETSITE_ROOT/bin/cert/admin/bin/cert add
-f $NETSITE_ROOT/cert-<instance_id>/config/pwfile.
Be sure to include the file path as shown (in bold) in the example.
#!/bin/sh
/usr/netscape/server4/bin/cert/admin/bin/start -i testCA
-f /usr/netscape/server4/cert-testCA/config/pwfile -r
/usr/netscape/server4 -e -classpath
/usr/netscape/server4/cert-testCA/classes/:/usr/netscape/
server4/bin/cert/classes/:/usr/netscape/server4/bin/cert/
jars/jss.jar:/usr/netscape/server4/bin/cert/jars/
certsrv.jar:/usr/netscape/server4/java/ldapjdk.jar:/usr/
netscape/server4/bin/cert/jre/lib/rt.jar:/usr/netscape/
server4/bin/cert/jre/lib/i18n.jar:/usr/netscape/server4/
bin/cert/jars/jssjdk12.jar
To edit the start-cert.bat script in Windows NT, follow these steps:
a.
Open a command-line window.
b.
Go to the CMS instance directory.
For example, C:\netscape\server4\cert-testCA.
c.
Enter the following line at the prompt:
type start-cert.bat
You should see something similar to this:
net start cert-testCA /cC:\Netscape\Server4\cert-testCA\
classes\;C:\Netscape\Server4\bin\cert\classes\;C:\Netscape
\Server4\bin\cert\jars\jss.jar;C:\Netscape\Server4\bin\
cert\jars\certsrv.jar;C:\Netscape\Server4\java\ldapjdk.jar
;C:\Netscape\Server4\bin\cert\jre\lib\rt.jar;C:\Netscape
\Server4\bin\cert\jre\lib\i18n.jar;C:\Netscape\Server4\bin
\cert\jars\jssjdk12.jar;C:\Netscape\Server4\java\
swingall.jar
320
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Starting Certificate Management System
d.
Edit the script to include the file path to the pwfile file: to the end of the
line that begins net start cert-<instance_id> add
/fC:%NETSITE_ROOT%\cert-<instance_id>\config\pwfile.
Be sure to include the file path as shown in the example (shown in bold).
net start cert-testCA /fC:\Netscape\Server4\certtestCA\config\pwfile /cC:\Netscape\Server4\
cert-testCA\classes\;C:\Netscape\Server4\bin\cert\classes\;
C:\Netscape\Server4\bin\cert\jars\jss.jar;C:\Netscape\
Server4\bin\cert\jars\certsrv.jar;C:\Netscape\Server4\java\
ldapjdk.jar;C:\Netscape\Server4\bin\cert\jre\lib\rt.jar;C:\
Netscape\Server4\bin\cert\jre\lib\i18n.jar;C:\Netscape\
Server4\bin\cert\jars\jssjdk12.jar;C:\Netscape\Server4\java\
swingall.jar
e.
Save your changes.
5.
Use your operating system’s security feature to restrict access to the password
file.
6.
Restart the server from the command line; see “Starting From the Command
Line” on page 322.
It should start without prompting for the single sign-on password.
Starting From Netscape Console
You can use Netscape Console to start an instance of Certificate Management
System running on a local or remote host.
To start Certificate Management System from Netscape Console:
1.
Log in to Netscape Console (see “Logging In to Netscape Console” on
page 340).
2.
In the Console tab, select the Server Group that contains the CMS instance you
want to start.
3.
In the navigation tree, locate the CMS instance you want to start.
Chapter
8
Starting and Stopping CMS Instances
321
Starting Certificate Management System
4.
Select the instance, right-click, and select the Start Server option from the
pop-up menu.
When you start Certificate Management System, you are prompted to supply
the single sign-on password for the server.
5.
Type the single sign-on password you specified during installation and click
OK.
Certificate Management System won’t start until you provide this password.
For more information, see “Required Start-up Information” on page 316.
Starting From the Command Line
To start Certificate Management System from the command line:
322
1.
Open a terminal window to your server.
2.
In a Unix system, log in as root if the server runs on ports less than 1024;
otherwise, log in either as root or with the server’s user account.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Starting Certificate Management System
3.
At the command-line prompt, enter the following line:
<server_root>/cert-<instance_id>/start-cert[.bat]
.bat specifies the file extension; this is required only when running the
utility on a Windows NT system.
<server_root> is the directory where the CMS binaries are kept. You first
specified this directory during installation.
<instance_id> is the ID for this instance of Certificate Management
System. You first specified this when you installed this server.
4.
When prompted, enter the single sign-on password.
Certificate Management System won’t start until you provide this password.
For more information, see “Required Start-up Information” on page 316.
NOTE
If Certificate Management System is already running, the start-up
command fails. Stop the server first using the stop-cert
command, then use the start-cert command.
Starting From the Windows NT Services Panel
If you have installed Certificate Management System on a Windows NT system,
you can start the server (as a service) from the Windows NT Services panel (see
Figure 8-1). The CMS service has the following name:
Netscape CMS (<instance_id>)
Figure 8-1
CMS service in the Windows NT Services panel
Chapter
8
Starting and Stopping CMS Instances
323
Stopping Certificate Management System
To start Certificate Management System from the Windows NT Services panel:
1.
Click the Start button on your desktop.
2.
Select Control Panel from Settings.
3.
In the Control Panel window that appears, click Services.
4.
Select the CMS instance and click Start.
You are prompted to supply the single sign-on password for the server.
5.
Enter the single sign-on password you specified during installation and click
OK.
Certificate Management System won’t start until you provide this password.
For more information, see “Required Start-up Information” on page 316.
Stopping Certificate Management System
You can stop Certificate Management System in several ways:
•
From Netscape Console (locally and remotely)
•
From the command line (locally only)
•
On a Windows NT system, from the Windows NT Services panel
Stopping Certificate Management System shuts down all the subsystems
completely, interrupting service until the server is started again. If your machine
crashes or is taken offline, the server stops, and any requests it was servicing are
lost. You need to start the server again to restore service.
Stopping From Netscape Console
You can use Netscape Console to stop an instance of Certificate Management
System running on a local or remote host.
To stop Certificate Management System from Netscape Console:
324
1.
Log in to Netscape Console (see “Logging In to Netscape Console” on
page 340).
2.
In the Console tab, select the Server Group that contains the CMS instance you
want to stop.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Stopping Certificate Management System
3.
In the navigation tree, select the CMS instance you want to stop, right-click,
and select the Stop Server option from the pop-up menu.
The server is stopped.
Stopping From the Command Line
You can stop a CMS instance running on a local host by entering the appropriate
command at the command prompt.
To stop a Certificate Management System from the command line:
1.
Open a terminal window to your server.
2.
In a Unix system, log in either as root or using the server’s user account (if that
is how you started the server).
3.
At the command-line prompt, enter the following line:
<server_root>/cert-<instance_id>/stop-cert[.bat]
.bat specifies the file extension; this is required only when running the
utility on a Windows NT system.
<server_root> is the directory where the CMS binaries are kept. You first
specified this directory during installation.
<instance_id> is the ID for this instance of Certificate Management
System. You first specified this when you installed this server.
Chapter
8
Starting and Stopping CMS Instances
325
Restarting Certificate Management System
Stopping From the Windows NT Services Panel
You can stop a CMS instance running on a local host by stopping the
corresponding service; it is identified by the following in the Windows NT Services
panel (see Figure 8-1 on page 323):
iPlanet Certificate Management System (cert-<instance_id>)
To stop Certificate Management System from the Windows NT Services panel:
1.
Click the Start button on your desktop.
2.
Select Control Panel from Settings.
3.
In the Control Panel window that appears, click Services.
4.
Select the CMS instance and click Stop.
5.
When prompted, click Yes.
The server is stopped.
Restarting Certificate Management System
Whenever you change the CMS configuration, you must save your changes (by
clicking the Save button) for the changes to take effect. Some configuration changes
also require that you restart the server after you save the changes. If restarting is
required, the server prompts you accordingly.
You can restart the server in two ways:
•
From the CMS window (locally and remotely)
•
From the command line (locally only)
Restarting From the CMS Window
You can use the CMS window to restart an instance of Certificate Management
System on a local or remote host.
To restart Certificate Management System from the CMS window:
1.
326
Log in to the CMS window (see “Logging In to the CMS Window” on
page 347).
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Restarting Certificate Management System
2.
In the Tasks tab, click Restart the Server.
When you restart Certificate Management System, you are prompted to supply
the single sign-on password for the server.
3.
Type the single sign-on password you specified during installation and click
OK.
Certificate Management System won’t restart until you provide this password.
For more information, see “Required Start-up Information” on page 316.
Restarting From the Command Line
To restart Certificate Management System from the command line:
1.
Open a terminal window to your server.
2.
In a Unix system, log in either as root or using the server’s user account (if that
is how you started the server).
Chapter
8
Starting and Stopping CMS Instances
327
Checking System Status
3.
At the command-line prompt, enter the following line:
<server_root>/cert-<instance_id>/restart-cert[.bat]
.bat specifies the file extension; this is required only when running the
utility on a Windows NT system.
<server_root> is the directory where the CMS binaries are kept. You first
specified this directory during installation.
<instance_id> is the ID for this instance of Certificate Management
System. You first specified this when you installed this server.
4.
When prompted, enter the single sign-on password.
Certificate Management System won’t restart until you provide this password.
For more information, see “Required Start-up Information” on page 316.
Checking System Status
You can use Netscape Console to find out whether a particular instance of
Certificate Management System is running.
328
1.
Log in to Netscape Console (see “Logging In to Netscape Console” on
page 340).
2.
In the Console tab, select the instance that corresponds to the CMS instance
you want to check.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Attending to an Unresponsive Server
3.
In the right pane, check the Server Status field.
If the selected instance of Certificate Management System is running, the status
will be Started. Otherwise it will be Stopped or Unknown.
Attending to an Unresponsive Server
If an error causes Certificate Management System to become unresponsive, and all
attempts to stop it from Netscape Console fail, it may be necessary to kill the server
processes manually. For this purpose, Certificate Management System provides a
command-line tool killproc, which is explained in CMS Command-Line Tools
Guide.
CMS Watchdog Process
The CMS watchdog is a native bootstrapping program that provides specific native
functions. It works with Certificate Management System to enable it to start up
using a single password—instead of multiple passwords—called the single sign-on
password. In addition, it manages the start-up, stop, and restart states of Certificate
Management System.
The watchdog process (identified as cms_watchdog) implements the following
operations:
•
Starts Certificate Management System and the Virtual Java Machine, or Java
VM—the watchdog allows you to start Certificate Management System by
using a single password instead of the multiple passwords that would
otherwise be required. For details, see “Required Start-up Information” on
page 316. (During CMS installation the watchdog stores all the passwords
required by the server for starting up in a password cache, which is explained
in “Password Cache” on page 330.)
•
Stops Certificate Management System.
•
Restarts Certificate Management System (after configuration changes).
•
Detects Certificate Management System crashes and restarts the server—the
watchdog monitors Certificate Management System and the Java VM,
restarting the server in the case of a failure.
•
In the Unix version of Certificate Management System, the watchdog records
the server process ID (pid) and sets the user ID (uid) of the process.
Chapter
8
Starting and Stopping CMS Instances
329
Password Cache
Password Cache
During CMS installation, the installation program creates a password cache which
the CMS watchdog uses to store all the passwords required by the server during
start up (see “Required Start-up Information” on page 316). For example, when
you specify the cryptographic token password and the bind password for the
internal directory during installation, the watchdog adds these passwords into the
password cache; similarly, when you configure the server for LDAP publishing
from Netscape Console, the watchdog adds the corresponding password to the
cache.
The password cache is maintained in a triple-DES encrypted file named
pwcache.p12, which is located here:
<server_root>/cert-<instance_id>/config
The file is protected using the single sign-on password you specify during
installation. In the cache, passwords are stored along with a name, a string
describing the usage of the password, which is used by Certificate Management
System to index into the cache. For example, the contents of the password cache
could look like this:
----- Password Cache ----Internal LDAP Database : myIdbPwd
Internal Key Storage Token : myTokenPwd
Authentication : myPinAuthPwd
LDAP Publishing : myLdapPubPwd
Note that in the above example
•
The string Internal LDAP Database is the default value assigned to the
internaldb.ldapauth.bindPWPrompt parameter in the CMS configuration
file; it provides a descriptive usage for the password Certificate Management
System uses to bind to the internal database.
•
The string Internal Key Storage Token is hardcoded and it refers to the
Netscape Software Cryptographic Service provider; you cannot change it. You
can only change the corresponding password.
Other entries may appear in the password cache. For example, if you set up
PIN-based authentication with the remove PIN option, you will see an entry for the
password Certificate Management System uses to bind to the authentication
directory to remove a PIN after a user successfully authenticates; for details, see
UidPwdPinDirAuth plug-in module in CMS Plug-ins Guide. Similarly, if you enable
LDAP publishing with basic authentication, you will also see an entry for the
password Certificate Management System will use to bind to the publishing
directory; for details, see “Step 5. Identify the Publishing Directory” on page 660.
330
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Password-Quality Checker
Except for the string Internal LDAP Database, you can change any of the above
prompts by modifying the corresponding value in the configuration file and then
replacing (delete the old item and add the new item) the current entry in the
password cache with the new prompt and the password using the PasswordCache
utility explained in the CMS Command-Line Tools Guide.
When various modules in the server, such as authentication and LDAP publishing,
initialize, they query the password cache for the password. The password cache
returns the password if it has it, or else it prompts the user for one. Note that this
prompting happens only at server startup time, which means whenever you
change any of the required passwords or provide new passwords, you must restart
the server from the command-line (see “Starting From the Command Line” on
page 322) so that the watchdog can prompt you for the new passwords in order to
update the cache.
Password-Quality Checker
Certificate Management System comes with a plugin, called password-quality
checker, to monitor the quality of passwords set within the CMS system. All
passwords used in Certificate Management System are checked by the
password-quality checker, which by default checks that the length of a password is
at least 8 characters long; there are no checks regarding which characters are valid
or invalid. If you use a password that doesn’t meet the quality rules, you will get an
error message indicating that the password didn’t meet the password-quality
rules.
Note that Certificate Management System enforces password quality on only those
passwords that it strictly creates and manages. Passwords you enter for LDAP
directory access are not subjected to quality checks. The reason for this is, the
password quality is handled by the system that creates and manages the password.
In an LDAP directory access, the remote directory that you authenticate to enforces
the password quality of the password you use because it is created and managed
by the directory.
To enable you to customize password quality, the plugin for the password-quality
checker is included in the CMS samples package; for example, you can change the
default rule to ensure that all CMS passwords are constructed with certain types of
characters such as numbers, symbols, capital letters, and so on. The samples
package is located here: <server_root>/cms_sdk/cms_jdk/samples
Chapter
8
Starting and Stopping CMS Instances
331
Password-Quality Checker
332
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Part
3
Configuration
Chapter 9, “Administration Tasks and Tools”
Chapter 10, “CMS Configuration”
Chapter 11, “Setting Up Ports”
Chapter 12, “Setting Up Internal Database”
Chapter 13, “Managing Privileged Users and Groups”
Chapter 14, “Managing CMS Keys and Certificates”
Chapter 15, “Setting Up End-User Authentication”
Chapter 16, “Setting Up Automated Notifications”
Chapter 17, “Scheduling Automated Jobs”
Chapter 18, “Setting Up Policies”
333
Chapter 19, “Setting Up LDAP Publishing”
Chapter 20, “Publishing Certificates and CRLs to a File”
Chapter 21, “Setting Up an OCSP Responder”
Chapter 22, “Setting Up Key Archival and Recovery”
Chapter 23, “Managing CMS Logs”
334
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Chapter
9
Administration Tasks and Tools
In administering iPlanet Certificate Management System (CMS), you perform
server-specific tasks such as starting, stopping, and restarting the server; changing
configuration; configuring certificate issuance and management policies; adding or
modifying privileged-user and group information; setting up authentication
mechanisms for users who may request services from the server; performing
routine server maintenance tasks; monitoring logs; and backing up server data.
To enable system administrators to accomplish these server-specific tasks quickly
and easily, Certificate Management System provides a GUI-based administration
tool, called the CMS window, within Netscape Console. This chapter provides an
overview of both Netscape Console and the CMS window.
•
Netscape Console (page 336)
•
Logging In to Netscape Console (page 340)
•
The CMS Window (page 342)
•
Logging In to the CMS Window (page 347)
NOTE
You can use Netscape Console for managing various network
resources. However, this chapter’s focus is on using Netscape
Console for CMS administration. For complete information about
Netscape Console, see Managing Servers with Netscape Console,
which is included with the CMS documentation.
335
Netscape Console
Netscape Console
Netscape Console is a stand-alone Java application that provides a GUI-based front
end to all network resources registered in an organization’s configuration
directory. This unified administration interface (shown in Figure 9-1) simplifies
network administration by supplying access points to all Netscape version 4.x
server instances installed across a network. Similarly, it simplifies basic user and
group management by providing a unified administration interface to the user
directory.
Figure 9-1
Netscape Console window, with a CMS instance selected in the Console tab
Console Tab
For any given instance of Netscape Console, the limits of the network it can
administer are defined by the set of resources whose configuration information is
stored in the same configuration directory—that is, the maximum set of hosts and
servers that can be monitored from Netscape Console. The superadministrator (the
person who manages the configuration directory) can set access permissions on all
network resources registered in the configuration directory. Thus, for a given
administrator using Netscape Console, the actual number of visible servers and
hosts may be fewer, depending on the access permissions that the administrator
has.
336
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Netscape Console
The Console tab displays all servers registered in a particular configuration
directory, giving you a consolidated view of all the server software and resources
under your control. What you control is determined by the access permissions the
superadministrator has set up for you.
From this view you can perform tasks across arbitrary groups or a cluster of
servers in a single operation. In other words, you can use the Console tab to
manage a single server or multiple servers that are installed on different ports on
one machine. Also, you can access individual server windows (or administration
interfaces) by double-clicking the icons for the corresponding server instance
entries (SIEs).
With the exception of Certificate Management System, all server instances
displayed on the Console tab store their configuration information in the same
configuration directory. For security purposes, Certificate Management System
uses file-based configuration which is stored locally on the host system; during
installation, the server registers only its SIE in the configuration directory. For
details about this file, see “CMS Configuration” on page 349.
You can accomplish various CMS-specific tasks from the Console tab:
•
Install multiple instances of Certificate Management System.
•
Remove an instance of Certificate Management System from a system or host.
•
Clone an instance of Certificate Management System.
•
Set access permissions for Certificate Management System.
•
Migrate configuration information from one version of Certificate
Management System to another.
•
Launch the Administration Server window (so that you can configure an
Administration Server instance for administering Certificate Management
System).
•
Launch the CMS window.
Users and Groups Tab
The Users and Groups tab (shown in Figure 9-2) manages user accounts, group
lists, and access control information for individual users and groups. All
applications registered within the Netscape Console framework share core user
and group information in the user directory, which typically is a global directory
for corporatewide user data.
Chapter 9
Administration Tasks and Tools
337
Netscape Console
Figure 9-2
Users and Groups tab of Netscape Console
From this tab, you can accomplish various user- and group-specific tasks, such as
these:
•
Add, modify, and delete user and group information in the user directory.
•
Search for specific user and group entries in the user directory.
Netscape Administration Server
Netscape Administration Server is a web-based (HTTP) server that enables you to
configure all your Netscape version 4.x servers, including Certificate Management
System, through Netscape Console. Administration Server (and the configuration
directory) must be running before you can configure any of these servers. It is
included with all Netscape servers and is installed when you install your first
server in a server group. A server group refers to servers that are installed in a server
root directory and that are managed by a single instance of Netscape
Administration Server.
You access Administration Server by entering its URL in the Netscape Console
login screen. This URL is based on the computer host name and the port number
you chose when you installed Certificate Management System. The format for the
URL looks like this: http://<machine_name>.<your_domain>.<domain>:<port>
338
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Netscape Console
Whenever you try to gain access to Administration Server, you will be prompted to
authenticate yourself to the configuration directory by entering your user ID and
password. These are the administrator user name and password that you specified
when you installed Certificate Management System (or the first server in the server
group) and Administration Server on your computer. Once Administration Server
is running, you can use Netscape Console to administer all servers in that group,
including Certificate Management System.
For complete details about Netscape Administration Server, see Managing Servers
with Netscape Console. To locate an online version of this book, go to
<server_root>/manual/index.html.
Starting Administration Server
The CMS installation program automatically starts the instance of Administration
Server that you identified during installation for monitoring Certificate
Management System. If you stopped Administration Server after installation, you
must start it before you can administer Certificate Management System from the
CMS window.
You can start the server from Netscape Console, the command line, or the
Windows NT Services panel.
•
To start Administration Server from Netscape Console:
a.
Log in to Netscape Console (see “Logging In to Netscape Console” on
page 340).
b.
In the Console tab, locate the Administration Server instance that you want
to start, and double-click the corresponding entry.
The Administration Server window appears.
c.
•
In the Tasks tab, click Start the Server.
To start Administration Server from the command line:
At the prompt, enter the following line:
<server_root>/admin-<instance_id>/start-admin
This command starts Administration Server at the port number you specified
during installation. Once the server is running, you can use Netscape Console
to access Certificate Management System.
•
Administration Server runs as a service in a Windows NT system. You can use
the Windows NT Services panel to start the service directly.
Chapter 9
Administration Tasks and Tools
339
Logging In to Netscape Console
Shutting Down Administration Server
It is good security practice to shut down Administration Server when you are not
using it. This minimizes the chances of someone else changing your configuration.
You can shut down the server from Netscape Console, the command line, or the
Windows NT Services panel.
•
To shut down Administration Server from Netscape Console:
a.
Log in to Netscape Console (see “Logging In to Netscape Console” on
page 340).
b.
In the Console tab, locate the Administration Server instance that you want
to shut down, and double-click the corresponding entry.
The Administration Server window appears.
c.
•
In the Tasks tab, click Stop the Server.
To shut down Administration Server from the command line:
At the prompt, enter the following line:
<server_root>/admin-<instance_id>/stop-admin
•
Administration Server runs as a service in a Windows NT system; you can use
the Windows NT Services panel to stop the service directly.
Logging In to Netscape Console
You can launch and use Netscape Console only when the configuration directory
and Administration Server are running. If the servers are not running, go to the
command line and start them. For information on starting Administration Server
from the command line, see “Starting Administration Server” on page 339. For
information on starting the configuration directory, check the Netscape Directory
Server documentation.
When you launch Netscape Console, it displays a login window. You are required
to authenticate to the configuration directory by entering your administrator’s ID,
your password, and the URL (including port number) of the Administration Server
representing a server group to which you have access. You cannot use Netscape
Console without having login access to at least one server group on your network.
340
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Logging In to Netscape Console
1.
Open the Netscape Console application by using the appropriate option:
❍
❍
For local access on a Unix machine, at the command-line prompt, enter the
following line: <server_root>/admin-<instance_id>/start-console
Local access on a Windows NT machine, double-click the Netscape
Console icon on your desktop; this icon was created when you installed
your first Netscape version 4.x server.
The Netscape Console window appears.
2.
Authenticate yourself to the configuration directory.
User ID. Type the administrator ID you specified when you installed
Administration Server on your machine. You installed Administration Server
either when you installed your first Netscape 4.x server or as a part of CMS
installation.
Password. Type the administrator password that you specified when you
installed Administration Server on your computer during CMS installation.
Administration URL. This field should show the URL to Administration
Server. If it doesn’t or if it doesn’t have the URL of Administration Server that
you want, type the URL in this field. The URL is based on the computer host
name and the Administration Server port number you chose when you
installed Certificate Management System. Use this format:
http://<machine_name>.<your_domain>.<domain>:<port_number>
For example, if your domain name is siroe and you installed Administration
Server on a host machine called myHost and specified port number 12345, the
URL would look like this: http://myHost.siroe.com:12345
3.
Click OK.
Netscape Console appears with a list of all the servers and resources under
your control (see Figure 9-1). To view general information about a specific
server, click the corresponding entry. To access the administration interface for
a specific server, double-click the corresponding entry.
Chapter 9
Administration Tasks and Tools
341
The CMS Window
The CMS Window
The CMS window is a GUI-based administration interface that allows you to
perform day-to-day operational and managerial duties for Certificate Management
System. You launch the CMS window from within Netscape Console (Figure 9-3).
Figure 9-3
Certificate Management System window, launched from Netscape Console
You can use the CMS window to access the server locally or remotely. The window
has three separate tabs—Tasks, Configuration, and Status—each addressing
specific administrative areas.
342
iPlanet Certificate Management System Installation and Setup Guide • March 2001
The CMS Window
Tasks Tab
The Tasks tab enables you to perform tasks such as starting, stopping, and
restarting the server, and running the Certificate Setup Wizard. For details see
Chapter 8, “Starting and Stopping CMS Instances” and “Certificate Setup Wizard”
on page 459.
Configuration Tab
The Configuration tab enables you to view and modify the configuration.
Chapter 9
Administration Tasks and Tools
343
The CMS Window
Table 9-1 provides details about the tasks you can accomplish from this tab. You
access specific settings by selecting an entry in the navigation tree and working
with the tabs that appear in the right pane.
Table 9-1
Tasks you can accomplish from the Configuration tab
Task
Description
Configuring network
settings
This involves changing the administration, agent, and end-entity ports of
Certificate Management System. For details, see Chapter 11, “Setting Up
Ports.”
Configuring the internal
database settings
This involves specifying the host name and port number of the Directory
Server that Certificate Management System should use for storing data. For
details, see Chapter 12, “Setting Up Internal Database.”
Setting up privileged users
This involves operations such as the following:
• Entering information about privileged users (administrators, agents, and
trusted managers) into the CMS internal database.
• Modifying user information.
• Deleting users from the database.
For details, see see Chapter 13, “Managing Privileged Users and Groups.”
Managing CMS keys and
certificates
This involves operations such as the following:
• Managing the CMS certificate database.
• Generating new and renewing existing certificates for the Certificate
Manager, Registration Manager, Data Recovery Manager, and Online
Certificate Status Manager.
• Installing new hardware tokens.
For details, see Chapter 14, “Managing CMS Keys and Certificates.”
Determining
authentication for end
users
This involves operations such as the following:
• Viewing currently registered authentication plug-in modules.
• Configuring Certificate Management System to use a specific
authentication method to authenticate end users when they enroll for a
certificate.
• Registering custom authentication plug-in modules.
For details, see Chapter 15, “Setting Up End-User Authentication.”
344
iPlanet Certificate Management System Installation and Setup Guide • March 2001
The CMS Window
Table 9-1
Tasks you can accomplish from the Configuration tab (Continued)
Task
Description
Enabling automated email
notifications
This involves operations such as the following:
• Entering the information required by the server to send automated
notifications to one or more agents when a request enters the agent queue.
• Entering the information required by the server to send automated
certificate-issuance notifications to end entities when the server issues
them certificates.
• Specifying the host name and port number of the mail server that
Certificate Management System should use for sending email
notifications.
• Customizing the notification message templates to suit your
organization’s requirements.
For details, see Chapter 16, “Setting Up Automated Notifications.”
Scheduling automated jobs
This involves operations such as the following:
• Viewing currently registered plug-in modules for jobs.
• Configuring Certificate Management System to execute specific jobs.
For details, see Chapter 17, “Scheduling Automated Jobs.”
Configuring certificate
issuance and management
policies
This involves operations such as the following:
• Viewing currently registered policy plug-in modules for a Certificate
Manager or Registration Manager.
• Configuring the Certificate Manager or Registration Manager for
certificate formulation, issuance, renewal, and revocation policies, and
configuring the Data Recovery Manager for the archiving and recovery of
end users’ encryption private keys.
For details, see Chapter 18, “Setting Up Policies.”
Publishing certificates and
CRLs
This involves operations such as the following:
• Configuring the Certificate Manager to publish certificates and CRLs to an
LDAP-compliant directory, such as Netscape Directory Server. For details,
see Chapter 19, “Setting Up LDAP Publishing.”
• Configuring the Certificate Manager to publish certificates and CRLs to a
flat file for importing into other repositories. For details, see Chapter 20,
“Publishing Certificates and CRLs to a File.”
• Configuring the Certificate Manager to publish CRLs to the CMS OCSP
responder, Online Certificate Status Manager. For details, see Chapter 21,
“Setting Up an OCSP Responder.”
Chapter 9
Administration Tasks and Tools
345
The CMS Window
Table 9-1
Tasks you can accomplish from the Configuration tab (Continued)
Task
Description
Configuring the Data
Recovery Manager
This involves configuring the Data Recovery Manager for archival and
recovery of end users’ encryption private keys. For details, see Chapter 22,
“Setting Up Key Archival and Recovery.”
Managing CMS logs
This involves configuring system, error, and audit logs maintained by
Certificate Management System and using these logs to monitor the server’s
activities. For details, see Chapter 23, “Managing CMS Logs.”
Backing up and restoring
CMS data
This involves operations such as the following:
• Periodically backing up the CMS data.
• In the event of data loss, using the resulting archives to restore the data.
For details, see Chapter 6, “Backing Up and Restoring Data” of CMS
Command-Line Tools Guide.
Status Tab
The Status tab allows you to monitor the server by viewing the contents of various
logs maintained by Certificate Management System.
You can monitor active as well as rotated System, Error, and Audit log files. For
details, see “Monitoring CMS Logs” on page 783.
346
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Logging In to the CMS Window
Logging In to the CMS Window
You access the CMS window from Netscape Console. For details on Netscape
Console, see “Netscape Console” on page 336.
The Console tab of Netscape Console contains a list of network resources that are
under your control. In this list you can identify CMS instances by their icons or by
server identifiers you specified during installation (for example, you may have
named a CMS instance ABC Corp CA).
NOTE
Accessing the CMS window is a privileged operation that is
restricted to CMS administrators. After you log in for the first time,
create at least one user in each of the default groups; see “Groups
and Their Privileges” on page 402.
To open the CMS window for a specific CMS instance:
1.
Log in to Netscape Console (see “Logging In to Netscape Console” on
page 340).
2.
In the Console tab, select the Server Group that contains the CMS instance you
want to use as your source.
3.
In the navigation tree, locate the CMS instance you want to administer.
4.
Select the instance and click Open or double-click the corresponding entry.
If the selected server is not running, you are asked to start the server first. In
that case, start the server, and then repeat steps 2 through 4. For information on
starting the server, see “Starting Certificate Management System” on page 316.
If the selected server is running, you are prompted to authenticate to
Certificate Management System.
Chapter 9
Administration Tasks and Tools
347
Logging In to the CMS Window
5.
Enter the appropriate information:
User ID. If you are logging in for the first time, type the Certificate
Administrator ID; you specified this user ID during installation (so that you
could log in to the CMS window without having to create privileged-user
entries). Otherwise, type your privileged-user ID (administrator ID).
Password. If you are logging in for the first time, type the Certificate
Administrator password; you specified this password during installation (so
that you could log in to the CMS window without having to create
privileged-user entries). Otherwise, type your privileged-user (administrator)
password; see “Administrators” on page 390.
Upon successful authentication, the CMS window appears (Figure 9-3 on page
342).
348
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Chapter
10
CMS Configuration
The runtime properties of iPlanet Certificate Management System (CMS) are
governed by a set of configuration parameters. These parameters are stored in a
file that is read by the server during startup.
When you install Certificate Management System, the installer creates an ASCII
file, named CMS.cfg, and populates it with the appropriate configuration
parameters. You can control the way Certificate Management System functions by
making the appropriate changes to the configuration information.
This chapter explains how the installation affects the number of configuration files
created in your machine and their contents. It also explains ways in which you can
modify the configuration and precautions you should take when doing so. The
chapter ends with a road map to configuring individual subsystems.
The chapter has the following sections:
•
Effects of Installation Type on Configuration (page 349)
•
Locating the Configuration File (page 352)
•
Modifying the Configuration (page 353)
•
Road Map to Configuring Subsystems (page 370)
Effects of Installation Type on Configuration
For each instance of Certificate Management System there is a configuration file,
named CMS.cfg. The configuration file controls the runtime properties of the
corresponding CMS instance.
349
Effects of Installation Type on Configuration
A CMS instance can include a single subsystem or two subsystems in one of the
following combinations:
•
A single Certificate Manager, Registration Manager, Data Recovery Manager,
or Online Certificate Status Manager
•
A Certificate Manager and Data Recovery Manager together
•
A Registration Manager and Data Recovery Manager together
Figure 10-1 on page 351 illustrates a deployment scenario involving two instances
of Certificate Management System running on the same host (Host A) and a single
instance running on another host (Host B). Notice the two separate configuration
files for the instances running on Host A, one for each CMS instance.
Although the names of both the configuration files are the same, the information
included in the files differs according to the subsystems installed in each instance.
For example, the configuration file for CMS Instance 1 includes only those
parameters that govern the Registration Manager, whereas the configuration file
for CMS Instance 2 includes parameters that control both the Certificate Manager
and Data Recovery Manager.
It is also important to understand that subsystems installed in a CMS instance
share certain parts of the configuration. They use the same
350
•
Administration, agent, and end-entity ports for interaction
•
Internal token and trust database
•
SSL ciphers during SSL negotiation
•
Privileged users (administrators and agents)
•
Log files to log messages
•
Internal database for data storage
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Effects of Installation Type on Configuration
Figure 10-1
How installation affects configuration
Duplicating Configuration From One Instance to
Another
If you have deployed a large number of CMS instances that are identical—for
example, multiple Registration Managers—and you want all these instances to
Chapter 10
CMS Configuration
351
Locating the Configuration File
have the same configuration, you can accomplish this by configuring one of the
instances and then replacing the configuration files of the other instances with the
one that contains the required configuration. Figure 10-2 illustrates this quick way
of deploying multiple Registration Managers with the same configuration.
Figure 10-2
NOTE
Duplicating a configuration
Be careful when replacing configuration of one instance with
another. The configuration file for an instance contains
instance-specific parameters. If you replace these parameters, the
instance will fail to start or function properly.
Locating the Configuration File
Each instance of Certificate Management System has its own configuration file,
CMS.cfg. The default location for this file is as follows:
<server_root>/cert-<instance_id>/config
352
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Modifying the Configuration
Modifying the Configuration
You can modify the CMS configuration in two ways:
•
By changing the configuration parameter values from the CMS window. This
is the recommended method for changing configuration. See “Changing the
Configuration From the CMS Window” on page 353.
•
By manually changing the configuration parameter values in the configuration
file, CMS.cfg. See “Changing the Configuration by Editing the Configuration
File” on page 353.
Changing the Configuration From the CMS
Window
The CMS window allows you to view the current configuration of a CMS instance
and make the required changes. Because this is the recommended method for
changing configuration, the chapters that follow focus on explaining how to
change the various configuration parameter values from the CMS window.
NOTE
You may find the road map provided in “Road Map to Configuring
Subsystems” on page 370 useful in setting up your CMS instances.
Changing the Configuration by Editing the
Configuration File
This section explains how to change the CMS configuration by editing the
configuration parameter values in the file CMS.cfg. This ASCII file is read by
Certificate Management System when it is started.
CAUTION
Do not edit the configuration file directly if you are not familiar with
the configuration parameters or if you are not sure that the changes
you intend to make are acceptable by the server. Certificate
Management System will fail to start up if you make incorrect
modifications to the configuration file. Incorrect configuration can
also result in data loss.
Also, before you start editing the configuration file, be sure to read
“Guidelines for Editing the Configuration File” on page 354.
Chapter 10
CMS Configuration
353
Modifying the Configuration
To modify the configuration file directly:
1.
Stop the CMS instance whose configuration file you want to edit (see
“Stopping Certificate Management System” on page 324).
2.
Open a terminal window.
3.
Go to this directory: <server_root>/cert-<instance_id>/config
4.
Open the configuration file, CMS.cfg, in a text editor.
5.
Edit information in the file and save your changes.
6.
Restart Certificate Management System (see “Restarting Certificate
Management System” on page 326).
Guidelines for Editing the Configuration File
The file-based, configuration-store implementation for Certificate Management
System is based on java.util.Properties. The following guidelines may help
you interpret the information in the configuration file.
•
The format of the configuration file is as follows:
#comment
[parameter]=value
value
[parameter]
multi
line
value (e.g. base-64 encoded certificate)
354
•
Comment lines, blank lines, unknown parameters, or misspelled parameters
are ignored by Certificate Management System. Comment lines begin with a
number sign (#). A line beginning with white space is considered a
continuation of the previous line.
•
The configuration file has many sections. Some sections contain parameters
specific to the subsystems that have been installed; the other sections contain
parameters that are shared by the subsystems. Subsystem-specific parameters
are distinguished by a prefix identifying the subsystem:
❍
ca for the Certificate Manager
❍
ra for the Registration Manager
❍
kra for the Data Recovery Manager
❍
ocsp for the Online Certificate Status Manager
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Modifying the Configuration
•
The parameter names and their values are strings. The parameter names can be
hierarchically structured with '.' notation with multiple levels—for example,
ca.Policy.rule.RSAKeyRule.maxSize. The entries corresponding to a lower level
(such as Policy in the example) can be requested from the configuration
corresponding to its higher level (ca in the example).
•
The values that need to be localized (such as distinguished names in multibyte
format) should be entered in utf8 format. For more information on this format,
see the document UTF-8, a transformation format of Unicode and ISO 10646,
available at this URL:
http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2044.txt
•
Certificate Management System writes out the configuration in a sorted order.
•
The values of some parameters are referenced to other parts of the
configuration file. For example, assume that a parameter is defined as
subsystem.id=ca; when this parameter is processed by the server, all the
parameters beginning with ca will be used.
•
The configuration file supports Unix-style file separator, the forward slash (/).
If the backward slash (\) file separator is required, use two backward slashes
(\\) instead of one.
•
The sample shown on page 357 illustrates how authentication-specific
information appears in the configuration file. Keep the following points in
mind:
❍
❍
❍
❍
❍
All authentication-specific information, such as names of registered
authentication plug-in modules and any configured instances, appears in
the Authentication section of the configuration file.
Each registered authentication plug-in module is identified by its
implementation name and the corresponding Java class.
Each configured instance of an authentication module is identified by the
name or ID you specified when creating it.
You can create multiple instances out of an implementation; each instance
must have a unique name.
The name of an authentication instance must be used in the corresponding
enrollment form so that the server is able to determine the authentication
method during end-user enrollment. For details, see “Step 5. Set Up the
Enrollment Interface” on page 538.
Chapter 10
CMS Configuration
355
Modifying the Configuration
•
The sample shown on page 366 shows how Job Scheduler-specific information
appears in the configuration file. Note the following:
❍
❍
❍
❍
•
All job-specific information, such as registered job modules and configured
instances, appears in the Job Scheduler section of the configuration file.
Each registered job module is identified by its implementation name and
the corresponding Java class.
Each job (or configured instance of a job module) is identified by the name
specified when the job was created.
You can create as many instances of an implementation as you like; each
instance must have a unique name.
The sample shown on page 358 illustrates how policy-specific information
appears in the configuration file. Note the following:
❍
All policy-specific information, such as registered policy plug-in
implementations, configured rules, and ordering, appear in the Policy
section of the configuration file. If you have installed more than one
subsystem in a CMS instance, for example Certificate Manager and Data
Recovery Manager together, the configuration file will include policy
sections that are specific to each of the subsystems that share the
configuration.
You can identify policy pertaining to a subsystem by these prefixes:
Certificate Manager by ca, Registration Manager by ra, and Data Recovery
Manager by kra.
❍
❍
❍
•
356
Each registered policy plug-in module is identified by its implementation
name and the corresponding Java class.
Each configured rule of a policy module is identified by the name specified
when the rule was created.
You can create multiple rules out of an implementation; each rule must
have a unique name.
The sample on page 367 illustrates how information specific to logs appears in
the configuration file.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Modifying the Configuration
Sample Configuration File
The following sample configuration is of a Certificate Manager.
NOTE
_000=##
_001=## File Created On
_002=##
This sample file includes some of the parameters used by
Certificate Management System. However, there is no guarantee
that an arbitrary set of options you create will work.
: Sun Jan 02 23:02:35 PST 2000
instanceRoot=/usr/netscape/cert-testCA
machineName=testCA.siroe.com
agentGateway._000=##
agentGateway._001=## Agent Gateway
agentGateway._002=##
agentGateway.docRoot=/usr/netscape/cert-testCA/web/agent
agentGateway.dynamicVariables=serverdate=serverdate()
agentGateway.enableAdminEnroll=true
agentGateway.enableBulkInterface=true
agentGateway.keepAliveOn=true
agentGateway.mimeTypeConf=/usr/netscape/cert-testCA/config/mime.types
agentGateway.numServices=1
agentGateway.service0=https
agentGateway.CAGetBySerial.successTemplate=/ca/ImportCert.template
agentGateway.adminEnroll.successTemplate=/ca/EnrollSuccess.template
agentGateway.bulkissuance.errorTemplate=/ca/bulkissuance.template
agentGateway.bulkissuance.pendingTemplate=/ca/bulkissuance.template
agentGateway.bulkissuance.rejectedTemplate=/ca/bulkissuance.template
agentGateway.bulkissuance.successTemplate=/ca/bulkissuance.template
agentGateway.bulkissuance.svcpendingTemplate=/ca/bulkissuance.template
agentGateway.bulkissuance.unauthorizedTemplate=/ca/bulkissuance.template
agentGateway.bulkissuance.unexpectedErrorTemplate=/ca/bulkissuance.template
agentGateway.https.backlog=15
agentGateway.https.nickName=Server-Cert cert-testCA
agentGateway.https.port=4605
agentGateway.https.type=https
auths._000=##
auths._001=## Authentication
auths._002=##
auths.impl._000=##
auths.impl._001=## authentication manager implementations
auths.impl._002=##
Chapter 10
CMS Configuration
357
Modifying the Configuration
auths.impl.NISAuth.class=com.netscape.certsrv.authentication.NISAuth
auths.impl.PortalEnroll.class=com.netscape.certsrv.authentication.PortalEnroll
auths.impl.UidPwdDirAuth.class=com.netscape.certsrv.authentication.
UidPwdDirAuthentication
auths.impl.UidPwdPinDirAuth.class=com.netscape.certsrv.authentication.
UidPwdPinDirAuthentication
auths.revocationChecking.bufferSize=5
auths.revocationChecking.ca=ca
auths.revocationChecking.enabled=true
auths.revocationChecking.unknownStateInterval=0
auths.revocationChecking.validityInterval=120
ca.id=ca
ca.local=true
ca.Policy.order=KeyAlgRule, RSAKeyRule, DefaultValidityRule, RenewalConstraintsRule,
DefaultRenewalValidityRule, RevocationConstraintsRule, DefaultRevocationRule,
NSCertTypeExt, CMCertKeyUsageExt, RMCertKeyUsageExt, ClientCertKeyUsageExt,
ServerCertKeyUsageExt, ObjSignCertKeyUsageExt, SubjectKeyIdentifierExt,
CertificatePoliciesExt, NSCComment, OCSPNoCheckExt, OCSPSigningExt, CODESigningExt,
GenericASN1Ext, CRLDistributionPointsExt, SubjectAltNameExt, SigningAlgRule,
AuthorityKeyIdentifierExt, BasicConstraintsExt, UniqueSubjectName, NameConstraintsExt,
PolicyConstraintsExt, SubCANameCheck, PolicyMappingsExt, IssuerRule
ca.Policy.processor=classic
ca.Policy.impl._000=##
ca.Policy.impl._001=## Policy Implementations
ca.Policy.impl._002=##
ca.Policy.impl.AuthInfoAccessExt.class=com.netscape.certsrv.policy.AuthInfoAccessExt
ca.Policy.impl.AuthorityKeyIdentifierExt.class=com.netscape.certsrv.policy.
AuthorityKeyIdentifierExt
ca.Policy.impl.BasicConstraintsExt.class=com.netscape.certsrv.policy.
BasicConstraintsExt
ca.Policy.impl.CRLDistributionPointsExt.class=com.netscape.certsrv.policy.
CRLDistributionPointsExt
ca.Policy.impl.CertificatePoliciesExt.class=com.netscape.certsrv.policy.
CertificatePoliciesExt
ca.Policy.impl.DSAKeyConstraints.class=com.netscape.certsrv.policy.DSAKeyConstraints
ca.Policy.impl.DefaultRevocation.class=com.netscape.certsrv.policy.DefaultRevocation
ca.Policy.impl.ExtendedKeyUsageExt.class=com.netscape.certsrv.policy.
ExtendedKeyUsageExt
ca.Policy.impl.GenericASN1Ext.class=com.netscape.certsrv.policy.GenericASN1Ext
ca.Policy.impl.IssuerAltNameExt.class=com.netscape.certsrv.policy.IssuerAltNameExt
ca.Policy.impl.IssuerConstraints.class=com.netscape.certsrv.policy.IssuerConstraints
ca.Policy.impl.KeyAlgorithmConstraints.class=com.netscape.certsrv.policy.
KeyAlgorithmConstraints
ca.Policy.impl.KeyUsageExt.class=com.netscape.certsrv.policy.KeyUsageExt
ca.Policy.impl.NSCComment.class=com.netscape.certsrv.policy.NSCComment
ca.Policy.impl.NSCertTypeExt.class=com.netscape.certsrv.policy.NSCertTypeExt
ca.Policy.impl.NameConstraintsExt.class=com.netscape.certsrv.policy.NameConstraintsExt
ca.Policy.impl.OCSPNoCheckExt.class=com.netscape.certsrv.policy.OCSPNoCheckExt
ca.Policy.impl.AttributePresent.class=com.netscape.certsrv.policy.AttributePresent
358
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Modifying the Configuration
ca.Policy.impl.PolicyConstraintsExt.class=com.netscape.certsrv.policy.
PolicyConstraintsExt
ca.Policy.impl.PolicyMappingsExt.class=com.netscape.certsrv.policy.PolicyMappingsExt
ca.Policy.impl.PrivateKeyUsagePeriodExt.class=com.netscape.certsrv.policy.
PrivateKeyUsagePeriodExt
ca.Policy.impl.RSAKeyConstraints.class=com.netscape.certsrv.policy.RSAKeyConstraints
ca.Policy.impl.RenewalConstraints.class=com.netscape.certsrv.policy.RenewalConstraints
ca.Policy.impl.RenewalValidityConstraints.class=com.netscape.certsrv.policy.
RenewalValidityConstraints
ca.Policy.impl.RevocationConstraints.class=com.netscape.certsrv.policy.
RevocationConstraints
ca.Policy.impl.SigningAlgorithmConstraints.class=com.netscape.certsrv.policy.
SigningAlgorithmConstraints
ca.Policy.impl.SubCANameCheck.class=com.netscape.certsrv.policy.SubCANameCheck
ca.Policy.impl.SubjectAltNameExt.class=com.netscape.certsrv.policy.SubjAltNameExt
ca.Policy.impl.SubjectDirectoryAttributesExt.class=com.netscape.certsrv.policy.
SubjectDirectoryAttributesExt
ca.Policy.impl.SubjectKeyIdentifierExt.class=com.netscape.certsrv.policy.
SubjectKeyIdentifierExt
ca.Policy.impl.UniqueSubjectName.class=com.netscape.certsrv.policy.UniqueSubjectName
ca.Policy.impl.ValidityConstraints.class=com.netscape.certsrv.policy.
ValidityConstraints
ca.Policy.rule.AuthorityKeyIdentifierExt.enable=true
ca.Policy.rule.AuthorityKeyIdentifierExt.implName=AuthorityKeyIdentifierExt
ca.Policy.rule.AuthorityKeyIdentifierExt.predicate=
ca.Policy.rule.BasicConstraintsExt.enable=true
ca.Policy.rule.BasicConstraintsExt.implName=BasicConstraintsExt
ca.Policy.rule.BasicConstraintsExt.predicate=HTTP_PARAMS.certType == ca
ca.Policy.rule.BasicConstraintsExt.removeBasicExt=true
ca.Policy.rule.CMCertKeyUsageExt.crlSign=true
ca.Policy.rule.CMCertKeyUsageExt.digitalSignature=true
ca.Policy.rule.CMCertKeyUsageExt.enable=true
ca.Policy.rule.CMCertKeyUsageExt.implName=KeyUsageExt
ca.Policy.rule.CMCertKeyUsageExt.keyCertsign=true
ca.Policy.rule.CMCertKeyUsageExt.nonRepudiation=true
ca.Policy.rule.CMCertKeyUsageExt.predicate=certType==ca
ca.Policy.rule.CODESigningExt.critical=false
ca.Policy.rule.CODESigningExt.enable=true
ca.Policy.rule.CODESigningExt.id0=1.3.6.1.5.5.7.3.3
ca.Policy.rule.CODESigningExt.implName=ExtendedKeyUsageExt
ca.Policy.rule.CODESigningExt.predicate=certType==codeSignClient
ca.Policy.rule.CRLDistributionPointsExt.enable=false
ca.Policy.rule.CRLDistributionPointsExt.implName=CRLDistributionPointsExt
ca.Policy.rule.CRLDistributionPointsExt.issuerName0=
ca.Policy.rule.CRLDistributionPointsExt.issuerName1=
ca.Policy.rule.CRLDistributionPointsExt.issuerName2=
ca.Policy.rule.CRLDistributionPointsExt.issuerType0=
Chapter 10
CMS Configuration
359
Modifying the Configuration
ca.Policy.rule.CRLDistributionPointsExt.issuerType1=
ca.Policy.rule.CRLDistributionPointsExt.issuerType2=
ca.Policy.rule.CRLDistributionPointsExt.numPoints=0
ca.Policy.rule.CRLDistributionPointsExt.pointName0=
ca.Policy.rule.CRLDistributionPointsExt.pointName1=
ca.Policy.rule.CRLDistributionPointsExt.pointName2=
ca.Policy.rule.CRLDistributionPointsExt.pointType0=
ca.Policy.rule.CRLDistributionPointsExt.pointType1=
ca.Policy.rule.CRLDistributionPointsExt.pointType2=
ca.Policy.rule.CRLDistributionPointsExt.predicate=
ca.Policy.rule.CRLDistributionPointsExt.reasons0=
ca.Policy.rule.CRLDistributionPointsExt.reasons1=
ca.Policy.rule.CRLDistributionPointsExt.reasons2=
ca.Policy.rule.CertificatePoliciesExt.enable=false
ca.Policy.rule.CertificatePoliciesExt.implName=CertificatePoliciesExt
ca.Policy.rule.CertificatePoliciesExt.policyId=
ca.Policy.rule.CertificatePoliciesExt.predicate=
ca.Policy.rule.ClientCertKeyUsageExt.digitalSignature=true
ca.Policy.rule.ClientCertKeyUsageExt.enable=true
ca.Policy.rule.ClientCertKeyUsageExt.implName=KeyUsageExt
ca.Policy.rule.ClientCertKeyUsageExt.keyEncipherment=true
ca.Policy.rule.ClientCertKeyUsageExt.nonRepudiation=true
ca.Policy.rule.ClientCertKeyUsageExt.predicate=certType==client
ca.Policy.rule.DSAKeyRule.enable=true
ca.Policy.rule.DSAKeyRule.implName=DSAKeyConstraints
ca.Policy.rule.DSAKeyRule.maxSize=2048
ca.Policy.rule.DSAKeyRule.minSize=512
ca.Policy.rule.DSAKeyRule.predicate=
ca.Policy.rule.DefaultRenewalValidityRule.enable=true
ca.Policy.rule.DefaultRenewalValidityRule.implName=RenewalValidityConstraints
ca.Policy.rule.DefaultRenewalValidityRule.maxValidity=365
ca.Policy.rule.DefaultRenewalValidityRule.minValidity=30
ca.Policy.rule.DefaultRenewalValidityRule.predicate=
ca.Policy.rule.DefaultRenewalValidityRule.renewalInterval=15
ca.Policy.rule.DefaultRevocationRule.enable=true
ca.Policy.rule.DefaultRevocationRule.implName=DefaultRevocation
ca.Policy.rule.DefaultRevocationRule.predicate=
ca.Policy.rule.DefaultValidityRule.enable=true
ca.Policy.rule.DefaultValidityRule.implName=ValidityConstraints
ca.Policy.rule.DefaultValidityRule.maxValidity=365
ca.Policy.rule.DefaultValidityRule.minValidity=30
ca.Policy.rule.DefaultValidityRule.predicate=
ca.Policy.rule.GenericASN1Ext.critical=false
ca.Policy.rule.GenericASN1Ext.enable=false
ca.Policy.rule.GenericASN1Ext.implName=GenericASN1Ext
360
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Modifying the Configuration
ca.Policy.rule.GenericASN1Ext.name=
ca.Policy.rule.GenericASN1Ext.oid=
ca.Policy.rule.GenericASN1Ext.pattern=
ca.Policy.rule.GenericASN1Ext.predicate=
ca.Policy.rule.GenericASN1Ext.attribute.0.source=
ca.Policy.rule.GenericASN1Ext.attribute.0.type=
ca.Policy.rule.GenericASN1Ext.attribute.0.value=
ca.Policy.rule.GenericASN1Ext.attribute.1.source=
ca.Policy.rule.GenericASN1Ext.attribute.1.type=
ca.Policy.rule.GenericASN1Ext.attribute.1.value=
ca.Policy.rule.GenericASN1Ext.attribute.2.source=
ca.Policy.rule.GenericASN1Ext.attribute.2.type=
ca.Policy.rule.GenericASN1Ext.attribute.2.value=
ca.Policy.rule.GenericASN1Ext.attribute.3.source=
ca.Policy.rule.GenericASN1Ext.attribute.3.type=
ca.Policy.rule.GenericASN1Ext.attribute.3.value=
ca.Policy.rule.GenericASN1Ext.attribute.4.source=
ca.Policy.rule.GenericASN1Ext.attribute.4.type=
ca.Policy.rule.GenericASN1Ext.attribute.4.value=
ca.Policy.rule.GenericASN1Ext.attribute.5.source=
ca.Policy.rule.GenericASN1Ext.attribute.5.type=
ca.Policy.rule.GenericASN1Ext.attribute.5.value=
ca.Policy.rule.GenericASN1Ext.attribute.6.source=
ca.Policy.rule.GenericASN1Ext.attribute.6.type=
ca.Policy.rule.GenericASN1Ext.attribute.6.value=
ca.Policy.rule.GenericASN1Ext.attribute.7.source=
ca.Policy.rule.GenericASN1Ext.attribute.7.type=
ca.Policy.rule.GenericASN1Ext.attribute.7.value=
ca.Policy.rule.GenericASN1Ext.attribute.8.source=
ca.Policy.rule.GenericASN1Ext.attribute.8.type=
ca.Policy.rule.GenericASN1Ext.attribute.8.value=
ca.Policy.rule.GenericASN1Ext.attribute.9.source=
ca.Policy.rule.GenericASN1Ext.attribute.9.type=
ca.Policy.rule.GenericASN1Ext.attribute.9.value=
ca.Policy.rule.IssuerRule.enable=false
ca.Policy.rule.IssuerRule.implName=IssuerConstraints
ca.Policy.rule.IssuerRule.issuerDN=
ca.Policy.rule.IssuerRule.predicate=certType==client AND certauthEnroll==on
ca.Policy.rule.KeyAlgRule.algorithms=RSA
ca.Policy.rule.KeyAlgRule.enable=true
ca.Policy.rule.KeyAlgRule.implName=KeyAlgorithmConstraints
ca.Policy.rule.KeyAlgRule.predicate=
ca.Policy.rule.NSCComment.enable=false
ca.Policy.rule.NSCComment.implName=NSCComment
ca.Policy.rule.NSCComment.policyId=
ca.Policy.rule.NSCComment.predicate=
ca.Policy.rule.NSCertTypeExt.enable=true
ca.Policy.rule.NSCertTypeExt.implName=NSCertTypeExt
Chapter 10
CMS Configuration
361
Modifying the Configuration
ca.Policy.rule.NSCertTypeExt.predicate=certType!=CEP-Request
ca.Policy.rule.NameConstraintsExt.critical=true
ca.Policy.rule.NameConstraintsExt.enable=false
ca.Policy.rule.NameConstraintsExt.implName=NameConstraintsExt
ca.Policy.rule.NameConstraintsExt.numExcludedSubtrees=3
ca.Policy.rule.NameConstraintsExt.numPermittedSubtrees=3
ca.Policy.rule.NameConstraintsExt.predicate=certType == ca
ca.Policy.rule.NameConstraintsExt.excludedSubtrees0.base=
ca.Policy.rule.NameConstraintsExt.excludedSubtrees0.max=-1
ca.Policy.rule.NameConstraintsExt.excludedSubtrees0.min=0
ca.Policy.rule.NameConstraintsExt.excludedSubtrees0.valueType=
ca.Policy.rule.NameConstraintsExt.excludedSubtrees1.base=
ca.Policy.rule.NameConstraintsExt.excludedSubtrees1.max=-1
ca.Policy.rule.NameConstraintsExt.excludedSubtrees1.min=0
ca.Policy.rule.NameConstraintsExt.excludedSubtrees1.valueType=
ca.Policy.rule.NameConstraintsExt.excludedSubtrees2.base=
ca.Policy.rule.NameConstraintsExt.excludedSubtrees2.max=-1
ca.Policy.rule.NameConstraintsExt.excludedSubtrees2.min=0
ca.Policy.rule.NameConstraintsExt.excludedSubtrees2.valueType=
ca.Policy.rule.NameConstraintsExt.permittedSubtrees0.base=
ca.Policy.rule.NameConstraintsExt.permittedSubtrees0.max=-1
ca.Policy.rule.NameConstraintsExt.permittedSubtrees0.min=0
ca.Policy.rule.NameConstraintsExt.permittedSubtrees0.valueType=
ca.Policy.rule.NameConstraintsExt.permittedSubtrees1.base=
ca.Policy.rule.NameConstraintsExt.permittedSubtrees1.max=-1
ca.Policy.rule.NameConstraintsExt.permittedSubtrees1.min=0
ca.Policy.rule.NameConstraintsExt.permittedSubtrees1.valueType=
ca.Policy.rule.NameConstraintsExt.permittedSubtrees2.base=
ca.Policy.rule.NameConstraintsExt.permittedSubtrees2.max=-1
ca.Policy.rule.NameConstraintsExt.permittedSubtrees2.min=0
ca.Policy.rule.NameConstraintsExt.permittedSubtrees2.valueType=
ca.Policy.rule.OCSPNoCheckExt.critical=false
ca.Policy.rule.OCSPNoCheckExt.enable=true
ca.Policy.rule.OCSPNoCheckExt.implName=OCSPNoCheckExt
ca.Policy.rule.OCSPNoCheckExt.predicate=certType==ocspResponder
ca.Policy.rule.OCSPSigningExt.critical=false
ca.Policy.rule.OCSPSigningExt.enable=true
ca.Policy.rule.OCSPSigningExt.id0=1.3.6.1.5.5.7.3.9
ca.Policy.rule.OCSPSigningExt.implName=ExtendedKeyUsageExt
ca.Policy.rule.OCSPSigningExt.predicate=certType==ocspResponder
ca.Policy.rule.ObjSignCertKeyUsageExt.digitalSignature=true
ca.Policy.rule.ObjSignCertKeyUsageExt.enable=true
ca.Policy.rule.ObjSignCertKeyUsageExt.implName=KeyUsageExt
ca.Policy.rule.ObjSignCertKeyUsageExt.keyCertsign=true
ca.Policy.rule.ObjSignCertKeyUsageExt.predicate=certType==objSignClient
ca.Policy.rule.PolicyConstraintsExt.critical=false
362
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Modifying the Configuration
ca.Policy.rule.PolicyConstraintsExt.enable=false
ca.Policy.rule.PolicyConstraintsExt.implName=PolicyConstraintsExt
ca.Policy.rule.PolicyConstraintsExt.inhibitPolicyMapping=0
ca.Policy.rule.PolicyConstraintsExt.predicate=certType==ca
ca.Policy.rule.PolicyConstraintsExt.reqExplicitPolicy=0
ca.Policy.rule.PolicyMappingsExt.critical=false
ca.Policy.rule.PolicyMappingsExt.enable=false
ca.Policy.rule.PolicyMappingsExt.implName=PolicyMappingsExt
ca.Policy.rule.PolicyMappingsExt.numPolicyMappings=1
ca.Policy.rule.PolicyMappingsExt.predicate=certType==ca
ca.Policy.rule.PolicyMappingsExt.policyMap0.issuerDomainPolicy=
ca.Policy.rule.PolicyMappingsExt.policyMap0.subjectDomainPolicy=
ca.Policy.rule.RMCertKeyUsageExt.digitalSignature=true
ca.Policy.rule.RMCertKeyUsageExt.enable=true
ca.Policy.rule.RMCertKeyUsageExt.implName=KeyUsageExt
ca.Policy.rule.RMCertKeyUsageExt.nonRepudiation=true
ca.Policy.rule.RMCertKeyUsageExt.predicate=certType==ra
ca.Policy.rule.RSAKeyRule.enable=false
ca.Policy.rule.RSAKeyRule.exponents=3,7,17,65537
ca.Policy.rule.RSAKeyRule.implName=RSAKeyConstraints
ca.Policy.rule.RSAKeyRule.maxSize=2048
ca.Policy.rule.RSAKeyRule.minSize=512
ca.Policy.rule.RSAKeyRule.predicate=
ca.Policy.rule.RenewalConstraintsRule.enable=true
ca.Policy.rule.RenewalConstraintsRule.implName=RenewalConstraints
ca.Policy.rule.RenewalConstraintsRule.predicate=
ca.Policy.rule.RevocationConstraintsRule.enable=true
ca.Policy.rule.RevocationConstraintsRule.implName=RevocationConstraints
ca.Policy.rule.RevocationConstraintsRule.predicate=
ca.Policy.rule.ServerCertKeyUsageExt.dataEncipherment=true
ca.Policy.rule.ServerCertKeyUsageExt.digitalSignature=true
ca.Policy.rule.ServerCertKeyUsageExt.enable=true
ca.Policy.rule.ServerCertKeyUsageExt.implName=KeyUsageExt
ca.Policy.rule.ServerCertKeyUsageExt.keyEncipherment=true
ca.Policy.rule.ServerCertKeyUsageExt.nonRepudiation=true
ca.Policy.rule.ServerCertKeyUsageExt.predicate=certType==server
ca.Policy.rule.SigningAlgRule.algorithms=MD5withRSA,MD2withRSA,SHA1withRSA,SHA1withDSA
ca.Policy.rule.SigningAlgRule.enable=true
ca.Policy.rule.SigningAlgRule.implName=SigningAlgorithmConstraints
ca.Policy.rule.SigningAlgRule.predicate=
ca.Policy.rule.SubCANameCheck.enable=true
ca.Policy.rule.SubCANameCheck.implName=SubCANameCheck
ca.Policy.rule.SubCANameCheck.predicate=
ca.Policy.rule.SubjectAltNameExt.enable=true
Chapter 10
CMS Configuration
363
Modifying the Configuration
ca.Policy.rule.SubjectAltNameExt.enableManualValues=false
ca.Policy.rule.SubjectAltNameExt.implName=SubjectAltNameExt
ca.Policy.rule.SubjectKeyIdentifierExt.enable=true
ca.Policy.rule.SubjectKeyIdentifierExt.implName=SubjectKeyIdentifierExt
ca.Policy.rule.SubjectKeyIdentifierExt.predicate=certType==ca
ca.Policy.rule.UniqueSubjectName.enable=false
ca.Policy.rule.UniqueSubjectName.implName=UniqueSubjectName
ca.Policy.rule.UniqueSubjectName.predicate=
ca.crl._000=##
ca.crl._001=## CA CRL
ca.crl._002=##
ca.crl.MasterCRL.allowExtensions=false
ca.crl.MasterCRL.autoUpdateInterval=20
ca.crl.MasterCRL.class=com.netscape.certsrv.ca.CRLIssuingPoint
ca.crl.MasterCRL.description=CA's complete Certificate Revocation List
ca.notification.certIssued.emailSubject=Your Certificate Request
ca.notification.certIssued.emailTemplate=/usr/netscape/cert-testCA/emails/
certIssued_CA.html
ca.notification.certIssued.enabled=false
ca.notification.certIssued.senderEmail=
ca.notification.requestInQ.emailSubject=Certificate Request in Queue
ca.notification.requestInQ.emailTemplate=/usr/netscape/cert-testCA/emails/
reqInQueue.html
ca.notification.requestInQ.enabled=false
ca.notification.requestInQ.recipientEmail=
ca.notification.requestInQ.senderEmail=
ca.publish.mapper.impl.LdapDNCompsMap.class=com.netscape.certsrv.ldap.LdapCertCompsMap
ca.publish.mapper.impl.LdapDNExactMap.class=com.netscape.certsrv.ldap.LdapCertExactMap
ca.publish.mapper.impl.LdapSimpleMap.class=com.netscape.certsrv.ldap.LdapSimpleMap
ca.publish.mapper.impl.LdapSubjAttrMap.class=com.netscape.certsrv.ldap.LdapCertSubjMap
ca.publish.mapper.instance.LdapCaCertMap.dnPattern=UID=$cert.cn,OU=people,O=$cert.o
ca.publish.mapper.instance.LdapCaCertMap.pluginName=LdapSimpleMap
ca.publish.mapper.instance.LdapCrlMap.dnPattern=UID=$cert.cn,OU=people,O=$cert.o
ca.publish.mapper.instance.LdapCrlMap.pluginName=LdapSimpleMap
ca.publish.mapper.instance.LdapUserCertMap.dnPattern=UID=$cert.UID,OU=people,O=$cert.o
ca.publish.mapper.instance.LdapUserCertMap.pluginName=LdapSimpleMap
ca.publish.publisher.impl.FileBasedPublisher.class=com.netscape.certsrv.ldap.
FileBasedPublisher
ca.publish.publisher.impl.LdapCaCertPublisher.class=com.netscape.certsrv.ldap.
LdapCaCertPublisher
ca.publish.publisher.impl.LdapCrlPublisher.class=com.netscape.certsrv.ldap.
LdapCrlPublisher
ca.publish.publisher.impl.LdapUserCertPublisher.class=com.netscape.certsrv.ldap.
LdapUserCertPublisher
ca.publish.publisher.impl.ValiCertPublisher.class=com.valicert.publisher.VcPublisher
364
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Modifying the Configuration
ca.publish.publisher.instance.LdapCaCertPublisher.caCertAttr=caCertificate;binary
ca.publish.publisher.instance.LdapCaCertPublisher.caObjectClass=certificationAuthority
ca.publish.publisher.instance.LdapCaCertPublisher.pluginName=LdapCaCertPublisher
ca.publish.publisher.instance.LdapCrlPublisher.crlAttr=certificateRevocationList;binary
ca.publish.publisher.instance.LdapCrlPublisher.pluginName=LdapCrlPublisher
ca.publish.publisher.instance.LdapUserCertPublisher.certAttr=userCertificate;binary
ca.publish.publisher.instance.LdapUserCertPublisher.pluginName=LdapUserCertPublisher
ca.publish.rule.impl.Rule.class=com.netscape.certsrv.ldap.LdapRule
ca.publish.rule.instance.LdapCaCertRule.enable=true
ca.publish.rule.instance.LdapCaCertRule.mapper=LdapCaCertMap
ca.publish.rule.instance.LdapCaCertRule.pluginName=Rule
ca.publish.rule.instance.LdapCaCertRule.predicate=
ca.publish.rule.instance.LdapCaCertRule.publisher=LdapCaCertPublisher
ca.publish.rule.instance.LdapCaCertRule.type=ca
ca.publish.rule.instance.LdapCrlRule.enable=true
ca.publish.rule.instance.LdapCrlRule.mapper=LdapCrlMap
ca.publish.rule.instance.LdapCrlRule.pluginName=Rule
ca.publish.rule.instance.LdapCrlRule.predicate=
ca.publish.rule.instance.LdapCrlRule.publisher=LdapCrlPublisher
ca.publish.rule.instance.LdapCrlRule.type=crl
ca.publish.rule.instance.LdapObjSignCertRule.enable=true
ca.publish.rule.instance.LdapObjSignCertRule.mapper=LdapUserCertMap
ca.publish.rule.instance.LdapObjSignCertRule.pluginName=Rule
ca.publish.rule.instance.LdapObjSignCertRule.predicate=
ca.publish.rule.instance.LdapObjSignCertRule.publisher=LdapUserCertPublisher
ca.publish.rule.instance.LdapObjSignCertRule.type=objSignClient
ca.publish.rule.instance.LdapUserCertRule.enable=true
ca.publish.rule.instance.LdapUserCertRule.mapper=LdapUserCertMap
ca.publish.rule.instance.LdapUserCertRule.pluginName=Rule
ca.publish.rule.instance.LdapUserCertRule.predicate=
ca.publish.rule.instance.LdapUserCertRule.publisher=LdapUserCertPublisher
ca.publish.rule.instance.LdapUserCertRule.type=client
ca.signing.cacertnickname=caSigningCert cert-testCA
ca.signing.defaultSigningAlgorithm=MD5withRSA
ca.signing.tokenname=Internal Key Storage Token
cms.version=4.22
dbs.ldap=internaldb
dbs.newSchemaEntryAdded=true
dbs.nextSerialNumber=1
eeGateway._000=##
eeGateway._001=## End Entity Gateway
eeGateway._002=##
Chapter 10
CMS Configuration
365
Modifying the Configuration
eeGateway.authority=ca
eeGateway.docRoot=/usr/netscape/cert-testCA/web/ee
eeGateway.dynamicVariables=serverdate=serverdate(),subsystemname=subsystemname(),
http=http()
eeGateway.enableConnector=true
eeGateway.keepAliveOn=true
eeGateway.mimeTypeConf=/usr/netscape/cert-testCA/config/mime.types
eeGateway.numServices=2
eeGateway.service0=http
eeGateway.service1=https
eeGateway.http.backlog=15
eeGateway.http.enable=true
eeGateway.http.port=4603
eeGateway.http.type=http
eeGateway.https.backlog=15
eeGateway.https.nickName=Server-Cert cert-testCA
eeGateway.https.port=4604
eeGateway.https.type=https
internaldb._000=##
internaldb._001=## Internal Database
internaldb._002=##
internaldb.maxConns=15
internaldb.minConns=3
internaldb.ldapauth.authtype=BasicAuth
internaldb.ldapauth.bindDN=cn=Directory Manager
internaldb.ldapauth.bindPWPrompt=Internal LDAP Database
internaldb.ldapconn.host=testCA.siroe.com
internaldb.ldapconn.port=3602
internaldb.ldapconn.secureConn=false
jobsScheduler._000=##
jobsScheduler._001=## jobScheduler
jobsScheduler._002=##
jobsScheduler.enabled=false
jobsScheduler.interval=1
jobsScheduler.impl.RenewalNotificationJob.class=com.netscape.certsrv.jobs.
RenewalNotificationJob
jobsScheduler.impl.RequestInQueueJob.class=com.netscape.certsrv.jobs.
RequestInQueueJob
jobsScheduler.impl.UnpublishExpiredJob.class=com.netscape.certsrv.jobs.
UnpublishExpiredJob
jobsScheduler.job.certRenewalNotifier.cron=0 3 * * 1-5
jobsScheduler.job.certRenewalNotifier.emailSubject=Certificate Renewal Notification
jobsScheduler.job.certRenewalNotifier.emailTemplate=/usr/netscape/cert-testCA/emails/
rnJob1.txt
jobsScheduler.job.certRenewalNotifier.enabled=false
jobsScheduler.job.certRenewalNotifier.notifyEndOffset=30
jobsScheduler.job.certRenewalNotifier.notifyTriggerOffset=30
jobsScheduler.job.certRenewalNotifier.pluginName=RenewalNotificationJob
jobsScheduler.job.certRenewalNotifier.senderEmail=
jobsScheduler.job.certRenewalNotifier.summary.emailSubject=Certificate Renewal
366
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Modifying the Configuration
Notification Summary
jobsScheduler.job.certRenewalNotifier.summary.emailTemplate=/usr/netscape/cert-testCA/
emails/rnJob1Summary.txt
jobsScheduler.job.certRenewalNotifier.summary.enabled=true
jobsScheduler.job.certRenewalNotifier.summary.itemTemplate=/usr/netscape/
cert-testCA/emails/rnJob1Item.txt
jobsScheduler.job.certRenewalNotifier.summary.recipientEmail=
jobsScheduler.job.certRenewalNotifier.summary.senderEmail=
jobsScheduler.job.requestInQueueNotifier.cron=0 0 * * 0
jobsScheduler.job.requestInQueueNotifier.enabled=false
jobsScheduler.job.requestInQueueNotifier.pluginName=RequestInQueueJob
jobsScheduler.job.requestInQueueNotifier.subsystemId=ca
jobsScheduler.job.requestInQueueNotifier.summary.emailSubject=Requests in Queue
Summary Report
jobsScheduler.job.requestInQueueNotifier.summary.emailTemplate=/usr/netscape/
cert-testCA/emails/riq1Summary.html
jobsScheduler.job.requestInQueueNotifier.summary.enabled=true
jobsScheduler.job.requestInQueueNotifier.summary.recipientEmail=
jobsScheduler.job.requestInQueueNotifier.summary.senderEmail=
jobsScheduler.job.unpublishExpiredCerts.cron=0 0 * * 6
jobsScheduler.job.unpublishExpiredCerts.enabled=false
jobsScheduler.job.unpublishExpiredCerts.pluginName=UnpublishExpiredJob
jobsScheduler.job.unpublishExpiredCerts.summary.emailSubject=Expired Certs
Unpublished Summary
jobsScheduler.job.unpublishExpiredCerts.summary.emailTemplate=/usr/netscape/
cert-testCA/emails/euJob1.html
jobsScheduler.job.unpublishExpiredCerts.summary.enabled=true
jobsScheduler.job.unpublishExpiredCerts.summary.itemTemplate=/usr/netscape/
cert-testCA/emails/euJob1Item.html
jobsScheduler.job.unpublishExpiredCerts.summary.recipientEmail=
jobsScheduler.job.unpublishExpiredCerts.summary.senderEmail=
jss._000=##
jss._001=## JSS
jss._002=##
jss.certdb=/usr/netscape/cert-testCA/config/cert7.db
jss.enable=true
jss.keydb=/usr/netscape/cert-testCA/config/key3.db
jss.moddb=/usr/netscape/admin-serv/config/secmodule.db
jss.ssl.cipherfortezza=true
jss.ssl.cipherpref=
jss.ssl.cipherversion=cipherdomestic
logAudit._000=##
logAudit._001=## Logging
logAudit._002=##
log.Error._000=##
log.Error._001=## Logging
log.Error._002=##
log.System._000=##
log.System._001=## Logging
log.System._002=##
Chapter 10
CMS Configuration
367
Modifying the Configuration
log.impl.NTEventLog.class=com.netscape.certsrv.logging.NTEventLog
log.impl.file.class=com.netscape.certsrv.logging.RollingLogFile
log.instance.Audit.bufferSize=512
log.instance.Audit.enable=true
log.instance.Audit.expirationTime=2592000
log.instance.Audit.fileName=/usr/netscape/cert-testCA/logs/audit
log.instance.Audit.flushInterval=5
log.instance.Audit.level=1
log.instance.Audit.maxFileSize=100
log.instance.Audit.pluginName=file
log.instance.Audit.rolloverInterval=2592000
log.instance.Audit.type=audit
log.instance.Error.bufferSize=512
log.instance.Error.enable=true
log.instance.Error.expirationTime=2592000
log.instance.Error.fileName=/usr/netscape/cert-testCA/logs/error
log.instance.Error.flushInterval=5
log.instance.Error.level=3
log.instance.Error.maxFileSize=100
log.instance.Error.pluginName=file
log.instance.Error.rolloverInterval=2592000
log.instance.Error.type=system
log.instance.NTAudit.NTEventSourceName=cert-testCA
log.instance.NTAudit.enable=true
log.instance.NTAudit.level=1
log.instance.NTAudit.pluginName=NTEventLog
log.instance.NTAudit.type=audit
log.instance.NTSystem.NTEventSourceName=cert-testCA
log.instance.NTSystem.enable=true
log.instance.NTSystem.level=2
log.instance.NTSystem.pluginName=NTEventLog
log.instance.NTSystem.type=system
log.instance.System.bufferSize=512
log.instance.System.enable=true
log.instance.System.expirationTime=2592000
log.instance.System.fileName=/usr/netscape/cert-testCA/logs/system
log.instance.System.flushInterval=5
log.instance.System.level=3
log.instance.System.maxFileSize=100
log.instance.System.pluginName=file
log.instance.System.rolloverInterval=2592000
log.instance.System.type=system
368
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Modifying the Configuration
oidmap.auth_info_access.class=com.netscape.certsrv.cert.AuthInfoAccessExtension
oidmap.auth_info_access.oid=1.3.6.1.5.5.7.1.1
oidmap.challenge_password.class=com.netscape.certsrv.cmsgateway.cert.
crs.ChallengePassword
oidmap.challenge_password.oid=1.2.840.113549.1.9.7
oidmap.extended_key_usage.class=com.netscape.certsrv.cert.ExtendedKeyUsageExtension
oidmap.extended_key_usage.oid=2.5.29.37
oidmap.extensions_requested_pkcs9.class=com.netscape.certsrv.cmsgateway.cert.
crs.ExtensionsRequested
oidmap.extensions_requested_pkcs9.oid=1.2.840.113549.1.9.14
oidmap.extensions_requested_vsgn.class=com.netscape.certsrv.cmsgateway.cert.
crs.ExtensionsRequested
oidmap.extensions_requested_vsgn.oid=2.16.840.1.113733.1.9.8
oidmap.netscape_comment.class=netscape.security.x509.NSCCommentExtension
oidmap.netscape_comment.oid=2.16.840.1.113730.1.13
oidmap.ocsp_no_check.class=com.netscape.certsrv.cert.OCSPNoCheckExtension
oidmap.ocsp_no_check.oid=1.3.6.1.5.5.7.48.1.5
os.serverName=cert-testCA
os.userid=nobody
radm._000=##
radm._001=## Remote Admin
radm._002=##
radm.keepAliveOn=true
radm.mimeTypeConf=/usr/netscape/cert-testCA/config/mime.types
radm.numServices=1
radm.service0=https
radm.https.backlog=15
radm.https.maxThreads=10
radm.https.minThreads=3
radm.https.nickName=Server-Cert cert-testCA
radm.https.port=4606
radm.https.timeout=0
radm.https.type=https
smtp.host=localhost
smtp.port=25
subsystem._000=##
subsystem._001=## Loadable Subsystems
subsystem._002=##
subsystem.0.class=com.netscape.certsrv.ca.CertificateAuthority
subsystem.0.id=ca
subsystem.1.class=com.netscape.certsrv.cmsgateway.EEGateway
subsystem.1.id=eeGateway
usrgrp._000=##
usrgrp._001=## User/Group
usrgrp._002=##
usrgrp.ldap=internaldb
Chapter 10
CMS Configuration
369
Road Map to Configuring Subsystems
Road Map to Configuring Subsystems
This section outlines how to configure an instance of Certificate Management
System and indicates where to find the information required to accomplish the
task.
Step 1. Check Which Subsystems are Installed in the Instance
Log in to the CMS window for the CMS instance you installed, and check the
navigation tree to see which subsystems are installed in that instance; this way you
will know the subsystems you should configure. To log in to the CMS window, see
“Logging In to the CMS Window” on page 347.
Step 2. Check the Port Numbers
Check the port numbers assigned for administration, agent, and end-entity
operations. Make the appropriate modifications, if necessary. Keep in mind that all
subsystems installed in an instance use the same ports, but can be configured to
listen on different IP addresses. For instructions, see “Configuring Port Numbers”
on page 378.
Step 3. Verify Key Pair and Certificates
When you install a CMS instance, the server prompts you to create the certificates
required for the subsystems in that instance to function. You should check the
certificates used by each subsystem, and determine if you need to get additional
certificates, use hardware tokens, and so on.
370
•
Each subsystem in an instance has a set of certificates that it uses for specific
purposes. Understand how and when the subsystem uses its certificates. For
details, see “Keys and Certificates for the Main Subsystems” on page 440.
•
Determine if you want to generate any new certificates. For example, if you
have two subsystems installed in an instance, you may want them to use
separate SSL server certificates; by default, there’s only one SSL server
certificate per instance. For details, see “Getting New Certificates for the
Subsystems” on page 489.
•
Determine if you want to use hardware tokens for generating and storing these
certificates. If required, install new hardware tokens. For details, see “Tokens
for Storing CMS Keys and Certificates” on page 454.
•
Determine if you want to renew any of the existing certificates. For example, if
you have issued certificates with very short validity periods, you might want
to renew them. For details, see “Renewing Certificates for the Subsystems” on
page 497.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Road Map to Configuring Subsystems
•
Check the certificate database to see which CA certificates are trusted. Delete
any unwanted CA certificates, change the trust settings of CA certificates that
you don’t want to trust to untrusted, and install any new CA certificate or
certificate chains. For details, see “Managing the Certificate Database” on
page 505.
Step 4. Set up Privileged Users
Set up required administrators and agents. This way you can delegate
administration and agent tasks to other individuals. For details, see “Setting Up
Privileged Users” on page 407.
If you have installed remote Registration Managers that have certificates signed by
third-party CAs (that is, not by a Certificate Manager), you should add their
certificates to the Certificate Manager’s database to facilitate SSL client
authenticated communication. For details, see “Setting Up Trusted Managers” on
page 417.
Step 5. Customize End-Entity and Agent Forms
End entities can interact with the Certificate Manager and Registration Manager
with the help of end-entity forms; end entities cannot interact with the Data
Recovery Manager. Similarly, agents can interact with the appropriate subsystem
using the agent forms. Certificate Management System provides HTML
forms-based interfaces for end entities and agents out of the box. For details, see
CMS Customization Guide.
Determine which forms you want to use for end-entity enrollment and whether
they require any customization. You may also use your own forms for this
purpose, provided you add the required JavaScript.
When customizing end-entity forms, keep in mind the authentication
method—manual or automated—you want to employ for your end entities.
Step 6. Setup Authentication for End Users
Depending on how you’ve deployed Certificate Management System, you may
need to do this for a Certificate Manager or Registration Manager, or for both. For
example, you may have a PKI setup in which Registration Managers act as front
ends to Certificate Managers—that is, end entities interact with Registration
Managers only; they do not interact with the Certificate Manager.
Determine which of the authentication plug-in module is suitable for your users
and then configure the Certificate Manager or Registration Manager to use that
authentication method; see “Configuring Authentication for End-User Enrollment”
on page 525.
Chapter 10
CMS Configuration
371
Road Map to Configuring Subsystems
Step 7: Enable Event-Driven Notifications
You can also configure both Certificate Manager and Registration Manager to send
email notifications automatically to end entities, agents, or administrators when
certain events occur. Unlike jobs that are executed at preconfigured schedule, these
notifications are event-driven—that is, whenever an event occurs, the server
notifies the user. Notifiable events include certificate issuance and pending
requests in an agent queue.
Decide if you want to turn on any of the notifications. For details, see “Configuring
a Subsytem to Send Notifications” on page 563.
Step 8. Schedule Jobs
Each CMS instance includes a Job Scheduler component that can execute specific
jobs at specified times. The Job Scheduler functions similar to a traditional Unix
cron daemon in that it takes registered cron jobs and executes them at a
preconfigured date and time.
During installation, a few jobs are already created and enabled. Jobs that you might
want to schedule include email notifications of timed events (such as the expiration
of a certificate) that require action on the part of users, and periodic activities such
as removing expired certificates from the publishing directory. For scheduling jobs,
follow the instructions in “Configuring a Subsystem to Run Automated Jobs” on
page 569.
Step 9. Set up Policies
Each subsystem in a CMS instance has its own policy processor. If you have
installed more than one subsystem in an instance, you should apply the
instructions in this section to each subsystem. That is, you should configure the
Certificate Manager and Registration Manager for certificate formulation, issuance,
renewal, and revocation policies. Similarly, configure the Data Recovery Manager
for key archival and recovery policies. To understand policy, see “Introduction to
Policy” on page 583.
372
1.
During installation, a few policy rules are already created and enabled. Check
each policy rule and decide whether you want to use it. If you don’t, you can
either disable it or delete it altogether from the configuration. For those rules
that you want to use, check the configuration parameter values and make
changes as appropriate.
2.
Determine if you want to add any new policy rules. Check the built-in policy
plug-in modules to see if they can be used to create the rules you want. You can
also plug-in your own modules in the CMS framework and use them.
3.
Add new rules, if required.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Road Map to Configuring Subsystems
For instructions to do all of the above tasks, see “Configuring Policy Rules for a
Subsystem” on page 593.
Step 10. Set up Publishing
This step is optional, and is applicable to the Certificate Manager only—you need
to do this only if you want the Certificate Manager to publish certificates and CRLs
to any of the supported repositories.
•
To configure a Certificate Manager to publish certificates and CRLs to an
LDAP-compliant directory, such as Netscape Directory Server, see
“Configuring a Certificate Manager to Publish Certificates and CRLs” on
page 619.
•
To configure a Certificate Manager to publish certificates and CRLs to a flat
file, see “Configuring Certificate Manager to Publish to Files” on page 671.
•
To configure a Certificate Manager to publish CRLs to the Online Certificate
Status Manager (an online validation authority), see “Setting Up a Remote
OCSP Responder” on page 712.
Step 11. Set up Key Archival and Recovery
If you have installed the Data Recovery Manager, follow the instructions in
“Configuring Key Archival and Recovery Process” on page 755 and set up archival
and recovery for end users’ encryption private keys.
Step 12. Set up Logging
Each instance of Certificate Management System maintains extensive audit, error,
and system logs. By looking at these logs, you can monitor a server’s activities.
Also, by configuring these logs, you can control the information that gets written to
the log files. Because Certificate Management System maintains the log files in the
file system of the host machine, it is important that you configure the logs
appropriately (so that the host machine doesn’t get overloaded). Be sure to read
“Introduction to Logs” on page 769; this chapter will help you decide log
configuration.
Once you decide the configuration for server logs, follow the information in
“Configuring CMS Logs” on page 777 and configure all the three logs. Then, start
monitoring the server’s activities as explained in “Monitoring CMS Logs” on
page 783.
Chapter 10
CMS Configuration
373
Road Map to Configuring Subsystems
Step 13. Plan for Backing up CMS Configuration and Data
It is a good practice to periodically back up the CMS data on to some backup
media. Creating backups will help you use them for data restoration in the event of
data loss. For details, r details, see Chapter 6, “Backing Up and Restoring Data” of
CMS Command-Line Tools Guide.
374
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Chapter
11
Setting Up Ports
Subsystems installed in an instance of iPlanet Certificate Management System
(CMS) share certain configuration information. For example, they use the same
administration, agent, and end-entity ports; internal database for data storage; mail
server for automated notifications; internal token and trust database for PKI
operations; SSL ciphers during SSL negotiation; privileged users; and log files to
log messages to. This chapter explains how to configure the ports for a CMS
instance.
The chapter has the following sections:
•
CMS Ports (page 375)
•
Configuring Port Numbers (page 378)
CMS Ports
Certificate Management System listens to different ports for requests from
different users. As illustrated in Figure 11-1, it listens to the administration port,
the agent port, and end-entity ports.
375
CMS Ports
Figure 11-1
CMS ports for administration, agent, and end-entity operations
When choosing ports for Certificate Management System, be sure to choose ports
that are unique on the host system—that is, no other application can be using, or
attempting to use, the port numbers you assign to Certificate Management System.
To verify that a port is available for use, check the appropriate file for your
operating system; port numbers for network-accessible services are usually
maintained in a file named services. (On Unix, if you are not running as root or
superuser when you install or start the server, you will have to use a port number
higher than 1024.)
Remote Administration Port
The administration port is an SSL (encrypted) port at which Certificate
Management System listens to requests from its administration interface;
administrators make these requests from the CMS window. When you install
Certificate Management System, it assigns a random number (greater than 1024) as
the administration port number. You can change this port number at any time, to
any number between 1 and 65535. For security reasons you should consider
changing the administration port number periodically.
376
iPlanet Certificate Management System Installation and Setup Guide • March 2001
CMS Ports
Agent Port
The agent port is an SSL (encrypted) port at which Certificate Management System
listens to requests from agents; agents make these requests from the appropriate
Agent Services interface.
•
The Certificate Manager and Registration Manager agents use the agent port to
process certificate issuance and management requests from end entities and to
perform certain other privileged operations over HTTPS.
•
Data Recovery Manager agents use the agent port for recovering end users’
encryption private keys over HTTPS.
Agent functions always require SSL client authentication. For a brief list of
supported agent operations, see “Agent Services Interface” on page 68.
When you install Certificate Management System, it assigns a random number
(greater than 1024) as the agent port number and prompts you to change it, if
necessary; the port number can be any number between 1 and 65535. The number
you choose for the agent port affects your agent users—all agents access Certificate
Management System by specifying the name of the server (the CMS instance) and
the agent port number in the URL. For example, if you choose port number 4430,
the URL would look like this:
https://<hostname>:4430/<subsystem>
<hostname> is in the form <machine_name>.<your_domain>.<domain>
<subsystem> is a prefix identifying the subsystem that hosts the agent
interface: ca for the Certificate Manager, ra for the Registration Manager, , kra
for the Data Recovery Manager, and ocsp for Online Certificate Status
Manager.
For example, the URL to a Certificate Manager agent interface would look like this:
https://demoCA.siroe.com:5600/ca
If you change the agent port number, be sure to inform your agent users.
End-Entity Ports
For requests from end entities, Certificate Management System can listen to two
ports, an SSL (encrypted) port and a non-SSL port. End entities make these
requests from the end entity services interface; see “End-Entity Services Interface”
on page 72.
Chapter 11
Setting Up Ports
377
Configuring Port Numbers
Certificate Management System provides the following services through the HTTP
and HTTPS ports:
•
The HTTP port can be used to service end-entity-initiated PKI requests, such as
enrollment, renewal, and revocation; enrollment requests can include requests
from Cisco routers (using the CEP protocol). You have the choice of keeping
this port enabled or disabled.
•
The HTTPS port can be used to provide the following services for enforcing
data privacy and client authentication:
❍
❍
End-entity-initiated PKI requests, such as enrollment, renewal, and
revocation.
General certificate retrieval requests, such as retrieving a single certificate
identified by a serial number, listing certificates based on certain criteria
(for example, an LDAP search filter defined over standard attributes), and
getting a CA’s certificate chain.
Similar to the HTTP port, you can enable or disable the HTTP port. For
example, if you don’t want end-entity interaction with a Certificate Manager,
you can disable the HTTPS port. For details, see “Step 6. Enable End-Entity
Interaction” on page 543.
Configuring Port Numbers
Configuring port numbers for a CMS instance involves two steps:
•
Step 1. Specify the Port Number
•
Step 2: Specify IP Addresses
Step 1. Specify the Port Number
To change the administration, agent, or end-entity port numbers used by a CMS
instance:
1.
378
Log in to the CMS window (see “Logging In to the CMS Window” on
page 347).
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Configuring Port Numbers
2.
Select the Configuration tab.
The Network tab appears.
3.
To change the administration port number, enter the port number in the
Administration section:
SSL port. Type a TCP/IP port number. Certificate Management System uses
this port for SSL-enabled communications with the CMS window—that is,
HTTPS requests from administrators. Make sure the port number you specify
is unique on the host system.
Backlog. Type the number of connections that can be waiting to be serviced at
the administration port. The default number is 15. The number you enter in
this field is passed to the operating system’s listen() call.
To change the agent port number, enter the port number in the Agent section:
SSL port. Type a TCP/IP port number. Certificate Management System uses
this port for SSL-enabled communications with the Agent Services
interface—that is, HTTPS requests from agents. Make sure the port number
you specify is unique on the host system.
Backlog. Type the number of connections that can be waiting to be serviced at
the agent port. The default number is 15. The number you enter in this field is
passed to the operating system’s listen() call.
Chapter 11
Setting Up Ports
379
Configuring Port Numbers
4.
To change the end-entity port numbers, enter the port numbers in the End
Entity section.
Certificate Management System is capable of simultaneous SSL and non-SSL
communications at the end-entity port. This means that you do not have to
choose between SSL and non-SSL communications; you can use both at the
same time. But if you prefer, you can disable the non-SSL port by unchecking
the “Enable” option.
Port. Type a TCP/IP port number that is unique on the host system. Certificate
Management System uses this port for non-SSL communications with the end
entity services interface.
This port is provided to allow enrollments of end entities that do not support
SSL; for example, HTTP requests from end entities such as routers. You can use
the Enable check box to turn this port on or off. Keep in mind that if this port is
enabled, end entities will be able to enroll over HTTP too, which means their
certificate requests could be intercepted and replayed to the server.
If the CMS instance includes a Certificate Manager and if the Certificate
Manager is configured to service OCSP requests from OCSP-compliant clients,
then this port must be enabled so that OCSP-compliant clients can successfully
query the Certificate Manager for the revocation status of a certificate. For
details, see “Setting Up a Certificate Manager with OCSP Service” on page 699.
Backlog. Type the number of connections that can be waiting to be serviced at
the end entity HTTP port. The default number is 15. The number you enter in
this field is passed to the operating system’s listen() call.
Enable. This check box allows you to enable or disable the HTTP port.
Uncheck the option if you want to disable the port.
For issuing certificates to routers (using the CEP protocol), the port must be
enabled. For details, see Chapter 25, “Setting Up CEP Enrollment.”
SSL port. Type a TCP/IP port number. Certificate Management System uses
this port for SSL-enabled communications with the end entity services
interface (that is, HTTPS requests from end entities during certificate
enrollment, renewal, and revocation). Make sure the port number you specify
is unique on the host system.
If you don’t want end-entity interaction with a subsystem, for example, if you
don’t want end entities to interact with a Certificate Manager, you can disable
this port too (in addition to the HTTP port). See “Step 6. Enable End-Entity
Interaction” on page 543.
380
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Configuring Port Numbers
Backlog. Type the number of connections that can be waiting to be serviced at
the end-entity HTTPS port. The default number is 15. The number you enter in
this field is passed to the operating system’s listen() call.
5.
To save your changes, click Save.
The CMS configuration is modified. If the changes you made require you to
restart the server, you will be prompted accordingly. In that case, restart the
server.
Step 2: Specify IP Addresses
This step is optional.
You can configure CMS instances to listen to specific IP addresses. For example,
you can install the Certificate Manager and Data Recovery Manager on a single
host, in separate instances, and then configure the instances so that the Certificate
Manager is served on one IP address and the Data Recovery Manager is served on
another address.
To clarify this further, consider the machine that hosts the Certificate Manager and
Data Recovery Manager has two Ethernet cards that respond to the IP addresses
197.1.137.97 and 197.1.137.98. You can set up the Certificate Manager to listen
to port 443 for the IP address 197.1.137.97 and the Data Recovery Manager to
listen to port 443 for the IP address 197.1.137.98.
To configure a CMS instance to listen to specific IP addresses:
1.
Stop the CMS instance; see “Stopping Certificate Management System” on
page 324.
2.
Open the configuration file in a text editor; to locate the file, see “Locating the
Configuration File” on page 352.
3.
Add one or more of the following as appropriate:
❍
For remote administration port, add this line: radm.https.host=
❍
For agent port, add this line: agentGateway.https.host=
❍
For end-entity HTTPS port, add this line: eeGateway.https.host=
❍
For end-entity HTTP port, add this line: eeGateway.http.host=
Chapter 11
Setting Up Ports
381
Configuring Port Numbers
4.
Add the IP address or the host name or interface name as the value for the
parameter you just added. For example,
❍
❍
382
If you entered an IP address as the value, the parameter would look similar
to this: radm.https.host=197.1.137.98
If you entered the host name as the value, the parameter would look
similar to this: radm.https.host=cert.siroe.com
5.
If necessary, repeat step 4 for the other ports.
6.
Save your changes, and close the configuration file.
7.
Start the CMS instance; see “Starting Certificate Management System” on
page 316.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Chapter
12
Setting Up Internal Database
Subsystems installed in an instance of iPlanet Certificate Management System
(CMS) share certain configuration information. For example, they use the same
administration, agent, and end-entity ports; internal database for data storage; mail
server for automated notifications; internal token and trust database for PKI
operations; SSL ciphers during SSL negotiation; privileged users; and log files to
log messages to. This chapter explains how to configure the internal database for a
CMS instance.
The chapter has the following sections:
•
Internal Database (page 383)
•
Configuring the Internal Database (page 384)
Internal Database
Certificate Management System performs various certificate and key-management
functions in response to the requests it receives. These functions include the
following:
•
Storing and retrieving of certificate issuance requests
•
Storing and retrieving of certificate records
•
Storing of CRLs
•
Storing and retrieving of end users’ encryption private key records
383
Configuring the Internal Database
To fulfill these functions, Certificate Management System maintains a persistent
store—a preconfigured Netscape Directory Server—referred to as the internal
database or local database. The internal database is installed automatically as a part of
the CMS installation. It is used as an embedded database exclusively by Certificate
Management System and can be managed using Directory management tools that
come with Netscape Directory Server.
The Directory Server instance used for the internal database is different from the
LDAP-compliant directory that you use to manage your corporatewide data (users
and groups, their certificates, CRLs, and so on).
•
In Netscape Console, you can distinguish an internal database instance from
other Directory Server instances. It is in this form:
<cms_instance_id>-db
<cms_instance_id> is the ID of the CMS instance that is using the
database. You first specified this when you installed this server.
•
If you check the files installed under <server_root>, the internal database
instance appears like this: slapd-<cms_instance_id>-db
Keep in mind that the subsystems use the database for storing different objects. A
Certificate Manager stores all the data, certificate issuance requests, certificates,
CRLs, and related information; a Registration Manager only stores the certificate
issuance requests it receives; and a Data Recovery Manager only stores key records
and related data.
Configuring the Internal Database
Each instance of Certificate Management System uses a Netscape Directory Server
instance as its internal database. All the subsystems that were installed in a CMS
instance use the same Directory Server instance to store their data. For example, if
you installed a Certificate Manager and Data Recovery Manager together, they use
the same internal database for data storage.
CAUTION
384
The internal database schema is preconfigured for storing CMS data
only. Do not make any changes to it or configure Certificate
Management System to use any other LDAP directory. Doing so can
result in loss of data. Also, do not attempt to use this database for
any other purpose.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Configuring the Internal Database
Step 1. Identify the Directory Server Instance
To identify the Directory Server instance that a CMS instance should use as its
internal database:
1.
Log in to the CMS window (see “Logging In to the CMS Window” on
page 347).
2.
Select the Configuration tab, and then in the right pane, select the Internal
Database tab.
3.
Identify a Directory Server instance by providing the following details:
Host name. Type the full host name of the machine on which Netscape
Directory Server is installed. Certificate Management System uses this name to
access the directory. The format for the host name is as follows:
<machine_name>.<your_domain>.<domain>
By default, the host name of the Directory Server instance being used as the
internal database is shown as localhost instead of the actual host name (for
example, certificates.netscape.com). This is done on purpose to insulate
the internal database from being visible outside the system—that is, a server on
localhost can only be accessed from the local machine. Thus, the default
configuration minimizes the risk of someone connecting to this Directory
Server instance from outside the local machine.
Chapter 12
Setting Up Internal Database
385
Configuring the Internal Database
You can configure the host name to something other than localhost if you
know what you are doing and you think you can limit the visibility of the
internal database to a local subnet. For example, if you installed Certificate
Management System and Directory Server on separate machines for load
balancing, you will have to specify the host name of the machine in which
Directory Server is installed.
Port number. Type a TCP/IP port number; Certificate Management System
uses this port for non-SSL communications with the Directory Server instance
that is functioning as the internal database. Make sure that the port you specify
is unique on the host system.
Directory manager DN. Type the distinguished name (DN) of an entry in your
LDAP directory that has read and write permission to the entire directory tree.
Certificate Management System will use this DN when it accesses the directory
tree to communicate with the directory. Keep in mind that the access control
set up for this DN determines whether Certificate Management System can
communicate with the directory. Typically, you would want to enter the
directory manager’s DN (the root DN) because this DN will have read/write
permission to the entire directory tree.
4.
To save your changes, click Save.
The CMS configuration is modified. If the changes you made require you to
restart the server, you will be prompted accordingly. In that case, restart the
server.
Step 2. Restrict Access to the Internal Database
This step is optional.
Netscape Console displays an entry or icon for the Directory Server instance that
Certificate Management System uses as its internal database. You can distinguish
an internal database instance from other Directory Server instances. It is in this
form: slapd-<cms_instance_id>-db
Unlike the CMS window, access to which is restricted to users with CMS
administrator privileges, the Directory Server window can be accessed by the
person who has privileges to access Netscape Console. That is, this person can
open the Directory Server window for the internal database and make changes to
the data stored there. For example, this person can make changes to the CMS
administrators group, such as deleting existing users and adding entries for self.
386
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Configuring the Internal Database
If you are concerned about this, you can restrict access to the internal database to
only those users who know its Directory Manager DN and corresponding
password. You can change this password by modifying the single sign-on
password cache. For instructions, check the section that explains how to change the
password of an entry in the password cache in Chapter 2, “Password Cache
Utility” of CMS Command-Line Tools Guide.
1.
Log in to Netscape Console (see “Logging In to the CMS Window” on
page 347).
2.
In the Console tab, select the server group that contains the CMS instance you
want.
3.
Select the entry that corresponds to the internal database to which you want to
restrict access, and click Open.
The Directory Server window appears.
4.
Select the Configuration tab.
5.
In the navigation tree, expand Plugins, and then select Pass Through
Authentication.
6.
In the right pane, uncheck or disable the “Enable plugin” option.
7.
Click Save to save your changes.
You are prompted to restart the server.
Chapter 12
Setting Up Internal Database
387
Configuring the Internal Database
8.
Click the Tasks tab and click “Restart the Directory Server.”
9.
Close the Directory Server window.
10. When the server is restarted, from Netscape Console, open the Directory
Server window.
The “Login to Directory” dialog box appears; the Distinguished Name field
displays the Directory Manager DN and you’re required to enter the password
that corresponds to this entry.
The Directory Server window (for the internal database) opens only if you
enter the correct password.
388
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Chapter
13
Managing Privileged Users and
Groups
Privileged users are users who are designated to perform privileged operations on
iPlanet Certificate Management System (CMS); these operations are privileged
because no one else can perform them. You assign privileged-user status to a user by
storing the user’s login information in the internal database of Certificate
Management System, associating the user’s login information with a personal
certificate (if the user is an agent or a trusted manager), and granting access
permissions to various CMS resources by adding the user to appropriate groups.
This chapter describes the types of privileged users you need to set up for a CMS
instance, what each user does, how Certificate Management System identifies these
users, and how you create and manage these users. The chapter also describes
what a group is and discusses the groups that Certificate Management System
provides by default.
The chapter has the following sections:
•
Privileged-User Types and Responsibilities (page 390)
•
Groups and Their Privileges (page 402)
•
Setting Up Privileged Users (page 407)
•
Changing Privileged-User Information (page 433)
•
Deleting a Privileged User (page 437)
389
Privileged-User Types and Responsibilities
Privileged-User Types and Responsibilities
After you install Certificate Management System, your first task is to set up
privileged users. There are three types of privileged users: administrators, agents,
and trusted managers.
•
Administrators are users (people) who manage server-specific tasks for the CMS
maangers, the Certificate Manager, Registration Manager, Data Recovery
Manager, and Online Certificate Status Manager. For details, see
“Administrators” on page 390.
•
Agents are users (people) who manage the request queues for the CMS
managers. For details, see “Agents” on page 391.
•
Trusted managers are CMS subsystems that are connected to other subsystems
and that are trusted to perform certain activities for them. For example, you
might set up a Registration Manager to screen end-entity certificate requests
for a Certificate Manager. Because the Certificate Manager trusts the
Registration Manager, it approves all certificate requests received from this
Registration Manager. For details, see “Trusted Managers” on page 398.
The role of a privileged user—whether administrator, agent, or trusted
manager—is determined by the group to which the user belongs. This is explained
in “Groups and Their Privileges” on page 402.
Administrators
Administrators are users who have been assigned CMS administration
privileges—permission to access the CMS window and perform all the system
administration tasks defined there. You assign these privileges to users by adding
them to the internal database and assigning membership in a group called
Administrators that Certificate Management System creates during installation.
For each CMS instance, the server must have at least one administrator. You can
also have more than one individual administering the server.
During installation, Certificate Management System prompts you to provide
information for creating the first user entry in the Administrators group.
Following installation, therefore, this group has a single user entry. For more
information about this group, see “Group for Administrators” on page 403.
Certificate Management System authenticates users with administrator-level
privileges based on its built-in authentication mechanism. This is explained in
“Authentication of Administrators” on page 514.
390
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Privileged-User Types and Responsibilities
Agents
Agents are users who have been assigned end-entity certificate- and
key-management privileges. Certificate Management System defines four agent
roles, one for each of its subsystems: Certificate Manager agents, Registration
Manager agents, Data Recovery Manager agents, and Online Certificate Status
Manager agents.
Agents interact with the corresponding CMS manager to manage operations such
as these:
•
List, approve, and reject pending certificate issuance and renewal requests
•
List certificates
•
Search for certificates
•
Revoke end-entity certificates
•
Manually update certificates and CRLs stored in a publishing directory
•
Manage key archival and retrieval requests
•
Manually add CRLs to the Online Certificate Status Manager
•
See the list of OCSP requests processed by the Online Certificate Status
Manager
For a complete list of agent tasks, see CMS Agent’s Guide. To locate this guide, see
“Where to Go for Related Information” on page 28.
All agents perform their tasks through HTML forms-based interfaces. The HTML
forms an agent uses to manage a specific subsystem are grouped together and
named after the subsystem they represent. For example, the forms-based interface
provided for the Certificate Manager is called Certificate Manager Agent Services (see
Figure 13-1). For more information, see “Agent Services Interface” on page 68.
Agents cannot access the CMS window and perform the tasks provided within the
Netscape Console framework—unless they are given administrator privileges.
Chapter
13
Managing Privileged Users and Groups
391
Privileged-User Types and Responsibilities
Figure 13-1
Agents use the HTML forms-based interface called Agent Services
Each subsystem installed in a CMS instance must have at least one agent. You can
also have more than one individual managing agent services.
You create agents by adding them to the internal database of a CMS instance,
assigning membership in the appropriate agent groups, and identifying certificates
that the agents must use for SSL client authentication to the subsystem (for it to
service requests from the agents). For information about agents’ certificates, see
“Agent’s Certificate for SSL Client Authentication” on page 393. For information
on creating agents for a CMS instance, see “Setting Up Agents” on page 410.
During installation, Certificate Management System automatically creates
appropriate groups with agent privileges for the CMS managers installed; for
example, if you install a Certificate Manager and a Data Recovery Manager in a
CMS instance, you’ll see two agent groups. For more information about these
groups, see “Groups for Agents” on page 404.
Certificate Management System authenticates users with agent-level privileges
based on its built-in authentication mechanism. This is explained in
“Authentication of Agents” on page 516.
392
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Privileged-User Types and Responsibilities
Agent’s Certificate for SSL Client Authentication
To make a user an agent for a subsystem, one of the things you must do is store the
user’s client (personal) certificate information in the internal database of the
subsystem. For example, if you set up an agent for a Certificate Manager, you store
the agent’s client certificate in the internal database of that Certificate Manager.
Then, when the subsystem receives a request from the agent, it uses this certificate
to verify the authenticity of the request before servicing it. For details on how the
subsystem verifies the authenticity of a request from an agent, see “Authentication
of Agents” on page 516.
If the user you want to set up as an agent does not own a client certificate, ask the
user to get one. Depending on your company’s PKI policy, the user could get the
client certificate from either an internally deployed CA or any public CA.
Keep in mind that the CA that signs your agents’ certificates must be trusted by the
subsystem that processes requests sent by these agents; for example, if your
subsystems are set up not to trust public CAs, your agents should not get their
certificates signed by public CAs. Make sure that the CA’s certificate exists in the
subsystem’s certificate or trust database and that the certificate is valid and trusted.
To check whether or not the CA’s certificate exists in a subsystem’s trust database,
follow the instructions in “Viewing the Certificate Database Content” on page 505.
•
If the CA’s certificate isn’t listed, follow the instructions in “Using the Wizard
to Install a Certificate or Certificate Chain” on page 475 and add the certificate
to the subsystem’s certificate database.
•
If the CA’s certificate is listed but untrusted, follow the instructions in
“Changing the Trust Settings of a CA Certificate” on page 508 and change the
setting to trusted.
Getting an Agent’s Certificate from a Public CA
The following general guidelines explain how a user can get a client certificate
from a public CA and how you can copy that certificate (in base-64 encoded form)
to the internal database of the appropriate subsystem:
1.
The user sends a client certificate request to the public CA from the client
machine that he or she will use to access the subsystem from the Agent
Services interface. It is important that the user generate and submit this request
from the machine she or he will use later to access the subsystem, because part
of this request process generates a private key on the local machine.
Alternatively, if location independence is required, the user can use a
hardware token, such as a smart card, to generate and store the key pair (and
the certificate when the user receives it from the public CA).
Chapter
13
Managing Privileged Users and Groups
393
Privileged-User Types and Responsibilities
2.
When the user receives the certificate from the public CA, the user imports the
certificate into the web browser that he or she will use to access the subsystem.
It is a good idea to ask the user to inform you that the certificate has been
installed.
3.
Ask the user to send you the certificate information sent by the public CA. In
the information that you receive, locate the user’s certificate in base-64 encoded
form.
You can also get the user’s certificate from the public CA that issued it. Access
the public CA site, search for the user’s certificate, and locate the certificate in
base-64 encoded form.
4.
Copy the base-64 encoded certificate, including the -----BEGIN
CERTIFICATE----- and -----END CERTIFICATE----- marker lines, to a text
file.
The copied information should look similar to the following example:
-----BEGIN CERTIFICATE----MIICJzCCAZCgAwIBAgIBAzANBgkqhkiG9w0BAQQFADBCMSAwHgYDVQQKExdOZXRzY2FwZSBDb21tdW5pYF
0aW9uczngjhnMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyNzE5MDAwMFoXDTk5MDIyMzE5MDAw
MnbjdgngYoxIDAeBgNVBAoTF05ldHNjYXBlIENvbW11bmljYXRpb25zMQ8wDQYDVQQLEwZQZW9wbGUxFzA
VBgoJkiaJkIsZAEBEwdzdXByaXlhMRcwFQYDVQQDEw5TdXByaXlhIFNoZXR0eTEjMCEGCSqGSIb3DbndgJ
ARYUc3Vwcml5YUBuZXRzY2FwZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBIAkEAoYiYgthgtbbnjfngjn
jgnagwJjAOBgNVHQ8BAf8EBAMCBLAwFAYJYIZIAYb4QgEj
-----END CERTIFICATE-----
5.
Save the text file and use it to store a copy of the certificate in a subsystem’s
internal database (see “Step 3. Store the Agent’s SSL Client Certificate in the
Internal Database” on page 414).
Getting an Agent’s Certificate from Certificate Management System
The following general instructions explain how a user can get a client certificate
from Certificate Management System and how you can copy that certificate (in
base-64 encoded form) to the internal database of a subsystem:
1.
394
The user sends a client certificate request to Certificate Management System
from the client machine that he or she will use to access the subsystem from the
Agent Services interface. It is important that the user generate and submit this
request from the machine he or she will use later to access the subsystem,
because part of this request process generates a private key on the local
machine. Alternatively, if location independence is required, the user can also
use a hardware token, such as a smart card, to generate and store the key pair
(and the certificate when the user receives it from the public CA).
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Privileged-User Types and Responsibilities
2.
Depending on how your Certificate Management System is configured for
certificate issuance, one of the following events happen:
❍
❍
If Certificate Management System is configured for manual certification,
an issuing agent must process the request and approve it for issuance.
Once the request is approved, the server issues the client certificate to the
user.
If Certificate Management System is configured for automated certification
and the request passes authentication and policy checks, the server
automatically issues the client certificate to the user.
3.
When the user receives the certificate, the user must import the certificate into
the web browser that he or she will use to access the subsystem. It is a good
idea to ask the user to inform you that the certificate has been installed.
4.
After the user imports the certificate into the web browser, you need to copy
the certificate (in base-64 encoded form) in order to be able to add it to a
subsystem’s internal database.
To copy an agent’s certificate:
1.
Open a web browser window.
2.
Go to the Certificate Management System home page for end entities (by
default, it is called End Entity Registration Services).
The default URL for this page is in this form:
http://<host_name>:<end_entity_HTTP_port> or
https://<host_name>:<end_entity_HTTPS_port>
In both cases, the <host_name> must be in this form:
<machine_name>.<your_domain>.<domain>
For example, the URL may look like this: https://testCA.siroe.com
3.
Click the Retrieval tab.
4.
In the left frame, click either the List Certificates or Search For Certificates link,
and search for the user’s certificate.
5.
In the page listing the results of your search, click the Details button (next to
the corresponding user’s entry) to see detailed information about the
certificate.
6.
Scroll down to the section named “Installing This Certificate in a Client,”
which contains the user’s certificate in base-64 encoded form.
Chapter
13
Managing Privileged Users and Groups
395
Privileged-User Types and Responsibilities
7.
Copy the base-64 encoded certificate, including the -----BEGIN
CERTIFICATE----- and -----END CERTIFICATE----- marker lines, to a text
file.
The copied information should look similar to the following example:
-----BEGIN CERTIFICATE----MIICJzCCAZCgAwIBAgIBAzANBgkqhkiG9w0BAQQFADBCMSAwHgYDVQQKExdOZXRzY2FwZSBDb21tdW5pY2
F0aW9uczngjhnMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyNzE5MDAwMFoXDTk5MDIyMzE5MDA
wMnbjdgngYoxIDAeBgNVBAoTF05ldHNjYXBlIENvbW11bmljYXRpb25zMQ8wDQYDVQQLEwZQZW9wbGUxFz
AVBgoJkiaJkIsZAEBEwdzdXByaXlhMRcwFQYDVQQDEw5TdXByaXlhIFNoZXR0eTEjMCEGCSqGSIb3Dbndg
JARYUc3Vwcml5YUBuZXRzY2FwZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBIAkEAoYiYgthgtbbnjfngj
njgnagwJjAOBgNVHQ8BAf8EBAMCBLAwFAYJYIZIAYb4QgEBAQHBAQDAgCAMA0GCSq
-----END CERTIFICATE-----
8.
Save the text file and use it to store a copy of the certificate in a subsystem’s
internal database (see “Step 3. Store the Agent’s SSL Client Certificate in the
Internal Database” on page 414).
Revocation Status Checking of Agent Certificates
You can configure a Certificate Manager and Registration Manager to check the
revocation status of an agent’s certificate the server receives during SSL client
authentication. You can configure a Data Recovery Manager (or Online Certificate
Status Manager) to check the revocation status of its agents’ certificates only if you
have deployed an OCSP responder and have issued agent certificates with
Authority Information Access extension pointing to the OCSP responder. For
information about adding Authority Information Access extension to certificates,
see “Configuring Policy Rules for a Subsystem” on page 593. For information about
setting up an OCSP responder, see Chapter 21, “Setting Up an OCSP Responder.”
NOTE
The CMS configuration file (CMS.cfg) includes a parameter named
jss.ocspcheck.enable, which enables you to specify whether a
CMS manager should use Online Certificate Status Protocol (OCSP)
to verify the revocation status of the certificate it receives as a part
of SSL client or server authentication (from clients or servers it
makes connections with). If you change the value of this parameter
to true, the CMS manager reads the Authority Information Access
extension in the certificate and verifies the revocation status of the
certificate from the OCSP responder specified in the extension.
396
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Privileged-User Types and Responsibilities
The configuration files of both Certificate Manager and Registration Manager
include parameters that enable you to specify whether the server should do the
revocation checking and if it should, at what interval. Note that the
revocation-status verification works for only those agent certificates that have been
issued by the Certificate Manager (and not by any third-party CAs).
The configuration parameters pertaining to this feature of the Certificate Manager
are as follows:
auths.revocationChecking.bufferSize=5
auths.revocationChecking.ca=ca
auths.revocationChecking.enabled=true
auths.revocationChecking.unknownStateInterval=0
auths.revocationChecking.validityInterval=120
The configuration parameters pertaining to this feature of the Registration
Manager are as follows:
auths.revocationChecking.bufferSize=5
auths.revocationChecking.enabled=true
auths.revocationChecking.ra=ra
auths.revocationChecking.unknownStateInterval=0
auths.revocationChecking.validityInterval=120
If you have a Data Recovery Manager installed in the same instance, in addition to
the above lines, you’ll also notice this line:
auths.revocationChecking.kra=kra
Table 13-1 provides details for the above mentioned parameters.
Table 13-1 Configuration parameters for checking the revocation status of agents’ certificates
Parameter name
Description
revocationChecking.bufferSize
Specifies the total number of last-checked certificates the
server should maintain in its cache. For example, if you
configure the buffer size to be 2, the server retains the last two
certificates it checked in its cache. By default, the server caches
the last 5 certificates.
revocationChecking.<subsystem>
Specifies the name of the CMS instance. <subsystem>
indicates whether the subsystem is a Certificate Manager (ca)
or Registration Manager (ra). You must not change the
default values.
revocationChecking.enabled
Specifies whether revocation checking is to be is enabled or
disabled. To enable the feature, enter true; to disable the
feature, enter false. By default, the feature is enabled.
Chapter
13
Managing Privileged Users and Groups
397
Privileged-User Types and Responsibilities
Table 13-1 Configuration parameters for checking the revocation status of agents’ certificates (Continued)
Parameter name
Description
revocationChecking.
unknownStateInterval
The default interval is o seconds.
revocationChecking.
validityInterval
Specifies how long, in seconds, the cached certificates are
considered valid. Be judicious when choosing the interval,
especially when configuring a Registration Manager. For
example, if you configure the validity period to be 60 seconds,
the server discards the certificates in its cache every minute
and attempts to retrieve them from their source—the
Certificate Manager uses its internal database to retrieve and
verify the revocation status of the certificates, whereas the
Registration Manager retrieves certificates from its own
internal database and then requests the Certificate Manager
for the revocation status of these certificates.
The default validity period is 120 seconds (2 minutes).
To configure a Certificate Manager or Registration Manager to verify the
revocation status of its agents’ certificates:
1.
Stop the CMS instance; see “Stopping Certificate Management System” on
page 324.
2.
Go to this directory: <server_root>/cert-<instance_id>/config
3.
Open the configuration file (CMS.cfg) in a text editor.
4.
Locate the parameters mentioned above and edit their values as appropriate.
5.
Save your changes, and close the configuration file.
6.
Start the CMS instance; see “Starting Certificate Management System” on
page 316.
Trusted Managers
Trusted managers are those CMS subsystems or managers that are connected to
other CMS subsystems and that are trusted to perform specific functions for them.
In other words, a trusted manager acts as a front end to the subsystem that trusts it,
performing specific functions, depending on the subsystem to which it is
connected. You establish this trust between the two subsystems by configuring
them to function in certain way.
398
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Privileged-User Types and Responsibilities
Subsystems That Can Function as Trusted Managers
In Certificate Management System, the Registration Manager and Certificate
Manager can function as a trusted manager; the Data Recovery Manager and
Online Certificate Status Manager cannot function as a trusted manager.
You can configure a Certificate Manager to delegate its end-entity interactions to a
trusted Registration Manager, for reasons of localizability (proximity to end
entities), customizability, and CA scalability; the Certificate Manager trusts the
Registration Manager and signs all certificate signing requests sent by this
Registration Manager. For example, as illustrated in the figure below, you might
deploy one or more Registration Managers to process, approve, and forward
certificate signing requests to a Certificate Manager.
You can configure a Registration Manager to delegate its end-entity interactions to
a trusted Registration Manager, for reasons of localizability (proximity to end
entities), customizability, and scalability; the Registration Manager trusts the
Registration Manager and services all certificate requests sent by this Registration
Manager. For example, as illustrated in the figure below, you might deploy one or
more Registration Managers to forward requests to another Registration Manager
in a Registration Manager chain. (The Registration Manager passing the request
acts as the client and the one receiving the request acts as the server.)
Chapter
13
Managing Privileged Users and Groups
399
Privileged-User Types and Responsibilities
You can configure a Data Recovery Manager to delegate its end-entity interactions
to a trusted Certificate Manager or Registration Manager for security reasons; the
Data Recovery Manager trusts the Certificate Manager or Registration Manager
and services all key archival and recovery requests initiated by this subsystem. For
example, as illustrated in figure below, you might deploy one or more Certificate
Managers or Registration Managers to send key archival or recovery requests to a
Data Recovery Manager.
Connectors for Linking Trusted Managers
Certificate Management System supports proprietary HTTPS connectors for
linking CMS subsystems. You can use these connectors to make the following
connections:
•
Registration Manager to Certificate Manager
•
Registration Manager to Registration Manager
•
Registration Manager to Data Recovery Manager
•
Certificate Manager to Data Recovery Manager
•
Certificate Manager to Certificate Manager (in a cloned-CA setup, which is
explained in “Cloning a Certificate Manager” on page 288)
Figure 13-2 illustrates how a trusted Registration Manager communicates with a
Certificate Manager.
400
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Privileged-User Types and Responsibilities
Figure 13-2
Connectivity service between a trusted Registration Manager and other
subsystems
Keep in mind that a trusted manager does not take on the main functions of the
subsystem that trusts it. For example, if a Registration Manager is connected to a
Certificate Manager, the Registration Manager has no authority to issue (sign)
certificates or CRLs. It receives end-entity requests, authenticates them, and
forwards them to the Certificate Manager for signing. After receiving a response
from the Certificate Manager, it notifies the end entity of the results.
Similarly, a Certificate Manager or Registration Manager connected to a Data
Recovery Manager has no authority to archive and recover end users’ encryption
private keys.
You can configure a subsystem to trust one or more managers. You do this by
adding these managers as privileged users to the internal database of that
subsystem, assigning them memberships in the appropriate group, and identifying
the certificates the managers must use for SSL client authentication to the
subsystem they report to. For information about adding a trusted manager, see
“Setting Up Trusted Managers” on page 417.
During installation, Certificate Management System automatically creates a group
with trusted manager privileges. For more information about this group, see
“Group for Trusted Managers” on page 406.
Trusted Manager’s Certificate for SSL Client Authentication
By default, a Registration Manager that has been set up to function as a trusted
manager uses its signing certificate for SSL client authentication to the subsystem
that trusts it. For information on this certificate, see “Signing Key Pair and
Certificate” on page 449. Similarly, a Certificate Manager that has been set up to
function as a trusted manager uses its SSL server certificate for SSL client
authentication to the subsystem that trusts it. For information on this certificate, see
“SSL Server Key Pair and Certificate” on page 445.
Chapter
13
Managing Privileged Users and Groups
401
Groups and Their Privileges
When you set up a trusted manager for a CMS subsystem, it is important to know
which CA has issued the certificate the trusted manager will use for SSL client
authentication to the subsystem. The certificate must be issued by a CA that the
subsystem trusts. For example, when you set up a trusted Registration Manager for
a subsystem, it is important to know which CA has issued the Registration
Manager’s signing certificate. The certificate must be issued by a CA that the
subsystem trusts. If the subsystem is a Certificate Manager, the certificate must be
issued by either the Certificate Manager itself or a CA that the Certificate Manager
trusts. Similarly, if the Registration Manager is connected to a Data Recovery
Manager, the signing certificate must be issued by the CA that the Data Recovery
Manager trusts.
The issuer of a Registration Manager’s signing certificate is the CA from which you
requested the certificate when you installed the Registration Manager. If you have
renewed the certificate since installation, the issuer is the CA from which you
requested the renewed certificate. Check the signing certificate for its issuer’s
name; see “Viewing the Certificate Database Content” on page 505. You can also
find this information by looking at the installation worksheet you completed in
preparation for installing the system.
Once you learn the issuer’s name, verify that this CA’s certificate exists in the
subsystem’s trust database and that the certificate is trusted. To check whether the
CA’s certificate exists in the subsystem’s trust database, follow the instructions in
“Viewing the Certificate Database Content” on page 505.
•
If the CA’s certificate isn’t listed, follow the instructions in “Using the Wizard
to Install a Certificate or Certificate Chain” on page 475 and add the certificate
to the subsystem’s certificate database.
•
If the CA’s certificate is listed but untrusted, follow the instructions in
“Changing the Trust Settings of a CA Certificate” on page 508 and change the
trust setting to trusted.
Groups and Their Privileges
In Certificate Management System, a group refers to a collection of privileged
users—administrators, agents, or trusted Registration Managers. Each group has
predetermined privileges, based on its access control. All users belonging to a
group automatically inherit the privileges of that group.
402
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Groups and Their Privileges
When you installed Certificate Management System, it automatically created the
following groups for the subsystems you installed:
•
Group for Administrators
•
Groups for Agents
•
Group for Trusted Managers
These default groups are created in the internal database of the appropriate CMS
instance. They can help you set up your privileged users quickly and easily.
You can add new privileged users to these groups; see “Setting Up Privileged
Users” on page 407. You cannot delete or change the group names. Also, don't
change the internal database in which the groups are stored.
Group for Administrators
During installation, Certificate Management System automatically creates a group
called Administrators and adds a user to this group; the server sets the name of
this user to the certificate administrator ID (of the CMS administrator) you specified
during installation. If you don’t remember this name, see the installation
worksheet you completed in preparation for installing the system (see
(“Administrator” on page 197). For example, if you specified admin as the user ID
for the CMS administrator, the name of the user in the Administrators group will
be admin.
Keep in mind that the Administrators group must always contain at least one
user entry. This means you can delete the entry that was created in this group
during installation, provided you add another user to the group.
After installation, be sure to do the following:
1.
Log in to the CMS window with the administrator ID and password specified
during installation.
2.
Depending on the components you installed, create one or more privileged
users and add them to the appropriate groups. It is recommended that you add
at least one more user to the Administrators group. For instructions on
creating privileged users and adding them to one or more groups, see “Setting
Up Privileged Users” on page 407.
Chapter
13
Managing Privileged Users and Groups
403
Groups and Their Privileges
Groups for Agents
Depending on the subsystems you chose to install, Certificate Management System
automatically creates a combination of the following groups for a CMS instance:
•
Certificate Manager Agents group, if you have installed the Certificate
Manager
•
Registration Manager Agents group, if you have installed the Registration
Manager
•
Data Recovery Manager Agents group, if you have installed the Data
Recovery Manager
•
Online Certificate Status Manager Agents group, if you have installed
the Online Certificate Status Manager
Group for Certificate Manager Agents
When the Certificate Manager is installed, a group called Certificate Manager
Agents is automatically created in its internal database. After installation, this
group has a single user entry—when you get the first agent certificate from the
Certificate Manager (see “Stage 3. Enrolling for Administrator/Agent Certificate”
on page 277), the server automatically adds the initial administrator as the agent
and stores a copy of the agent certificate against that user entry. The user ID for this
agent user is the same as the certificate administrator ID, as specified during
installation.
The Certificate Manager Agents group has access rights to agent-specific
resources of the Certificate Manager; that is, privileged users you add to this group
automatically inherit access rights to the agent port of the Certificate Manager. For
information on ports, see “CMS Ports” on page 375.
After installation, you should add to this group the privileged users to whom you
want to assign Certificate Manager agent privileges. All agents who belong to the
Certificate Manager Agents group can access the Certificate Manager Agent
Services interface; see “Certificate Manager Agent Services” on page 68.
For an agent to be able to carry on SSL client-authenticated communication with a
Certificate Manager, you need to do additional configurations. See “Setting Up
Agents” on page 410.
Group for Registration Manager Agents
When the Registration Manager is installed, a group called Registration
Manager Agents is automatically created in its internal database. By default, this
group has no entries.
404
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Groups and Their Privileges
The Registration Manager Agents group has access rights to agent-specific
resources of the Registration Manager; that is, privileged users you add to this
group automatically inherit access rights to the agent ports of the Registration
Manager. For information on ports, see “CMS Ports” on page 375.
After installation, you should add to this group the privileged users to whom you
want to assign Registration Manager agent privileges. All agents who belong to the
Registration Manager Agents group can access the Registration Manager Agent
Services interface; see “Registration Manager Agent Services” on page 69.
For an agent to be able to do SSL client-authenticated communication with a
Registration Manager, you need to do additional configurations. See “Setting Up
Agents” on page 410.
Group for Data Recovery Manager Agents
When the Data Recovery Manager is installed, a group called Data Recovery
Manager Agents is automatically created in its internal database. By default, this
group has no entries. Note that if the Data Recovery Manager is colocated with a
Certificate Manager, following installation, this group has a single user
entry—when you get the very first agent certificate from the Certificate Manager,
the server automatically adds the initial administrator as the agent and stores a
copy of the agent certificate against that user entry. The user ID for this agent user
is the same as the certificate administrator ID (as specified during installation).
The Data Recovery Manager Agents group has access rights to agent-specific
resources of the Data Recovery Manager; that is, privileged users you add to this
group automatically inherit access rights to the agent ports of the Data Recovery
Manager. For information on ports, see “CMS Ports” on page 375.
After installation, you should add to this group the privileged users to whom you
want to assign Data Recovery Manager agent privileges. All agents who belong to
the Data Recovery Manager Agents group can access the Data Recovery
Manager Agent Services interface; see “Data Recovery Manager Agent Services”
on page 70.
For an agent to be able to carry on SSL client-authenticated communication with a
Data Recovery Manager, you need to do additional configurations. See “Setting Up
Agents” on page 410.
Group for Online Certificate Status Manager Agents
When the Online Certificate Status Manager is installed, a group called Online
Certificate Status Manager Agents is automatically created in its internal
database. By default, this group has no entries.
Chapter
13
Managing Privileged Users and Groups
405
Groups and Their Privileges
The Online Certificate Status Manager Agents group has access rights to
agent-specific resources of the Online Certificate Status Manager; that is, privileged
users you add to this group automatically inherit access rights to the agent ports of
the Online Certificate Status Manager. For information on ports, see “CMS Ports”
on page 375.
After installation, you should add to this group the privileged users to whom you
want to assign Online Certificate Status Manager agent privileges. All agents who
belong to the Online Certificate Status Manager Agents group can access the
Online Certificate Status Manager Agent Services interface; see “Online Certificate
Status Manager Agent Services Interface” on page 71.
For an agent to be able to do SSL client-authenticated communication with a
Online Certificate Status Manager, you need to do additional configurations. See
“Setting Up Agents” on page 410.
Group for Trusted Managers
When the Certificate Manager, Registration Manager, or Data Recovery Manager is
installed, a group called Trusted Managers is automatically created in its internal
database. By default, this group has no entries.
The Trusted Managers group has access rights to the corresponding agent
gateway; that is, the subsystems you add to this group automatically inherit access
rights to the agent port of the corresponding Certificate Manager, Registration
Manager, or Data Recovery Manager. For information on ports, see “CMS Ports”
on page 375.
After installation, you should add to this group the subsystems that you want to
function as trusted managers. All subsystems that belong to the Trusted
Managers group can carry on SSL client-authenticated communication with the
subsystem that trusts them and receive responses back.
For a Registration Manager to be able to do SSL client-authenticated
communication with a subsystem, you need to do additional configurations. See
“Setting Up Trusted Managers” on page 417.
406
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Setting Up Privileged Users
Setting Up Privileged Users
Setting up privileged users for a CMS instance involves adding the appropriate
user information to the internal database of that instance. You can set up any
number of privileged users for a CMS instance. If the user is a person (that is, an
administrator or agent), you can put that user into as many groups as you like.
This section describes the following tasks:
•
Setting Up Administrators
•
Setting Up Agents
•
Setting Up Trusted Managers
Setting Up Administrators
You need at least one administrator for each instance of Certificate Management
System. To understand the role of an administrator, see “Administrators” on
page 390.
To set up an administrator follow these steps:
•
Step 1. Find the Required Information
•
Step 2. Add the Information to the Internal Database
Step 1. Find the Required Information
Note the user’s corporate information, such as name, user ID, email address, and
phone number.
Step 2. Add the Information to the Internal Database
To add the information to the internal database of a CMS instance:
1.
Log in to the CMS window (see “Logging In to the CMS Window” on
page 347).
Chapter
13
Managing Privileged Users and Groups
407
Setting Up Privileged Users
2.
In the navigation tree, select Users and Groups.
The Users tab appears on the right pane.
3.
Click Add.
The Select User Type window appears.
408
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Setting Up Privileged Users
4.
Select Administrator and click OK.
The Edit User Information window appears.
5.
Specify information as appropriate:
User ID. Type a user ID or login name for the user. The ID can be an
alphanumeric string of up to 255 characters. Give this ID to the user. The user is
required to enter this ID in the login screen of the CMS window; see “Logging
In to the CMS Window” on page 347.
Full name. Type the user’s full name. The user never sees this. This field is to
help you keep track of your users. The name can be an alphanumeric string of
up to 255 characters.
Password. Type a password of up to eight characters for the user. Give this
password to the user. The user is required to enter this password in the login
screen of the CMS window.
Confirm password. Retype the password exactly as you typed it in the
Password field.
Email. Type the user’s complete email address. The user never sees this. This
field is to help you contact the user, if the need arises.
Phone. Type the user’s phone number. The user never sees this. This field is to
help you contact the user, if the need arises.
Group. Select Administrators; see “Group for Administrators” on page 403.
When you set up a user, you can add him or her to only one group. To add the
user to another group, see “Changing Members in a Group” on page 435.
6.
Click OK.
You are returned to the Users tab. The administrator you just added will be
displayed in the list of users.
7.
Click Refresh to view the updated configuration.
Chapter
13
Managing Privileged Users and Groups
409
Setting Up Privileged Users
Setting Up Agents
You need an agent for each subsystem installed in a given CMS instance. To
understand the role of an agent, see “Agents” on page 391. This section explains
how to add agents to a CMS instance.
You can set up agents for a CMS instance in two ways:
•
Setting up Agents Using the Automated Process
•
Setting up Agents Using the Manual Process
Setting up Agents Using the Automated Process
Certificate Management System automates the process of setting up agents if
agents request their certificate using the manual enrollment form. The automated
process is built into the request-approval form (the page that displays the pending
request) in the Agent Services interface and it enables the person who has both
Certificate Manager agent and Administrator privileges to create new agents for a
CMS instance—that is, the Certificate Manager agent who approves new agents’
certificate requests must belong to both Certificate Manager Agents and
Administrators groups in the internal database of the Certificate Manager.
The request-approval form includes a checkbox labeled “This certificate is for a
<subsystem> agent”, where <subsystem> indicates Certificate Manager,
Registration Manager, or Data Recovery Manager. Selecting the checkbox indicates
that the user who has requested the certificate should be made an agent for the
specified subsystem. Selecting the checkbox also requires the Certificate Manager
agent to specify a user ID for the new agent.
If the Certificate Manager agent approves the certificate request with the checkbox
selected and user ID specified, the server automatically adds the user as an agent to
its internal database, copies the user’s client certificate to the database, and
associates the certificate with the new user’s entry.
If you want to test this feature, follow these steps:
410
1.
Open a web browser window.
2.
Access the end-entity interface.
3.
In the Enrollment tab, under Browser, select Manual.
4.
In the enrollment form that appears, enter sample data and submit the request.
5.
Next, access the Certificate Manager Agent Services interface.
6.
Click List Requests.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Setting Up Privileged Users
7.
In the page that displays, select the “Show pending requests”, and click Find.
8.
In the list of certificate signing requests that displays, select the request you
submitted.
9.
In the request approval form for user enrollment requests, verify the request. If
required, adjust some of the parameters such as the subject name and validity
period.
10. Next, check the box labeled “This certificate is for a Certificate Manager agent”,
specify a user ID for the new agent, and approve the certificate request.
The Certificate Manager processes the requests, issues the certificate to the
user, automatically adds the user as an agent to its user and group database,
copies the user’s client certificate to the database, and associates the certificate
with the new user’s entry.
11. To verify, log in to the CMS window for the Certificate Manager.
12. In the navigation tree, click Users and Groups.
13. In the list of users, you should find the user ID you specified for the new agent.
To view the certificate issued to the new agent, select the user ID and click
Certificates.
Setting up Agents Using the Manual Process
Typically, you add agents to a CMS instance by manually creating a
privileged-user entry for the agent in the corresponding subsystem’s user and
group database and then add the agent’s certificate to the database.
Setting up an agent involves the following steps:
•
Step 1. Find the Required Information
•
Step 2. Add the Information to the Internal Database
•
Step 3. Store the Agent’s SSL Client Certificate in the Internal Database
•
Step 4. Check the Certificate Database for the CA Certificate
Chapter
13
Managing Privileged Users and Groups
411
Setting Up Privileged Users
Step 1. Find the Required Information
Before adding an agent to the internal database of a CMS instance:
•
Note the user’s corporate information, such as name, login ID, password, email
address, and phone number.
•
Make sure the user has one or more client certificates that are currently valid;
the certificate must not have expired, been revoked, or been signed by an
untrusted authority. If the user does not own a client certificate, either issue the
user a certificate or ask the user to get a certificate. For details, see “Agent’s
Certificate for SSL Client Authentication” on page 393.
•
Identify the certificate that the user must use for SSL client authentication to
Certificate Management System. You can identify more than one certificate if
you want.
•
Copy this certificate, in base-64 encoded format, to a text file.
Step 2. Add the Information to the Internal Database
To add the information to the internal database of a CMS instance:
1.
Log in to the CMS window (see “Logging In to the CMS Window” on
page 347).
2.
In the navigation tree, select Users and Groups.
The Users tab appears.
412
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Setting Up Privileged Users
3.
Click Add.
The Select User Type window appears.
4.
Select Agent and click OK.
The Edit User Information window appears.
5.
Specify information as appropriate.
The information you enter here is to help you keep track of your agent users;
the user never sees or uses it. The server relies solely on the agent’s client
certificate (which you will add next) for authentication.
User ID. Type the user ID or login name. The ID can be an alphanumeric string
of up to 255 characters.
Full name. Type the user’s full name. The name can be an alphanumeric string
of up to 255 characters.
Email. Type the user’s complete email address.
Phone. Type the user’s phone number.
Chapter
13
Managing Privileged Users and Groups
413
Setting Up Privileged Users
Group. Choose the appropriate agent group; for more information about this
group, see “Groups for Agents” on page 404. When you set up a user, you can
add her or him to only one group. To add the user to another group, see
“Changing Members in a Group” on page 435.
6.
Click OK.
You are returned to the Users tab. The agent you just added is displayed in the
list of users.
What you do next depends on whether you have the agent’s certificate:
•
If you copied the user’s certificate in base-64 encoded form to a text file,
proceed to Step 3. (For details on getting the user’s certificate, see “Agent’s
Certificate for SSL Client Authentication” on page 393.)
•
Otherwise, save your changes.
You can add the certificate to the internal database later, following the
instructions provided in “Changing a Privileged User’s Certificate” on
page 434.
Step 3. Store the Agent’s SSL Client Certificate in the Internal Database
To store a copy of an agent’s SSL client certificate in the internal database:
1.
In the Users tab, click Certificates.
The Manage User Certificates window appears.
2.
Click Import.
The Import Certificate window appears.
414
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Setting Up Privileged Users
3.
Click inside the text area, and paste the user’s certificate in base-64 encoded
form.
Be sure to include the -----BEGIN CERTIFICATE----- and -----END
CERTIFICATE----- marker lines.
4.
Click OK.
You are returned to the Manage User Certificates window. The certificate you
imported should now be listed in this window.
Chapter
13
Managing Privileged Users and Groups
415
Setting Up Privileged Users
5.
To view the certificate you imported, select it and click View.
The certificate information appears.
6.
Click Done.
You are returned to the Users tab.
7.
Click Refresh to view the updated configuration.
Step 4. Check the Certificate Database for the CA Certificate
The CA that signed the agent’s SSL client certificate must be trusted by the
subsystem that services requests from the agent. Make sure that this CA’s
certificate exists in the subsystem’s certificate database (internal or external) and
that it is trusted. To check whether the CA’s certificate exists in your subsystem’s
certificate database, follow the instructions in “Viewing the Certificate Database
Content” on page 505.
416
•
If the CA certificate isn’t listed, follow the instructions in “Using the Wizard to
Install a Certificate or Certificate Chain” on page 475 and add the certificate to
the certificate database.
•
If the CA’s certificate is listed but untrusted, follow the instructions in
“Changing the Trust Settings of a CA Certificate” on page 508 and change the
trust setting to trusted.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Setting Up Privileged Users
Setting Up Trusted Managers
You can set up a Registration Manager or Certificate Manager to function as a
trusted manager to another CMS instance. This section explains how to do this.
•
Setting up Trusted Managers Using the Automated Process
•
Setting Up a Registration Manager as a Trusted Manager
•
Setting Up a Certificate Manager as a Trusted Manager
To understand the role of a trusted manager in your PKI, see “Trusted Managers”
on page 398.
Setting up Trusted Managers Using the Automated Process
Certificate Management System automates the process of setting up trusted
managers. The automated process is built into the request-approval form (the page
that displays the pending request) in the Agent Services interface and it enables the
person who has both Certificate Manager agent and Administrator privileges to create
new trusted managers for a CMS instance—that is, the Certificate Manager agent
who approves the subsystems’ certificate requests must belong to both the
Certificate Manager Agents and Administrators groups in the user and group
database of the Certificate Manager. For more information about these groups, see
“Groups and Their Privileges” on page 402.
•
The request-approval form for Certificate Manager’s SSL server certificate
request includes a checkbox labeled “This certificate is for a Trusted Manager.”
•
Similarly, The request-approval form for Registration Manager’s signing
certificate request includes a checkbox labeled “This certificate is for a Trusted
Manager.”
If selected, the checkbox indicates that the subsystem that has requested the
certificate must be made a trusted manager. Selecting the checkbox also requires
the agent to specify an ID for the subsystem that will be set up as a trusted
manager.
If the Certificate Manager agent approves the certificate request with the checkbox
selected and user ID specified, the server automatically adds the subsystem as a
new privileged user to its user and group database, adds the user to the Trusted
Managers group, copies the corresponding certificate to the database, and
associates the certificate with the new user’s entry.
Chapter
13
Managing Privileged Users and Groups
417
Setting Up Privileged Users
Note that for a Certificate Manager to add the Registration Manager this way, the
Certificate Manager agent who approves the Registration Manager signing
certificate request must belong to both the Certificate Manager Agents and
Administrators groups in the internal database of the Certificate Manager. For
more information about these groups, see “Groups and Their Privileges” on
page 402.
Setting Up a Registration Manager as a Trusted Manager
You can set up a remote Registration Manager to function as a trusted manager to a
Certificate Manager, another Registration Manager, or a Data Recovery Manager.
•
Step 1. Find the Required Information
•
Step 2. Create a User Entry for the Registration Manager
•
Step 3. Copy the Registration Manager’s Certificate to the Internal Database
•
Step 4. Check the Certificate Database for the CA Certificate
•
Step 5. Configure Registration Manager’s Connector Settings
Step 1. Find the Required Information
Before setting up a Registration Manager to function as a trusted manager to
another CMS subsystem:
418
•
Note identifying information, such as the instance ID and host name of the
Registration Manager.
•
Make sure that the Registration Manager has the certificate you want it to use
for SSL client authentication to the subsystem that will trust it; by default, the
Registration Manager uses its signing certificate for this purpose. The certificate
must be currently valid; the certificate must not have expired, been revoked, or
been signed by an authority untrusted by the subsystem. For details, see
“Trusted Manager’s Certificate for SSL Client Authentication” on page 401.
•
Locate the certificate in base-64 encoded format. Copy the certificate, including
the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----marker lines, to a text file.
•
Identify the subsystem—Certificate Manager, Registration Manager, or Data
Recovery Manager—to which you want to connect the Registration Manager.
Note details, such as the host name and port number of that subsystem.
•
If you are planning to connect the Registration Manager to a Certificate
Manager, keep this in mind: during the installation of a Registration Manager,
you generated a signing certificate for the Registration Manager. If you
requested the signing certificate from a Certificate Manager, you were given an
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Setting Up Privileged Users
opportunity to add the Registration Manager as a trusted manager to that
Certificate Manager’s database. If you chose this option, then the Registration
Manager is already set up to function as a trusted manager to that Certificate
Manager—in this case, you are not required to go through these steps.
Step 2. Create a User Entry for the Registration Manager
In this step, you create a privileged-user entry for the Registration Manager in the
internal database of the subsystem. As a part of creating this entry, you also add
the user entry to the Trusted Managers group in order to give the entry access
privileges to the agent port of the subsystem.
To create a user entry with appropriate access privileges for a Registration
Manager:
1.
Log in to the CMS window for the subsystem (see “Logging In to the CMS
Window” on page 347). For the purposes of completing these instructions, let
us assume that the subsystem is a Certificate Manager.
2.
In the navigation tree, select Users and Groups.
The Users tab appears.
Chapter
13
Managing Privileged Users and Groups
419
Setting Up Privileged Users
3.
Click Add.
The Select User Type window appears.
4.
Select Trusted Manager and click OK.
The Edit User Information window appears.
5.
Specify information as appropriate.
The information you enter here is to help you keep track of the Registration
Manager; the subsystem never uses it. The subsystem relies solely on the
Registration Manager’s SSL client certificate (which you will add in Step 3) for
authentication.
User ID. Type the Registration Manager’s instance ID (or any other ID that will
help you identify the Registration Manager in the list of privileged users). The
ID can be an alphanumeric string of up to 255 characters.
Host name. Type the full host name of the Registration Manager. The host
name can be an alphanumeric string of up to 255 characters. It must be in the
<machine_name>.<your_domain>.<domain> form.
Group. Select Trusted Managers; for more information about this group, see
“Group for Trusted Managers” on page 406.
420
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Setting Up Privileged Users
6.
Click OK.
You are returned to the Users tab. The Registration Manager you just added
appears in the list of users.
What you do next depends on whether you have the Registration Manager’s SSL
client certificate:
•
If you copied the Registration Manager’s certificate in base-64 encoded form to
a text file, proceed to Step 3. (For details on getting this certificate, see “Trusted
Manager’s Certificate for SSL Client Authentication” on page 401.)
•
Otherwise, skip to Step 5. You can add the certificate later, following the
instructions in “Changing a Privileged User’s Certificate” on page 434.
Step 3. Copy the Registration Manager’s Certificate to the Internal
Database
In this step, you add a copy of the Registration Manager’s SSL client authentication
certificate to the internal database of the subsystem and associate the certificate
with the user entry you created in Step 2.
To store the Registration Manager’s SSL client certificate in the internal database of
the subsystem:
1.
In the Users tab, select the user entry you just added for the Registration
Manager and click Certificates.
The Manage User Certificates window appears.
2.
Click Import.
The Import Certificate window appears.
Chapter
13
Managing Privileged Users and Groups
421
Setting Up Privileged Users
3.
Click inside the text area, and paste the Registration Manager’s certificate in
base-64 encoded form.
Be sure to include the -----BEGIN CERTIFICATE----- and -----END
CERTIFICATE----- marker lines.
4.
Click OK.
You are returned to the Manage User Certificates window. The certificate you
imported should now be listed in this window.
422
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Setting Up Privileged Users
5.
To view the certificate you imported, select it and click View.
The certificate information appears. Verify that the certificate you added is the
correct one.
6.
Click Done.
You are returned to the Users tab.
Step 4. Check the Certificate Database for the CA Certificate
The issuer of the Registration Manager’s certificate that you added in Step 3 must
be trusted by the subsystem that services certificate requests approved by the
Registration Manager. Make sure that this CA’s certificate exists in the subsystem’s
certificate database (internal) and that it is trusted. To check whether the CA’s
certificate exists in the subsystem’s certificate database, follow the instructions in
“Viewing the Certificate Database Content” on page 505.
•
If the CA certificate isn’t listed, follow the instructions in “Using the Wizard to
Install a Certificate or Certificate Chain” on page 475 and add the certificate to
the certificate database.
•
If the CA’s certificate is listed but untrusted, follow the instructions in
“Changing the Trust Settings of a CA Certificate” on page 508 and change the
trust setting to trusted.
Step 5. Configure Registration Manager’s Connector Settings
In this step, you configure the connector settings of the Registration Manager. This
enables the Registration Manager to utilize the proprietary HTTPS connectors to
communicate with the subsystem (following successful SSL client authentication).
Chapter
13
Managing Privileged Users and Groups
423
Setting Up Privileged Users
1.
Log in to the CMS window for the Registration Manager (see “Logging In to
the CMS Window” on page 347).
2.
In the navigation tree, select Registration Manager.
The General Settings tab appears in the right pane.
3.
Select the Connectors tab.
4.
In the “List of connectors” select the connector:
❍
❍
❍
If you are connecting the Registration Manager to a Certificate Manager,
select Certificate Manager Connector and click Edit.
If you are connecting the Registration Manager to another Registration
Manager, select Registration Manager Connector and click Edit.
If you are connecting the Registration Manager to a Data Recovery
Manager, select Data Recovery Manager Connector and click Edit.
For the purposes of completing these instructions, let us assume you selected
Certificate Manager Connector.
424
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Setting Up Privileged Users
The Edit Connector dialog box appears.
5.
Select the Enable checkbox to enable the connector configuration.
6.
Select Remote, and enter the appropriate information:
Host. Type the full host name of the subsystem that trusts this Registration
Manager; in this case, it would be the host name of the Certificate Manager.
The Registration Manager uses this name to locate the Certificate Manager. The
format for the host name must be as follows:
<machine_name>.<your_domain>.<domain>
Port. Type the number of the TCP/IP port at which the Certificate Manager
will listen to requests from the trusted Registration Manager. The default port
designated for communication between a trusted Registration Manager and a
subsystem is the agent’s port. See “Agent Port” on page 377.
Timeout. Connection timeout. By default, it is 30 seconds.
The sample screen above shows how to connect the Registration Manager to a
Certificate Manager running on a host called nolan-nt.mcom.com listening for
HTTPS requests on port 888.
7.
Click OK.
You are returned to the Connectors tab.
8.
To save your changes, click Save.
The CMS configuration is modified. If the changes you made require you to
restart the server, you will be prompted accordingly. In that case, stop and
restart the server.
Chapter
13
Managing Privileged Users and Groups
425
Setting Up Privileged Users
Setting Up a Certificate Manager as a Trusted Manager
You can set up a Certificate Manager to function as a trusted manager to a remote
Data Recovery Manager. The setup process involves the following steps:
•
Step 1. Find the Required Information
•
Step 2. Create a User Entry for the Certificate Manager
•
Step 3. Copy the Certificate Manager’s Certificate to the Internal Database
•
Step 4. Check the Certificate Database for the CA Certificate
•
Step 5. Configure Certificate Manager’s Connector Settings
Step 1. Find the Required Information
Before setting up a Certificate Manager to function as a trusted manager to a Data
Recovery Manager:
•
Note identifying information, such as the instance ID and host name of the
Certificate Manager.
•
Make sure that the Certificate Manager has the certificate you want it to use for
SSL client authentication to the Data Recovery Manager that will trust it; by
default, the Certificate Manager uses its SSL server certificate for this purpose.
The certificate must be currently valid; the certificate must not have expired,
been revoked, or been signed by an authority untrusted by the subsystem. For
details, see “Trusted Manager’s Certificate for SSL Client Authentication” on
page 401.
•
Locate the certificate in base-64 encoded format. Copy the certificate, including
the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----marker lines, to a text file.
•
Identify the Data Recovery Manager to which you want to connect the
Certificate Manager. Note details, such as the host name and port number of
that Data Recovery Manager.
Step 2. Create a User Entry for the Certificate Manager
In this step, you create a privileged-user entry for the Certificate Manager in the
internal database of the Data Recovery Manager. As a part of creating this entry,
you also add the user entry to the Trusted Managers group in order to give the
entry access privileges to the agent port of the Data Recovery Manager.
426
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Setting Up Privileged Users
To create a user entry with appropriate access privileges for a Certificate Manager:
1.
Log in to the CMS window for the Data Recovery Manager (see “Logging In to
the CMS Window” on page 347).
2.
In the navigation tree, select Users and Groups.
The Users tab appears in the right pane.
3.
Click Add.
The Select User Type window appears.
Chapter
13
Managing Privileged Users and Groups
427
Setting Up Privileged Users
4.
Select Trusted Manager and click OK.
The Edit User Information window appears.
5.
Specify information as appropriate.
The information you enter here is to help you keep track of the Certificate
Manager; the Data Recovery Manager never uses it. The Data Recovery
Manager relies solely on the Certificate Manager’s SSL server certificate (which
you will add in Step 3) for authentication.
User ID. Type the Certificate Manager’s instance ID (or any other ID that will
help you identify the Certificate Manager in the list of privileged users). The ID
can be an alphanumeric string of up to 255 characters.
Host name. Type the fully qualified host name of the Certificate Manager. The
host name can be an alphanumeric string of up to 255 characters. It must be in
this form: <machine_name>.<your_domain>.<domain>
Group. Select Trusted Managers; for more information about this group, see
“Group for Trusted Managers” on page 406.
6.
Click OK.
You are returned to the Users tab. The Certificate Manager you just added is
displayed in the list of users.
What you do next depends on whether you have the Certificate Manager’s SSL
server certificate:
428
•
If you copied the Certificate Manager’s certificate in base-64 encoded form to a
text file, proceed to Step 3. (For details on getting this certificate, see “Trusted
Manager’s Certificate for SSL Client Authentication” on page 401.)
•
Otherwise, skip to Step 5. You can add the certificate later, following the
instructions in “Changing a Privileged User’s Certificate” on page 434.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Setting Up Privileged Users
Step 3. Copy the Certificate Manager’s Certificate to the Internal Database
In this step, you add the Certificate Manager’s SSL server certificate to the internal
database of the Data Recovery Manager and associate the certificate with the user
entry you created in Step 2.
To store the Certificate Manager’s SSL server certificate in the internal database of
the subsystem:
1.
In the Users tab, select the user entry you just added for the Certificate
Manager and click Certificates.
The Manage User Certificates window appears.
2.
Click Import.
The Import Certificate window appears.
3.
Click inside the text area, and paste the Certificate Manager’s certificate in
base-64 encoded form.
Be sure to include the -----BEGIN CERTIFICATE----- and -----END
CERTIFICATE----- marker lines.
Chapter
13
Managing Privileged Users and Groups
429
Setting Up Privileged Users
4.
Click OK.
You are returned to the Manage User Certificates window. The certificate you
imported should now be listed in this window.
5.
To view the certificate you imported, select it and click View.
The certificate information appears. Verify that the certificate you added is the
correct one.
6.
Click Done.
You are returned to the Users tab.
430
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Setting Up Privileged Users
Step 4. Check the Certificate Database for the CA Certificate
The issuer of the Certificate Manager’s certificate that you added in Step 3 must be
trusted by the Data Recovery Manager that services the key archival requests
initiated by the Certificate Manager. Make sure that this CA’s certificate exists in
the Data Recovery Manager’s certificate database (internal) and that it is trusted.
To check whether the CA’s certificate exists in the Data Recovery Manager’s
certificate database, follow the instructions in “Viewing the Certificate Database
Content” on page 505.
•
If the CA certificate isn’t listed, follow the instructions in “Using the Wizard to
Install a Certificate or Certificate Chain” on page 475 and add the certificate to
the certificate database.
•
If the CA’s certificate is listed but untrusted, follow the instructions in
“Changing the Trust Settings of a CA Certificate” on page 508 and change the
trust setting to trusted.
Step 5. Configure Certificate Manager’s Connector Settings
In this step you configure the connector settings of the Certificate Manager. This
enables the Certificate Manager to utilize the proprietary HTTPS connectors to
communicate with the Data Recovery Manager (following successful SSL client
authentication).
Note that during the installation of a Data Recovery Manager, you were prompted
to specify the host name and port number of the Certificate Manager to which the
Data Recovery Manager will be connected. If you specified this information, you
are not required to go through this step. However, it is recommended that you
verify the connector setting and make sure that the information you entered during
installation is correct.
1.
Log in to the CMS window for the Certificate Manager (see “Logging In to the
CMS Window” on page 347).
2.
In the navigation tree, select Certificate Manager.
The General Settings tab appears in the right pane.
Chapter
13
Managing Privileged Users and Groups
431
Setting Up Privileged Users
3.
Select the Connectors tab.
4.
In the “List of connectors” select Data Recovery Manager Connector and click
Edit.
The Edit Connector dialog box appears.
5.
Select the Enable checkbox to the enable the connector configuration.
6.
Select Remote, and enter the appropriate information:
Host. Type the full host name of the Data Recovery Manager that trusts this
Certificate Manager. The Certificate Manager uses this name to locate the Data
Recovery Manager. The format for the host name must be in the
<machine_name>.<your_domain>.<domain> form.
432
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Changing Privileged-User Information
Port. Type the number of the TCP/IP port at which the Data Recovery
Manager will listen to requests from the trusted Certificate Manager. The port
designated for communication between a trusted Certificate Manager and a
Data Recovery Manager is the agent port. See “Agent Port” on page 377.
Timeout. Connection timeout. By default, it is 30 seconds.
The sample screen above shows how to connect the Certificate Manager to a
Data Recovery Manager running on a host called testKRA.siroe.com
listening for HTTPS requests at port 8000.
7.
Click OK.
You are returned to the Connectors tab.
8.
To save your changes, click Save.
The CMS configuration is modified. If the changes you made require you to
restart the server, you will be prompted accordingly. In that case, stop and
restart the server.
Changing Privileged-User Information
You can change privileged-user information in several ways:
•
To change the login information of a privileged user, see “Changing a
Privileged User’s Login Information” on page 433.
•
To add or remove certificates of a privileged user, see “Changing a Privileged
User’s Certificate” on page 434.
•
To change the group membership or access permissions of a privileged user,
see “Changing Members in a Group” on page 435.
Changing a Privileged User’s Login Information
To change a privileged user’s login information:
1.
Log in to the CMS window (see “Logging In to the CMS Window” on
page 347).
2.
In the navigation tree, select Users and Groups.
The Users tab appears in the right pane.
Chapter
13
Managing Privileged Users and Groups
433
Changing Privileged-User Information
3.
In the User ID list, select the user you want to edit, and click Edit.
The Edit User Information window appears.
4.
Make the appropriate modifications.
If you need details about individual fields, see “Setting Up Privileged Users”
on page 407.
5.
Click OK.
You are returned to the Users tab.
6.
Click Refresh to view the updated configuration.
Changing a Privileged User’s Certificate
To change a privileged user’s certificate:
1.
Log in to the CMS window (see “Logging In to the CMS Window” on
page 347).
2.
In the navigation tree, select Users and Groups.
The Users tab appears in the right pane.
434
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Changing Privileged-User Information
3.
In the User ID list, select the user whose certificate information you want to
change, and click Certificates.
The Manage User Certificate window appears.
4.
Take the appropriate action:
❍
To view a certificate, select the certificate and click View.
❍
To delete a certificate, select the certificate and click Delete.
❍
5.
To add a new certificate for this user to the internal database, click Import.
In the Import Certificate window that appears, paste the new certificate in
the text area. Be sure to paste the entire base-64 encoded block, including
the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----marker lines. For details on getting the user’s certificate, see “Agent’s
Certificate for SSL Client Authentication” on page 393.
Click Done.
You are returned to the Users tab.
6.
Click Refresh to view the updated configuration.
Changing Members in a Group
You can add or remove members from all groups. Keep in mind that the group for
administrators must have at least one user entry. For details, see “Groups and
Their Privileges” on page 402.
To change a group’s members:
1.
Log in to the CMS window (see “Logging In to the CMS Window” on
page 347).
2.
In the navigation tree, select Users and Groups.
The Users tab appears in the right pane.
Chapter
13
Managing Privileged Users and Groups
435
Changing Privileged-User Information
3.
Click the Groups tab.
4.
In the Group Name list, select the group you want to change, and click Edit.
The Edit Group Information window appears.
5.
Make the appropriate changes:
❍
❍
❍
436
To change the group description, type a new description in the “Group
description” field.
To remove a user from the group, select the user and click Delete.
To add users, click Add User. In the User Selection window that appears,
select the users you want to add and click OK. You are returned to the Edit
Group Information window.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Deleting a Privileged User
6.
Click OK when you are done with the changes.
You are returned to the Groups tab.
7.
Click Refresh to view the updated configuration.
Deleting a Privileged User
You can delete privileged users from the internal database. Deleting a user from
the internal database deletes that user from all groups to which the user belongs. If
you want to delete a user from specific groups, you should modify the appropriate
groups; for details, see “Changing Members in a Group” on page 435.
To delete a privileged user from the internal database:
1.
Log in to the CMS window (see “Logging In to the CMS Window” on
page 347).
2.
In the navigation tree, select Users and Groups.
The Users tab appears in the right pane.
3.
In the User ID list, select the user you want to delete, and click Delete.
4.
When prompted, confirm your action.
If you click OK, the user entry is deleted from the internal database.
5.
Click Refresh to view the updated configuration.
Chapter
13
Managing Privileged Users and Groups
437
Deleting a Privileged User
438
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Chapter
14
Managing CMS Keys and Certificates
The main subsystems of iPlanet Certificate Management System (CMS)—the
Certificate Manager, Registration Manager, Data Recovery Manager and Online
Certificate Status Manager—use certificates for various purposes, including
authentication during SSL-enabled communication. For example, when a
Registration Manager forwards a certificate issuance request to a Certificate
Manager for signing, the Certificate Manager expects the Registration Manager to
have performed SSL client authentication before processing the request.
When you installed Certificate Management System, the installation program
prompted you to generate the required certificates for the subsystems you chose to
install. This chapter provides an overview of those certificates and it explains how
to perform operations such as renewing the existing certificates before their
validity period expires, getting new certificates for the subsystems, adding trusted
CA certificates and certificate chains to the CMS trust database, and changing the
trust setting of CA certificates. The chapter also explains the certificate Setup
Wizard, which automates the process of requesting and installing CMS certificates.
The chapter has the following sections:
•
Keys and Certificates for the Main Subsystems (page 440)
•
Tokens for Storing CMS Keys and Certificates (page 454)
•
Hardware Cryptographic Accelerators (page 459)
•
Certificate Setup Wizard (page 459)
•
Configuring the Server’s Security Preferences (page 482)
•
Getting New Certificates for the Subsystems (page 489)
•
Renewing Certificates for the Subsystems (page 497)
•
Managing the Certificate Database (page 505)
439
Keys and Certificates for the Main Subsystems
Keys and Certificates for the Main Subsystems
This section explains the various certificates required and used by the CMS
managers:
•
Certificate Manager’s Key Pairs and Certificates
•
Registration Manager’s Key Pairs and Certificates
•
Data Recovery Manager’s Key Pairs and Certificates
•
Online Certificate Status Manager’s Key Pairs and Certificates
The key pairs that correspond to certificates used by these subsystems can be
stored either in an internal or an external token, or in both. It depends on the token
you chose for the generation and storage of the keys and certificates. For
information on tokens, see “Tokens for Storing CMS Keys and Certificates” on
page 454.
As an administrator, you must make sure that the private keys that correspond to
all certificates, especially the CA signing certificate, used by CMS managers are
adequately protected. This includes protecting them from damage (in other words,
by archiving and backing up the keys) as well as protecting them from
unauthorized access or use. The passwords that protect the tokens containing these
keys must also be carefully guarded. Access to the token itself should be limited.
•
If the keys are in the internal token (the key3.db file), make sure that only you
or authorized administrators have access to this file. It’s also important to
know if the file is stored on backup tapes or is otherwise available for someone
to intercept. Because the destruction of a private key in a disk crash can be
disastrous if you are depending upon that key for a hierarchy of certificate
authorities, backing up your key data is commensurately important. If you do
make copies of your keys, however, you must protect your backups with the
same level of security that you use for protecting your original keys.
•
If the keys are in an external token, such as a smart card, keep it in a locked
facility. Also, periodically change the passwords that protect these keys. See
“Changing a Token’s Password” on page 458.
All CMS certificates have a validity period, as specified when the certificates were
generated, beyond which they cannot be used. For a certificate to be valid beyond
it’s expiration date, it must ne renewed. For instructions to renew a CMS certificate,
see section “Renewing Certificates for the Subsystems” on page 497.
440
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Keys and Certificates for the Main Subsystems
All key pairs associated with CMS certificates must be well protected to ensure that
they are never compromised. However, if you know or suspect that a key pair has
been compromised, reissue the certificate with a new key pair. For instructions to
get a new CMS certificate, see section “Getting New Certificates for the
Subsystems” on page 489.
Certificate Manager’s Key Pairs and Certificates
The Certificate Manager uses the following key pairs and corresponding
certificates:
•
CA Signing Key Pair and Certificate
•
wTLS CA Signing Certificate
•
OCSP Signing Key Pair and Certificate
•
CRL Signing Key Pair and Certificate
•
SSL Server Key Pair and Certificate
•
Remote Administration Server Certificate
CA Signing Key Pair and Certificate
Every Certificate Manager you installed has a certificate, identified as the Certificate
Manager CA signing certificate, whose public key corresponds to the private key the
Certificate Manager uses to sign the X.509 certificates it issues. The first time you
generated this certificate is when you installed the Certificate Manager. The default
nickname for the certificate is caSigningCert cert-<instance_id>, where
<instance_id> identifies the CMS instance in which the Certificate Manager is
installed, and the default validity period for the certificate is two years.
The subject name of the CA signing certificate reflects the name of your certificate
authority (CA) as specified during the installation. All certificates signed or issued
by the Certificate Manager include this name to identify the issuer of the certificate.
The Certificate Manager’s status as a root or subordinate CA is determined by
whether its CA signing certificate is self-signed or is signed by another CA.
•
If the Certificate Manager is a root CA, its CA signing certificate is
self-signed—that is, the subject name and issuer name of the certificate is the
same.
Chapter
14
Managing CMS Keys and Certificates
441
Keys and Certificates for the Main Subsystems
•
If the Certificate Manager is a subordinate CA, its CA signing certificate is
signed by another CA, usually the one that is a level above in the CA hierarchy
(which may or may not be a root CA). If you have deployed the Certificate
Manager as a subordinate CA in a CA hierarchy, you must import your root
CA’s signing certificate into individual clients and servers before you can use
the Certificate Manager to issue certificates to them.
NOTE
You cannot change the CA name; doing so would make all
previously issued certificates invalid. Similarly, reissuing a
Certificate Manager’s CA signing certificate with a new key pair
invalidates all certificates that have been signed by the old key pair.
wTLS CA Signing Certificate
During the installation of a Certificate Manager, you’re given the option to enable
issuance of Wireless Transport Layer Security (wTLS)-compliant certificates for use
with wireless applications. If you chose to enable this option, the Installation
Wizard transparently generates a wTLS CA signing certificate.
Note that for the wTLS CA signing certificate, the wizard does not generate a
separate key pair. Instead, it uses the same key pair that you generated for the CA
signing certificate, which is explained in section “CA Signing Key Pair and
Certificate” on page 441. The subject name and validity period of the wTLS CA
signing certificate will be the same as the one you specified for the CA signing
certificate. The Certificate Manager uses the private key (that corresponds to the
public key used to generate the wTLS CA signing certificate) to sign both X.509 and
wTLS certificates it issues.
OCSP Signing Key Pair and Certificate
During the installation of a Certificate Manager, you’re given the option to enable
its OCSP-service feature. This feature enables the Certificate Manager to function
as an OCSP responder, enabling OCSP-compliant clients to query the Certificate
Manager for the revocation status of certificates issued by the Certificate Manager.
For more information about an OCSP responder and setting up a Certificate
Manager to function as an OCSP responder, see Chapter 21, “Setting Up an OCSP
Responder.”
442
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Keys and Certificates for the Main Subsystems
Irrespective of whether you chose to enable the OCSP service feature, the
Installation Wizard transparently generates a key pair and a corresponding
certificate identified as the OCSP signing certificate. The reason for generating this
certificate even if you chose to not enable the OCSP service is that you can enable
the OCSP service feature in the CMS window after installation. This way, if you
decide to enable the feature in a future date, you wouldn’t have to go through the
process of requesting an OCSP signing certificate.
Note that for generating the OCSP signing key pair, the wizard uses some of the
information you provide for the CA signing key pair, which is explained in section
“CA Signing Key Pair and Certificate” on page 441. The key type, key size, key
algorithm, and validity period of the OCSP signing certificate is the same as the one
you specified for the CA signing key pair. The subject name of the OCSP signing
certificate is in the form CN=OCSP cert-<cms_instance_id>, and it contains
extensions, such as OCSPSigning and OCSPNoCheck, required for signing OCSP
responses.
The Certificate Manager uses the private key (that corresponds to the public key
used to generate the OCSP signing certificate) to sign the OCSP responses it sends
to the OCSP-compliant clients when queried about the revocation status of
certificates. The Certificate Manager’s signature provides persistent proof to the
client that the Certificate Manager has processed the request.
The default nickname for the OCSP signing certificate is
ocspSigningCert cert-<instance_id>, where <instance_id> identifies the
CMS instance in which the Certificate Manager is installed.
CRL Signing Key Pair and Certificate
By default, a Certificate Manager you have installed uses the same key pair, the one
that corresponds to the CA signing certificate explained in “CA Signing Key Pair and
Certificate” on page 441, for signing certificates and certificate revocation lists
(CRLs). For details about CRLs, see “What’s a CRL?” on page 615.
If you want a Certificate Manager to use a separate key pair for signing the CRL it
generates, you can do so after installation. The instructions are provided below.
Note that a Certificate Manager’s CRL signing certificate must be signed or issued
by itself; make sure you submit the request to the Certificate Manager itself.
1.
Request and install a CRL signing certificate for the Certificate Manager. To do
this, you may use either of these options:
❍
Use the Certificate Setup Wizard available within the CMS window.
Chapter
14
Managing CMS Keys and Certificates
443
Keys and Certificates for the Main Subsystems
❍
Use the Key Database (keyutil) tool to generate a key pair, the Certificate
Database (certutil) tool to request a certificate for the key pair and install
the certificate in the Certificate Manager’s certificate database. For more
information about the Key Database and Certificate Database tools, see
CMS Command-Line Tools Guide.
To request and install a CRL signing certificate for a Certificate Manager using
its Certificate Setup Wizard, follow these instructions:
444
a.
Log in to Netscape Console; see “Logging In to Netscape Console” on
page 340.
b.
Locate the CMS instance for the Certificate Manager, make sure it’s started,
and then log in to the CMS window of the Certificate Manager.
c.
Select the Configuration tab, and then select the Encryption tab.
d.
Click the Certificate Setup Wizard button to launch the wizard, which is
explained in “Certificate Setup Wizard” on page 459.
e.
Select the option to request a certificate and then follow the on-screen
prompts to generate a certificate request for the CRL signing certificate—in
the Certificate Selection window, select Other and specify caCrlSigning
as the certificate type in the associated text field.
f.
Once you have the certificate request ready, submit it to the Certificate
Manager so that it can issue a certificate—in the request submission screen
of the wizard, use the auto-submission feature by entering the Certificate
Manager’s hostname and port number so that the request gets added to the
Certificate Manager’s agent queue. For general instructions to use the
wizard to request a certificate, see section “Using the Wizard to Request a
Certificate” on page 460.
g.
Log in to the Agent Services interface, check the request for required
extensions. For example, the CRL signing certificate must contain the Key
Usage extension with the crlSigning bit set. (By default, the Certificate
Manager’s policy is configured to add the Key Usage extension with
correct bits to the CRL signing certificate; see the policy rule named
CRLSignCertKeyUsageExt, which is an instance of KeyUsageExt plug-in.)
h.
Approve the request.
i.
Once you have the CRL signing certificate ready, restart the wizard and
install the certificate in the Certificate Manager’s database. For general
instructions to use the wizard to add a certificate, see “Using the Wizard to
Install a Certificate or Certificate Chain” on page 475.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Keys and Certificates for the Main Subsystems
2.
After you’ve installed the certificate successfully, go to the Tasks tab and stop
the Certificate Manager.
3.
Update the Certificate Manager’s configuration to recognize the new key pair
and certificate.
a.
In the Certificate Manager host machine, go to this directory:
<server_root>/cert-<instance_id>/config
b.
Open the configuration file (CMS.cfg) in a text editor.
c.
Add the following lines to the configuration file:
ca.crl_signing.cacertnickname=<nickname> cert-<instance_id>
ca.crl_signing.defaultSigningAlgorithm=<signing_algorithm>
ca.crl_signing.tokenname=<token_name>
d.
Edit the lines as below. Replace
<nickname> with the name assigned to the CRL signing certificate.
<instance_id> with the name assigned to the Certificate Manager
instance.
<signing_algorithm> with MD5withRSA, MD2withRSA, or SHA1withRSA, if
the key type is RSA, or SHA1withDSA, if the key type is DSA.
<token_name> with the name of the token used for generating the key pair
and the certificate. If you used the internal/software token, use Internal
Key Storage Token as the value.
For example, your edited entries might look like this:
ca.crl_signing.cacertnickname=crlSigningCert cert-demoCA
ca.crl_signing.defaultSigningAlgorithm=MD5withRSA
ca.crl_signing.tokenname=Internal Key Storage Token
e.
4.
Save your changes and close the file.
Restart the Certificate Manager. Now the Certificate Manager is ready to use
the CRL signing certificate to sign the CRLs it generates.
SSL Server Key Pair and Certificate
Every Certificate Manager you have installed has at least one SSL server certificate.
The first time you generated this certificate is when you installed the Certificate
Manager. The default nickname for the certificate is
Server-Cert cert-<instance_id>, where <instance_id> identifies the CMS
instance in which the Certificate Manager is installed.
Chapter
14
Managing CMS Keys and Certificates
445
Keys and Certificates for the Main Subsystems
The Certificate Manager’s SSL server certificate was issued by the CA to which you
submitted the certificate signing request. You might have submitted the request to
the Certificate Manager itself, another internally deployed CA, or a public CA. To
find out the issuer name, follow the instructions in “Viewing the Certificate
Database Content” on page 505.
The Certificate Manager uses its SSL server certificate to do SSL server-side
authentication to the following:
•
The End-Entity Services interface (the HTTPS port)
•
The Certificate Manager Agent Services interface
•
Clone Certificate Managers, when used as a master Certificate Manager in a
cloned CA setup (see “Cloning a Certificate Manager” on page 288)
By default, the Certificate Manager uses a single SSL server certificate for
authentication purposes. However, you can request and install additional SSL
server certificates for the Certificate Manager. For example, you can configure the
Certificate Manager to use separate server certificates for authenticating to the
End-Entity Services interface and Agent Services interface. For instructions, see
“Configuring the Server to Use Separate SSL Server Certificates” on page 482.
If you configure the Certificate Manager for SSL-enabled communication with a
publishing directory, the Certificate Manager also uses its SSL server certificate for
SSL client authentication to the publishing directory. This is the default
configuration. You can configure the Certificate Manager to use an alternate
certificate for this purpose; see “Getting an SSL Client Certificate for a Subsystem”
on page 484.
If you configure the Certificate Manager to function as a trusted manager to a Data
Recovery Manager, the Certificate Manager also uses its SSL server certificate for
SSL client authentication to the Data Recovery Manager. For details on trusted
managers, see “Trusted Managers” on page 398. You can also configure the
Certificate Manager to use an alternate certificate for this purpose; see “Getting an
SSL Client Certificate for a Subsystem” on page 484.
NOTE
446
If you have installed the Certificate Manager with a Data Recovery
Manager, both subsystems use the same SSL server certificate.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Keys and Certificates for the Main Subsystems
Remote Administration Server Certificate
Netscape Console (version 4.2) does not support the DSA key algorithm. To
workaround this problem, during the installation of a Certificate Manager, the
Installation Wizard transparently generates an SSL server certificate identified as
the Remote Administration Server Certificate. The Certificate Manager uses the
certificate for SSL server authentication to the remote administration interface,
Netscape Console. The certificate is self-signed, and is generated with RSA key
type and a key size of 512 bits. The validity period of the certificate is set to the
same validity period that you chose for the SSL server certificate, which is used by
the Certificate Manager for SSL server authentication to its HTTP interfaces; see
“SSL Server Key Pair and Certificate” on page 445.
Note that the remote administration server certificate is not listed in the internal
database, and thus, you’ll not be able to list or search for it in the Retrieval tab of
the Certificate Manager’s end-entity interface. However, you’ll see the certificate if
you use the command-line tool, Certificate Database Tool (certutil) to list
certificates in the Certificate Manager’s certificate database (the cert7.db file):
•
The nickname for the certificate is
Remote Admin Server-Cert cert-<instance_id>, where <instance_id>
identifies the CMS instance in which the Certificate Manager is installed.
•
The CN component in both the subject name and issuer name of the certificate
is set to CN=SSLserver cert-<instance_id>.
Like any certificate, the remote administration server certificate has a validity
period. You must renew the certificate before it expires. For instructions to renew a
certificate, see “Renewing Certificates for the Subsystems” on page 497.
Note that the “SSL Server for Remote Admin” option in the Certificate Setup
Wizard allows you to renew the remote administration certificate by submitting
the request to a CA only—it doesn’t allow you to renew the certificate as a
self-signed one (as done during installation). If the CA signing certificate of the CA
to which you submit the renewal request is based on the DSA key algorithm, then
resulting certificate will be unusable because Netscape Console doesn’t support the
DSA algorithm.
If you want to self sign the certificate, you must use certutil and keyutil tools to
extract the key ID from the key database first and the generate a certificate for the
key. The steps below outline how to use these tools to renew the certificate. Be sure
to check the CMS Command-Line Tools Guide for details on certutil and keyutil
tools to customize your commands to suit your requirements.
1.
Note the name (also called nickname) of the remote administration SSL server
certificate; the default name is
Remote Admin Server-Cert cert-<instance_id>.
Chapter
14
Managing CMS Keys and Certificates
447
Keys and Certificates for the Main Subsystems
2.
Stop Certificate Management System.
3.
Open a command window.
4.
Go to this directory: <server_root>/cert-<instance_id>/config
5.
Enter the command below, replacing <certname> with the name of the remote
administration SSL server certificate. You may use the -h <tokenname>
argument to specify whether the certificate database is on a particular
hardware or software token.
certutil -L -n “<certname>”
For example, your command might look like this:
certutil -L -n “Remote Admin Server-Cert cert-firefly”
You should see detailed information about the remote administration SSL
server certificate.
6.
Locate the “Subject Public Key Info:” section and then the Modulus section. For
example:
RSA Public Key:
Modulus:
00:f6:9e:71:37:62:af:7c:46:af:cb:bf:1e:d8:1a:
64:0b:5e:71:e2:d8:ec:88:18:6d:eb:32:65:6f:f2:
18:4b:ef:b3:70:ae:61:de:6f:21:d5:4e:0e:7b:9b:
b7:42:98:94:1c:d7:46:42:53:39:db:10:07:6c:b8:
75:7e:94:18:b5
7.
Note the second and third byte (f69e in the above example) in the modulus;
this is the short key ID for the certificate.
8.
Delete the certificate you want to renew.
9.
Run the certutil command again to regenerate the certificate for the correct
key and to add the resulting certificate to the database. Be sure to use the same
name for the certificate and to add the required certificate extensions, such as
the Key Usage extension. A sample command syntax is below:
certutil -S -k <shortkeyID> -y rsa|dsa -n "<certname>"
-s "<subject>" -t "<trustargs>" -x -m <serial-number>
-v <valid-months> -d <certdir> -1)
For example, your command might look like this:
certutil -S -k f69e -y rsa -n "Remote Admin Server-Cert
cert-firefly" -s "cn=SSLserver cert-firefly" -t "u,u,u" -x -m 3
-v 12 -d . -1
10. Restart Certificate Management System.
448
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Keys and Certificates for the Main Subsystems
Registration Manager’s Key Pairs and
Certificates
The Registration Manager uses the following certificates:
•
Signing Key Pair and Certificate
•
SSL Server Key Pair and Certificate
•
Remote Administration Server Certificate
Signing Key Pair and Certificate
Every Registration Manager you have installed has a certificate, identified as the
Registration Manager signing certificate, whose public key corresponds to the private
key the Registration Manager uses to sign certificate requests before sending them
to the Certificate Manager for signing. The Registration Manager’s signature
provides persistent proof to the Certificate Manager that the Registration Manager
has processed the request. The first time you generated this certificate is when you
installed the Registration Manager. The default nickname for the certificate is
raSigningCert cert-<instance_id>, where <instance_id> identifies the CMS
instance in which the Registration Manager is installed.
The Registration Manager’s signing certificate was issued by the CA to which you
submitted the certificate signing request. You might have submitted the request to
an internally deployed CA or a public CA. To find out the issuer name, follow the
instructions in “Viewing the Certificate Database Content” on page 505.
If you configure the Registration Manager to function as a trusted manager to
another subsystem, the Registration Manager uses its signing certificate for SSL
client authentication to the subsystem; this is the default configuration. For details,
see “Trusted Manager’s Certificate for SSL Client Authentication” on page 401.
SSL Server Key Pair and Certificate
Every Registration Manager you have installed has at least one SSL server certificate.
The first time you generated this certificate is when you installed the Registration
Manager. The default nickname for the certificate is
Server-Cert cert-<instance_id>, where <instance_id> identifies the CMS
instance in which the Registration Manager is installed.
The Registration Manager’s SSL server certificate was issued by the CA to which
you submitted the certificate signing request. You might have submitted the
request to an internally deployed CA or a public CA. To find out the issuer name,
follow the instructions in “Viewing the Certificate Database Content” on page 505.
Chapter
14
Managing CMS Keys and Certificates
449
Keys and Certificates for the Main Subsystems
The Registration Manager uses its SSL server certificate to do SSL server-side
authentication to the following:
•
The end entity services interface (the HTTPS port)
•
The Registration Manager Agent Services interface
By default, the Registration Manager uses a single SSL server certificate for
authentication purposes. However, you can request and install additional SSL
server certificates for the Registration Manager. For example, you can configure the
Registration Manager to use separate server certificates for authenticating to
Netscape Console, the end entity services interface, and the Registration Manager
Agent Services interface. For instructions, see “Configuring the Server to Use
Separate SSL Server Certificates” on page 482.
NOTE
If you installed the Registration Manager with a Data Recovery
Manager, both subsystems use the same SSL server certificate.
Remote Administration Server Certificate
Similar to the Certificate Manager, the Registration Manager too has a remote
administration server certificate. For details, see “Remote Administration Server
Certificate” on page 447.
Data Recovery Manager’s Key Pairs and
Certificates
The Data Recovery Manager uses the following key pairs and certificates:
450
•
Transport Key Pair and Certificate
•
Storage Key Pair
•
SSL Server Key Pair and Certificate
•
Remote Administration Server Certificate
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Keys and Certificates for the Main Subsystems
Transport Key Pair and Certificate
Every Data Recovery Manager you have installed has a Data Recovery Manager
transport certificate. The public key of the key pair that is used to generate the
transport certificate is used by the client software to encrypt an end user’s
encryption private key before it is sent to the Data Recovery Manager for archival;
only those clients capable of generating dual-key pairs (one for signing and one for
encryption) use the transport certificate. For more information on how this
certificate is used, see “Key Archival Process” on page 741.
The first time you generated this certificate is when you installed the Data
Recovery Manager. The default nickname for the certificate is
kraTransportCert cert-<instance_id>, where <instance_id> identifies the
CMS instance in which the Data Recovery Manager is installed.
The transport certificate was issued by the CA to which you submitted the
certificate signing request. You might have submitted the request to the Certificate
Manager that is installed in the same instance, internally deployed another CA, or a
public CA. To find out the issuer name, follow the instructions in “Viewing the
Certificate Database Content” on page 505.
Storage Key Pair
Every Data Recovery Manager you have installed has a Data Recovery Manager
storage key pair. The first time you generated this key pair is when you installed the
Data Recovery Manager.
The Data Recovery Manager uses the public component of this key pair to encrypt
(or wrap) end users’ encryption private keys during the key archival operation; it
uses the private component to decrypt (or unwrap) the archived key during the
recovery operation. That is, the public key is used to encrypt the key repository the
server uses to store end users’ encryption private keys. For more information on
how this key pair is used, see Chapter 22, “Setting Up Key Archival and Recovery.”
Note that the public component of the storage key pair is not certified; there is no
certificate that corresponds to the public key.
Keys encrypted with the storage key can be retrieved only by authorized key
recovery agents. For details, see “Key Recovery Agents and Their Passwords” on
page 745.
Chapter
14
Managing CMS Keys and Certificates
451
Keys and Certificates for the Main Subsystems
SSL Server Key Pair and Certificate
Every Data Recovery Manager you have installed has at least one SSL server
certificate. The first time you generated this certificate is when you installed the
Data Recovery Manager. The default nickname for the certificate is
Server-Cert cert-<instance_id>, where <instance_id> identifies the CMS
instance in which the Data Recovery Manager is installed.
The Data Recovery Manager’s SSL server certificate was issued by the CA to which
you submitted the certificate signing request. You might have submitted the
request to the Certificate Manager that is installed in the same instance, an
internally deployed CA, or a public CA. To find out the issuer name, follow the
instructions in “Viewing the Certificate Database Content” on page 505.
The Data Recovery Manager uses its SSL server certificate to do SSL server-side
authentication to the following:
•
The end entity services interface (the HTTPS port)
•
The Data Recovery Manager Agent Services interface
By default, the Data Recovery Manager uses a single SSL server certificate for
authentication purposes. However, you can request and install additional SSL
server certificates for the Data Recovery Manager. For example, you can configure
the Data Recovery Manager to use separate server certificates for authenticating to
Netscape Console, the end entity services interface, and the Data Recovery
Manager Agent Services interface. For instructions, see “Configuring the Server to
Use Separate SSL Server Certificates” on page 482.
NOTE
If you installed the Data Recovery Manager with a Certificate
Manager or Registration Manager, both subsystems use the same
SSL server certificate.
Remote Administration Server Certificate
Similar to the Certificate Manager and Registration Manager, the Data Recovery
Manager too uses a remote administration server certificate. For details, see section
“Remote Administration Server Certificate” on page 447.
452
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Keys and Certificates for the Main Subsystems
Online Certificate Status Manager’s Key Pairs
and Certificates
The Online Certificate Status Manager uses the following certificates:
•
OCSP Signing Key Pair and Certificate
•
SSL Server Key Pair and Certificate
•
Remote Administration Server Certificate
OCSP Signing Key Pair and Certificate
Every Online Certificate Status Manager you have installed has a certificate,
identified as the Online Certificate Status Manager signing certificate, whose public
key corresponds to the private key the Online Certificate Status Manager uses to
sign OCSP responses before sending them to OCSP-compliant clients. The Online
Certificate Status Manager’s signature provides persistent proof to an
OCSP-compliant client that the Online Certificate Status Manager has processed
the request. The first time you generated this certificate is when you installed the
Online Certificate Status Manager. The default nickname for the certificate is
ocspSigningCert cert-<instance_id>, where <instance_id> identifies the
CMS instance in which the Online Certificate Status Manager is installed.
The Online Certificate Status Manager’s signing certificate was issued by the CA to
which you submitted the certificate signing request. You might have submitted the
request to an internally deployed CA or a public CA. To find out the issuer name,
follow the instructions in “Viewing the Certificate Database Content” on page 505.
SSL Server Key Pair and Certificate
Every Online Certificate Status Manager you have installed has at least one SSL
server certificate. The first time you generated this certificate is when you installed
the Online Certificate Status Manager. The default nickname for the certificate is
Server-Cert cert-<instance_id>, where <instance_id> identifies the CMS
instance in which the Online Certificate Status Manager is installed.
The Online Certificate Status Manager’s SSL server certificate was issued by the CA
to which you submitted the certificate signing request. You might have submitted
the request to an internally deployed CA or a public CA. To find out the issuer
name, follow the instructions in “Viewing the Certificate Database Content” on
page 505.
The Online Certificate Status Manager uses its SSL server certificate to do SSL
server-side authentication to the Online Certificate Status Manager Agent Services
interface.
Chapter
14
Managing CMS Keys and Certificates
453
Tokens for Storing CMS Keys and Certificates
By default, the Online Certificate Status Manager uses a single SSL server
certificate for authentication purposes. However, you can request and install
additional SSL server certificates for the Online Certificate Status Manager. For
example, you can configure the Online Certificate Status Manager to use separate
server certificates for authenticating to Netscape Console and the Online Certificate
Status Manager Agent Services interface. For instructions, see “Configuring the
Server to Use Separate SSL Server Certificates” on page 482.
Remote Administration Server Certificate
Similar to the Certificate Manager and Registration Manager, the Online Certificate
Status Manager too uses a remote administration server certificate. For details, see
section “Remote Administration Server Certificate” on page 447.
Tokens for Storing CMS Keys and Certificates
A token is a hardware or software device that performs cryptographic functions
and optionally stores public-key certificates, cryptographic keys, and data defined
by the application using the cryptographic services. Alternatively, a token can also
be considered as a device that you can use to generate and store your key pairs and
corresponding certificates.
Certificate Management System defines two types of tokens, internal and external,
for storing key pairs and certificates that belong to the Certificate Manager,
Registration Manager, Data Recovery Manager, and Online Certificate Status
Manager.
NOTE
454
Only those who have the password that protects a token can access
it. For information on changing the password that protects a token,
use the command-line utility called the Key Database Tool, which is
explained in the CMS Command-Line Tools Guide. To locate an online
version of this document, see “Where to Go for Related
Information” on page 28.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Tokens for Storing CMS Keys and Certificates
Internal Token
An internal (software) token refers to a pair of software files, usually called
certificate database and key database, that Certificate Management System uses to
generate and store its key pairs and certificates. Certificate Management System
automatically generates these files in the file system of its host machine when you
choose to use the internal token for the first time. These files were created for you
during CMS installation if you chose to use the internal token for key-pair
generation.
In the CMS host system, the certificate database is identified by the name
cert7.db; the key database is identified by the name key3.db. You can find both
these files at this location: <server_root>/cert-<instance_id>/config
External Token
An external (hardware) token refers to an external hardware device, such as a
smart card, FORTEZZA card, or other crypto card, that Certificate Management
System uses to generate and store its key pairs and certificates. Certificate
Management System supports any hardware tokens that are compliant with
PKCS#11 version 2.01. For details, see the information provided at this URL:
http://developer.netscape.com/support/faqs/pkcs_11.html
If you haven’t already done so, consider using external tokens for generating and
storing the key pairs and certificates used by Certificate Management System.
These devices represent another security measure you can take to safeguard
private keys because hardware tokens are sometimes considered more secure than
software tokens. For additional details, check the literature provided by
hardware-token vendors.
Installing External Tokens
To use external encryption devices or tokens, you need to take the following steps:
•
Step 1. Install the Cryptographic Device
•
Step 2. Install the PKCS #11 Module
Step 1. Install the Cryptographic Device
To install the drivers provided by the device manufacturer, follow the instructions
that came with the device. When you install a hardware token, you are given an
opportunity to name it; be sure to use a name that will help you identify the token
later.
Chapter
14
Managing CMS Keys and Certificates
455
Tokens for Storing CMS Keys and Certificates
Step 2. Install the PKCS #11 Module
PKCS #11 is a standard set of APIs and shared libraries used by Netscape and a
number of encryption vendors. PKCS #11 isolates an application from the details of
the cryptographic device, thus enabling the application to provide a unified
interface for PKCS #11-compliant cryptographic devices.
The PKCS #11 module implemented in Certificate Management System (in
Netscape Administration Server) enables it to support cryptographic devices
supplied by many different manufacturers. Specifically, it allows Certificate
Management System to plug in shared libraries or DLLs supplied by
manufacturers of external encryption devices and use them for generating and
storing keys and certificates for the CMS managers.
There are two ways in which you can install a PKCS #11 module, by using the
interface provided within Netscape Console or by using the command-line utility
named modutil. Both the methods are documented below.
•
To install the PKCS #11 module using Netscape Console:
a.
Log in to the CMS window (see “Logging In to the CMS Window” on
page 347).
b.
From the Console menu, choose Manage PKCS#11.
The PKCS #11 Management window appears.
c.
Click Add.
The Add PKCS #11 Module window appears.
456
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Tokens for Storing CMS Keys and Certificates
d.
Enter information as appropriate. If you choose JAR as your file type, you
are required to provide the path to the JAR file that contains the DLLs. If
you choose DLL as your file type, in addition to the path to the DLL you
are also required to provide a name for the module you’re attempting to
install (so as to help you identify it easily later). The sample in the figure
shows how you would install an nCipherTM token.
Pick DLL to add a UNIX shared/dynamic library, which on a Solaris
machine is identified with the .so extension.
e.
•
Click OK.
To install the PKCS #11 module using the modutil tool:
a.
Locate the CMS instance for which you want to install the PKCS #11
module.
b.
Open a terminal window.
c.
Go to the configuration directory of Administration Server; it is located
here: <server_root>/admin-serv/config
d.
At the prompt, enter this command:
<server_root>/shared/bin/modutil -dbdir . -nocertdb
-create
This creates the required security module database file (secmod.db) in the
configuration directory.
e.
At the prompt, enter this command:
<server_root>/shared/bin/modutil -dbdir . -nocertdb
-add <module_name> -libfile <library_file>
<library_file> specifies the path to the DLL or other library file
containing the implementation of the PKCS #11 interface module.
<module_name> specifies the name of the PKCS #11 module (which
you specified in Step 1 when you installed the drivers).
For example, if you are installing a LitronicTM token, the command would
look like this:
<server_root>/shared/bin/modutil -dbdir . -nocertdb
-add CryptOS -libfile core32
f.
Copy the new secmod.db (secmodule.db on Unix) to the following
location: <server-root>/cert-<instance_id>/config/
This overwrites the old secmod.db in this directory.
Chapter
14
Managing CMS Keys and Certificates
457
Tokens for Storing CMS Keys and Certificates
Managing Tokens Used by the Subsystems
There are two main tasks involved in managing the tokens used by Certificate
Management System:
•
Viewing Tokens
•
Changing a Token’s Password
Viewing Tokens
To view a list of the tokens currently installed for a CMS instance:
1.
Log in to the CMS window (see “Logging In to the CMS Window” on
page 347).
2.
Select the Configuration tab, and then in the right pane, select the Encryption
tab.
3.
In the Map To section, check the Token drop-down list.
It shows the names (as specified when the tokens were installed) of external
tokens installed for the currently selected CMS instance. For information on
installing external tokens, see “External Token” on page 455.
Changing a Token’s Password
The token, internal or external, that stores the key pairs and certificates for the
subsystems is protected (encrypted) by a password. To decrypt the key pairs or to
gain access to them, you must enter that password. The first time you specified this
password is when you used the token the first time, most likely during CMS
installation.
458
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Hardware Cryptographic Accelerators
It is good security practice to periodically change the password that protects your
server’s keys and certificates; changing the password periodically minimizes the
risk of someone finding out the password. To change a token’s password, use the
command-line utility called the Key Database Tool, which is documented in CMS
Command-Line Tools Guide.
Note that the single sign-on password cache stores the passwords for tokens in
order to start the server using a single password; for details, see “Required Start-up
Information” on page 316. Whenever you change the password, the cache is
updated with the new password.
Hardware Cryptographic Accelerators
Certificate Management System allows you to use hardware cryptographic
accelerators with external tokens. Many of the accelerators provide the following
security features:
•
Fast SSL connections—speed is important if you want your Certificate
Manager, Registration Manager, or Data Recovery Manager to be able to
accommodate a high number of simultaneous enrollment or service requests.
•
Hardware protection of private keys—these devices behave like smart cards, in
that they do not allow the private keys to be copied or removed from the
hardware token. This is important if you are concerned about the risks
associated with key theft from an active attacker of your online Registration
Manager or Certificate Manager.
For a list of vendors that supply hardware cryptographic accelerators, see this
URL: http://www.iplanet.com/products/infrastructure/dir_security/
cert_sys/index.html
Certificate Setup Wizard
Certificate Management System provides a wizard, called the Certificate Setup
Wizard, which automates the process of requesting and installing the certificates
required by the CMS managers—Certificate Manager, Registration Manager, Data
Recovery Manager, and Online Certificate Status Manager—installed in the
currently selected CMS instance. For details about these certificates, see “Keys and
Certificates for the Main Subsystems” on page 440.
Chapter
14
Managing CMS Keys and Certificates
459
Certificate Setup Wizard
The Certificate Setup Wizard is integrated into the CMS window, enabling you to
accomplish the following tasks:
•
Renew certificates of the CMS managers installed in a CMS instance; renewing a
certificate means getting a new certificate with the same subject name and
public and private key material as that of the existing certificate, but with an
extended validity period.
•
Request and install new certificates for the CMS managers installed in a CMS
instance; reissuing or requesting a new certificate means getting a certificate
based on a new public and private key pair.
•
Install CA certificates in the certificate or trust database of a CMS instance.
•
Install CA certificate chains in the certificate database of a CMS instance.
When you start the wizard, which you do by clicking the Certificate Setup Wizard
button in the Encryption tab of the CMS window (see the figure on page 458), you
are asked to specify whether you want to request or install a certificate. The wizard
presents you with the screens appropriate to your choice and walks you through
the entire process.
For installing certificates, except for cases when the certificate is self-signed by the
CA, you will need to run the wizard twice: once, to request the certificate and once
to install the certificate. The reason for this is, if you submit the certificate request to
a non-local CA, you will have to wait for the certificate until it is delivered to you.
The following sections explain the process of requesting and installing a certificate
by using the Certificate Setup Wizard:
•
Using the Wizard to Request a Certificate
•
Using the Wizard to Install a Certificate or Certificate Chain
For instructions on getting new certificates, see “Getting New Certificates for the
Subsystems” on page 489. For instructions on renewing existing certificates, see
“Renewing Certificates for the Subsystems” on page 497.
Using the Wizard to Request a Certificate
The Certificate Setup Wizard allows you to request any of the certificates used by
the Certificate Manager, Registration Manager, Data Recovery Manager, or Online
Certificate Status Manager installed in the currently selected CMS instance.
460
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Certificate Setup Wizard
Using the wizard to request a certificate involves the following steps:
•
Step 1. Select the Operation
•
Step 2. Choose the Certificate
•
Step 3. Specify the Key-Pair Information
•
Step 4. Specify the Subject Name for the Certificate
•
Step 5. Specify the Validity Period
•
Step 6. Specify Extensions
•
Step 7. Copy the Certificate Signing Request
•
Step 8. Check the Certificate Request Status
Step 1. Select the Operation
Indicate whether you want to request a certificate or install a certificate.
For the purposes of completing the instructions that follow, assume that you chose
to request a certificate.
Chapter
14
Managing CMS Keys and Certificates
461
Certificate Setup Wizard
Step 2. Choose the Certificate
Choose the certificate (by name) that you want to request.
The drop-down list shows various certificates used by the currently selected CMS
instance. Choose the one you want to request—which certificates you see in the list
depends on the subsystems installed in the currently selected CMS instance. You
may see a combination of the following options:
462
•
If a Certificate Manager is installed, the list includes the Certificate Manager’s
CA signing, OCSP signing, remote administration server, and SSL server
certificates. For details, see “Certificate Manager’s Key Pairs and Certificates”
on page 441.
•
If a Registration Manager is installed, the list includes the Registration
Manager’s signing, remote administration server, and SSL server certificates.
For details, see “Registration Manager’s Key Pairs and Certificates” on
page 449.
•
If a Data Recovery Manager is installed, the list includes the Data Recovery
Manager’s transport, remote administration server, and SSL server certificate.
For details, see “Data Recovery Manager’s Key Pairs and Certificates” on
page 450.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Certificate Setup Wizard
•
If a Online Certificate Status Manager is installed, the list includes the Online
Certificate Status Manager’s signing, remote administration server, and SSL
server certificate. For details, see “Online Certificate Status Manager’s Key
Pairs and Certificates” on page 453.
Depending on the certificate you want to generate, choose the one in the
drop-down list:
•
Certificate Manager Signing Certificate—choose this option if you want to
request a signing certificate for the Certificate Manager installed in the
currently selected CMS instance. If you choose this option, you must also
specify whether the certificate request is for a self-signed CA (also known as
the root CA) or a subordinate CA.
•
Certificate Manager OCSP Signing Certificate—choose this option if you want
to request an OCSP signing certificate for the Certificate Manager installed in
the currently selected CMS instance.
•
Data Recovery Manager Transport Certificate—choose this option if you want
to request a transport certificate for the Data Recovery Manager installed in the
currently selected CMS instance.
•
Online Certificate Status Manager Signing Certificate—choose this option if
you want to request a signing certificate for the Online Certificate Status
Manager installed in the currently selected CMS instance.
•
Registration Manager Signing Certificate—choose this option if you want to
request a signing certificate for the Registration Manager installed in the
currently selected CMS instance.
•
SSL Server Certificate—choose this option if you want to generate an SSL
server certificate request for the CMS managers installed in the currently
selected CMS instance.
•
SSL Server Certificate for Remote Admin—choose this option if you want to
generate a remote administration server certificate request for the CMS
managers installed in the currently selected CMS instance.
•
Other—choose this option if you want to generate a certificate request for a
certificate that is not generated by a CMS manager by default. For example, in
a Certificate Manager, you can use this option to request a CRL signing
certificate (see “CRL Signing Key Pair and Certificate” on page 443) or a
separate SSL client certificate exclusively for authenticating to the publishing
directory. Be sure to specify the certificate type in the adjoining field. By
Chapter
14
Managing CMS Keys and Certificates
463
Certificate Setup Wizard
default only two certificate types are supported: caCrlSigning for the CRL
signing certificate (see “CRL Signing Key Pair and Certificate” on page 443)
and client for SSL client certificate (see “Getting an SSL Client Certificate for a
Subsystem” on page 484)
Step 3. Specify the Key-Pair Information
Specify the key-pair information for the certificate to be requested.
You need to identify the following:
•
The token that contains the key pair for generating the certificate request—the
drop-down list shows the names of tokens currently installed for the selected
CMS instance; these are the tokens you can use now.
❍
❍
464
The internal token is identified as internal. You should choose this option if
the key pair for the certificate you chose in the previous step is stored in
the local key database.
The names of external tokens vary, matching the names specified when the
tokens were installed. You should choose this option if the key pair for the
certificate you chose in the previous step is in an external cryptographic
device. If you don’t see the token you want to use, exit from the wizard,
make sure the token is installed properly, restart the server, and repeat the
process. For information on using or installing external tokens, see
“Installing External Tokens” on page 455.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Certificate Setup Wizard
•
The key pair for generating the certificate request—you can choose to generate
the certificate request based on an existing or a new key pair.
❍
If you want to renew the certificate you selected in the previous step, use
the existing key pair for generating the request. For example, you can
extend the validity period of a certificate by renewing it.
To generate a certificate request based on an existing key pair, select the
token that contains the key pair you want to use for generating the request.
The wizard automatically selects the key pair that corresponds to the
certificate you chose in the previous step.
❍
If you want a new certificate, use a new key pair for generating the request.
For example, you may want to get a new SSL server certificate or may want
to replace an existing certificate whose private key has been compromised.
To generate a certificate request based on a new key pair, select the token
that can generate the key pair you want to use for generating the request.
For example, if you want to generate the key pair using an external
cryptographic device, such as a smart card, select that as the token. In
addition, you will be required to indicate details, such as the key algorithm
and size for the key pair.
•
The type and length of the key pair—you are required to provide this
information only if you chose to generate the certificate request based on a new
key pair. For key type, you can choose RSA or DSA. Be sure to select a key type
that the CA (to which you will later submit the request for signing) can certify.
For key length, enter the size in bits.
❍
❍
If the key type is RSA, the key size can be 512, 1024, 2048, 4098, or custom.
If the key type is DSA, the key size can be 512, 1024, or custom (must be in
increments of 64 bit).
Keep in mind that generating a new key pair takes time—the longer the key
length the longer the time the wizard takes to generate it.
Chapter
14
Managing CMS Keys and Certificates
465
Certificate Setup Wizard
Step 4. Specify the Subject Name for the Certificate
Specify the subject name, in distinguished name (DN) format, for the certificate to
be requested. Note that you will see this screen only if you chose to generate the
certificate for a new key pair.
You can either enter values for individual DN attributes required to build the
subject DN or build the complete subject DN string yourself. If you enter values for
individual DN attributes, the wizard constructs the subject DN string.
If you want to enter values for individual DN components, provide the following
information:
•
Common name—enter the name as appropriate. Except for the SSL server
certificate, the common name format can be a descriptive name of up to 255
characters. For example, you can name the Certificate Manager’s signing
certificate as “Root CA for ABC Corporation”; similarly, you can name the
Registration Manager’s signing certificate as “Registration Authority for North
America”. For a SSL server certificate, the name must be the fully qualified host
name of Certificate Management System in this form:
<machine_name>.<your_domain>.<domain>
To determine the machine and domain names, go to Netscape Console, and
locate the CMS host in the navigation tree.
466
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Certificate Setup Wizard
•
Organizational unit—enter the organizational unit the server belongs to. For
example, Corporate Security.
•
Organization—enter a description that identifies your organization. For
example, Siroe Corporation.
•
Locality—enter the name of the city where your business is located. For
example, Mountain View.
•
State or province—enter the name of the state or province where your business
is located. For example, California.
•
Country—enter the name of the country where your business is located. For
example, US.
Step 5. Specify the Validity Period
You need to complete this step only if you chose to generate a self-signed CA
certificate request.
Specify the starting and ending dates of the validity period for the certificate
request you want to generate. You can also specify the time at which the validity
period should start and end on those dates.
The default validity period is two years.
Chapter
14
Managing CMS Keys and Certificates
467
Certificate Setup Wizard
Step 6. Specify Extensions
You need to complete this step only if you chose to generate a CA signing
certificate request for a Certificate Manager (deployed as either the root CA or a
subordinate CA).
This screen allows you to set the standard X.509 version 3 extensions and
Netscape-defined extensions for the certificate to be requested. The required
extensions are chosen by default. If you want to change the default choices, be sure
to read the general guidelines explained in “Certificate and CRL Extensions” in
Appendix C of CMS Plug-ins Guide.
Also note that certificate extensions are required if you are setting up a hierarchy of
certificate authorities (CAs). Subordinate CAs must have certificates that include
the extension identifying them as either a subordinate SSL CA (which allows them
to issue certificates for SSL) or a subordinate email CA (which allows them to issue
certificates for secure email). If you disable certificate extensions, you will not be
able to set up CA hierarchies. For more information on CA hierarchies, see
“Certificate Hierarchies” in Appendix D of Managing Servers with Netscape Console.
You can set the following extensions:
•
468
Basic constraints—select this option if you want to set any of the basic
constraints extension bits in the certificate you are requesting. When you select
the option, the associated fields are enabled. You should select the ones you
want to set.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Certificate Setup Wizard
•
Netscape certificate type—select this option if you want to set any of the
Netscape Certificate Type extension bits in the certificate you are requesting.
When you select the option, the associated fields are enabled. You should select
the ones you want to set.
•
Authority key identifier—select this option if you want to set the authority key
identifier extension in the certificate you are requesting.
•
Subject key identifier—select this option if you want to set the subject key
identifier extension in the certificate you are requesting.
•
Key usage—select this option if you want to set the key usage extension in the
certificate you are requesting. If you choose this option, the digital signature
(bit 0), non repudiation (bit 1), key Certificate Sign (bit 5), and CRL sign (bit 6)
bits are set by default. The extension is marked critical as recommended by the
PKIX standard and RFC 2459 (see http://www.ietf.org/rfc/rfc2459.txt
for a description of the Key Usage extension).
•
Extension in MIME 64 DER encoding—select this option if you want to specify
any custom extension. When you select the option, the associated text field is
enabled. You should paste your extension (in MIME 64 DER encoded format)
into the text field.
Certificate Management System provides tools that generate MIME-64
encoded blobs for many standard extensions. You can use these tools for
generating MIME-64 encoded blobs for any extensions that you may want to
include in CA and other certificate requests. For details about these tools, check
this directory in your CMS installation: <server_root>/bin/cert/tools
Note that the text field provided for pasting the extension in general accepts a
single extension blob. If you want to add multiple extensions, you should use
the ExtJoiner program, which is also provided in the tools directory
mentioned above. For instructions to use the program, see Chapter 5,
“Extension Joiner Tool” of CMS Command-Line Tools Guide.
Chapter
14
Managing CMS Keys and Certificates
469
Certificate Setup Wizard
Step 7. Copy the Certificate Signing Request
Based on the information you’ve entered in the previous steps, the wizard now
displays the certificate signing request (CSR).
The request is in a base-64 encoded PKCS #10 format and is bounded by the marker
lines -----BEGIN NEW CERTIFICATE REQUEST----- and -----END NEW
CERTIFICATE REQUEST-----. An example is show below:
-----BEGIN NEW CERTIFICATE REQUEST----MIICJzCCAZCgAwIBAgIBAzANBgkqhkiG9w0BAQQFADBC6SAwHgYDVQQKExdOZXRzY2FwZSBDb21tdW5pY2
F0aW9uczngjhnMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyNzE5MDAwMFoXDTk5MDIyMzE5MDA
wMnbjdgngYoxIDAeBgNVBAoTF05ldHNjYXBlIENvbW11bmljYXRpb25zMQ8wDQYDVQQLEwZQZW9wbGUxFz
AVBgoJkiaJkIsZAEBEwdzdXByaXlhMRcwFQYDVQQDEw5TdXByaXlhIFNoZXR0eTEjMCEGCSqGSIb3Dbndg
JARYUc3Vwcml5Yhvfggsvwryw4y7214vAOBgNVHQ8BAf8EBAMCBLAwFAYJYIZIAYb4QgEBAQHBAQDAgCAM
A0GCSqGSIb3DQEBBAUAA4GBAFi9FzyJlLmS+kzsue0kTXawbwamGdYql2w4hIBgdR+jWeLmD4CP4x
-----END NEW CERTIFICATE REQUEST-----
The wizard also copies the CSR to a text file it creates in the configuration
directory, which is located at <server_root>/cert-<instance_id>/config. The
name of the text file varies depending on for which key pair you generated the
request. Table 14-1 lists them.
470
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Certificate Setup Wizard
Table 14-1 Names of files created for certificate signing requests
Filename
Certificate Signing Request
cacsr.txt
Certificate Manager CA signing certificate
ocspcsr.txt
Certificate Manager OCSP signing certificate
racsr.txt
Registration Manager signing certificate
kracsr.txt
Data Recovery Manager transport certificate
ocspcsr.txt
Online Certificate Status Manager signing certificate
sslcsr.txt
SSL server certificate
sslcsrradm.txt
Remote administration server certificate
othercsr.txt
Other certificates, such as Certificate Manager CRL signing
certificate or SSL client certificate
Do not modify the CSR; you must send it to the CA as it is. You can either submit
the request automatically or copy the request and manually submit it to the CA by
visiting the URL it provides for this purpose. Note that the wizard’s
auto-submission feature—a feature that enables you to send the request directly to
a remote CA without having to manually copy the base-64 encoded certificate and
paste the request in an enrollment form—can be used to submit requests to a
remote Certificate Manager or Registration Manager (if that Certificate Manager is
configured to receive requests via the Registration Manager) only. It can’t be used
for submitting the request to a third-party CA. For a third-party CA, you must
manually copy the certificate request and paste it into the text area provided in the
CA’s enrollment form.
Sending the CSR Automatically to a CMS Manager
To send the certificate signing request (CSR) automatically to a Certificate
Manager:
1.
Type the appropriate values in the following fields:
Send the request to a remote CMS now. Select this option.
Host name. Type the fully-qualified host name (in the
<machine_name>.<your_domain>.<domain> format) of the Certificate
Manager to which you want to submit your request automatically. For
example, CAmachine.siroe.com.
EE port number. Type the end-entity port number. For example, 80.
Chapter
14
Managing CMS Keys and Certificates
471
Certificate Setup Wizard
Yes, it’s the SSL secure server port. Select this option if the end entity port
number you specified is the SSL port for end entities.
2.
Click Next to submit your request to the CA.
The Certificate Manager returns a request ID for your request. Note the request
ID as you can use it later to get the certificate from the Certificate Manager to
which you submitted the request.
The request you submitted gets queued for agent approval—an agent needs to
process and approve the certificate request, which the CA signs then and
delivers back to the email address specified in the request. You can contact the
CA agent to find out when the certificate will be delivered to you. If you have
agent privileges to the Certificate Manager, you can log in to its agent interface
and approve the request yourself.
3.
Once the certificate has been issued, you can use the request ID to import the
certificate into the wizard. Alternatively, you can also install the certificate
following the instructions in “Using the Wizard to Install a Certificate or
Certificate Chain” on page 475.
Sending the CSR Manually to an Internal CA
The following instructions assume that your internally deployed CA is a Certificate
Manager and that you are using the default HTML forms provided for end-entity
enrollment. If you have customized these forms, you should follow the appropriate
instructions.
To send the certificate signing request (CSR) manually to an internal CA:
1.
Copy the CSR, including the marker lines -----BEGIN NEW CERTIFICATE
REQUEST----- and -----END NEW CERTIFICATE REQUEST-----, to a text file.
If you are running the wizard on a Windows NT system, you can also copy the
CSR to the Windows clipboard. In a Unix system, you may have to open an
application, such as Netscape Composer, with a clipboard.
2.
Open a web browser window.
3.
Enter the URL to the CA’s home page.
By default, the CA’s home page is the end entity services interface. Depending
on the port at which the CA is listening to end-entity requests (see “End-Entity
Ports” on page 377) the URL to the end entity services is one of the following:
http://<hostname>:<end_entity_port> or
https://<hostname>:<end_entity_port>, where <hostname> is in the form
<machine_name>.<your_domain>.<domain>
The end entity services interface appears.
472
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Certificate Setup Wizard
4.
Click the Enrollment tab.
5.
In the menu list, click the appropriate link:
❍
❍
❍
❍
6.
If the CSR is for a subordinate CA certificate, in the Server section, click the
Certificate Manager link.
If the CSR is for a Registration Manager’s signing certificate, in the Server
section, click the Registration Manager link.
If the CSR is for a Certificate Manager’s OCSP signing certificate or Online
Certificate Status Manager’s signing certificate certificate, in the Server
section, click the OCSP Responder link.
If the CSR is for an SSL server certificate or remote administration server
certificate, in the Server section, click the SSL Server link.
In the form that appears, enter the required information and paste the CSR
from either the clipboard or text file.
For information on how a form works, click the Help button provided on the
form. Be sure to include the marker lines, -----BEGIN NEW CERTIFICATE
REQUEST----- and -----END NEW CERTIFICATE REQUEST-----.
7.
Submit the request.
8.
When the CA sends you a response, save the information in a text file for
future reference or inquiry.
Note that the you submitted gets queued for agent approval—an agent needs
to process and approve the certificate request, which the CA signs then and
delivers back to the email address specified in the request. You can contact the
CA agent to find out when the certificate will be delivered to you. If you have
agent privileges to the Certificate Manager, you can approve the request
yourself.
9.
When you receive the certificate from the CA, you’ll need to install it following
the instructions in “Using the Wizard to Install a Certificate or Certificate
Chain” on page 475.
Sending the CSR to an External CA
An external CA is any public or third-party CA. Before sending the CSR to a public
CA, make sure that the CA can issue the certificate you want to request. Also, it is a
good idea to read the policy statement published by a CA to see whether the CA
imposes any restrictions on the validity period or usage of the certificate.
Chapter
14
Managing CMS Keys and Certificates
473
Certificate Setup Wizard
To send the CSR manually to an external or third-party CA:
1.
Copy the CSR, including the marker lines -----BEGIN NEW CERTIFICATE
REQUEST----- and -----END NEW CERTIFICATE REQUEST-----, to a text file.
If you are running the wizard on a Windows NT system, you can also copy the
CSR to the Windows clipboard. In a Unix system, you may have to open an
application, such as Netscape Composer, with a clipboard.
2.
Open a web browser window.
3.
Navigate to the CA’s home page by entering the appropriate URL in the
browser window.
4.
Locate the form that allows you to submit certificate requests for servers.
5.
Enter the required information and paste the CSR from the text file.
6.
Submit the request.
7.
When the CA sends you a response, save the information in a text file for
future reference or inquiry.
8.
When you receive the certificate from the CA, install it following the
instructions in “Using the Wizard to Install a Certificate or Certificate Chain”
on page 475.
Step 8. Check the Certificate Request Status
The wizard now informs you of the status of the request.
474
•
If you requested a self-signed CA certificate, the wizard automatically submits
the CSR to the CA. If the CSR includes all the required information, the CA
signs the certificate and returns it to the wizard, which then installs it in the
appropriate token.
•
If you requested any other certificate, you must get the certificate from the CA
and install it using the process outlined in “Using the Wizard to Install a
Certificate or Certificate Chain” on page 475.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Certificate Setup Wizard
Using the Wizard to Install a Certificate or
Certificate Chain
The Certificate Setup Wizard allows you to install or import the following
certificates into either an internal or external token used by the currently selected
CMS instance:
•
Any of the certificates used by a Certificate Manager, Registration Manager,
Data Recovery Manager, and Online Certificate Status Manager
•
Any other trusted CA certificates (certificates of CAs that you want to trust)
•
Certificate chains
A certificate chain typically includes a collection of certificates: the subject
certificate, the trusted root CA certificate, and any intermediate CA certificates
needed to link the subject certificate to the trusted root. However, the
certificate chain the wizard allows you to import must include only CA
certificates; none of the certificates can be a user certificate.
In a certificate chain, each certificate in the chain is encoded as a separate
DER-encoded object. When the wizard imports a certificate chain, it imports
these objects one after the other, all the way up the chain to the last certificate,
which may or may not be the root CA certificate. If any of the certificates in the
chain already exist in the local certificate database, the wizard replaces them by
the ones included in the chain. If the chain includes intermediate CA
certificates, the wizard adds them to the certificate database as untrusted CA
certificates.
The certificate or certificate chain you provide to the wizard for installation must
be in one of the data formats supported by the wizard. This is explained in “Data
Formats for Installing Certificates and Certificate Chains” on page 476.
Using the wizard to install a certificate or certificate chain involves the following
steps, described in detail on page 477:
•
Step 1. Select the Operation
•
Step 2. Select the Certificate or Certificate Chain
•
Step 3. Specify the Location of the Certificate
•
Step 4. View the Certificate or Certificate Chain
•
Step 5. Install the Certificate or Certificate Chain
•
Step 6. Verify the Certificate Status
Chapter
14
Managing CMS Keys and Certificates
475
Certificate Setup Wizard
Data Formats for Installing Certificates and Certificate Chains
The wizard can accept certificates and certificate chains in several data formats.
This section briefly explains the data formats recognized by the wizard.
Binary Formats
The wizard can recognize certificates and certificate chains in the following binary
formats:
•
DER-encoded certificate—This is a single binary DER-encoded certificate.
•
PKCS #7 SignedData objects—This is a PKCS #7 SignedData object. The only
significant field in the SignedData object is the certificate. In particular, the
signature and the contents are ignored. The PKCS #7 format allows multiple
certificates to be downloaded at once.
•
DER-encoded certificates—These are DER-encoded certificates that may or
may not be wrapped in a base-64 encoding package surrounded by the
delimiters -----BEGIN CERTIFICATE----- and -----END
CERTIFICATE-----.
•
Netscape Certificate Sequence—This is a simpler format for downloading
certificate chains. It consists of a PKCS #7 ContentInfo structure, wrapping a
sequence of certificates. The value of the contentType field should be
netscape-cert-sequence, while the content field is the following structure:
CertificateSequence ::= SEQUENCE OF Certificate
This format allows multiple certificates to be downloaded at once.
Text Formats
The wizard can also import certificates and certificate chains in text formats. Here’s
what you should be aware of when using the wizard to install a certificate or
certificate chain in text format:
The text format must begin with the following line:
-----BEGIN CERTIFICATE-----
Following this line should be the certificate data, which can be in any of the binary
formats described in “Binary Formats” on page 476. This data should be base-64
encoded as described by RFC 1113 (for details, see
http://www.scit.wlv.ac.uk/rfc/rfc11xx/RFC1113.html).
Following the certificate data must be this line:
-----END CERTIFICATE-----
476
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Certificate Setup Wizard
Step 1. Select the Operation
Indicate whether you want to request a certificate or install a certificate.
For the sake of completing the instructions that follow, assume that you chose to
install a certificate.
Chapter
14
Managing CMS Keys and Certificates
477
Certificate Setup Wizard
Step 2. Select the Certificate or Certificate Chain
Select the certificate you want to install.
The drop-down list shows various options. Depending on whether you want to
install a CMS certificate, any other trusted CA certificate, or a CA certificate chain,
choose the appropriate option from the list box:
478
•
Certificate Manager Signing Certificate—choose this option if you want to
install a CA signing certificate for the Certificate Manager installed in the
currently selected CMS instance.
•
OCSP Signing Certificate—choose this option if you want to install an OCSP
signing certificate for the Certificate Manager installed in the currently selected
CMS instance.
•
Registration Manager Signing Certificate—choose this option if you want to
install a request signing certificate for the Registration Manager installed in the
currently selected CMS instance.
•
Data Recovery Manager Transport Certificate—choose this option if you want
to install a transport certificate for the Data Recovery Manager installed in the
currently selected CMS instance.
•
Online Certificate Status Manager Signing Certificate—choose this option if
you want to install a signing certificate for the Online Certificate Status
Manager installed in the currently selected CMS instance.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Certificate Setup Wizard
•
SSL Server Certificate—choose this option if you want to install an SSL server
certificate for the CMS managers installed in the currently selected CMS
instance.
•
SSL Server Certificate Remote Admin—choose this option if you want to install
a remote administration server certificate for the Certificate Manager,
Registration Manager, Data Recovery Manager, or Online Certificate Status
Manager installed in the currently selected CMS instance.
•
Trusted CA Certificate Chain—choose this option if you want to install a
trusted CA certificate chain; the CA certificate will be included in the chain.
•
Untrusted CA Certificate Chain—choose this option if you want to install an
untrusted CA certificate chain.
•
Other—choose this option if you want to install any other certificate, for
example, a CRL signing certificate or a SSL client certificate.
Step 3. Specify the Location of the Certificate
Locate the certificate or certificate chain you want to install.
You can keep the certificate or certificate chain in a text file or copy it to the text
area on the wizard screen. Here is some information that will help you decide on
the location.
Chapter
14
Managing CMS Keys and Certificates
479
Certificate Setup Wizard
•
Keeping the certificate or certificate chain in a text file—the wizard can import
a certificate or certificate chain from a text file in text as well as binary formats;
see “Data Formats for Installing Certificates and Certificate Chains” on
page 476. If you have copied the certificate or certificate chain to a text file, you
will be required to provide the wizard with the absolute path to that file. The
file must be located in the host system the wizard is running. If the file is
located elsewhere, exit from the wizard, copy the file to the local disk, and
restart the wizard.
•
Copying the certificate or certificate chain to the text area on the wizard
screen—you can paste the certificate or certificate chain into the text area
provided by the wizard. This is a text input field, so you can paste the
certificate or certificate chain in text format only. For example, if you are
installing a certificate, it base-64 encoded certificate blob should look similar to
this:
-----BEGIN CERTIFICATE----MIICKzCCAZSgAwIBAgIBAzANgkqkiG9w0BAQQFADA3MQswCQYDVQQGEwJVUzERMA8GA1UEChMITmV0c2Nh
cGUxFTATBgNVBAsTDFN1cHJpeWEncyBDQTAeFw05NzEwMTgwMTM2MjVaFw05OTEwMTgwMTM2MjVaMEgxCz
AJBgNVBAYTAlVTMREwDwYDVQQKEwhOZXRzY2FwZTENMAsGA1UECxMEUHawczEXMBUGA1UEAxMOU3Vwcml5
YSBTaGV0dHkwgZ8wDQYJKoZIhdfNAQEBBQADgY0AMIGJAoGBAMr6eZiPGfjX3uRJgEjmKiqG7SdATYzBcA
Bu1AVyd7chRFOGD3wNktbf6hRo6EAmM5R1Askzf8AW7LiQZBcrXpc0k4du+2j6xJu2MPm8WKuMOTuvzpo+
SGXelmHVChEqooCwfdiZywyZNmgaMa2MS6pUkfQVAgMBAAGjNjA0MBEGCWCGSAGG+EIBAQQEAwIAgD
-----END CERTIFICATE-----
•
480
The certificate is at the CMS where your request was sent— if you have
previously sent the certificate request to a remote Certificate Manager
automatically and have noted the request ID that you received in return, you
can use it to retrieve the certificate from the Certificate Manager.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Certificate Setup Wizard
Step 4. View the Certificate or Certificate Chain
The wizard displays the certificate or certificate chain you have chosen to install.
Make sure you have chosen the right one; otherwise, use the Back button to go back
and locate the right one. Specify a nickname for the certificate.
Step 5. Install the Certificate or Certificate Chain
The wizard shows the certificate or certificate chain information you have selected
for installing. You should check the information to make sure that you have chosen
the correct one for installing.
After verifying that the certificate you have chosen is the correct one, click the
Install button. The wizard installs the certificate or the CA chain in the token you
have chosen.
•
If you installed a certificate that has been issued by CA whose certificate chain
doesn’t exist in the certificate database, you must add that CA’s certificate
chain to the database. To add the CA chain to the database, copy the CA chain
to a text file, start the wizard again, and install the CA chain.
Chapter
14
Managing CMS Keys and Certificates
481
Configuring the Server’s Security Preferences
•
If you installed (or imported) a certificate chain, the wizard adds (to the local
trust database) the first certificate in the chain as a trusted CA certificate and
any subsequent certificates as untrusted CA certificates. For more information
on how the wizard installs a certificate chain, see “Using the Wizard to Install a
Certificate or Certificate Chain” on page 475.
Step 6. Verify the Certificate Status
This step is applicable only if you installed a certificate chain.
After you install a certificate chain in the trust database of a CMS instance, check
the trust status of each certificate that got installed, and make sure that the correct
CA certificates are trusted. For instructions, see “Changing the Trust Settings of a
CA Certificate” on page 508.
Configuring the Server’s Security Preferences
Configuring a CMS manager’s security preferences involves identifying the
following:
•
The SSL server certificates a server must use for authenticating to the end
entity, agent, and administration interfaces. For details, see “Configuring the
Server to Use Separate SSL Server Certificates” on page 482.
•
The SSL client certificate a Certificate Manager must use for authenticating to
the publishing directory (if the Certificate Manager is configured to publish
certificates and CRLs to the directory). For details, see “Getting an SSL Client
Certificate for a Subsystem” on page 484.
•
The version of SSL that an instance of Certificate Management System must
use during SSL communication. The latest version is SSL version 3, but many
older clients use SSL version 2. Because client authentication is required for
performing privileged operations, you must enable SSL version 3 ciphers
supported by Certificate Management System. For details, see “Setting Up
Cipher Preferences for SSL Communications” on page 486.
Configuring the Server to Use Separate SSL
Server Certificates
You can configure a CMS instance to use separate SSL server certificates for
authenticating to Netscape Console, the Agent Services interface, and the end
entity services interface.
482
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Configuring the Server’s Security Preferences
This configuration involves the following steps:
•
Step 1. Get the Required SSL Server Certificates
•
Step 2: Update the Configuration
Step 1. Get the Required SSL Server Certificates
You must first request and install the required number of SSL server certificates for
the particular CMS instance. For instructions, see “Getting New Certificates for the
Subsystems” on page 489.
Once you have installed the certificates, you should be able to see them in the list of
SSL server certificates in the Encryption tab of the CMS window.
Step 2: Update the Configuration
After you verify that the certificates are installed, configure the server as follows:
1.
Stop the CMS instance; see “Stopping Certificate Management System” on
page 324.
2.
Go to this directory: <server_root>/cert-<instance_id>config
3.
Open the configuration file (CMS.cfg) in a text editor.
Chapter
14
Managing CMS Keys and Certificates
483
Configuring the Server’s Security Preferences
4.
Change the configuration:
❍
To change the certificate used for authenticating to the Agent Services
interface, locate the agentGateway.https.nickName parameter and
change its value to the nickname of the new SSL server certificate. For
example, if the nickname of the SSL server certificate is ServerCert_agt,
the configuration should look like this:
agentGateway.https.nickName=ServerCert_agt cert-<instance_id>
❍
To change the certificate used for authenticating to the end-entity services
interface, locate the eeGateway.https.nickName parameter and change its
value to the nickname of the new SSL server certificate. For example, if the
nickname of the SSL server certificate is ServerCert_ee, the configuration
should look like this:
eeGateway.https.nickName=ServerCert_ee cert-<instance_id>
❍
To change the certificate used for authenticating to the administration
interface, Netscape Console, locate the radm.https.nickName parameter
and change its value to the nickname of the new SSL server certificate. For
example, if the nickname of the SSL server certificate is
ServerCert_admin, the configuration should look like this:
radm.https.nickName=ServerCert_admin cert-<instance_id>
5.
Save your changes.
6.
Start the server; see “Starting Certificate Management System” on page 316.
Getting an SSL Client Certificate for a
Subsystem
By default, the Certificate Manager uses its SSL server certificate for SSL client
authentication to the publishing directory. For details about publishing certificates
and CRLs to a directory, see Chapter 19, “Setting Up LDAP Publishing.”
If you want the Certificate Manager to use another certificate for authenticating to
the publishing directory, you can do so. This section provides instructions for
requesting and installing an SSL client certificate for a Certificate Manager and
configuring it to use that certificate for SSL client authentication to the publishing
directory.
1.
484
Log in to Netscape Console; see “Logging In to Netscape Console” on
page 340.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Configuring the Server’s Security Preferences
2.
Locate the CMS instance for the Certificate Manager, make sure it’s started,
and then log in to the CMS window of the Certificate Manager.
3.
Select the Configuration tab, and then select the Encryption tab.
4.
Click the Certificate Setup Wizard button to launch the wizard, which is
explained in “Certificate Setup Wizard” on page 459.
5.
Select the option to request a certificate and then follow the on-screen prompts
to generate a certificate request for the client certificate—in the Certificate
Selection window, select Other and specify client as the certificate type in the
associated text field.
6.
Once you have the certificate request ready, submit it to a CA so that it can
issue a certificate. For general instructions to use the wizard to request a
certificate, see section “Using the Wizard to Request a Certificate” on page 460.
7.
If you submitted the request to a Certificate Manager and if you have agent
privileges for that Certificate Manager, log in to its Agent Services interface,
locate the request, and check the request for required extensions. (If you
submitted the request to any other CA, you must ask the person managing that
CA to make the same changes to the request before approving it.)
Make sure that only the SSL Client option for certificate type is selected in the
request. For certificates with no Netscape Certificate Type extensions, the Key
Usage extension must be included with Signing and Encryption bits set.
8.
Approve the request.
9.
Once you have the certificate ready, restart the wizard and install the certificate
in the Certificate Manager’s database. For general instructions to use the
wizard to add a certificate, see “Using the Wizard to Install a Certificate or
Certificate Chain” on page 475.
Note that the default nickname for the certificate is
crlSigningCert cert-<instance_id>, where <instance_id> identifies the
CMS instance in which the Certificate Manager is installed.
10. After you’ve installed the certificate successfully, go to the Tasks tab and stop
the Certificate Manager.
11. Configure the Certificate Manager to use this certificate.
After you install the certificate, configure the Certificate Manager to use the
new certificate for SSL client authentication to the publishing directory. For
instructions, see “Step 5. Identify the Publishing Directory” on page 660.
Chapter
14
Managing CMS Keys and Certificates
485
Configuring the Server’s Security Preferences
Setting Up Cipher Preferences for SSL
Communications
A cipher is the algorithm used in encryption. Some ciphers have stronger encryption
capabilities than others. Generally speaking, the more bits a cipher uses during
encryption, the harder it is to decrypt the data.
When a client initiates an SSL connection with Certificate Management System, it
lets the server know what ciphers it prefers to use to encrypt information. In any
two-way encryption process, both parties must use the same ciphers. A number of
ciphers are available; your server needs to be able to use the most popular ones.
SSL Ciphers Supported in Certificate Management System
Figure 14-1 shows the ciphers supported by Certificate Management System (on
the server side). The figure shows SSL 2.0 and 3.0 ciphers supported in the
domestic (US and Canada) version of Certificate Management System. Note that
Certificate Management System has received retail status from the United States
Department of Commerce Bureau of Export Administration; under new
regulations, retail status makes it possible to export Certificate Management
System with the same encryption and cryptographic features available in the US
and Canada. For more information, see Appendix C, “Export Control
Information.”
Figure 14-1
486
SSL version 2.0 and 3.0 cipher suites supported (in the domestic version)
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Configuring the Server’s Security Preferences
You can choose ciphers from the SSL 2.0 protocol, as well as from SSL 3.0. To
specify which ciphers your server can use, check them in the list of ciphers to
enable them. Unless you have a compelling reason not to use a specific cipher, you
should check them all, except as noted in the warning that follows. For a detailed
description of ciphers, see "Ciphers Used with SSL" in Appendix E of Managing
Servers with Netscape Console.
CAUTION
You might not want to check the options that say “No Encryption,
only MD5 message authentication” and “No Encryption, only
Fortezza and SHA message authentication.” The reason for this is, if
no other ciphers are available on the client side, the server will use
these and no encryption will occur.
Previous US law prohibited the export of software with strong encryption, so most
browsers still in use outside of the US and Canada do not support 128-bit
encryption. Disabling all 40-bit ciphers will ensure that all connections use
higher-grade security, but will prevent access to your service to many users outside
of the US and Canada.
Note that Netscape Communicator too has received retail status from the United
States Department of Commerce Bureau of Export Administration; under new
regulations, retail status makes it possible to export Communicator with the same
encryption and cryptographic features available in the US and Canada.
Prior to the retail status, international users of Netscape Communicator (with
encryption capability restricted to 40-bit encryption) could use Netscape’s
International Step-Up program to step up to stronger encryption, 56-bit, 128-bit, or
168-bit. Step-up refers to the ability of export browsers to establish strong SSL
sessions with domestic SSL servers, if they have the appropriate step-up
certificates.
Because many of the features, such as issuance of dual certificates for dual key
pairs and real-time verification of certificates using the OCSP protocol, supported
in Certificate Management System require Communicator versions 4.7x or
Netscape 6, it’s recommended that you upgrade your browser. For information on
downloading the browser, check this site:
http://home.netscape.com/download/
Chapter
14
Managing CMS Keys and Certificates
487
Configuring the Server’s Security Preferences
Configuring the Server to Use Specific Ciphers
You can set a number of systemwide preferences for SSL by specifying the ciphers
that Certificate Management System should recognize and use during SSL
communication; the server applies the cipher settings you choose to all the SSL
(HTTPS) ports it uses.
To change the cipher settings for a CMS instance:
1.
Log in to the CMS window (see “Logging In to the CMS Window” on
page 347).
2.
Select the Configuration tab, and then in the right pane, select the Encryption
tab.
3.
Click SSL Cipher Preferences, and choose the appropriate options.
For details, see “Setting Up Cipher Preferences for SSL Communications” on
page 486.
4.
Click OK.
You are returned to the Encryption tab.
5.
To save your changes, click Save.
The CMS configuration is modified. If the changes you made require you to
restart the server, you will be prompted accordingly. In that case, restart the
server.
488
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Getting New Certificates for the Subsystems
Getting New Certificates for the Subsystems
You may need to get new certificates for the CMS managers installed in a CMS
instance. Getting a new certificate means getting a certificate based on a new public
and private key pair.
The sections that follow explain how to get new certificates for the Certificate
Manager, Registration Manager, Data Recovery Manager, and Online Certificate
Status Manager using the Certificate Setup Wizard. Alternatively, you can use the
command-line utilities called the Key Database Tool and Certificate Database Tool.
For details about these tools, check the CMS Command-Line Tools Guide. To locate an
online version of this book, see “Where to Go for Related Information” on page 28.
Getting a new key pair and a corresponding certificate involves the following
steps:
•
Step 1. Plan for the New Certificate
•
Step 2. Request the New Certificate
•
Step 3. Install the New Certificate
•
Step 4. Deploy the New Certificate
Step 1. Plan for the New Certificate
Getting a new certificate for a CMS manager requires careful planning. This section
provides some guidelines that will help you request and install the new certificate.
Determine which certificate you want to get
You can get CA signing, OCSP signing, CRL signing, SSL server, and remote
administration certificates for the Certificate Manager; signing, SSL server, and
remote administration certificates for the Registration Manager; transport, SSL
server, and remote administration certificates for the Data Recovery Manager; and
signing, SSL server, and remote administration certificates for the Online
Certificate Status Manager. For details about the certificates used by a CMS
manager, see “Keys and Certificates for the Main Subsystems” on page 440.
•
If you have deployed a Certificate Manager as your root CA and if you want to
get a new self-signed CA certificate for that Certificate Manager, you must
consider the possible effects on your PKI setup of changing the key pair of the
root CA. If you reissue the Certificate Manager’s CA signing certificate with a
new key material, none of the certificates issued or signed by the CA using its
old key will work; the reason for this is, when you change the root CA key, all
certificates that rely on the CA certificate for validation will no longer be
Chapter
14
Managing CMS Keys and Certificates
489
Getting New Certificates for the Subsystems
validated. For example, if the CA has issued certificates to subordinate
Certificate Managers, Registration Managers, Data Recovery Managers, Online
Certificate Status Manager, and agents, all those certificates will become
invalid—the subsystems will fail to function, and agents will fail to access
agent interfaces.
Before getting a new self-signed certificate for the Certificate Manager,
therefore, you must address issues involved in deploying the new root CA
certificate across your enterprise. It is beyond the scope of this document to
explain how you should deploy the new CA certificate. You may find it useful
to go over some of the deployment issues discussed in the document available
at this URL: http://help.netscape.com/kb/corporate/19980710-25.html
490
•
If you have deployed a Certificate Manager as a subordinate CA (that’s
chained to a root CA) and if you want to get a new subordinate CA certificate
for that Certificate Manager, you must consider the possible effects on your
PKI setup of changing the key pair of the subordinate CA. When you change
the subordinate CA key, all certificates that rely on the subordinate CA
certificate for validation will no longer be validated. Before getting a new
subordinate certificate, therefore, you must plan to address issues involved in
deploying the new subordinate CA certificate across you enterprise.
•
If you have deployed a Certificate Manager and if you have configured it to
publish CRLs to a Online Certificate Status Manager, you will need to identify
the Certificate Manager to the Online Certificate Status Manager again. For
details, see “Step 3. Identify the CA to the OCSP Responder” on page 715.
•
If you want to get a new signing certificate for a Registration Manager, check
whether the Registration Manager has been set up as a trusted manager for a
Certificate Manager and Data Recovery Manager—that is, you must identify
the subsystems that have been configured to receive requests from this
Registration Manager; see “Trusted Managers” on page 398. You will need to
replace the existing signing certificate with the new one in all these
subsystems.
•
If you want to get a new transport certificate for a Data Recovery Manager, you
must identify the end-entity interfaces or forms that have been set up for the
archival of end users’ encryption private keys; see “How Key Archival Works”
on page 743. You will need to replace the existing transport certificate with the
new one in all these forms.
•
If you want to get a new SSL server certificate for a Certificate Manager,
determine whether the Certificate Manager is used as a master CA in a
cloned-CA setup; see “Cloning a Certificate Manager” on page 288. If it is,
you’ll have to update the clone CAs certificate databases with the new SSL
server certificate.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Getting New Certificates for the Subsystems
Also determine whether the Certificate Manager is configured to publish
certificates and CRLs to an LDAP directory and whether it uses the SSL server
certificate for SSL client authentication to the directory. If it does, you will have
to request the certificate with the appropriate extensions, and after installing
the certificate you will have to configure the publishing directory to use this
certificate.
•
You can get any number of SSL server certificates.
Decide on the CA that will sign the certificate
If you want to get a new self-signed CA certificate, you don’t have to make this
decision, because the CA itself signs it. For all other certificates, you must decide on
the CA that will sign the certificate.
If you want the certificate to be signed by an internally deployed CA, check to be
sure (for example, the policy configuration) that the CA can issue the certificate
you want request.
If you want the certificate to be signed by a public CA, find out the following:
•
Does the public CA have a public policy statement? If one is available, read it;
it may help you decide whether to request the certificate from this CA.
•
Is the public CA’s certificate already installed in the trusted CA in the trust
database of Certificate Management System? If not, do you want to install it?
•
Is the public CA a trusted CA in the trust database of Certificate Management
System? If not, do you want to trust it?
•
Can the public CA issue the certificate you want to request?
•
Does the public CA impose any restrictions on certificates it issues? For
example, if you are planning for requesting a subordinate CA certificate for a
Certificate Manager, you may want to find out whether the public CA imposes
any restrictions on the validity period, volume, or type of certificates your CA
can issue. If you are planning for requesting a signing certificate for a
Registration Manager, you may want to find out whether the public CA
imposes any restrictions on the validity period or the number of certificate
requests the Registration Manager can sign using the certificate. If you are
planning for requesting a transport certificate for a Data Recovery Manager,
you may want to find out whether the public CA imposes any restrictions on
the validity period or the number of keys the Data Recovery Manager can
archive using the certificate.
•
What information does the public CA expects you to provide with the
certificate request?
Chapter
14
Managing CMS Keys and Certificates
491
Getting New Certificates for the Subsystems
•
How long will the public CA take to deliver the certificate, and how will the
certificate be delivered to you? (The most common delivery mechanism is by
email.)
Determine the token for generating the key pair
Identify the token, internal or external, that you want to use to generate the key
pair for the certificate and to store the certificate. For details, see “Tokens for
Storing CMS Keys and Certificates” on page 454. If you want to use an existing
token, you must know the password that protects the token. If the token is external,
make sure that the token is installed properly; for instructions, see “Installing
External Tokens” on page 455.
Determine certificate formulation information
Decide on the subject DN and nickname for the certificate you want generate. Also
decide on details such as the key algorithm, key size, extensions, and validity
period for the certificate.
Step 2. Request the New Certificate
Once you have all the information, go ahead and request the certificate. The
Certificate Setup Wizard built into the CMS window automates the process of
requesting certificates used by the CMS managers. You can use this wizard to
generate a new certificate request and submit the request to any CA for signing.
For instructions, see “Using the Wizard to Request a Certificate” on page 460.
Step 3. Install the New Certificate
When you receive the certificate from the CA, you must install it in the token that
contains the key pair for this certificate; it must be the token you used to generate
the request in Step 2 above.
The Certificate Setup Wizard automates the process of installing certificates used
by the CMS managers. You can use this wizard to install the new certificate. For
instructions, see “Using the Wizard to Install a Certificate or Certificate Chain” on
page 475.
492
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Getting New Certificates for the Subsystems
Step 4. Deploy the New Certificate
In this step, follow the instructions appropriate for the certificate you installed:
•
If you installed a new CA signing certificate for a Certificate Manager, see
“Deploying Certificate Manager’s CA Signing Certificate” on page 493.
•
If you installed a new signing certificate for a Registration Manager, see
“Deploying Registration Manager’s Signing Certificate” on page 494.
•
If you installed a new transport certificate for a Data Recovery Manager, see
“Deploying Data Recovery Manager’s Transport Certificate” on page 495.
•
If you installed a new SSL server certificate, see “Deploying a Subsystem’s SSL
Server Certificate” on page 496.
Deploying Certificate Manager’s CA Signing Certificate
If you reissued the Certificate Manager’s CA signing certificate with a new key
material, none of the certificates issued by the CA using its old key will work. For
example, if the CA has issued certificates to subordinate Certificate Managers,
Registration Managers, Data Recovery Managers, Online Certificate Status
Manager, and agents, all those certificates will become invalid—the subsystems
will fail to function and agents will fail to access the agent interfaces.
To reinstate your PKI setup, first you should get an agent certificate from the new
CA so that you can get access to the Certificate Manager’s agent interface. Once
you have access to this interface, you will be able to approve new certificate
requests from entities such as Registration Managers, Data Recovery Managers,
Online Certificate Status Managers, and agents.
To request an agent certificate from the new CA:
1.
Go to this directory: <server_root>/cert-<instance_id>/config
2.
Open the configuration file, CMS.cfg, in a text editor.
3.
Locate the agentGateway.enableAdminEnroll parameter and change its
value from false to true. The modified parameter should look like this:
agentGateway.enableAdminEnroll=true
4.
Save your changes and close the file.
5.
Restart the server.
6.
Open a web browser window.
Chapter
14
Managing CMS Keys and Certificates
493
Getting New Certificates for the Subsystems
7.
Go to the Certificate Manager’s agent interface.
The URL is in this format: https://<hostname>:<agent_port>
8.
Enter all the information and request a new certificate.
If you need more information on getting the first agent certificate, see “Stage 3.
Enrolling for Administrator/Agent Certificate” on page 277.
9.
Once you get the certificate, install it in your browser.
10. Access the Certificate Manager’s agent interface using your new certificate.
Deploying Registration Manager’s Signing Certificate
If you installed a new Registration Manager signing certificate, you must also
install this certificate in the certificate database of all subsystems (Certificate
Manager, Registration Manager, and Data Recovery Manager) that trust this
Registration Manager.
Here’s what you must do:
1.
Install the new signing certificate in the subsystems’ certificate databases.
Because the Registration Manager uses its signing certificate for SSL client
authentication to the subsystems, you must add the new signing certificate to
the internal database of all subsystems that have been configured to receive
requests from the Registration Manager.
To add the new certificate to a subsystem’s internal database:
❍
❍
❍
494
Note the instance ID and host name of the Registration Manager for which
you got the new signing certificate; this information will help you to
identify the Registration Manager in a subsystem’s list of privileged users.
Copy the new signing certificate, in base-64 encoded format, to a text file.
Add the new certificate to the individual subsystem’s internal database
following the instructions in “Changing a Privileged User’s Certificate” on
page 434. Repeat this step for all subsystems that receive requests from this
Registration Manager.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Getting New Certificates for the Subsystems
2.
Ensure that the CA that signed the Registration Manager’s certificate is in the
certificate database of the subsystem.
When a Registration Manager does SSL client authentication using its new
certificate, the subsystem, as a part of validating the certificate presented by the
Registration Manager, checks its trust database for the CA (certificate) that
signed the Registration Manager’s new certificate. If the subsystem does not
find the CA as a trusted CA in its trust database, it rejects the Registration
Manager.
For instructions on checking the trust database of a subsystem, see “Viewing
the Certificate Database Content” on page 505.
❍
❍
If you don’t find the CA certificate, add it to the database as a trusted CA.
For instructions on adding a CA certificate to the trust database of a
subsystem, see “Installing a New CA Certificate in the Certificate
Database” on page 510.
If you find the CA certificate, verify its trust status. If it is untrusted,
change the status to trusted. For instructions on changing the trust setting
of a CA certificate, see “Changing the Trust Settings of a CA Certificate” on
page 508.
Deploying Data Recovery Manager’s Transport Certificate
Because clients capable of generating dual key pairs use the transport certificate for
encrypting end users’ encryption private keys before sending them to the Data
Recovery Manager, you must update the appropriate enrollment or key archival
page to identify and use the new transport certificate. Otherwise, the Data
Recovery Manager will fail to archive users’ encryption private keys.
In general, here’s what you need to do:
1.
Locate the enrollment page that embeds the key archival feature.
2.
View the HTML source, and identify the parameter that corresponds to the
Data Recovery Manager’s transport certificate.
The default enrollment forms for end users embed this feature. Figure 14-2
shows the default directory-based user enrollment form with the transport
certificate-related information. (For more information, see “Step C. Customize
the Certificate Enrollment Form” on page 757.)
Chapter
14
Managing CMS Keys and Certificates
495
Getting New Certificates for the Subsystems
Figure 14-2
3.
Data Recovery Manager’s transport certificate in the enrollment form
Replace the current MIME-64 string with the one for the new transport
certificate.
To copy the MIME-64 string for the new transport certificate, locate the new
transport certificate; the MIME-64 string for the certificate will be listed there.
4.
Repeat steps 1 through 3 for any additional enrollment or key-archival pages.
Deploying a Subsystem’s SSL Server Certificate
By default, the Certificate Manager and Registration Manager use a single SSL
server certificate to do server-side authentication to all the CMS ports. If a
Certificate Manager is configured for SSL-client-authenticated communication
with the publishing directory, it also uses its SSL server certificate for
authenticating to the publishing directory. Depending on the purpose for which
you requested this certificate, you should configure the server appropriately.
496
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Renewing Certificates for the Subsystems
•
To configure the server to use this certificate for authenticating to one of the
clients, see “Configuring the Server to Use Separate SSL Server Certificates” on
page 482.
•
To configure the Certificate Manager to use this certificate for authenticating to
the publishing directory, see “Step 5. Identify the Publishing Directory” on
page 660.
•
If you’re using the Certificate Manager as a master CA, add the new SSL server
certificate to the certificate databases of cloned Certificate Managers.
Renewing Certificates for the Subsystems
All certificates used by Certificate Management System have a validity period
beyond which they are not usable, unless the validity period is extended. For
Certificate Management System to function properly, you must renew the
certificates used by the Certificate Manager, Registration Manager, Data Recovery
Manager, or Online Certificate Status Manager before they expire. For example, if
you generated these certificates during CMS installation with a validity period of
two years, at the end of which they will all expire; you must consider renewing
them well in advance, maybe two months in advance.
When you renew a certificate, you get a new certificate with the same subject name
and public and private key material as that of the existing certificate, but with an
extended validity period.
The sections that follow explain how to renew certificates for the Certificate
Manager, Registration Manager, Data Recovery Manager, and Online Certificate
Status Manager using the Certificate Setup Wizard. Alternatively, you use the
command-line utility called the Certificate Database Tool, which is explained in CMS
Command-Line Tools Guide.
Renewing an existing certificate involves the following:
•
Step 1. Plan for Certificate Renewal
•
Step 2. Renew the Existing Certificate
•
Step 3. Install the Renewed Certificate
•
Step 4. Deploy the Renewed Certificate
•
Step 5. Restart the Server
Chapter
14
Managing CMS Keys and Certificates
497
Renewing Certificates for the Subsystems
Step 1. Plan for Certificate Renewal
Renewing a CMS manager’s certificate requires careful planning. This section
provides some guidelines that will help you renew the certificate smoothly.
Before renewing a certificate:
•
Note the subject DN and nickname of the certificate you want to renew.
If you are planning on renewing the CA signing certificate of a Certificate
Manager, make sure that the Certificate Manager has updated your LDAP
directory, file, and OCSP responder with the most current certificate and CRL
information. For details, see Chapter 19, Chapter 20, and, Chapter 21.
When you renew its CA signing certificate, the Certificate Manager
automatically formulates a new certificate with the same public key and other
details from the existing certificate, and publishes the new CA certificate to the
configured LDAP directory.
498
•
Identify the token, internal or external, that contains the keys for the certificate
you want to renew. To use an existing token, you must know the password
that protects the token. If the token is external, make sure that the token is
installed properly; see “Installing External Tokens” on page 455.
•
Decide on the validity period of the renewed certificate.
•
Decide on the CA that will sign the certificate. If you want the certificate to be
signed by a public CA, find out what information you need to provide with the
certificate request. If you want the certificate to be signed by an internally
deployed CA, check to be sure it can issue the certificate you want to request
and that it’s configured to set the required extensions in the certificate.
•
Find out how long the CA will take to deliver the certificate to you. Make sure
the renewed certificate is delivered to you well in advance so that you have a
buffer period for installing and testing the renewed certificate, before the
current certificate expires.
•
Find out how the certificate will be delivered to you; the most common
delivery mechanism is email. Make appropriate arrangements to receive the
certificate.
•
If you want to renew a subordinate CA certificate, plan how you will deploy
the renewed CA certificate to end entities that rely on this certificate for
validation.
•
If you want to renew a root CA certificate, plan how you will deploy the
renewed root CA certificate in your enterprise.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Renewing Certificates for the Subsystems
Step 2. Renew the Existing Certificate
Once you have all the information, go ahead and renew the certificate. The
Certificate Setup Wizard built into the CMS window automates the process of
renewing certificates used by the CMS managers. The wizard can generate a
certificate request based on the existing key pair and submit the request to a CA for
signing. For instructions on using the wizard, see “Using the Wizard to Request a
Certificate” on page 460.
NOTE
When renewing a certificate, be sure to use the existing key pair to
generate the certificate signing request.
Note that when you renew any of the CMS certificates using the wizard, it saves
the old or previous certificate (in its base-64 encoded format) to a text file in the
configuration directory, which is located here:
<server_root>/cert-<instance_id>/config
The names of the text files vary depending on the certificate you choose for
renewal. Table 14-2 lists them.
Table 14-2 Names of backup files created for old CMS certificates
Filename
Renewed Certificate
prevCACert.txt.<timestamp>
Certificate Manager CA signing
certificate
prevOCSPCert.txt.<timestamp>
Certificate Manager OCSP signing
certificate
prevRACert.txt.<timestamp>
Registration Manager signing
certificate
prevKRACert.txt.<timestamp>
Data Recovery Manager transport
certificate
prevOCSPCert.txt.<timestamp>
Online Certificate Status Manager
signing certificate
prevSSLCert.txt.<timestamp>
SSL server certificate
prevSSLRadmCert.txt.<timestamp>
Remote administration server
certificate
prevOtherCert.txt.<timestamp>
Other certificates, such as Certificate
Manager CRL signing certificate or SSL
client certificate
Chapter
14
Managing CMS Keys and Certificates
499
Renewing Certificates for the Subsystems
Table 14-2 Names of backup files created for old CMS certificates (Continued)
Filename
Renewed Certificate
prevClientCert.txt.<timestamp>
SSL client
The wizard also deletes the old certificate from the server’s certificate database and
adds the renewed certificate to the database, so that the server is able to use the
renewed certificate upon restart. This feature restricts you to set the value of the
notBefore attribute of the renewed certificate to either the current time or any time
in the past, but not in the future.
If you set the validity period of the renewed certificate to begin on a future date
and time, the server fails to use the certificate for its intended purposes. If this
happens, you may either reinstall the old certificate (saved to the text file
mentioned above) or renew the certificate again with an appropriate validity
period.
Step 3. Install the Renewed Certificate
When you receive the renewed certificate from the CA, you must install it in the
token that contains the key pair for the certificate; this is the token you used to
generate the request in Step 2.
The Certificate Setup Wizard automates the process of installing certificates used
by the CMS managers. For instructions on using the wizard, see “Using the Wizard
to Install a Certificate or Certificate Chain” on page 475.
Step 4. Deploy the Renewed Certificate
Follow the instructions appropriate for the certificate you installed:
500
•
If you installed a renewed CA signing certificate for a Certificate Manager, see
section “Deploying Certificate Manager’s Renewed CA Signing Certificate” on
page 501.
•
If you installed a renewed signing certificate for a Registration Manager, see
section “Deploying Registration Manager’s Renewed Signing Certificate” on
page 501.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Renewing Certificates for the Subsystems
•
If you installed a renewed transport certificate for a Data Recovery Manager,
see section “Deploying Data Recovery Manager’s Renewed Transport
Certificate” on page 502.
•
If you installed a renewed SSL server certificate, see section “Deploying a
Subsystem’s Renewed SSL Server Certificate” on page 504.
For all certificates, make sure the that CA-chain verification takes place smoothly.
For example, if you requested the certificate from a different CA, be sure to import
a CA certificate into the certificate database of the subsystem using the Certificate
Setup Wizard. For instructions, see “Using the Wizard to Install a Certificate or
Certificate Chain” on page 475. After you install the CA certificate, you can follow
the instructions in see “Changing the Trust Settings of a CA Certificate” on
page 508 to trust the CA certificate you imported.
Deploying Certificate Manager’s Renewed CA Signing Certificate
If you renewed a CA signing certificate, deploy it in the PKI environment that
depends on this certificate for validation. For example, you’ll need to add the
renewed CA certificate to the certificate databases of clients that trust this CA.
Similarly, if you have configured the Certificate Manager to publish CRLs to a
Online Certificate Status Manager, you will need to identify the Certificate
Manager to the Online Certificate Status Manager again. For details, see “Step 3.
Identify the CA to the OCSP Responder” on page 715.
You might also need to get a new agent certificate. For instructions, see the
procedure outlined in “Deploying Certificate Manager’s CA Signing Certificate”
on page 493.
It is beyond the scope of this book to explain how you should deploy the new CA
certificate. You may find it useful to go over some of the deployment issues
discussed in the document available at this URL:
http://help.netscape.com/kb/corporate/19980710-25.html
Deploying Registration Manager’s Renewed Signing Certificate
Here’s what you must do:
1.
Install the renewed signing certificate in the subsystem’s certificate database.
Because the Registration Manager uses its signing certificate for SSL client
authentication to the subsystems, you must add the renewed signing certificate
to the internal database of all subsystems that have been configured to receive
requests from the Registration Manager.
Chapter
14
Managing CMS Keys and Certificates
501
Renewing Certificates for the Subsystems
To add the renewed certificate to a subsystem’s internal database:
2.
a.
Note the instance ID and host name of the Registration Manager for which
you got the signing certificate; this information will help you to identify
the Registration Manager in a subsystem’s list of privileged users.
b.
Copy the renewed signing certificate, in its base-64 encoded format, to a
text file.
c.
Add the renewed certificate to the individual subsystem’s internal
database following the instructions in “Changing a Privileged User’s
Certificate” on page 434. Repeat this step for all subsystems that receive
requests from this Registration Manager.
Ensure that the CA that signed the Registration Manager’s certificate is in the
trust database of the subsystem.
When a Registration Manager does SSL client authentication using its renewed
certificate, the subsystem, as a part of validating the certificate presented by the
Registration Manager, checks its trust database for the CA (certificate) that
signed the Registration Manager’s renewed certificate. If the subsystem does
not find the CA as a trusted CA in its trust database, it rejects the Registration
Manager.
For instructions on checking the trust database of a subsystem, see “Viewing
the Certificate Database Content” on page 505.
❍
❍
If you don’t find the CA certificate, add it to the database as a trusted CA.
For instructions on adding a CA certificate to the trust database of a
subsystem, see “Installing a New CA Certificate in the Certificate
Database” on page 510.
If you find the CA certificate, verify its trust status. If it is untrusted,
change the status to trusted. For instructions on changing the trust setting
of a CA certificate, see “Changing the Trust Settings of a CA Certificate” on
page 508.
Deploying Data Recovery Manager’s Renewed Transport Certificate
Because clients capable of generating dual key pairs use the transport certificate for
encrypting end users’ encryption private keys before sending them to the Data
Recovery Manager, you must update the appropriate enrollment or key archival
page to identify and use the renewed transport certificate. Otherwise, the Data
Recovery Manager will fail to archive users’ encryption private keys.
502
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Renewing Certificates for the Subsystems
In general, here’s what you need to do:
1.
Locate the page that embeds the key archival feature.
2.
View the HTML source, and identify the parameter that corresponds to the
Data Recovery Manager’s transport certificate.
The default enrollment forms for end users embed this feature. Figure 14-3
shows the default directory-based user enrollment form with the transport
certificate-related information. (For more information, see “Step C. Customize
the Certificate Enrollment Form” on page 757.)
Figure 14-3
Data Recovery Manager’s transport certificate in the enrollment form
Chapter
14
Managing CMS Keys and Certificates
503
Renewing Certificates for the Subsystems
3.
Replace the current MIME-64 string with the one for the renewed transport
certificate.
To copy the MIME-64 string for the renewed transport certificate, locate the
certificate; the MIME-64 string for the certificate will be listed there.
4.
Repeat steps 1 through 3 for any additional key archival or enrollment pages.
Deploying a Subsystem’s Renewed SSL Server Certificate
If you renewed the SSL server certificate of a Certificate Manager and if the
Certificate Manager is used as a master CA in a cloned-CA setup (see “Cloning a
Certificate Manager” on page 288), you should add the renewed SSL server
certificate to the certificate databases of the clone Certificate Managers.
By default, the Certificate Manager and Registration Manager use a single SSL
server certificate to do server-side authentication to all the CMS ports. If a
Certificate Manager is configured for SSL client authenticated communication with
the publishing directory, it also uses the SSL server certificate for authenticating to
the publishing directory. The Certificate Manager, if configured to function as a
trusted manager to a Data Recovery Manager, also uses its SSL server certificate for
SSL client authentication to the Data Recovery Manager. Depending on the
purpose for which the certificate being renewed is used currently, you should
configure the server appropriately.
•
To configure the server to use this certificate for authenticating to one of the
clients, see “Configuring the Server to Use Separate SSL Server Certificates” on
page 482.
•
To configure the Certificate Manager to use this certificate for authenticating to
the publishing directory, see “Step 5. Identify the Publishing Directory” on
page 660.
Step 5. Restart the Server
After you renew any of the CMS certificates using the wizard, you must restart the
server. For instructions, see “Restarting Certificate Management System” on
page 326.
504
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Managing the Certificate Database
Managing the Certificate Database
Each CMS instance has a certificate database (cert7.db), which is maintained in its
internal token. This database contains certificates belonging to the subsystems
installed in the CMS instance (see “Keys and Certificates for the Main Subsystems”
on page 440) and various CA certificates the subsystems use for validating the
certificates they receive.
Whether you use an internal token or an external token for generating and storing
key pairs, Certificate Management System always maintains its list of trusted and
untrusted CA certificates in its internal token.
You may need to add new certificates to the database, remove unwanted
certificates from the database, or change the trust settings of CA certificates in the
database. This section explains how to view the contents of the certificate database,
delete unwanted certificates, and change the trust settings of CA certificates
installed in the database using the CMS window. For information on adding
certificates to the database, see “Certificate Setup Wizard” on page 459.
NOTE
Certificate Management System also provides a command-line
utility called certutil for managing its certificate database. For
details, check CMS Command-Line Tools Guide.
Viewing the Certificate Database Content
Each CMS instance has a certificate database that contains the list of certificates the
server uses. To view the contents of the database:
1.
Log in to the CMS window (see “Logging In to the CMS Window” on
page 347).
Chapter
14
Managing CMS Keys and Certificates
505
Managing the Certificate Database
2.
Select the Configuration tab, and then in the right pane, select the Encryption
tab.
3.
Click Manage Certificate.
The Certificate Database Management window appears.
506
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Managing the Certificate Database
The window lists the certificates in a table, with each certificate occupying a
row. The certificates are listed in alphabetical order. If the database contains
multiple certificates with the same nickname, they are sorted by their validity
periods; the most recently requested certificate is placed at the top.
For each certificate, you see the following information:
Certificate Name. Specifies the nickname of the certificate.
Expiry Date. Specifies the date (and time) on which the certificate expires.
Trust Status. Specifies whether the CA is trusted or untrusted. To change the
trust setting, see “Changing the Trust Settings of a CA Certificate” on page 508.
Deleting a Certificate From the Certificate
Database
By default, the CMS certificate database includes a few public or third-party CA
certificates. As an administrator, you should periodically check the contents of the
certificate database and make sure that it doesn’t include any unwanted CA
certificates. For example, if the database includes CA certificates that you don’t
ever want to trust in your PKI setup, you should delete them.
Removing unwanted certificates also reduces the size of the certificate database.
NOTE
When deleting CA certificates from the certificate database, be
careful not to delete the intermediate CA certificates, which help a
subsystem chain up to the trusted CA certificate. If in doubt, leave
the certificates in the database as untrusted CA certificates; see
“Changing the Trust Settings of a CA Certificate” on page 508.
To delete a CA certificate from the certificate database:
1.
Log in to the CMS window (see “Logging In to the CMS Window” on
page 347).
2.
Select the Configuration tab, and then in the right pane, select the Encryption
tab.
Chapter
14
Managing CMS Keys and Certificates
507
Managing the Certificate Database
3.
Click Manage Certificate.
The Certificate Database Management window appears. The window lists all
the certificates for the selected instance of Certificate Management System; the
list is a table, with each certificate occupying a row.
4.
Select the CA certificate you want to delete, and click Delete.
5.
When prompted, confirm the delete action.
6.
Click Close.
You are returned to the Encryption tab.
7.
To save your changes, click Save.
The CMS configuration is modified. If the changes you made require you to
restart the server, you will be prompted accordingly. In that case, restart the
server.
Changing the Trust Settings of a CA Certificate
Certificate Management System relies on the CA certificates in its certificate
database for validating certificates it receives during an SSL-enabled
communication. For example, when a Certificate Manager is authenticating a
Registration Manager that has sent a certificate signing request, the Certificate
Manager checks its certificate database to see whether the CA that has signed the
certificate presented by the Registration Manager is included in the database as a
trusted CA.
You may need to change the status of a currently trusted CA to untrusted (or vice
versa) temporarily or permanently. For example, you may be notified that a CA is
experiencing technical difficulty that prevents certificate authentication. By making
the CA certificate untrusted, you can prevent entities whose certificates have been
signed by that CA from successfully authenticating to Certificate Management
System. You can then return the trust option to trusted when the CA notifies you
that the problem has been resolved.
If you want to untrust a CA permanently, you should consider removing its
certificate from the trust database altogether. For instructions, see “Deleting a
Certificate From the Certificate Database” on page 507.
Changing the trust setting changes the trust flag (or bit) in the CA certificate. To
change the trust setting of a CA certificate:
1.
508
Log in to the CMS window (see “Logging In to the CMS Window” on
page 347).
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Managing the Certificate Database
2.
Select the Configuration tab, and then in the right pane, select the Encryption
tab.
3.
Click Manage Certificate.
The Certificate Database Management window appears.
The window lists the certificates currently installed for the selected CMS
instance; the list is a table, with each certificate occupying a row.
4.
Select the CA certificate whose trust setting you want to modify, and click Edit.
The Certificate Information window appears.
Chapter
14
Managing CMS Keys and Certificates
509
Managing the Certificate Database
The window shows detailed information about the selected certificate,
including serial number, validity period, subject name, issuer name, certificate
fingerprint, and trust status.
If the certificate you selected is currently trusted, the window shows a button
named “Change to Untrusted.” If it is untrusted, the window shows a button
named “Change to Trusted.”
5.
Click “Change to Untrusted” or “Change to Trusted,” as appropriate.
6.
Click Close.
You are returned to the Certificate Database Management window. The
certificate now shows a different trust status.
7.
Click Close.
You are returned to the Encryption tab.
8.
To save your changes, click Save.
The CMS configuration is modified. If the changes you made require you to
restart the server, you will be prompted accordingly. In that case, restart the
server.
Installing a New CA Certificate in the Certificate
Database
You may need to install new trusted CA certificates in the certificate database of a
CMS instance. For example, assume that you renewed the signing certificate of a
Registration Manager. Also assume that the CA that signed the Registration
Manager’s certificate is not included in the trust database of the Certificate
Manager that has been configured to sign certificate requests from this Registration
Manager.
When the Registration Manager attempts to request a service from the Certificate
Manager (using the renewed certificate for SSL client authentication), the
Certificate Manager fails to authenticate the Registration Manager. This happens
because, as a part of validating the certificate presented by the Registration
Manager, the Certificate Manager checks its certificate database for the CA that
signed the Registration Manager’s certificate. The Certificate Manager does not
find the CA listed in its trust database as a trusted CA, so it rejects the Registration
Manager’s service request.
510
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Managing the Certificate Database
The Certificate Setup Wizard built into the CMS window automates the process of
installing trusted CA certificates in the certificate database. For instructions on
using the wizard, see “Using the Wizard to Install a Certificate or Certificate
Chain” on page 475.
NOTE
Be sure to choose the “Other Trusted CAs” option in Step 2 of the
wizard process.
Installing a CA Certificate Chain in the Certificate
Database
Any client or server software that supports certificates maintains a collection of
trusted CA certificates in its certificate database. These CA certificates determine
which other certificates the software can validate—in other words, which issuers of
certificates the software can trust. In the simplest case, the software can validate
only certificates issued by one of the CAs for which it has a certificate. It’s also
possible for a trusted CA certificate to be part of a chain of CA certificates, each
issued by the CA above it in a certificate hierarchy; for details on certificate
hierarchies and certificate chains, see "How CA Certificates Are Used to Establish
Trust" in Appendix D of Managing Servers with Netscape Console.
Chapter
14
Managing CMS Keys and Certificates
511
Managing the Certificate Database
512
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Chapter
15
Setting Up End-User Authentication
iPlanet Certificate Management System (CMS) provides a customizable
authentication component that supports various methods for authenticating end
users. This chapter provides an introduction to various parts of Certificate
Management System that require authentication and explains how to configure a
Certificate Manager and Registration Manager to use specific authentication
plug-in modules for authenticating end users during certificate enrollment.
The chapter has the following sections:
•
Introduction to Authentication (page 513)
•
Configuring Authentication for End-User Enrollment (page 525)
•
Managing Authentication Instances (page 548)
•
Managing Authentication Plug-in Modules (page 551)
Introduction to Authentication
Authentication is the process of verifying the identity of a user that is requesting a
service from iPlanet Certificate Management System (CMS). More specifically,
authentication involves acquiring and verifying the values of the configured
attributes of the user. For example, the user might be prompted to log in with a
user name and password, and then the server would look in a preconfigured
database to verify that the user’s password was correct.
Service requests to Certificate Management System come from any of the following
users:
•
End entities—general users or applications that make certificate issuance,
renewal, and revocation requests
513
Introduction to Authentication
•
Administrators—privileged users who connect to the server to do system or
server administration tasks
•
Agents—privileged users who connect to the server to do agent operations
This section explains how Certificate Management System identifies and
authenticates these users, and it provides details about the various authentication
methods supported by the server.
This section has the following sections:
•
Privileged-User Authentication
•
End-Entity Authentication
Privileged-User Authentication
For authenticating privileged users, such as administrators and agents, Certificate
Management System uses built-in authentication mechanisms.
Authentication of Administrators
When an administrator makes an administrative request to Certificate
Management System (from the CMS window within Netscape Console or from any
command-line tool), the server needs to authenticate the administrator before
processing the request. To facilitate this, Certificate Management System supports
an authentication method that includes user ID- and password-based
authentication from the client and SSL server authentication from the server.
Certificate Management System identifies and authenticates users with
administrator privileges by checking their user IDs and passwords in its internal
database. These are the user IDs and passwords you entered in the internal
database when you created these user entries. For details, see “Setting Up
Administrators” on page 407.
Figure 15-1 illustrates the authentication process.
514
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Introduction to Authentication
Figure 15-1
CMS authentication of a user with administrator privileges
These are the steps shown in Figure 15-1:
1.
An administrator opens Netscape Console and attempts to log in to the CMS
window by entering the user ID and password at the login prompt. The server
takes the administrator’s user ID and password and binds them to
privileged-user entries in its internal database.
2.
If the user ID and password bind successfully to a user entry, authentication
succeeds; otherwise, it fails.
❍
❍
If authentication fails, the server logs an error message and sends a
rejection notification. See Chapter , “.”
If authentication succeeds, the server checks the user’s access rights (based
on group memberships) to determine whether the user is authorized to
perform the requested operation.
If both authentication and authorization succeed, the server services the
request. Otherwise, it rejects the request and logs the reason for the rejection.
NOTE
Authentication for administrators is hardcoded; it is not
configurable.
Chapter
15
Setting Up End-User Authentication
515
Introduction to Authentication
Authentication of Agents
When an agent makes a request to Certificate Management System (from the
appropriate Agent Services interface), the server needs to authenticate the agent
before processing the request. To facilitate this, Certificate Management System
supports a certificate-based authentication method.
Certificate Management System identifies and authenticates a user with agent
privileges by checking the user’s SSL client certificate in its internal database. The
certificates it checks are the ones you imported and stored in the internal database
while creating or modifying the user entry. You create agent users for a CMS
instance by adding their client certificates into the internal database and
associating them with the corresponding users’ identification information; for
details, see “Setting Up Agents” on page 410.
When an agent makes a request to perform a privileged operation, the server
requests SSL client authentication from the client that the agent has used to connect
to the server. The server then uses the successfully SSL client-authenticated
certificate to map to internal user entries for further checks. The server checks the
certificate’s subject name and issuer name against the list of privileged-user
certificates stored in its internal database. If the certificate belongs to a privileged
user who is authorized (based on group membership) to perform agent operations,
the server allows the user to perform the requested operation. Otherwise, the
server rejects the request and logs an appropriate message; for details, see ,
“Managing CMS Logs.”
NOTE
Authentication for agents is hardcoded; it is not configurable.
Figure 15-2 shows how a Registration Manager authenticates and authorizes a
Registration Manager agent.
516
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Introduction to Authentication
Figure 15-2
Registration Manager authentication of a user with Registration Manager agent privileges
This example shows these steps:
1.
An agent opens a web browser and enters the URL to the Registration Manager
Agent Services interface hosted by the Registration Manager. The server
requests the client for SSL client authentication. The client in turn prompts the
agent to specify the certificate that it should present to the server for
authentication. The successfully SSL client authenticated certificate is
presented to the Registration Manager.
Chapter
15
Setting Up End-User Authentication
517
Introduction to Authentication
2.
Upon receiving the certificate, the Registration Manager performs the
following authentication and authorization process:
❍
First, it verifies that the certificate exists in its internal database. Next, it
verifies that the certificate is a valid client certificate. If the certificate is
valid, the Registration Manager proceeds. Otherwise (for example, if the
certificate has expired or been revoked or was signed by an untrusted
authority), the Registration Manager rejects the request, sends an error
message to the agent, and logs a reason for the rejection.
Note that the Registration Manager verifies the revocation status of the
agent certificate if it has been issued by the Certificate Manager to which
the Registration Manager is connected to; the Certificate Manager keeps a
record of all the certificates it has issued and their current status in its
internal database. However, if the agent certificate is issued by any other
CA, the Registration Manager cannot verify the revocation status of the
certificate; it can only verify that the certificate is valid and that it has been
issued by a CA that the Registration Manager trusts. For details on
configuring the Certificate Manager or Registration Manager to check the
revocation status of its agents’ certificates, see “Revocation Status
Checking of Agent Certificates” on page 396.
If the internal database contains an invalid certificate for an agent, the
server rejects all requests from that agent. For the server to accept requests
from that agent, you would have to replace the agent’s invalid certificate in
the internal database with a valid one. For details on how to do this, see
“Changing a Privileged User’s Certificate” on page 434.
❍
The Registration Manager reads the user’s subject name (in DN form) and
the issuer name from the certificate. This combination is unique. It then
finds the login name corresponding to this unique combination in its
privileged-users list, which is stored in the internal database. If a login
name is associated with the certificate, the Registration Manager proceeds.
Otherwise, it rejects the request.
The Registration Manager then checks the group memberships of the login
name and the corresponding access rights to determine whether the user is
authorized to perform the requested service.
If both authentication and authorization succeed, the Registration Manager
services the request. Otherwise, it rejects the request and logs a reason for the
rejection.
518
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Introduction to Authentication
End-Entity Authentication
This section provides an overview of how Certificate Management System
authenticates end entities during certificate enrollment, renewal, and revocation
processes.
Authentication of End Entities During Certificate Enrollment
When an end entity submits a certificate request, a Certificate Manager or
Registration Manager’s first task is to identify and authenticate the end entity. The
server must perform this task before it can register the end entity for certificate
issuance. This task includes verifying the end entity’s identity based on
information the end entity provides and returning enough information about the
end entity so that the subject name for the certificate can be constructed.
To cater to a variety of end-entity enrollment scenarios, Certificate Management
System supports both manual and automated certificate issuance. For detailed
description of authentication methods supported by the Certificate Manager and
Registration Manager, see Chapter 1, “Authentication Plug-in Modules” of CMS
Plug-ins Guide. To locate an online version of this guide, open the
<server_root>/manual/index.html file.
Authentication of End Users During Certificate Renewal
When an end user submits a certificate renewal request, the first step in the
renewal process is for the Certificate Manager or Registration Manager to identify
and authenticate the end user. This step includes making sure that the end user’s
current certificate is either “valid” or “expired” (“revoked” is not acceptable).
Certificate Management System verifies the authenticity of a certificate renewal
request by mapping the subject name in the certificate being presented for renewal
to certificates in its internal database. The server renews the certificate only if the
subject name maps successfully to a certificate in its internal database. If the
internal database contains more than one certificate with matching subject name as
that the one presented by the end entity for client authentication, the server lists all
the matching certificates and expects the end entity to pick one for renewal.
Here are a few things to keep in mind about certificate renewal:
•
The certificate being presented by the end user for renewal must be issued by a
Certificate Manager.
•
If the renewal request is processed by a Registration Manager, the end-user
certificate presented must be issued by a Certificate Manager that the
Registration Manager knows and is connected to; the Registration Manager
forwards certificate requests to this Certificate Manager for signing.
Chapter
15
Setting Up End-User Authentication
519
Introduction to Authentication
•
The certificate being presented by the end user for renewal must be currently
valid or must have expired; it cannot have been revoked.
•
The validity period of a renewed certificate is determined by the policy rule
explained in “RenewalValidityConstraints Plug-in Module” of CMS Plug-ins
Guide. If the renewal lead time does not permit renewing, the server rejects the
renewal request. Also, if the policy is disabled, renewal of certificates fails.
•
If the certificate being presented by the end user has already been renewed, the
server displays the URL for downloading the certificate.
This situation may occur if the end user forgets to download the renewed
certificate. It can also happen if the end user maintains two identical certificate
databases on two machines, renews the certificate from one machine, and then
tries to renew the same certificate from the other machine.
Certificate Renewal Form
The End Entity Services interface of the Certificate Manager and Registration
Manager includes a default HTML form for renewing end users’ certificates. The
form is accessible from the Renewal tab as shown in Figure 15-3.
Figure 15-3
520
Certificate renewal form for end users
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Introduction to Authentication
The default renewal form is preconfigured for SSL client authentication, enabling
end users to renew their personal or client certificates by presenting valid or
expired certificates.
If you want to change the form content to suit your organization’s requirements,
edit the following file:
<server_root>/cert-<instance_id>/web/ee/UserRenewal.html
For details on individual form elements, see the online help available by clicking
the Help button on the form. For more information on customizing the form, see
CMS Customization Guide. To locate an online version of this guide, open the
<server_root>/manual/index.html file.
Authentication of End Users During Certificate Revocation
Certificates can be revoked by administrators, agents, and end users. When an end
user submits a certificate revocation request, the first step in the revocation process
is for the Certificate Manager or Registration Manager to identify and authenticate
the end user. The reason for this is when an end user attempts to revoke a
certificate, the server needs to verify that the user is attempting to revoke his or her
own certificate, not a certificate belonging to someone else.
Both Certificate Manager and Registration Manager support the following
methods of revocation:
•
SSL client authenticated revocation
This method requires an end user to present a valid or revoked certificate that
has the same subject name as the one he or she wants to revoke. Without the
certificate, the user won’t be able to revoke the certificate.
•
Challenge-password-based revocation
This method requires an end user to enroll for a personal certificate using the
manual enrollment method. The reason for this is, by default, only the manual
enrollment form includes fields for entering the challenge password when
requesting a certificate. None of the other enrollment forms, for example
directory-based or NIS server-based forms, by default allow end users to
specify a challenge password.
You can use the manual-enrollment form (ManUserEnroll.html) as a model
and introduce the input fields for entering the challenge password in any of the
other end user enrollment forms. Keep in mind that this feature is available for
end-user certificates only; the feature is not available for other types of
certificates.
Chapter
15
Setting Up End-User Authentication
521
Introduction to Authentication
Revoking a certificate using the challenge password is useful in certain
situations. For example, if you issue a single certificate to a user and the user is
unable to use the certificate due to loss of corresponding key pair, it’s not
possible for the user to revoke his or her own certificate using the SSL client
authenticated revocation method. If the user has a challenge password for the
certificate, he or she can use it to revoke the certificate the server maintains in
its database.
Forms for both methods are available through the End Entity Services interface
(HTTPS only) of the Certificate Manager and Registration Manager; see “Certificate
Revocation Forms” on page 524.
Here are a few common points to keep in mind about the automated revocation of
end users’ certificates:
•
A Certificate Manager can revoke only those certificates that it has issued; it
cannot revoke certificates issued by other CAs.
•
If the revocation request is processed by a Registration Manager, it must be
connected as a trusted manager to the Certificate Manager that has issued the
certificate the user is attempting to revoke; the Registration Manager forwards
certificate revocation requests to this Certificate Manager. For information on
trusted managers, see “Trusted Managers” on page 398.
•
The certificate the user attempts to revoke must be currently valid or must
have expired; it cannot have been already revoked.
•
At the time of revocation, the user can also specify additional details, such as
the date of revocation and revocation reason, for each certificate or for the list
as a whole.
SSL Client Authenticated Revocation
In an SSL client authenticated revocation method, the server expects the end user
to present a certificate that has the same subject name as the one he or she wants to
revoke and uses that for authentication purposes. The server verifies the
authenticity of a revocation request by mapping the subject name in the certificate
being presented for client authentication to certificates in its internal database. The
server revokes the certificate only if the certificate maps successfully to one or more
valid or expired certificates in its internal database.
After successful authentication, if the server detects only one valid or expired
certificate with matching subject name as that of the one presented for client
authentication, it revokes the certificate. If the server detects more than one valid or
expired certificate with matching subject name, it lists all those certificates. The
user can then either select the certificate to be revoked or revoke all certificates in
the list.
522
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Introduction to Authentication
Here are a few things, in addition to the ones listed on page 522, to keep in mind
about SSL client authenticated revocation:
•
The certificate being presented by the user for revocation must be issued by a
Certificate Manager.
•
If the revocation request is processed by a Registration Manager, the certificate
presented for SSL client authentication must be issued by a Certificate Manager
that the Registration Manager knows about and is connect to (the Registration
Manager forwards certificate requests to this Certificate Manager for signing).
•
The certificate being presented by the user for revocation must be currently
valid or must have expired; it cannot have been already revoked.
•
The user can revoke only certificates that contain the same subject name as the
one in the certificate presented for authentication.
Challenge-Password-Based Revocation
A challenge password is a unique, alphanumeric string that the end user specifies
when requesting a certificate; the user is expected to keep this password
confidential and use it to authenticate to the server when revoking the certificate.
When the server issues the certificate, it associates the password with the
certificate, stores both the certificate and password in its internal database, and
uses them later for authenticating any revocation requests.
In the challenge-password-based revocation method, the server expects the end
user to specify the serial number of the certificate the user wants to revoke and the
challenge password associated with the certificate. The server verifies the
authenticity of a revocation request by mapping the serial number to the list of
certificates in its internal database followed by mapping the challenge password
specified to the one associated with the matching certificate it detects in the internal
database.
The server revokes the certificate only if the certificate maps successfully to one or
more valid or expired certificates in its internal database. If the server detects only
one valid or expired certificate with a matching serial number and challenge
password, it automatically revokes the certificate. If the server detects more than
one valid or expired certificates with matching serial numbers, it lists all those
certificates. The user can then select the certificate to be revoked or revoke all
certificates in the list.
Here are a few things, in addition to the ones listed on page 522, to keep in mind
about the challenge-password-based revocation:
•
The certificate being presented by the user for revocation must be issued by a
Certificate Manager.
Chapter
15
Setting Up End-User Authentication
523
Introduction to Authentication
•
The user must have requested the certificate using the manual enrollment
method—only the default manual enrollment form includes fields for entering
the challenge password when requesting a certificate.
•
The user can revoke only those certificates that contain the specified serial
number with the corresponding challenge password. For example, if there is a
mismatch between the challenge password and serial number, the server
rejects the revocation request.
Certificate Revocation Forms
The End Entity Services interface of the Certificate Manager and Registration
Manager includes default HTML forms for both the SSL client authenticated
revocation and challenge-password-based revocation. The forms are accessible
from the Revocation tab. Figure 15-4 shows the form that enables end users to
revoke their certificates using a challenge password. You can view the form that
enables SSL client authenticated revocation by clicking the User Certificate link.
Figure 15-4
524
Form for SSL client authenticated certificate revocation
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Configuring Authentication for End-User Enrollment
If you want to change the forms to suit your organization’s requirements, you can
edit the following files:
•
ChallengeRevoke1.html (the form that allows challenge password based
revocation of client or personal certificates)
•
UserRevocation.html (the form that allows SSL client authenticated
revocation of client or personal certificates)
Both the files are located here: <server_root>/cert-<instance_id>/web/ee
For details on individual form elements, see the online help available by clicking
the Help button on the form. For more information on customizing the form, see
CMS Customization Guide.
Configuring Authentication for End-User
Enrollment
To set up a Certificate Manager or Registration Manager to authenticate end users
based on a specific criteria, follow these steps:
•
Step 1. Before You Begin
•
Step 2. Set Up the Directory for PIN-Based Enrollment (required for PIN-based
enrollment only)
•
Step 3. Enable the AttributePresentConstraints Policy (required for PIN-based
enrollment only)
•
Step 4: Add an Authentication Instance
•
Step 5. Set Up the Enrollment Interface
•
Step 6. Enable End-Entity Interaction
•
Step 7. Turn on Automated Notification
•
Step 8. Test Your Authentication Setup
•
Step 9. Deliver PINs to End Users (required for PIN-based enrollment only)
Chapter
15
Setting Up End-User Authentication
525
Configuring Authentication for End-User Enrollment
NOTE
If you do not configure a Certificate Manager or Registration
Manager to use any of the registered authentication plug-in
modules, the server uses manual authentication for end-user
enrollment. This means that all end-user enrollment requests are
queued for agent approval. For more information, see section
“Manual Authentication” in Chapter 1, “Authentication Plug-in
Modules” of CMS Plug-ins Guide.
Step 1. Before You Begin
Before setting up a Certificate Manager or Registration Manager to use a specific
authentication method:
•
Determine the authentication module you want to use. To find out about the
modules that are installed with the server, see Chapter 1, “Authentication
Plug-in Modules” of CMS Plug-ins Guide. If you want to develop and use a
custom plug-in module, be sure to check the tutorials provided in this
directory: <server_root>/cms_sdk/cms_jdk/samples/authentication
❍
❍
If you decided to use the directory-based authentication module, note the
authentication directory credentials, such as the host name, port number,
base DN, the user entry to bind as and the corresponding password, the
DN pattern to retrieve from the directory to construct certificate subject
names, LDAP version number, and minimum and maximum number of
connections permitted.
If you decided to use the directory- and PIN-based authentication module,
note the authentication directory credentials, such as the host name, port
number, based DN, the user entry to bind as and the corresponding
password, LDAP version number, and minimum and maximum number
of connections permitted.
Next, read Chapter 4 , “PIN Generator Tool” of CMS Command-Line Tools
Guide. Determine the options you want to use to generate PINs and
construct the command for generating the PINs. Note that the optfile
option enables you to put all the arguments in a file (instead of typing the
arguments at the command prompt) and then point the tool to read
arguments from the file.
❍
526
If you decided to use the NIS server-based authentication module, note the
NIS server host name and domain name. If you have an LDAP directory
deployed and want to use that for formulating the certificate subject
names, note the directory-specific information.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Configuring Authentication for End-User Enrollment
❍
•
If you decided to use the portal authentication module, note the LDAP
directory-specific information.
Determine the enrollment form you want your users to use. Decide whether
you want to customize it.
The next step depends on the authentication module you chose:
•
If you decided to use the directory- and PIN-based authentication module, go
to the next step, “Step 2. Set Up the Directory for PIN-Based Enrollment” on
page 527.
•
For all other modules, skip to “Step 4: Add an Authentication Instance” on
page 533.
Step 2. Set Up the Directory for PIN-Based
Enrollment
Complete this step only if you want to configure the server to use the directoryand PIN-based authentication method (with or without PIN removal). Otherwise,
skip to the next step.
To set up a directory for PIN-based authentication method:
•
Step A. Check the Directory for User Entries
•
Step B. Update the Directory
•
Step C. Prepare the Input File
•
Step D. Run the Command Without the Write Option
•
Step E. Check the Output File
•
Step F. Run the Command Again with the Write Option
Step A. Check the Directory for User Entries
Before you run the PIN Generator tool, make sure that the directory you intend to
use for generating PINs has been populated with end-user entries that require
PINs. It is also a good idea to confirm with that directory’s administrator that all
pending directory requests have been processed before the PIN Generator starts its
operation.
Chapter
15
Setting Up End-User Authentication
527
Configuring Authentication for End-User Enrollment
Step B. Update the Directory
By default, the PIN Generator modifies the pin attribute in a directory’s user entry.
Because this attribute is not part of the standard organizationalPerson, it’s likely
that the user entries in your directory do not contain the pin attribute. This means,
before you run the PIN Generator, you’ll need to add the pin attribute to the user
entries in your directory—that is, you’ll need to create a new object class (named
pinPerson) in your authentication directory’s schema.
In general, you’ll need to update the slapd.user_at.conf file to include the pin
attribute and the slapd.user_oc.conf file to include the object-class definition.
The modified schema should look similar to this:
attribute pin bin
objectclass pinPerson
superior organizationalPerson
allows
pin
In addition, if you want to make use of the PIN-removal feature—that is, remove a
user’s PIN from the directory after Certificate Management System successfully
authenticates that user and thus prevents the user from enrolling for another
certificate—ACIs must be set up on the directory to prevent end users from
creating new PINs for themselves. To do this, you’ll need to create an entry for a
PIN manager user with read-write permission to the pin attribute.
For your convenience, the PIN Generator tool comes with a configuration file,
named setpin.conf, which enables you to automate the process of updating the
authentication directory with changes required for setting up PIN-based
authentication. The configuration file is located in this directory:
<server_root>/bin/cert/tools
To make the required schema changes and add an entry for the PIN manager user
(using the configuration file):
1.
Go to this directory: <server_root>/bin/cert/tools
2.
Open the setpin.conf file in a text editor.
3.
Follow the instructions outlined in the file and make the appropriate changes.
Typically, you will need to update the Directory Server’s host name, Directory
Manager’s bind password, and PIN manager’s password.
4.
528
Run the setpin command with its optfile option pointing to the
setpin.conf file (setpin optfile=setpin.conf).
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Configuring Authentication for End-User Enrollment
The tool modifies the schema with a new attribute (by default, pin) and a new
object class (by default, pinPerson), creates a pinmanager user, and sets the
ACI to allow only the pinmanager user to modify the pin attribute.
If the tool is able to update the directory with all the changes, you should see a
status-update message, similar to the sample shown below:
Adding attribute: ( pin-oid NAME 'pin' DESC 'User Defined
Attribute' SYNTAX '1.3.6.1.4.1.1466.115.121.1.5' SINGLE-VALUE )
.. successful
Adding objectclass: ( pinPerson-oid NAME 'pinPerson' DESC 'User
Defined ObjectClass' SUP 'top' MUST ( objectclass ) MAY ( aci $
pin )
.. successful
Adding user: cn=pinmanager,o=siroe.com
.. successful
modifying ACI for: ou=people,o=siroe.com
.. successful
Step C. Prepare the Input File
This step is optional.
If you want to generate PINs for specific user entries or want to provide your own
PINs, use an input file (to provide the tool with such information). For information
on constructing an input file, check the PIN Generator documentation.
Step D. Run the Command Without the Write Option
Run the setpin command without the write option. Be sure to include the output
option and bind to the directory as the PIN manager user.
The tool will write PINs to the specified output file; no changes are made to the
directory yet. This will give you the opportunity to check the PINs (by looking at
the output file) before updating the directory.
To run the command:
1.
Open a terminal window.
2.
Go to this directory: <server_root>/bin/cert/tools
3.
Run the setpin command with the appropriate arguments; be sure to point the
optfile option to the file you’ve created (and not to the setpin.conf file).
Chapter
15
Setting Up End-User Authentication
529
Configuring Authentication for End-User Enrollment
Step E. Check the Output File
Check the output file to be sure it contains PINs for your users; the output should
look similar to the one specified in PIN Generator documentation.
Next, verify that the tool has assigned PINs to the correct users and that the PINs
conform to the length and character-set restrictions you specified. If the output isn’t
what you want, run the command again with appropriate arguments. Repeat the
process until the output file shows the results you want.
Step F. Run the Command Again with the Write Option
When you are sure about the results, run the command again (with exactly the
same arguments) with the write option and the output option. The tool stores the
hashed PINs in the directory. For information on how PINs are stored in the
directory, see section “How PINs Are Stored in the Directory” of the PIN Generator
tool documentation.
Use the output file for delivering PINs to users after you complete setting up the
required authentication method; see “Step 9. Deliver PINs to End Users” on
page 548.
Step 3. Enable the AttributePresentConstraints
Policy
This step is required for PIN-based enrollment with PIN removal only in certain
deployment scenarios. Here’s some information that will help you decide whether
you need to enable this policy.
In the password and PIN-based enrollment method, users enroll for a certificate
using their directory user ID, password and PIN. After a PIN has been used to
successfully authenticate a user, the Certificate Manager calls the
PinRemovalListener module. This module removes the PIN from the
authentication directory when the Certificate Manager issues the requested
certificate.
Note that listeners in Certificate Management System are objects which register
themselves as interested in knowing about certain events—for example, change in
the state of a request—and carry out a specific task. For more information on
listeners, check the samples directory:
<server_root>/cms_sdk/cms_jdk/samples/listeners
Once the PIN is removed from the authentication directory, it prevents the user
from enrolling for another certificate.
530
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Configuring Authentication for End-User Enrollment
The above mentioned process works smoothly if a Certificate Manager or
Registration Manager is configured to use the master directory for authenticating
users. The process may not work smoothly in deployment scenarios that involve
replicated directories. In these scenarios, you need to use the Attribute Present
Constraints policy to verify that the PIN has been removed from the directory.
Here’s an example of such a scenario:
A Registration Manager acts as an enrollment authority, passing authenticated
certificate requests to a Certificate Manager; the users have no direct interaction
with the Certificate Manager. The Certificate Manager (CA) and the master
corporate directory are behind the firewall. The Registration Manager and a replica
of the corporate directory are outside the firewall. The Certificate Manager is
configured to communicate with the master corporate directory. The Registration
Manager has read-only permission to the replicated corporate directory and it uses
the directory for authenticating end entities. Both the Certificate Manager and
Registration Manager are configured for password and PIN-based enrollment with
the PIN removal feature turned on. The master corporate directory is configured to
update its replica (outside the firewall) every 10 minutes.
When a user enrolls for a certificate using the End Entity Services interface of the
Registration Manager, it authenticates the user against the replica of the corporate
directory. If the user presents a valid user ID, password, and PIN, the Registration
Manager authenticates the user successfully and forwards the request to the
Certificate Manager. As the Registration Manager is configured for PIN-based
enrollment with PIN removal, it attempts to remove the PIN from the replicated
directory, but it can’t as it has no write permission to the replicated directory; the
PIN is still around.
When the Certificate Manager processes the request forwarded by the Registration
Manager, it calls the PinRemovalListener module, which in turn removes the PIN
from the master corporate directory when the Certificate Manager issues the
certificate. (The Certificate Manager sends the certificate to the Registration
Manager, which in turn sends it to the user.)
Although the Certificate Manager has removed the PIN from the master directory,
the replicated directory still has the PIN, because the update hasn’t occurred. In the
meantime, the user may enroll again successfully (from the Registration Manager)
for another certificate and receive it from the Certificate Manager.
The Attribute Present Constraints policy enables you to prevent users from
successfully enrolling for multiple certificates from the Registration Manager
during the time interval between directory updates. If you configure the Certificate
Manager to use this policy to check the master directory for PINs before issuing
Chapter
15
Setting Up End-User Authentication
531
Configuring Authentication for End-User Enrollment
certificates, successive certificate requests would fail because the PIN has been
removed from the master directory. This way, even if the Registration Manager
authenticates successive requests, the Certificate Manager rejects them, thus
ensuring that a user has only one certificate.
If you are not familiar with the Attribute Present Constraints policy, see section
“AttributePresentConstraints Plug-in Module” in Chapter 3, “Constraints Policy
Plug-in Modules” of CMS Plug-ins Guide.
Note that unlike some of the other policy rules, Certificate Management System
does not create an instance of the Attribute Present Constraints policy rule during
installation. If you created this rule after installation, you can configure the server
to use that rule. The instructions below explain how to create a new rule:
1.
Log in to the CMS window for the Certificate Manager (see “Logging In to the
CMS Window” on page 347).
2.
Select the Configuration tab.
3.
In the navigation tree, select Certificate Manager, and then select Policies.
The Policy Rules Management tab appears. It lists currently configured policy
rules.
4.
Click Add.
The Policy Plugin Implementation window appears.
532
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Configuring Authentication for End-User Enrollment
5.
Select AttributePresentConstraints and click Next.
The Policy Rule Editor window appears. It lists the configuration information
required for this policy rule.
6.
Enter the appropriate information.
7.
Click OK to save your configuration.
You are returned to the Policy Rules Management tab. If required, click the
Reorder button and order the rules as appropriate. For details, see “Step 5.
Reorder Policy Rules” on page 603.
Step 4: Add an Authentication Instance
Adding an authentication instance to the CMS configuration involves creating a
new instance of an already registered plug-in module, assigning a unique name or
ID to the instance, and entering appropriate values for the parameters that define
the plug-in you want to create an instance of.
Chapter
15
Setting Up End-User Authentication
533
Configuring Authentication for End-User Enrollment
When naming an authentication instance (or rule), be sure to formulate the name
using any combination of letters (aA to zZ), digits (0 to 9), an underscore (_), and a
hyphen (-); other characters and spaces are not allowed. For example, you can type
My_Auth_Rule or MyAuthRule as the instance name, but not My Auth Rule.
Also note that when you add an authentication instance, the CMS configuration is
updated with authentication-specific information only. The server does not
associate the authentication instance you added with any of the end-user
enrollment forms—that is, the end-user servlets that should use this authentication
instance are not configured yet. You make this association by manually embedding
the authentication instance name in the enrollment forms.
By default, the enrollment forms include authentication instance names listed in
Table 15-1. Note that the authentication instances are not created by default; only
the instance names are embedded in the forms for your convenience. If you create
authentication instances with the default names, you can skip the step (“Step A.
Associate the Authentication Instance With the Enrollment Form” on page 538)
that explains how to update an enrollment form to associate it with the name of an
authentication instance.
Table 15-1 Default authentication instance names embedded in end user enrollment forms
Enrollment form (filename)
Authentication instance name
Certificate-based enrollment for dual certificates
(CertBasedDualEnroll.html)
UserDirEnrollment
Certificate-based enrollment for encryption certificates
(CertBasedEncryptionEnroll.html)
UserDirEnrollment
Certificate-based enrollment for single certificates
(CertBasedSingleEnroll.html)
UserDirEnrollment
Directory-based enrollment
(DirUserEnroll.html)
UserDirEnrollment
Directory- and PIN-based enrollment
(DirPinUserEnroll.html)
PinDirEnrollment
NIS server-based enrollment
(NISUserEnroll.html)
NISAuth
Portal enrollment
(PortalEnrollment.html)
PortalEnrollment
Figure 15-5 shows the default directory-based enrollment form configured to use
an authentication instance named UserDirEnrollment.
534
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Configuring Authentication for End-User Enrollment
Figure 15-5
Authentication information in the default directory-based enrollment form
For information on locating and customizing the default end-entity forms, see CMS
Customization Guide.
To add an authentication instance to the CMS configuration:
1.
In the CMS window, select the Configuration tab.
Chapter
15
Setting Up End-User Authentication
535
Configuring Authentication for End-User Enrollment
2.
In the navigation tree, select Authentication.
The right pane shows the Authentication Instance tab, which lists any currently
configured authentication instances.
3.
Click Add.
The Select Authentication Plugin Implementation window appears. It lists the
currently registered authentication plug-in modules.
4.
Select a plug-in module.
The following choices are the ones provided by default with Certificate
Management System. If you have registered any custom authentication plug-in
modules, they too will be available for selection.
UidPwdDirAuth. Select this if you want to use the directory-based
authentication module.
536
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Configuring Authentication for End-User Enrollment
UidPwdPinDirAuth. Select this if you want to use the directory- and
PIN-based authentication module (with or without PIN removal). To configure
Certificate Management System for PIN-based enrollment method, you must
have completed “Step 2. Set Up the Directory for PIN-Based Enrollment” on
page 527.
NISAuth. Select this if you want to use the NIS server-based authentication
module.
PortalEnroll. Select this if you want to use the portal authentication module.
For the purposes of this instruction, assume that you selected
UidPwdPinDirAuth.
5.
Click Next.
The Authentication Instance Editor window appears. The Authentication
Instance ID field shows the default instance name embedded in the associated
enrollment form (see Table 15-1 on page 534). The Authentication Plugin ID
field shows the module you’ve chosen. The remaining fields list the
configuration information required for this authentication instance.
Chapter
15
Setting Up End-User Authentication
537
Configuring Authentication for End-User Enrollment
6.
If you don’t want to use the default instance name, in the Authentication
Instance ID field, type a unique name for this instance that will help you
identify it.
For the name, be sure to use an alphanumeric string with no spaces. If you
chose to use a different name, be sure to edit the default name in the
enrollment form in the next step, “Step 5. Set Up the Enrollment Interface” on
page 538.
7.
Fill in values for the remaining parameters.
8.
Click OK.
The CMS configuration is modified. If the changes you made require you to
restart the server, you will be prompted accordingly. Don’t restart the server
yet; you can do this after you’ve made all the required changes.
Step 5. Set Up the Enrollment Interface
This step explains how to customize the end-entity interface for the enrollment
method you’ve chosen for your users.
•
Step A. Associate the Authentication Instance With the Enrollment Form
•
Step B. Customize the Form
•
Step C. Hook Up the Certificate-Based Enrollment Form (optional)
•
Step D. Remove Unwanted Enrollment Options
Step A. Associate the Authentication Instance With the Enrollment
Form
You can skip this step if, in the previous step, you chose the default instance name
suggested in Table 15-1 on page 534. Otherwise, you must edit the enrollment form
to associate the instance you added because Certificate Management System relies
on the authentication instance name embedded in the enrollment form to
determine the authentication method.
For the new authentication instance to work with end-entity enrollment forms, you
must update the appropriate forms, as follows:
1.
In the CMS host system, go to this directory:
<server_root>/cert-<instance_id>/web/ee
538
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Configuring Authentication for End-User Enrollment
2.
Locate the file that corresponds to the authentication module you chose in
“Step 4: Add an Authentication Instance” on page 533; use Table 15-1 for
guidance.
3.
Open the file in a text editor.
4.
Locate the attribute that associates the authentication instance with the
enrollment form.
In the default enrollment forms, locate this line:
<INPUT TYPE="HIDDEN" NAME="authenticator" VALUE="myAuthMgr">
In the custom enrollment form, be sure to include the following line, and
replace myAuthMgr with the name of the authentication instance you added.
<INPUT TYPE=”HIDDEN” NAME=”authenticator” VALUE=”myAuthMgr”>
5.
Check the value assigned to authenticator attribute (the VALUE= field). Make
sure that it is same as the name or ID you assigned to the authentication
instance you created in Step 5. If it is different, replace it with the name of the
authentication instance. For example, if you used test_auth as the instance
name, the edited line should look like this:
<INPUT TYPE="HIDDEN" NAME="authenticator" VALUE="test_auth">
6.
Save your changes and close the file.
Step B. Customize the Form
You can make any other changes to meet your organization’s requirements.
Step C. Hook Up the Certificate-Based Enrollment Form
This step is required only if you want to use any of the certificate-based enrollment
forms.
As explained in the “Certificate-Based Enrollment” section in Chapter 1,
“Authentication Plug-in Modules” of CMS Plug-ins Guide, Certificate Management
System provides three forms for certificate-based enrollment:
•
CertBasedDualEnroll.html
•
CertBasedEncryptionEnroll.html
•
CertBasedSingleEnroll.html
Chapter
15
Setting Up End-User Authentication
539
Configuring Authentication for End-User Enrollment
By default, the form named CertBasedDualEnroll.html is hooked up to the
Enrollment tab of the end-entity interface. You can replace this form with either of
the other two forms, CertBasedEncryptionEnroll.html and
CertBasedSingleEnroll.html; you can do this by uncommenting the script
relevant to either of the forms in the index file and by commenting out the script for
CertBasedDualEnroll.html—thus, effectively unhook the old one and hook the
new one.
To enable any of the certificate-based enrollment forms, follow these steps:
1.
In the CMS host system, go to this directory:
<server_root>/cert-<instance_id>/web/ee
2.
Locate the index.html file.
3.
Open the file in a text editor.
4.
Follow instructions as appropriate:
If you want to enable the CertBasedDualEnroll.html form, search for
CertBasedDualEnroll. You should find a block of script like the following:
count++;
}
if (http != 'true') {
// this one is directory based, cert-based
if ( isAuthMgrEnabled("UidPwdDirAuth") ) {
item = 'certBasedDualEnroll';
menuItems[count] = top.EnrollMenu[count] =
new menuItem(item, 'CertBasedDualEnroll.html','Certificate');
If you want to enable the CertBasedEncryptionEnroll.html form, search for
CertBasedEncryption. You should find a block of script like the following:
count++;
}
//
item = 'certBasedEncEnroll';
//
menuItems[count] = top.EnrollMenu[count] =
//
new menuItem(item, CertBasedEncryptionEnroll.html',
//
'Certificate');
Uncomment the lines and then add lines for using the automated enrollment
module you configured the server with. Your edited lines should look similar
to this:
540
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Configuring Authentication for End-User Enrollment
count++;
}
if (http != 'true') {
// this one is directory based cert-based
if ( isAuthMgrEnabled("UidPwdDirAuth") ) {
item = 'certBasedEncEnroll';
menuItems[count] = top.EnrollMenu[count] =
new menuItem(item, 'CertBasedEncryptionEnroll.html',
'Certificate');
If you want to enable the CertBasedSingleEnroll.html form, search for
CertBasedSingle. You should find a block of script similar to this:
count++;
}
//
item = 'certBasedSingleEnroll';
//
menuItems[count] = top.EnrollMenu[count] =
//
new menuItem(item, 'CertBasedSingleEnroll.html',
//
'Certificate');
Uncomment the lines and then add lines for using the automated enrollment
module you configured the server with. Your edited lines should look like
these:
count++;
}
if (http != 'true') {
// this one is directory based cert-based
if ( isAuthMgrEnabled("UidPwdDirAuth") ) {
item = 'certBasedSingleEnroll';
menuItems[count] = top.EnrollMenu[count] =
new menuItem(item, 'CertBasedSingleEnroll.html',
'Certificate');
5.
Make sure to comment out lines for any unused options.
6.
If you’re using any of the default modules, except for the one provided for the
directory-based enrollment (UidPwdDirAuth), edit the following line to replace
UidPwdDirAuth with the name of the module you’re using.
if ( isAuthMgrEnabled("UidPwdDirAuth") ) {
Chapter
15
Setting Up End-User Authentication
541
Configuring Authentication for End-User Enrollment
7.
By default, a link named Certificate will be created under the Browser
section. If you want to rename the link, replace Certificate in the following
line with the new name:
new menuItem(item, 'CertBasedDualEnroll.html', 'Certificate');
8.
Save your changes and close the file.
Step D. Remove Unwanted Enrollment Options
This step is optional.
By default, the Enrollment tab of the end-entity interface shows just one link,
named Manual, under the Browser section. The Manual link opens a form that
enables end users to request certificates manually. When you enable automated
enrollment, that is, when you create an instance of any of the automated
enrollment modules, a link for the corresponding form is automatically created
under the Browser section. For example, if you create an instance of the
directory-based authentication module, you will notice a new link named
Directory under the Browser section.
If you don’t want your end users to see the manual enrollment option, you can
remove it from the Enrollment tab altogether. The steps below explain how to
remove the Manual link from the Browser section of the Enrollment tab:
1.
In the CMS host system, go to this directory:
<server_root>/cert-<instance_id>/web/ee
2.
Locate the index.html file.
3.
Open the file in a text editor.
4.
Locate the initEnrollMenu function (the function initEnrollMenu() line).
5.
Remove or comment out lines that correspond to the Manual enrollment form.
count++;
item = 'manuser';
menuItems[count] = top.EnrollMenu[count] =
new menuItem(item, 'ManUserEnroll.html', 'Manual');
542
6.
Save your changes and close the file.
7.
Open a browser window.
8.
Go to the end-entity interface and verify your changes.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Configuring Authentication for End-User Enrollment
Step 6. Enable End-Entity Interaction
You can configure end-entity interaction with a Certificate Manager or a
Registration Manager, or with both. End entities cannot interact with a Data
Recovery Manager directly; they must interact through a Certificate Manager or
Registration Manager. By default, the Certificate Manager is configured for
end-entity interaction; the Registration Manager is not configured for end-entity
interaction.
Depending on the subsystem you’re configuring, follow the instructions in
“Enabling End-Entity Interaction with a Certificate Manager” on page 543 or in
“Enabling End-Entity Interaction with a Registration Manager” on page 545.
Enabling End-Entity Interaction with a Certificate Manager
To enable end-entity interaction with a Certificate Manager:
1.
In the CMS window, select the Configuration tab.
2.
In the navigation tree, select Certificate Manager.
The General Setting tab appears.
Chapter
15
Setting Up End-User Authentication
543
Configuring Authentication for End-User Enrollment
3.
In the Web Access section, check the “Enable end-entity interaction” option if
you want end entities to be able to interact with the selected Certificate
Manager via the HTTPS port; leave it unchecked to disable end-entity
interaction with the server.
Note that if you disable end-entity interaction, the Network tab still shows the
HTTPS port and allows you to configure it (see “Configuring Port Numbers”
on page 378). However, you should know that the server ignores this port.
4.
In the Certificate Validity section, check the “Override validity nesting
requirement” option, if you want the Certificate Manager to issue certificates
with validity periods beyond that of its CA signing certificate; see “CA Signing
Key Pair and Certificate” on page 441).
If you leave the box unchecked and if the Certificate Manager (CA) finds a
request with validity period extending beyond that of its CA signing
certificate, it automatically truncates the validity period to end on the day the
CA signing certificate expires. For example, if the CA signing certificate expires
on June 10, 2004, any enrollment or renewal request with validity period
beyond June 10, 2004 will have validity period truncated to end on June 10,
2004.
Validity periods of certificates during enrollment is determined by the policy
explained in ValidityConstraints plug-in module. Similarly, validity
periods of certificates during renewal is determined by the policy explained in
RenewalValidityConstraints plug-in module. Both the modules are
explained in CMS Plug-ins Guide.
5.
In the Certificate Serial Number section, specify the serial number range for
certificates issued by this Certificate Manager. The server assigns the serial
number you enter in the “Next serial number” to the next certificate it issues
and the number you enter in the “Ending serial number” to the last certificate it
issues.
The serial number range enables you to deploy multiple CAs, balancing the
number of certificates each CA issues. Note that the combination of an issuer
name and a serial number uniquely identifies a certificate. To ensure that two
distinct certificates issued by the same authority doesn’t contain the same serial
number, make sure the serial number range does not overlap among cloned
CAs. (For information on cloning CAs, “Cloning a Certificate Manager” on
page 288.)
Also note that when a CA exhausts all its serial numbers, you can revive it by
changing the values in the “Next serial number” and “Ending serial number”
fields, followed by restarting the Certificate Manager.
544
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Configuring Authentication for End-User Enrollment
6.
In the Default Signing Algorithm section, select the signing algorithm the
Certificate Manager should use for signing certificates. The choices are “MD2
with RSA,” “MD5 with RSA,” and “SHA1 with RSA,” if the CA’s signing key
type is RSA and “SHA1 with DSA,” if the CA’s signing key type is DSA.
Note that the signing algorithm specified in the Certificate Manager’s policy
configuration overrides the algorithm you select here. For information on a
Certificate Manager’s policy configuration, see
SigningAlgorithmConstraints policy plug-in module in CMS Plug-ins Guide.
7.
To save your changes, click Save.
The CMS configuration is modified. If the changes you made require you to
restart the server, you will be prompted accordingly. In that case, restart the
server.
Enabling End-Entity Interaction with a Registration Manager
To enable end-entity interaction with a Registration Manager:
1.
In the CMS window, select the Configuration tab.
2.
In the navigation tree, select Registration Manager.
The General Setting tab appears.
Chapter
15
Setting Up End-User Authentication
545
Configuring Authentication for End-User Enrollment
3.
In the Web Access section, check the “Enable end-entity interaction” option if
you want end entities to be able to interact with the selected Registration
Manager via the HTTPS port; leave it unchecked to disable end-entity
interaction with the server.
Note that if you disable end-entity interaction, the Network tab still shows the
HTTPS port and allows you to configure it (see “Configuring Port Numbers”
on page 378). However, you should know that the server ignores this port.
4.
To save your changes, click Save.
The CMS configuration is modified. If the changes you made require you to
restart the server, you will be prompted accordingly. In that case, restart the
server.
Step 7. Turn on Automated Notification
Both the Certificate Manager and the Registration Manager can send
certificate-issuance notification to end users. For details on turning this feature on,
see , “Setting Up Automated Notifications.”
Step 8. Test Your Authentication Setup
To test whether your end users can successfully enroll for a certificate using the
authentication method you’ve set up:
1.
Open a web browser window.
2.
Go to the end-entity interface for the enrollment authority you configured.
The default URL is as follows:
https://<hostname>:<end_entity_HTTPS_port> or
http://<hostname>:<end_entity_HTTP_port>
546
3.
In the Enrollment tab, open the enrollment form you customized.
4.
Fill in all the values and submit the request.
5.
The client prompts you to enter the password for your key database.
iPlanet Certificate Management System Installation and Setup Guide • March 2001
Configuring Authentication for End-User Enrollment
6.
When you enter the correct password, the client generates the key pair.
Do not interrupt the key-generation process. Upon completion of the key
generation, the