Netscape Communications Corporation(“Netscape”), a subsidiary of America Online, Inc., and its licensors retain all ownership
rights to the software programsoffered by Netscape (referred to herein as “Software”) and related documentation.Use of the
Software and related documentation i s governed by the license agreement accompanying the Software and applicable copyright law.
Your right to copy this documentation is limited by copyright law. Making unauthorized copies, adaptations, or compilation works
is prohibited and constitutes a punishable violation of the law. Netscape may revise this documentation from time to time without
notice.
THIS DOCUMENTATION IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND. IN NO EVENT SHALL NETSCAPE BE
LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL D AMAGES OF ANY KIND ARISING FROM ANY
ERROR IN THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION ANY LOSS OR INTERRUPTION OF BUSINESS,
PROFITS, USE, OR DATA.
Netscape and the Netscape N logo are registered trademarks of Netscape Communications Corporation in the United States 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. Other product and brand names are the exclusive property of their
respective owners.
The downloading, exporting, or reexporting of Netscape software or any underlying information or technology must be in full
compliance with all United States and other applicable laws and regulations. Any provision of Netscape software or documentation
to the U.S. Government is with restricted rights a s described in the license agreement accompanying Netscape software.
Index ....................................................................... 851
21
22Netscape Certificate Management System Installation and Setup Guide • October2001
About This Guide
The Installation and Setup Guide explains how to install, configure, and maintain
Netscape Certificate Management System (CMS), and use it for issuing and
managing certificates tovarious 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 andcommand-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 3, “Default Demo Installation” Describes how to set up a simple pilot
that demonstrates the basic capabilities of a Certificate Manager.
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 unw anted 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”
•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 Inte rnal 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.
24Netscape Certificate Management System Installation and Setup Guide • October2001
What’s in This Guide
•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.
•Chapter 16, “Setting Up AutomatedNotifications” Describes how to ena blethe
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, signingalgorithm,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.
About This Guide25
What You Should Already Know
Part 5, “Appendix”
•Appendix A, “Certificate Download Specification” Describes the data formats
used by Netscape Communicator 4.x for installing certificates.
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 t o
deploy Certificate Management System. CMS agents should refer to CMS Agent’sGuide for information on how to perform agent tasks, such as handling certificate
requests and revoking certificates.
This guide assumes that you
•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)
❍Certificate hierarchies
If you are new to these concepts, we recommend that you read the
security-related appendixes (Appendix D and Appendix E) of the
accompanying manual, Managing Servers with Net scape Console.
26Netscape Certificate Management System Installation and Setup Guide • October2001
•Are familiar with the role of Netscape Console in managing Netscape version
4.x servers. Otherwise, see the accompanying manual, Managing Servers withNetscape Console.
•Are reading this guide in conjunction with the documentation listed in section
“Where to Go for Related Information” on page 28.
•
computer screen or text that you should type. It’s also used for filenames,
functions, and examples.
Conventions Used in This Guide
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 controldepends 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.
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.
About This Guide27
WheretoGoforRelatedInformation
•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, substitutethe path names used on your computer.
Example: Using Netscape Communicator 4.7 or later, enter the URL for the
Netscape Administration Server:
•/—A slash is used to separate directories ina path. If you use the WindowsNT
operating system, you should replace / with \ in paths.
Example: Except for the Security Module Database Tool, yo u can find all the
other command-lineutilities at this location:
•Sidebar text—Sidebar text marks important information. Make sure you read
the information before continuing with a task.
Examples:
NOTEYou can use Netscape Console only when Administration Server is
http://<hostname>:<port_number>
<server_root>/bin/cert/tools
up and running.
CAUTIONA 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:
<server_root> is the directory where the CMS binaries are kept (which you
•
specify during installation).
<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 Co nsole
Provides background information on basic cryptography conceptsand the role
of Netscape Console. To view the HTML version of this guide, open this file:
<server_root>/manual/en/admin/help/contents.htm
28Netscape Certificate Management System Installation and Setup Guide • October2001
Where to Go for Related Information
•CMS 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:
30Netscape Certificate Management System Installation and Setup Guide • October2001
Overview and Demo Installation
Chapter 1, “Introduction to Certificate Management System”
Chapter 2, “Certificate Enrollment and Life-Cycle Management
Chapter 3, “Default Demo Installation”
Part1
31
32Netscape Certificate Management System Installation and Setup Guide • October2001
Chapter1
Introduction to Certificate
Management System
This chapter introduces Netscape 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 ManagementSystem 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 solutionfor 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 41)
•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 KeyFeatures
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.”
•Supports issuanceof 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.
•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, s ecure 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.
34Netscape Certificate Management System Installation and Setup Guide • October2001
”
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
TM
customized to store certificates and CRLs in an Oracle RDBMS
.Formore
information, see Chapter 20, “Publishing Certificates and CRL s 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,andOnline 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, suchas 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.
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 abilityto 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 394.
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;inthiscase,the
server signs its own CA signing key aswell 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 orsubordinate CA, see
Part 2, “Planning and Installation.”
Ability to function as a linked CA
Certificate Management System can function as a linked CA,chaininguptomany
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.”
36Netscape Certificate Management System Installation and Setup Guide • October2001
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 Managerand configureeach 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 286.
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.01-compliant
products.
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 PK CS #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 450.
Supportfor 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.
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.”
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 an d expiration notifications. These
features are available out of the box for both Certificate Manager and Registration
Manager.
For informationon enrollment, renewal,and revocation operations, see Chapter 15,
“Setting Up End-User Authentication.” For information on automated
notifications,
Built-inplug-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.
see Chapter 16, “Setting Up Automated Notifications.”
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.
Single administration point achieved via LDAP-compliant directory
integration
Certificate Management System works se amlessly 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, includingtheir 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.
38Netscape Certificate Management System Installation and Setup Guide • October2001
Overview of Key Features
•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 Chapter 19, “Setting Up LDAP Publishing
•A flat file; see Chapter 20, “Publishing Certificates and CRLs to a File
•An Online Certificate Status Protocol (OCSP)-compliant validationauthority or
OCSP responder; see Chapter 21, “Setting Up an OCSP Responder
Applications in your enterprise may use any of these repositories to verify the
revocation status of a certificate.
Supportscertificate 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 tw o separate certificates.
For more information, see “Clients That Can Generate Dual Key Pairs” on
page 736.
Works with Netscape Personal Security Manager, that can generate
dual key pairs
Certificate Management System works seamlesslywith Netscape Personal Security
Manager, which when plugged into Netscape Communicator version 4.7x enables
it to support protocols such as OCSP and CRMF/CMMF 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 additional details, see “Netscape Personal Security
Manager” on page 102.
Note that Personal Security Manager is integrated into Netscape 6 as its default
security component. For more information about Netscape 6, check this site:
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
•An employee leaves the company, and company officials need to perform an
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 agent s can authorize and initiate a key recovery process.
by forgetting the password to the key file) and is unable to read previously
encrypted data.
audit that requires gaining access to the employee’s encrypted data.
For more information, see “Where the Keys are Stored” on page 738.
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. Alllog records are stored in your local file
system for quick and easy retrieval.
For more information, see Chapter 23, “Managing CMS Logs.”
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 790.
40Netscape Certificate Management System Installation and Setup Guide • October2001
System Overview
Java SDK extension mechanism for customization
The software development kit (SDK) provided with Certificate Management
System includes APIs andtutorialsfor customizing different aspectsof the system.
You can write the following custom modules:
•Authentication—for authenticating end entities during certificate enrollment.
•Policy—for setting therules 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 CMSCustomizationGuide.
Easy upgrade from previous versions of Certificate Management
System
Certificate Management System provides an easy upgrade path from its previous
version.
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 ad minister 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 338.
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:
•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 w e ll-suitedfor 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) im plementations, 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 c lient and server
software, customer databases, security systems, and authentication procedures.
You can use Certificate Management Sys tem 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.
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.
42Netscape Certificate Management System Installation and Setup Guide • October2001
System Overview
•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 subordinateCAs 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 endentity(EE)is a person,
router, server, or other entity that uses a certificate to identify itself.
To participate in a PKI, an end entity mustenroll, or register, in the system. The end
entity typically initiates enrollment by giving the CA some form of i dentification
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 (man ual 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 sel ected 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
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,
andlogcomponents;forexample,Javacodemodulescanbepluggedinto
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 an d 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 morepublic dire ctories affectall aspects of installation and
configuration. Some organizations may want to install a single Certificate Manager
on one machine inside thefirewall and a singleRegistrationManager on a separ ate
44Netscape Certificate Management System Installation and Setup Guide • October2001
System Overview
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 thesignedcertificates 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
•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, a nd 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. Forexample, 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
•Customizedextensions
The Certificate Manager supports the following signing algorithms for both
certificates and CRLs: RSA with MD2, RSA with MD5, RSA with SHA-1, andDSA
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:
•Authority key identifier. Identifies the public key to be used to validate the
digital signature on the certificate.
•CRL number. A sequential numberunique toeach CRL issued by a given CRL
issuer. This number allows CRL-checking software to ensure that all previous
CRLs have been received.
•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.
46Netscape Certificate Management System Installation and Setup Guide • October2001
System Overview
•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, t he 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 rem otely, all reporting to a
single CA—a Certificate Manager—to verify user identities and process certificate
signing requests. The Certificate Manager’s abilityto 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.
The Registration Manager is designed to handle certificatelife-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 usedas is
or customized. For more information about default Registration Manager forms,
see “End Entities and Life-Cycle Management” on page 98.
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 ent ities’ private encryption keys with a Data
Recovery Manageras part of the process of issuing new certificates. End-entities do
not have direct access to the Data Recovery Manager.
TheDataRecoveryManagerisusefulonlyifendentitiesareencryptingdata(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
recover encryption keys for employees who have left the company or who are
unavailable for some other reason. In eithercase, 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.
48Netscape Certificate Management System Installation and Setup Guide • October2001
System Overview
Table 1-1Key pairs used by end entities and key pairs used by the Data Recovery Manager
used by end-entity
software to encrypt the
endentity’sprivate
encryption key before
sending it to Certificate
Management System for
storage.
Public storage key:
used to decrypt an end
entity’s stored private
encryptionkey afterm of
n recovery agents have
authorized the recovery
operation.
Privatesigningkey:
used by owner to
digitally sign
messages
Online Certificate Status Manager
The 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 OnlineCertificate 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 an OCSPresponder.
Private encryption key:
used by owner to decrypt
messages encrypted with
the public key
Private transport key:
used by Data Recovery
Manager to decrypt an
endentity’sprivate
encryption key
Private storage key:
used to encrypt an end
entity’s private
encryption key for
long-term storage
Figure 1-1 illustrates some of the data formats and protocols used among the four
independent CMS managers and various kinds o f end entities. To keep things
simple, the figure assumes that each m anager 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-1Basic CMS configuration and use of data formats and protocols
50Netscape Certificate Management System Installation and Setup Guide • October2001
System Overview
The end-entity dataformats and transport methods shownin the figureare usedto
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 ManagementMessage 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 cer tificate 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 storedin 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 s tandard transport methods used for all of thedata formats described
above:
•Hypertext Transport Protocol (HTTP) and Hypertext Transport ProtocolSecure (HTTPS). Protocols used to communicate with web servers.
For more information about end-entity data formats and protocols used by
Certificate ManagementSystem, see “End Entities and Life-Cycle Management” on
page 98 and “Standards Summary” on page 77.
The RegistrationManager communicates with the Data Recovery Manager andthe
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 o ther over
HTTPS—that is, HTTP over SSL, as shown in Figure1-1. For information about the
connectors, see “Trusted Managers” on page 394.
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 beconfigured 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.
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 ent ity 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.
52Netscape Certificate Management System Installation and Setup Guide • October2001
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 Certi ficate 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.
Figure 1-2Key storage process during end-entity enrollment
System Overview
Data encrypted with the storage key can be retrieved only if m of n “splitkeys” are
providedatthesametimebym 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.
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 f or storing private information such as
certificate records, key archival records, and the request queue.
preconfigured Netscape Directory Server (version 4.x) installed transparently at the time of
CMS installation. In this guide, theDirectory Server instance used by a subsystem for
This database is a
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 Systemto 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 singleCMS instance
on a single m achine, 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 age nt, Registration Manager agent, and
Data Recovery Manager agent,andOnline Certificate Status Manager agent. Theroleof
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 agentcan be confined to a specificmanager or can
include several different managers.
54Netscape Certificate Management System Installation and Setup Guide • October2001
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
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.
KEYGEN HTML tag or PKCS #10) for each type of
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 intoCertificate ManagementSystem insteadof being implementedas
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 s imple 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.
Table 1-2Authentication plug-in modules for end-user enrollments
Plug-in module nameDescription
Manual authenticationRequires 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. Italso 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
Directory-based PIN
authentication
NIS-based authenticationAuthenticates end users based on t heir user IDs and passwords stored in a
Portal-styleauthenticationChecks that a user’s name is unique in an LDAP directory.
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.
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 server. Optionally, uses an LDAP directory for formulating certificate
subject names.
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.
56Netscape Certificate Management System Installation and Setup Guide • October2001
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 Managerhas 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 validityperiod in
the request accordingly.
•An extensions policy che cks 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-3Policy plug-in modules for checking and formulating certificate contents
Plug-in module nameDescription
AttributePresentConstraintsRejectsa 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.
DSAKeyConstraintsAllows the server to certify only DSA keys of specified lengths.
IssuerConstraintsAllows the server to check for certificates that have been issued by a
Table 1-3Policy plug-in modules for checking and formulating certificate contents (Continued)
Plug-in module nameDescription
KeyAlgorithmConstraintsAllows the server to certify only those keys that are generated using one
of the specified algorithms, such as RSA or DSA.
RenewalConstraintsAllows or rejects requests for renewal of expired certificates.
RenewalValidityConstraintsEnforces the number of days before which a currently active certificate
can be renewed and a new validity period for the renewed certificate.
RevocationConstraintsAllows or rejects requests for revocation of expired certificates.
RSAKeyConstraintsAllows the server to certify only RSA keys of specified lengths.
SigningAlgorithmConstraintsAllows the server to specify the signature algorithm to be used by the
CA (a Certificate Manager) to sign certificates.
SubCANameConstraintsAllows the server to check for issuer name uniqueness and prevents
issuance of multiple subordinate CA certificates with same issuer
names.
UniqueSubjectNameConstraintsAllows the server to check for certificate subject name uniqueness and
prevents issuance of multiple certificates with same subject names.
ValidityConstraintsCauses 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-4Policy plug-in modules for setting extensions in certificates
Plug-in module nameDescription
AuthInfoAccessExtAdds the Authority Information Accessextension 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.
AuthorityKeyIdentifierExtAdds 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 tosign a certificate. This extension
is useful when an issuer has multiple signing keys (for example, due to
CA certificate renewal).
58Netscape Certificate Management System Installation and Setup Guide • October2001
System Overview
Table 1-4Policy plug-in modules for setting extensions in certificates (Continued)
Plug-in module nameDescription
BasicConstraintsExtAdds 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.
CertificatePoliciesExtAdds the Certificate Policies extension to certificates. The extension
contains a sequence of one or more policy statements, each indicatingthe
policy under which the certificate has been issued and identifying the
purposes for which the certificatemay be used.
CertificateRenewalWindowExtAdds the Certificate Renewal Window extension to certificates. The
extension specifies how to renew a certificate automatically and when
automatic renewal should be attempted.
CertificateScopeOfUseExtAdds the Certificate Scope of Use extension t o 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.
CRLDistributionPointsExtAdds the CRL Distribution Points extension to certificates.This extension
identifies one or more locations from where the application t hat is
validating the certificate can obtain the CRL information.
ExtendedKeyUsageExtAdds 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.
GenericASN1ExtAdds ASN.1 type custom extension to certificates. This policy enables
you to configure Certificate Management System to add custom
extensions to certificates.
IssuerAltNameExtAdds 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.
KeyUsageExtAdds the Key Usage extension t o 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
acertificatecanbeused.
NameConstraintsExtAdds the Name Constraints extension to certificates. The extension is
used in CA certificates to indicate a name space within which subject
names or subject alternativenames in subsequent certificates in a
certification path or chain should be located.
Table 1-4Policy plug-in modules for setting extensions in certificates (Continued)
Plug-in module nameDescription
NSCCommentExtAdds the Netscape Certificate Comment extension to certificates. The
extension can be used to include textual comments in certificates.
NSCertTypeExtAdds the Netscape CertificateType 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.
OCSPNoCheckExtAdds 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.
PolicyConstraintsExtAddsthe 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.
PolicyMappingsExtAdds 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 policiesof one CA
are equivalent to policies of another CA.
PrivateKeyUsagePeriodExtAdds the Private Key Usage Period extension to certificates. The
extensionallows the certificate issuer to specify a different validityperiod
for the private key than the one specified for the corresponding
certificate.
RemoveBasicConstraintsExtDetects and removes the BasicConstraints extensionincertificate
requests.
SubjectAltNameExtAdds 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.
SubjectDirectoryAttributesExtAdds a Subject Directory Attributes extension to certificates. The
extension is used to specify any desired directory attribute values for the
subject of the certificate.
SubjectKeyIdentifierExtAddsthe 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 distinguishingpublic keys if more than one is available
for a given subject name, for example after the certificate has been
renewed with a new key.
60Netscape Certificate Management System Installation and Setup Guide • October2001
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” ofCMS Plug-ins Guide. To locate this guide, see
“Where to Go for Related Information” on page 28.
Job Plug-In Modules
The CMS Job Schedulerallows youto configurea CertificateManagementSystem 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-5Plug-in modules for schedulable jobs
Plug-in module nameDescription
RenewalNotificationJobNotifies 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.
RequestInQueueJobNotifies 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.
UnpublishExpiredJobUpdates 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.
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 updatethe 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 im port others’ certificates from the global directory.
Figure 1-3Seamless integration with any LDAP-compliant directory
Seamless integration with any LDAP-compliant directory (see Figure 1-3) makes
possible the following:
•Corporate IS organizations can generate and manage certificates as an integral
part of their user and group management.
62Netscape Certificate Management System Installation and Setup Guide • October2001
System Overview
•Independent CAs can iss ue 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-6Default mapper plug-in modules for mapping certificates and CRLs
Plug-in module nameFunction
LdapCaSimpleMapMaps 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.
LdapDNCompsMapMaps a certificate to a directory entry by formulating the entry’s DN from
components (such as CN, OU, O,andC) in the certificate’s subject name and using it
as the search DN to locate the entry in the directory.
LdapDNExactMapMaps a certificate to a directory entry by searching for the entry whose DN exactly
matches the certificate subject name.
LdapSimpleMapMaps 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.
LdapSubjAttrMapMaps 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 l ists the publisher modules supported by Certificate Management System
out of the box. Publisher modules helpyou configure a Certificate Manager to
publish certificates and CRLs to the mapped directory entries, to files, or to the
Online Certificate Status Manager.
Table 1-7Default publisher plug-in modules for publishing certificates and CRLs
Plug-in module nameFunction
FileBasedPublisherPublishes certificates and CRLs to a flat file (for exporting into other
repositories).
LdapCaCertPublisherPublishes 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.
LdapCrlPublisherPublishes (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.
LdapUserCertPublisherPublishes or unpublishes a certificate to the userCertificate;binary
attribute of the mapped directory entry as a DER encoded binary blob.
OCSPPublisherPublishes 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.
64Netscape Certificate Management System Installation and Setup Guide • October2001
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:
For detailed information about these utilities, see CMS Command-Line Tools Guide.
<server_root>/bin/cert/tools
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:
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).
<server_root>/cms_sdk/
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 examplesfor 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”.
•Miscellaneous information about CMS features such as an AutoInstaller, an
AutoRestart, script for UNIX, anda large zip file con taining a sophisticated
demonstration of ObjectSigning capabilities.
•Examples of how to use Certificate Management System withsome third-party
products.
Entry Points for Various Types of Users
Certificate Management System provides entry points for various kinds of user
interaction.
Figure 1-4Entry 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.
66Netscape Certificate Management System Installation and Setup Guide • October2001
Table 1-8Certificate Management System user entry points
User typeComponent/ToolCMS interface
End entityWeb browserEnd 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 appropriateHTML
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.
AgentWeb browserAgent 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
CertificateStatus 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 certificatesfor SSL client authentication to Certificate
Management System.
Entry Points for Various Types of Users
AdministratorNetscapeConsole
(CMS window)
The remote administrationinterface supports a GUI-based
administration tool called Netscape Console t hat provides the
general administrationand management interface for Certificate
Management System. For details, see Chapter 9, “Administration
Tasks and Tools.”
Administrators can use thistool to perform day-to-dayoperational
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-userinformation 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.
As an administrator, you can designate privileged users, called agents,foreach
subsystem. Agents are responsible for the day-to-day operation of requests from
end entities. For details, see “Agents” on page 387.
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,
theseformsarecalledtheAgent Servicesinterface.
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 CMSCustomizationGuide.
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.
68Netscape Certificate Management System Installation and Setup Guide • October2001
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.
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.
70Netscape Certificate Management System Installation and Setup Guide • October2001
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 741.)
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.
Figure 1-8Online Certificate Status Manager Agent Services interface
Using the default forms, a Online Certificate Status Manager agent can perform
tasks such as checking which CAs arecurrently 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 thatneed to be able to request certificate issuanceand 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
generate keys; end entities running Internet Explorer present a form based on
PKCS #10, the RSA standard for certificate request syntax.
72Netscape Certificate Management System Installation and Setup Guide • October2001
KEYGEN to
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-9End-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.
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.
74Netscape Certificate Management System Installation and Setup Guide • October2001
System Architecture
One or m ore PKCS #11 modules must be available to any CMS subsysteminstance.
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 modu le with Certificate
Management System; see “Installing External Tokens” on page 451.
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 han dles both cryptographic operations and
communication with the
certX.db and keyX.db files.
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. F or example, you need to modify
secmod.db if
you are installing hardware accelerators for use in signing operations.
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 CertificateStatus 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.
76Netscape Certificate Management System Installation and Setup Guide • October2001
Authentication and Policy Modules
The top layerof 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
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 M anagement Message Formats (CMMF). Messageformats 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).
•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 underdevelopment by the IETF for a public-key infrastructure for the
Internet. Part 1 deals with specifications for certificates an d 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:
•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 ProtocolSecure (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
•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.
78Netscape Certificate Management System Installation and Setup Guide • October2001
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.
80Netscape Certificate Management System Installation and Setup Guide • October2001
Chapter2
Certificate Enrollment and Life-Cycle
Management
This chapter explains how you can use Netscape 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 Enroll ment (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 thekind 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
3.Process policies. Ifauthentication is successful, policies specified for this CMS
4.Service request. After policy processing, the servlet’s work is finished and 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.
manager are appliedto the request forthe 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.
CMS manager services the request (assuming that a policy has not trigg ered
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 usethe 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.
82Netscape Certificate Management System Installation and Setup Guide • October2001
Steps in End-Entity Enrollment
Figure 2-1Roles of servlets, a uthentication modules, and policy modules in end-entity enrollment
Chapter 2Certificate Enrollment and Life-Cycle Management83
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,managementof
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” 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:
•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 viaX.509 v3 certificates.
84Netscape Certificate Management System Installation and Setup Guide • October2001
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 existingcustomers 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
networkbyusingKerberos.
Chapter 2Certificate Enrollment and Life-Cycle Management85
Some Enrollment Scenarios
The sections that follow describe how Acme uses Certi ficate 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.
1.Request certificate. The customer fills in and submits a form (over SSL) that
2.Custom authentication. The Registration Manager uses a custom
specifies account information and other personal details stored in the existing
customer database.
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 certificateand delivers it to the
Registration Manager.
5.Delivercertificate. 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.
86Netscape Certificate Management System Installation and Setup Guide • October2001
Figure 2-2Custom authentication against an existing customer database
Some Enrollment Scenarios
Enrolling New Customers
The following process will be used for enrollingnew 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.Requestcertificate. The customer fills in andsubmits 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 2Certificate Enrollment and Life-Cycle Management87
Some Enrollment Scenarios
3.Manual approval. The Registration Manager administrator may configure the
4.Requestcertificate. The Registration Manager performs policy processing and,
5.Issue certificate. The Certificate Manager performs its own policy processing
6.Email notice of issuance. The Registration Manager sends an emailcontaining
7.Pick up certificate. The customer goes to the specified Registration Manager
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, includingmaking a personal
phone call. If all authentication procedures are successful, the agent approves
the request.
if the processing is successful, sends the approved request to the Certificate
Manager.
on the request and, if processingis successful, issues the certificate and delivers
it to the Registration Manager.
a URL to the new customer, asking the customer to pick up the certificate.
URL and picks up the certificate.
88Netscape Certificate Management System Installation and Setup Guide • October2001
Figure 2-3Manual authentication of new customers
Some Enrollment Scenarios
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 that takes advantage of its existing
Kerberos system without disturbing its current functions.
Chapter 2Certificate Enrollment and Life-Cycle Management89
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.)
1.Request certificate. A user of Acme’s existing extranet fills in and submits a
2.Authentication. The Registration Manager uses a third-party authentication
3.Request certificate. If authentication against Kerberos is successful, the
4.Issue certificate. The Certificate Manager performs its own policy processing
certificate request (over SSL) using a customized form that requires a Kerberos
ID and password.
module to validate the user’s identity using the existing internal Kerberos
system.
Registration Manager performs policy processing and, if processing is
successful, forwards the request to the Certificate Manager.
on the request and, if processingis 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.
90Netscape Certificate Management System Installation and Setup Guide • October2001
Figure 2-4Custom authentication against an existing Kerberos security system
Some Enrollment Scenarios
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, orsome other
meansofphysicaldelivery.
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
PINtoensureuniquehashing.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 2Certificate Enrollment and Life-Cycle Management91
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):
1.Generate PINs. The CMS administrator runs the CMS PIN Genera tor against
2.Write out PIN records. The CMS administrator uses the CMS PIN Generator to
3.Out-of-band delivery. The user receives the PIN via a batch mailing system,
4.Request certificate (using PIN). The user goes to a specified Registration
5.Authentication (using PIN). The Registration Manager uses the standard CMS
6.Request certificate. If authentication against the directory is successful, the
the existing directory, populating each entry with a unique PIN.
write out PIN records for use by an ou t-of-band delivery mechanism.
payroll stub, invoice form, or other out-of-band delivery mechanism.
Manager URL, fills in name and PIN, and submits a certificate request.
PIN-based directory authentication module to verify the P IN against the
directory.
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.
92Netscape Certificate Management System Installation and Setup Guide • October2001
Figure 2-5PIN-based enrollment
Some Enrollment Scenarios
VPN Client Enrollment and Revocation
Virtual private network (VPN) client s oftware 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 2Certificate Enrollment and Life-Cycle Management93
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.
1.EnrollinPKI.The VPN client sends a certificate request to the Registration
2.Issue certificate. The Certificate Manager issues the certificate, and the
3.Publish certificate. The Certificate Manager publishes the certificate to a
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.)
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.
directory (this is an optional step).
4.Revoke certificate. After some time has passed, the Certificate Manager agent
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.
94Netscape Certificate Management System Installation and Setup Guide • October2001
Figure 2-6VPN client enrollmentand revocation
Some Enrollment Scenarios
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 2Certificate Enrollment and Life-Cycle Management95
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 certificatelife-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.
1.EnrollinPKI.The routers each send a certificate request to the Certificate
2.Publish certificates. As part of the issuing process, the Certificate Manager
Manager via CEP, and the CertificateManager issuesthem certificates. (Anyof
the authentication methods discussed in the previous section can be used
during enrollment to authenticate the client.)
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 mustfetch 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 o f 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.
96Netscape Certificate Management System Installation and Setup Guide • October2001
Figure 2-7Router enrollment and revocation
Some Enrollment Scenarios
Chapter 2Certificate Enrollment and Life-Cycle Management97
End Entities and Life-Cycle Management
End Entities and Life-Cycle Management
Certificate Management System provides default web f orms 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 andversions
of Communicator earlier than 4.5 need to be presented with an enrollment form
based on the use of the HTML tag
Microsoft Internet Explorer require a form containing VBScript
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.
KEYGEN to generate keys. End entities running
XENROLL
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.
98Netscape Certificate Management System Installation and Setup Guide • October2001
End Entities and Life-Cycle Management
Table 2-1End entities, message formats, algorithms, and key pairs supported by Certificate Management
System
End entity softwareEnrollment message
format over HTTP or
HTTPS
Navigator 3.x
Communicator 4.0 to 4.5
Internet Explorer 3.x and
4.x
Internet Explorer 5.xPKCS #10Signing and encryption:
Communicator 4.7x and
Netscape6
Netscapeservers
(including CMS
managers) and other
servers
Ciscorouters (version IOS
12.04) and VPN clients
KEYGEN tagSigning and encryption:
PKCS #10Signing and encryption:
CRMF and CMMF
based on new
JavaScript API
PKCS #10Signing and encryption:
CEPSigning and encryption:
Cryptographic algorithmsNo. of key pairs
RSA
Signing only: RSA, DSA
RSA
Signing only: RSA
RSA
Signing only: RSA, DSA
Signing and encryption:
RSA
Signing only: RSA, DSA
RSA
RSA
Single key pair
Single key pair
Single or dual key
pairs
Single or dual key
pairs
Single key pair
Single key pair
Access to Subsystems
Three kinds of entitiescan 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 2Certificate Enrollment and Life-Cycle Management99
End Entities and Life-Cycle Management
End-entity interactions can take place ove r 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-8Access ports for Certificate Management System
100Netscape Certificate Management System Installation and Setup Guide • October 2001
Loading...
+ hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.