|Previous Contents Index Next|
|iPlanet Certificate Management System Installation and Setup Guide|
Chapter 1 Introduction to Certificate Management System
This chapter introduces iPlanet Certificate Management Server (CMS), a highly configurable set of software components and tools for creating, deploying, and managing certificates. Based on open standards for certificate management, Certificate Management System leverages iPlanet Directory Server and iPlanet Console to provide a complete, scalable, high-performance certificate management solution for extranets and intranets.
Whether you are looking for a security solution for your enterprise or setting up an independent certificate authority (CA) service, Certificate Management System offers a robust, customizable, and scalable foundation for your public-key infrastructure (PKI).
The chapter has the following sections:
Overview of Key Features 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.
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 issuance of Wireless Transport Layer Security (wTLS)-compliant certificates for use with wireless applications.
Supports signature key lengths of up to 1024 bits (DSA) and 4096 (RSA) on both hardware and software tokens. For details, see Appendix C "Export Control Information."
Supports multiple message formats, such as KEYGEN/SPAC, CRMF/CMMF, CRS/CEP/SCEP, and PKCS #10 and CMC for certificate requests. All requests are delivered to Certificate Management System over HTTP or HTTPS; in the case of CRS/CEP/SCEP protocol, the delivery method is always over HTTP. For a description of the acronyms, see Standards Summary.
Supports certificate formats that encompass certificates for SSL-based client and server authentication, secure Multipurpose Internet Mail Extensions (S/MIME) message signing and encryption, object signing, VPN clients, and CiscoTM routers.
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."
Publishes certificates and CRLs to a flat file for importing into other resources. For example, the sample code for Flat File CRL and certificate publisher can be customized to store certificates and CRLs in an Oracle RDBMSTM. For more information, see Chapter 20 "Publishing Certificates and CRLs to a File."
Publishes CRLs to an online validation authority (or OCSP responder), enabling real-time verification of certificates by OCSP-compliant clients. For more information, see Chapter 21 "Setting Up an OCSP Responder."
Separate subsystems for certificate and key operations
Certificate Management System includes four servers, the Certificate Manager, Registration Manager, Data Recovery Manager, and Online Certificate Status Manager.
The Certificate Manager functions as the certificate authority (CA); it is the entity named in the issuer field of a certificate. The Certificate Manager can sign and revoke certificates and generate CRLs. It can accept certificate requests directly from end entities and via Registration Managers to which it has delegated certain certificate management functions, such as authentication of an end entity. The Certificate Manager also maintains a database of issued certificates so that it can track renewal, expiration, and revocation.
The Registration Manager is an optional component in the PKI; it is a subordinate server to which a Certificate Manager can delegate some certificate management functions. For example, a Registration Manager may act as a front end to a Certificate Manager, performing tasks such as end-entity authentication and formulation of the certificate request for the Certificate Manager. For an overview of these subsystems, see CMS Subsystems or Managers.
Single CA supports multiple registration authorities
Certificate Management System lets you separate the registration process from the certificate-signing process with the help of Registration Managers. You can run multiple Registration Managers remotely, all reporting to a single Certificate Manager, to verify user identities and process certificate signing requests. The remote Registration Managers forward their completed and approved requests to the Certificate Manager for it to sign and issue the certificate automatically.
The Certificate Manager's ability to support multiple Registration Managers makes it more scalable and also adds an extra layer of security for the CA. For example, you can set a policy that requires all clients to go through a remote Registration Manager, and then have the remote Registration Manager route all client requests to the Certificate Manager located inside a firewall.
For more information, see Trusted Managers.
Ability to function as both a root and a subordinate CA in a CA hierarchy
Certificate Management System can function as a root or parent CA; in this case, the server signs its own CA signing key as well as other CA signing keys, enabling you to create your own CA hierarchy. You can also install the server to function as a subordinate CA; in this case, the server gets its CA signing key signed by another CA in an existing CA hierarchy.
For details on installing the Certificate Manager as a root or subordinate CA, see Part 2, "Planning and Installation."
Ability to function as a linked CA
Certificate Management System can function as a linked CA, chaining up to many third-party or public CAs for validation; this provides cross-company trust, so applications can verify certificate chains outside the company certificate hierarchy. You chain a Certificate Manager to a third-party CA by requesting the Certificate Manager's CA signing certificate from the third-party CA.
For details on installing the Certificate Manager as a linked CA, see Part 2, "Planning and Installation."
CA scalability via cloning
If you don't want to create a CA hierarchy comprising root and subordinate CAs, you can create multiple clones of a Certificate Manager and configure each clone to issue certificates that fall within a distinct range of serial numbers. Because clone CAs use the same CA signing key and certificate (as that of the master CA) to sign the certificates they issue, the issuer name in all the certificates in your PKI setup would be the same (as if they've been issued by a single CA).
For details on cloning a Certificate Manager, see Cloning a Certificate Manager.
PKCS #11 hardware support for smart cards and crypto accelerators
Certificate Management System supports smart cards and crypto accelerators provided by various third-party vendors of PKCS #11 version 2.1-compliant products. You can configure the server to use different PKCS #11 modules to generate and store key pairs (and certificates) for the Certificate Manager, Registration Manager, and Data Recovery Manager. Using hardware for key storage (especially for Certificate Manager and Data Recovery Manager key pairs) reduces the risk of key compromise, because hardware tokens don't reveal keys or provide means for them to be revealed, once the keys are generated in the hardware. Note that PKCS#11 hardware devices also provide key backup and recovery features for backup and recovery of the key material stored on the hardware token. Be sure to refer to the PKCS #11 vendor documentation on this subject.
For information on configuring Certificate Management System to use hardware tokens for generating and storing its key pairs and certificates, see Tokens for Storing CMS Keys and Certificates.
Support for Netscape client and iPlanet server products; client independence for non-Netscape products
Certificates issued by Certificate Management System work with existing Netscape client and iPlanet 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 facilitya preconfigured version of iPlanet Directory Server that's automatically installed with Certificate Management Systemenabling you to issue and manage a large number of certificates. For more information, see Chapter 12 "Setting Up Internal Database."
Flexible end-entity registration services framework
The registration services framework for end entities includes the most commonly expected PKI features: manual, directory-based, directory- and PIN-based, NIS-based, and portal enrollments; certificate-authenticated renewals and revocations (based on SSL client authentication); certificate life-cycle operations that include automated certificate renewal and expiration notifications. These features are available out of the box for both Certificate Manager and Registration Manager.
For information on enrollment, renewal, and revocation operations, see Chapter 15 "Setting Up End-User Authentication." For information on automated notifications, see Chapter 16 "Setting Up Automated Notifications."
Built-in plug-in modules for authentication, policy, job scheduling, and publishing
Certificate Management System simplifies the details involved in certificate issuance and management with its built-in, configurable, and extensible authentication, policy, job scheduling, and publishing components. Each of these components come with a set of default modules that enable you to configure Certificate Management System for your PKI requirements. For example, you can configure policy modules to determine the outcome of operations, such as certificate formulation (extensions, signing algorithm, key length, validity period, and so on), issuance, renewal, and revocation.
For information about all plug-in modules (such as authentication, job, policy, and publishing modules) that are provided for Certificate Management System, see Plug-in Modules.
Single administration point achieved via LDAP-compliant directory integration
Certificate Management System works seamlessly with any LDAP-compliant directory services for easy distribution of certificates and CRLs, thus lowering the cost of information management. The shared directory architecture enables you to manage users, including their security credentials and other shared data, at a single place. Certificate Management System can do the following:
Authenticate users based on the information that exists in the LDAP directory.
Supports many methods for verifying the revocation status of certificates
Revocation status of a certificate can be made available to PKI entities by publishing the CRL to various repositories. To aid you in this process, the Certificate Manager supports publishing of CRLs to the following repositories:
An LDAP-compliant directory; see , Setting Up LDAP Publishing.
A flat file; see , Publishing Certificates and CRLs to a File.
An Online Certificate Status Protocol (OCSP)-compliant validation authority or OCSP responder; see , Setting Up an OCSP Responder. Applications in your enterprise may use any of these repositories to verify the revocation status of a certificate.
Supports certificate generation for dual key pairsseparate key pairs for signing and encrypting mail messages
To support separate key pairs for signing and encrypting data, Certificate Management System supports generation of dual certificates for end entities capable of generating dual key pairs. If a client makes a certificate request for dual key pairs, the server issues two separate certificates.
For more information, see Clients That Can Generate Dual Key Pairs.
Works with Netscape Personal Security Manager, that can generate dual key pairs
Certificate Management System works seamlessly with Netscape Personal Security Manager, which when plugged into Netscape Communicator version 4.7x enables it to support protocols such as OCSP and CMC and generation dual key pairs. Personal Security Manager is a standards-based, client-independent application that performs PKI operations on behalf of Communicator 4.7x and other applications. For details, see Netscape Personal Security Manager.
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 unavailableas, for instance, in the following cases:
An employee loses an encryption private key (for example after a disk crash or by forgetting the password to the key file) and is unable to read previously encrypted data. For more information, see Chapter 22 "Setting Up Key Archival and Recovery."
Encrypted key storage and password-protected recovery
Certificate Management System stores users' encryption private keys in an encrypted key repository. Keys can be retrieved only by authorized key recovery agents. The key repository is encrypted using a Data Recovery Manager's storage private key, which is protected with one or more recovery agents' passwords. Only these designated recovery agents can authorize and initiate a key recovery process.
For more information, see Where the Keys are Stored.
Extensive audit and log records for detection of tampering
Certificate Management System maintains audit trails for all eventscertificate requests and issuance, revocation requests, CRL publication, and so on. These audit records enable you to detect any unauthorized access or activity. In addition, extensive system and error logs record various events and system errors so that you can monitor and debug the system. All log records are stored in your local file system for quick and easy retrieval.
For more information, see Chapter 23 "Managing CMS Logs."
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.
Java SDK extension mechanism for customization
The software development kit (SDK) provided with Certificate Management System includes APIs and tutorials for customizing different aspects of the system. You can write the following custom modules:
Authenticationfor authenticating end entities during certificate enrollment. For information about writing custom plug-ins, see CMS SDK.
For information on customizing end-entity and agent interfaces (HTML forms and templates), see CMS Customization Guide.
Easy upgrade from previous versions of Certificate Management System
Certificate Management System provides an easy upgrade path from its previous version. If you want to install a separate, stand-alone version of iPlanet Console for any reason, you can download it from this site: http://www.iplanet.com/downloads/patches/
GUI-based server installation and management
An installation wizard automates the installation and initial configuration process, helping you install Certificate Management System quickly and easily. Then after installation, you can locally or remotely administer Certificate Management System from various computers on your network (using the encryption, message integrity, and authentication services of SSL) with the help of an administration interface called the Certificate Management System window or the CMS window.
For more information, see The CMS Window.
Certificate Management System provides a highly scalable, easily deployable certificate infrastructure for supporting encryption, authentication, tamper detection, and digital signatures in networked communications. It is based on open standards and protocols that include the following:
Public-Key Cryptography Standard (PKCS) #11 Certificate Management System leverages iPlanet Directory Server and iPlanet Console to provide a complete, scalable, high-performance certificate management solution for extranets and intranets. Its strong support for existing and evolving standards makes Certificate Management System especially well-suited for large heterogeneous extranets that must support a variety of platforms, client and server software, hardware devices such as routers and hardware tokens, virtual private network (VPN) implementations, existing intranet security systems, wireless applications, and so on. It can be customized and configured to fit widely varying deployment scenarios, permitting rapid integration with existing client and server software, customer databases, security systems, and authentication procedures.
You can use Certificate Management System to set up and manage your own public-key infrastructure or to deploy a public certification authority. Certificate Management System meets the needs of an enterprise, leveraging your existing enterprise resources and services, and will grow with your business needs to meet the demand of Internet-scale deployments.
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.
Set up hierarchies of certificate authoritiesmultiple subordinate CAs chained up to a root CA. (Certificate Management System can also chain under popular public CAs that are already pretrust in popular client and server products.)
Publish certificate information to an LDAP-compliant directory, such as iPlanet 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.
The standards and services that facilitate the use of public-key cryptography and X.509 version 3 certificates in a networked environment are collectively called public-key infrastructure (PKI). In any PKI, a certificate authority (CA) is a trusted entity that issues, renews, and revokes certificates. An end entity (EE) is a person, router, server, or other entity that uses a certificate to identify itself.
To participate in a PKI, an end entity must enroll, or register, in the system. The end entity typically initiates enrollment by giving the CA some form of identification and a newly generated public key. The CA uses the information provided to authenticate, or confirm, the identity. In some cases the CA may require human intervention, such as an interview or examination of notarized documents, to authenticate the end entity (manual approval). In other cases the information provided may be sufficient (automatic approval). In addition to authenticating the end entity, the CA uses the public key to ensure "proof of possession"that is, cryptographic evidence that the certificate request was signed by the holder of the corresponding private key. Finally, the CA issues a certificate that associates the end entity's identity with the public key, and signs the certificate with the CA's own private signing key.
Certificate Management System dramatically simplifies the PKI enrollment process. Before you deploy a PKI, however, you need to make many decisions about the relationships between CAs and end entities and related policies and procedures.
End entities and CAs may be in different geographic or organizational areas or in completely different organizations that are linked through an extranet (that is, the extension of a company's internal network, or intranet) to selected customers, suppliers, and mobile employees via the Internet. CAs may include third parties that provide services through the Internet as well as the root CAs and subordinate CAs for individual organizations. Policies and certificate content may vary from one organization to another. For all these reasons and many others, the deployment and long-term management of any large-scale PKI require careful advance planning and custom configuration.
CMS Subsystems or Managers
Certificate Management System comprises four servers (also referred to as subsystems or CMS managers) namely:
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, and log components; for example, Java code modules can be plugged in to authenticate user identities and to enforce certificate issuance policies.
The Certificate Manager, Registration Manager, Data Recovery Manager, and Online Certificate Status Manager subsystems are all highly customizable and can be installed in a variety of configurations and physical locations. Decisions about the number of subsystems to install, where to install them, and the relationships among them and one or more public directories affect all aspects of installation and configuration. Some organizations may want to install a single Certificate Manager on one machine inside the firewall and a single Registration Manager on a separate machine outside the firewall. Others may have a single CA run by a single Certificate Manager and hundreds of Registration Managers in different geographic locations. Still others may have many different CAs or subordinate CAs, and only a few Registration Managers.
The sections that follow explain each subsystem in detail. For descriptions of some basic deployment options, see Chapter 4 "Planning Your Deployment".
A Certificate Manager functions as a root or subordinate certificate authority. This subsystem issues, renews, and revokes certificates, generates certificate revocation lists (CRLs), and can publish certificates to an LDAP directory and a file, and CRLs to an LDAP directory, a file, and an OCSP responder. The Certificate Manager can be configured to accept requests from end entities, Registration Managers, or both, and can process requests either manually (that is, with the aid of a person, identified in this document as Certificate Manager agent) or automatically (based entirely on customizable policies and procedures).
When set up to work with a separate Registration Manager, the Certificate Manager processes requests and returns the signed certificates to the Registration Manager for distribution to the end entities. (For an overview of the role of certificate authorities and related concepts of public-key cryptography, see Appendix D of Managing Servers with iPlanet 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 Note that the publishing tasks can be performed by the Certificate Manager only. The Certificate Manager also has a built-in OCSP service, enabling OCSP-compliant clients to directly query the Certificate Manager about the revocation status of a certificate that it has issued. For example, if you plan to deploy a PKI comprising a master CA and many clone CAs, you can enable the OCSP service of the master CA. This way, all clients in your PKI setup can verify the revocation status of a certificate by querying the master Certificate Manager.
The Certificate Manager can issue certificates with the following characteristics:
X.509 version 3 The Certificate Manager supports the following signing algorithms for both certificates and CRLs: RSA with MD2, RSA with MD5, RSA with SHA-1, and DSA with SHA-1.
The Certificate Manager can issue X.509 v1 or v2 CRLs. A CRL can be automatically updated whenever a certificate is revoked or at specified intervals.
CRL extensions supported include the following:
Authority key identifier. Identifies the public key to be used to validate the digital signature on the certificate. 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.
A Registration Manager is an optional component in the PKI, enabling you to separate the registration process from the certificate-signing process. A Registration Manager is typically installed on a different machine from the Certificate Manager that it serves. During installation, you connect the Registration Manager to a Certificate Manager and configure the Certificate Manager to trust the Registration Manager. Once the trust is established, the Registration Manager can perform a subset of the end-entity tasks performed by the Certificate Manager, such as enrollment or renewal, on behalf of the Certificate Manager. A Registration Manager cannot issue or revoke certificates by itself; instead, it evaluates end-entity requests and forwards them to a Certificate Manager for action, such as the issuing of a certificate. The Certificate Manager processes the requests and issues the certificates. The Registration Manager then distributes the certificates to the end entities.
Note that you can run multiple Registration Managers remotely, all reporting to a single CAa Certificate Managerto verify user identities and process certificate signing requests. The Certificate Manager's ability to support multiple Registration Managers makes it more scalable and also adds an extra layer of security for the CA. For example, you can set a policy that requires all clients to go through a remote Registration Manager, and then have the remote Registration Manager route all client requests to the Certificate Manager located inside a firewall.
The Registration Manager is designed to handle certificate life-cycle management tasksthat 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) A Registration Manager's default forms for end-entity interactions can be used as is or customized. For more information about default Registration Manager forms, see End Entities and Life-Cycle Management.
Data Recovery Manager
A Data Recovery Manager performs the long-term archival and recovery of private encryption keys for end entities. A Certificate Manager or Registration Manager can be configured to archive end entities' private encryption keys with a Data Recovery Manager as part of the process of issuing new certificates. End-entities do not have direct access to the Data Recovery Manager.
The Data Recovery Manager is useful only if end entities are encrypting data (using applications such as S/MIME email) that the organization may need to recover someday. It can be used only with client software that supports dual key pairsthat 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 either case, once the encryption key has been recovered, the user or administrator can use it to decrypt any data (such as saved email messages) that was encrypted with that key.
The Data Recovery Manager uses two special key pairs in the process of archiving an end entity's encryption key: a transport key pair (and certificate) and a storage key pair. The end entity must also have two key pairs: a signing key pair and an encryption key pair. The roles of all these keys are summarized in Table 1-1.
End-entity key pairs
Data Recovery Manager key pairs
Signing key pair
Encryption key pair
Transport key pair
Storage key pair
Online Certificate Status Manager
A Online Certificate Status Manager performs the task of an online certificate validation authority, by enabling OCSP-compliant clients to do real-time verification of certificates. The Online Certificate Status Manager can receive CRLs from multiple Certificate Managers and clients can query the Online Certificate Status Manager for the revocation status of certificates issued by all these Certificate Managers. For example, if you plan to create a CA hierarchy comprising a root CA and many subordinate CAs, you can configure each of these CAs to publish their CRLs to the Online Certificate Status Manager. This way, all clients in your PKI deployment can verify the revocation status of a certificate by querying the Online Certificate Status Manager.
Note that an online certificate-validation authority is often referred to as OCSP responder.
Basic System Configuration
Figure 1-1 illustrates some of the data formats and protocols used among the four independent CMS managers and various kinds of end entities. To keep things simple, the figure assumes that each manager is installed in a different CMS instance and on a different machine. The Registration Manager handles all interactions with different kinds of end entities, using protocols appropriate for each entity.
Figure 1-1    Basic CMS configuration and use of data formats and protocols
The end-entity data formats and transport methods shown in the figure are used to send enrollment and other requests to the Registration Manager (indicated by a right-pointing arrow) or to send responses back to the end entities (indicated by a left-pointing arrow). The end-entity data formats can be summarized as follows:
Certificate Request Message Format (CRMF) and Certificate Management Message Formats (CMMF). Proposed standards from the Internet Engineering Task Force (IETF) PKIX working group that define message formats used to convey requests to a Registration Manager or Certificate Manager and to return information to end entities. CMMF will be subsumed by another proposed standard, Certificate Management Messages over Cryptographic Message Syntax (CMC), which is also supported by Certificate Management System.
Certificate Enrollment Protocol (CEP). A certificate management protocol jointly developed by Cisco Systems and VeriSign, Inc. CEP governs communication between routers or VPN clients and a Registration Manager or Certificate Manager.
Public-Key Cryptography Standard (PKCS) #7. An encrypted data and message format developed by RSA Data Security to represent digital signatures, certificate chains, and encrypted data. This format is used to deliver certificates to end entities.
Public-Key Cryptography Standard (PKCS) #10. A message format developed by RSA Data Security for certificate requests. This format is supported by many server products and by Microsoft Internet Explorer. These are the standard transport methods used for all of the data formats described above:
Hypertext Transport Protocol (HTTP) and Hypertext Transport Protocol Secure (HTTPS). Protocols used to communicate with web servers. For more information about end-entity data formats and protocols used by Certificate Management System, see End Entities and Life-Cycle Management and Standards Summary.
The Registration Manager communicates with the Data Recovery Manager and the Certificate Manager as necessary to facilitate certificate management operations such as enrollment, renewal, or key storage. When the four subsystems are installed in separate CMS instances (whether on the same machine or on different machines), they use proprietary connectors to communicate with each other over HTTPSthat is, HTTP over SSL, as shown in Figure 1-1. For information about the connectors, see Trusted Managers.
The Certificate Manager maintains complete record of issued certificates and can publish certificates and CRLs many repositories, such as a directory using LDAP or LDAP over SSL (LDAPS), a file, or the Online Certificate Status Manager. If the Certificate Manager and directory are inside the firewall and if it's necessary for some entries in a directory to be available outside the firewall, Netscape recommends using the partial replication feature of Directory Server to replicate the relevant portion of the directory to which the Certificate Manager publishes. In this guide, a directory used for publishing certificates and CRLs is called a publishing directory. Publishing directories can also be used for authentication to implement an automated certificate enrollment method.
As mentioned earlier, the Data Recovery Manager performs the long-term archival and recovery of end users' private encryption keys. A Certificate Manager or Registration Manager can be configured to archive end users' private encryption keys with a Data Recovery Manager as part of the process of issuing new certificates. End-entities do not have direct access to the Data Recovery Manager.
The following steps summarize the key storage process during end-entity enrollment through a Registration Manager. Figure 1-2 illustrates these steps.
After the user completes and submits an enrollment form, the end entity generates dual key pairs and sends two certificate requests to the Registration Manager, which detects a request for key archival and requests the private encryption key from the end entity. The end entity then encrypts (or "wraps") its newly minted private encryption key with the Data Recovery Manager's public transport key (obtained from a copy of the transport certificate embedded in the enrollment form) and sends the wrapped private key to the Registration Manager.
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).
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.
The Data Recovery Manager signs a proof-of-archival token with its private transport key and sends the token to the Registration Manager.
The Registration Manager verifies the token and sends the certificate requests on to the Certificate Manager.
The Certificate Manager issues the signing and encryption certificates and sends them back to the Registration Manager.
The Registration Manager delivers the certificates to the end entity. Figure 1-2    Key storage process during end-entity enrollment
Data encrypted with the storage key can be retrieved only if m of n "split keys" are provided at the same time by m of n authorized recovery agents. By default, m and n are 2 and 3, respectively. Both values can be changed, as long as m is less than or equal to n.
The Data Recovery Manager indexes stored keys by owner name and a hash of the public key. This arrangement allows for highly efficient searching by name (all stored keys belonging to that owner are returned) or by public key (only the requested key is returned).
Each CMS manager has its own database for storing private information such as certificate records, key archival records, and the request queue. This database is a preconfigured iPlanet Directory Server installed transparently at the time of CMS installation. In this guide, the Directory Server instance used by a subsystem for storing its data is called an internal database. For example, the Certificate Manager uses its internal database for storing certificates and certificate requests; the Registration Manager uses its internal database for storing certificate requests (but not certificates, which are stored by the Certificate Manager only); the Data Recovery Manager uses its internal database for storing archived encryption keys; and the Online Certificate Status Manager uses its internal database for storing CRLs published by Certificate Managers. Using Directory Server as an internal database allows Certificate Management System to leverage the scalability and industry-leading performance of Directory Server, replacing the Relational Database Management System (RDBMS) used in Certificate Server 1.0x.
Some deployments require installation of two subsystems in a single CMS instance on a single machine, for example, Certificate Manager and Data Recovery Manager, Registration Manager and Data Recovery Manager, or Data Recovery Manager and Online Certificate Status Manager. In these dual-manager installations, both subsystems use the same internal database for storing data and communication between the two subsystems takes place internally (that is, within the same running process) rather than via HTTPS. (Note that a Certificate Manager performs all Registration Manager tasks, including end-entity interactions. Registration Managers are required only for remote or delegated administration of the CA.)
Throughout this guide, the term CMS administrator describes the person who installs and configures one or more managers and sets up privileges for the users who manage those subsystems. The users who manage day-to-day interactions of end entities with each manager, as well as other aspects of the PKI, are called CMS agents collectively, or the Certificate Manager agent, Registration Manager agent, and Data Recovery Manager agent, and Online Certificate Status Manager agent. The role of an agent is to approve, defer, or reject requests using Agent Services web pages served by the CMS manager for which that agent has been assigned the necessary privileges. The privileges of each agent can be confined to a specific manager or can include several different managers.
System administrators set up CMS subsystems through iPlanet 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."
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 userfor certificate enrollment, renewal, revocation, or retrievalis handled by a different servlet, a piece of Java code designed for that kind of request. Each servlet processes the request using the appropriate protocols (such as the KEYGEN HTML tag or PKCS #10) for each type of end entity. Additional servlets control interactions with administrators and agents.
The sections that follow provide an overview of the plug-in modules provided with Certificate Management System. For detailed information about all the plug-in modules, refer to CMS Plug-Ins Guide.
Authentication Plug-in Modules
An authentication module is a set of rules (implemented as a Java class) for authenticating an end user, server, or other entity that needs to interact with a CMS manager. (Similar rules are used to authenticate agents and administrators, but they are built into Certificate Management System instead of being implemented as plug-in modules.) With a typical end-user enrollment, the user supplies the information requested by the Registration Manager on an enrollment form, and then the servlet uses an authentication module specified within the form to validate the information and authenticate the user's identity. This simple input value makes it possible to use custom authentication for any form without changing the corresponding servlet code.
Both the Certificate Manager and Registration Manager support client SSL certificate-based authentication (for both agents and end entities). iPlanet 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.
Plug-in module name
Requires manual approval by an agent. This authentication module is hardwired; you cannot configure it. This ensures that when the server receives requests that lack authentication credentials, it sends them to the request queue for agent approval. It also means that if you don't configure Certificate Management System for any other authentication mechanism, the server automatically sends all certificate-related requests to a queue where they await agent approval.
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.
Makes it possible for a SunTM ONE Identity Server 6.0 user to authenticate himself to the Certificate Server by providing his Single Sign-On token instead of userID and password. The user can also apply for a general-purpose user certificate with a single click of a button, eliminating the need to manually import or install the certificate.
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 nameits 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.
For information about ways customized authentication modules can be used during enrollment, see Some Enrollment Scenarios.
Policy Plug-in Modules
A policy module is a rule (implemented as a Java class) that validates the contents of a certificate request and formulates the contents of the certificate to be issued. Policy modules are also responsible for accepting, rejecting, or deferring the request. Certificate Management System policies have nothing to do with export control policies or certificate usage policies.
After a Registration Manager or Certificate Manager has successfully authenticated an end entity, the entity's request is passed to a policy processor, which sequentially applies a set of policy rules configured for that CMS manager. The processor validates the contents of a certificate request for each rule and can add or modify any part of a certificate's contents, including validity dates, name constraints, and extensions.
Here are three typical examples of the use of policies:
A name constraints extension policy checks that the subject name matches a pattern, and it rejects, defers, or adjusts the subject name in the request accordingly. For an introduction to the role of policy modules in the enrollment process, see Authentication and Policy Modules.
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.
Plug-in module name
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.
Plug-in module name
Adds the Authority Information Access extension to certificates. The extension specifies how the application validating the certificate can access information, such as on-line validation services and CA policy statements, about the CA that has issued the certificate in which the extension appears.
Adds the Authority Key Identifier extension to certificates of a specified type. The Authority Key Identifier extension identifies the public key corresponding to the private key used to sign a certificate. This extension is useful when an issuer has multiple signing keys (for example, due to CA certificate renewal).
Adds the Basic Constraints extension to certificates of a specified type. This extension is used during the certificate chain verification process to identify CA certificates and to apply certificate chain path length constraints.
Adds the Certificate Policies extension to certificates. The extension contains a sequence of one or more policy statements, each indicating the policy under which the certificate has been issued and identifying the purposes for which the certificate may be used.
Adds the Certificate Scope of Use extension to SSL client certificates. This extension specifies Internet addresses where the certificate can be presented for SSL client authentication. This restriction prevents any private information that might be contained in the certificate from being released to servers not explicitly contained in the scope of use.
Adds the CRL Distribution Points extension to certificates. This extension identifies one or more locations from where the application that is validating the certificate can obtain the CRL information.
Adds the Extended Key Usage extension to certificates. The extension identifies one or more purposesin addition to or in place of the basic purposes indicated in the key usage extensionfor which the certified public key may be used.
Adds the Issuer Alternative Name extension to certificates. This extension enables binding of or associating Internet style identities, such as Internet electronic mail address, a DNS name, an IP address, and a uniform resource indicator (URI), with the certificate issuer.
Adds the Key Usage extension to certificates of a specified type. This extension defines the purpose of the key contained in the certificate. The Key Usage, Extended Key Usage, Basic Constraints, and Netscape Certificate Type extensions act together to specify the purposes for which a certificate can be used.
Adds the Name Constraints extension to certificates. The extension is used in CA certificates to indicate a name space within which subject names or subject alternative names in subsequent certificates in a certification path or chain should be located.
Adds the Netscape Certificate Type extension to certificates of a specified type. This extension can be used to limit the purposes for which a certificate can be used. It has been replaced by the X.509 v3 extensions extKeyUsage and basicConstraints, but must still be supported in deployments that include Navigator 3.x clients.
Adds the OCSP No Check extension to certificates. The extension, which should be used in OCSP responder certificates only, indicates how OCSP-compliant applications can verify the revocation status of the certificate an authorized OCSP responder uses to sign OCSP responses.
Adds the Policy Constraints extension to certificates. The extension, which can be used in CA certificates only, constrains path validation in two ways. It can be used to prohibit policy mapping or to require that each certificate in a path contain an acceptable policy identifier.
Adds the Policy Mappings extension to certificates. The extension lists one or more pairs of OIDs, each pair identifying two policy statements of two CAs. The pairing indicates that the corresponding policies of one CA are equivalent to policies of another CA.
Adds the Private Key Usage Period extension to certificates. The extension allows the certificate issuer to specify a different validity period for the private key than the one specified for the corresponding certificate.
Adds the Subject Alternative Name extension to certificates of a specified type. This extension includes one or more alternative (non-X.500) names for the identity bound by the CA to the certified public key. It may be used in addition to the certificate's subject name or as a replacement for it.
Adds the Subject Key Identifier extension to certificates of a specified type. This extension identifies the public key certified by this certificate. It provides a way of distinguishing public keys if more than one is available for a given subject name, for example after the certificate has been renewed with a new key.
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 sectionCMS SDK.
For detailed information about using certificate extensions, see Appendix C, "Certificate and CRL Extensions" of CMS Plug-Ins Guide.
Job Plug-In Modules
The CMS Job Scheduler allows you to configure a Certificate Management System to perform a specified action at a specified time, such as informing a user of the need to renew a certificate or removing an expired certificate from the directory. The scheduler checks at specified intervals for jobs waiting to be executed; if the specified execution time has arrived, the scheduler initiates the job.
You can use standard CMS job plug-ins or write your own Java plug-in class in much the same way that you can write your own authentication and policy modules. Plug-in classes are provided out of the box for scheduling the following jobs.
Plug-in module name
Notifies agents at regular intervals of the state of the request queue. Alternatively, an event-driven notification can be sent whenever a request has been added to the request queue; see the next section for details. Available for Registration Manager or Certificate Manager.
Updates a specified LDAP publishing directory periodically by removing expired certificates. This can be useful for end entities such as Netscape Enterprise Server 3.x that rely on the presence or absence of the certificate for authentication purposes, or if you wish to ensure that only current, valid certificates can be found in the directory. This job also sends a summary of removed certificates to agents or administrators. Available for Certificate Manager only.
Mapper and Publisher Plug-in Modules
Mapper and publisher plug-in modules enable Certificate Management System to establish a connection with the configured repository and publish certificates and CRLs. For example, LDAP-related mapper and publisher plug-in modules enable Certificate Management System to function seamlessly with an LDAP-compliant directory, such as iPlanet Directory Server, that organizations typically use to maintain corporatewide data about user and group accounts and other network resources. You can set up Certificate Management System to automatically publish certificate information and CRLs to a directory. The advantage of publishing certificates and CRLs to the directory is multifold:
You can keep users' certificate-related information with the rest of the user information. This way, when you update the user information, the certificate-related information automatically gets updated. For example, when you delete a user entry, the security credentials of that user automatically gets deleted from the directory.
If you are using S/MIME-enabled clients (for example, Netscape Communicator), publishing all certificates to a central directory enables your users to import others' certificates from the global directory. Figure 1-3    Seamless integration with any LDAP-compliant directory
Seamless integration with any LDAP-compliant directory (see Figure 1-3) makes possible the following:
Corporate IS organizations can generate and manage certificates as an integral part of their user and group management. 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.
Plug-in module name
Maps the CA certificate to the CA's directory entry by formulating the entry's DN from components specified in the certificate's issuer name and attribute variable assertion (AVA) constants. Optionally, the plug-in can also create an entry for the CA in the directory.
Maps a certificate to a directory entry by formulating the entry's DN from components (such as CN, OU, O, and C) in the certificate's subject name and using it as the search DN to locate the entry in the directory.
Table 1-7 lists the publisher modules supported by Certificate Management System out of the box. Publisher modules help you configure a Certificate Manager to publish certificates and CRLs to the mapped directory entries, to files, or to the Online Certificate Status Manager.
Plug-in module name
Publishes or unpublishes a certificate to the caCertificate;binary attribute of the mapped directory entry as a DER encoded binary blob. Also converts the object class to a certificationAuthority if it's not one already; similarly, removes the certificationAuthority object class on unpublish if the CA has no other certificates.
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. For more information, see Chapter 16 "Setting Up Automated Notifications."
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.
A number of command-line utilities or tools are bundled with Certificate Management System. These tools are useful for troubleshooting any problems that you may encounter with Certificate Management System. The binaries for all the utilities are located in this directory: <server_root>/bin/cert/tools
For detailed information about these utilities, see CMS Command-Line Tools Guide.
CMS Software Development Kit (SDK) includes information that's useful for developing new plug-in modules and for customizing various aspects of Certificate Management System. During installation, files for CMS SDK are copied to this directory: <server_root>/cms_sdk/
Below is an overview of what's contained in the above directory:
CMS JDK, which includes Javadocs, Samples, and Tutorials for developing Java plug-ins:
Javadocscomplete javadoc specification of the CMS Application Programming Interface (API).
Samplessample source code of various plug-in modules that are included in Certificate Management System out-of-the-box. This source code has been included for reference purposes only, and is only used to demonstrate how a particular CMS feature was implemented. Since a sample represents the actual code currently present in Certificate Management System, it does not require to be recompiled. You will find examples for the authentication, jobs, listeners, mappers, passwords, policies, publishers, and servlets modules.
Tutorials"How To" tutorial to help demonstrate how you can create your own plug-in modules for Certificate Management System. Each tutorial includes sample Java source code, environment and build scripts for both UNIX and Windows NT, and a detailed "cookbook" describing how to build and install these plug-in modules. Additionally, if necessary, some tutorials may also contain sample configuration files. A tutorial has been included for authentication, job, listener, mapper, password, policy, publisher, and servlet modules.
White papers about HTTP-related abilities of Certificate Management System including "How to add extra parameters to request from the Manual approval page" and "The CMS 4.x Bulk Generation Interface Specification".
Entry Points for Various Types of Users
Certificate Management System provides entry points for various kinds of user interaction.
Figure 1-4    Entry points for different types of CMS users
As illustrated in Figure 1-4, the server provides three separate user entry points; each entry point addresses the needs of a specific user type. This is explained in Table 1-8.
This interface provides the general front end for end-entity interactions with the server. Through this interface, the Certificate Manager or Registration Manager serves the appropriate HTML forms for end-entity operations (the Data Recovery Manager and Online Certificate Status Manager do not have an end-entity interface). These include forms for certificate enrollment, retrieval, query, renewal, import, and revocation. For details, see End-Entity Services Interface.
This interface provides the general front end for agent interactions with the server. Through this interface, a Certificate Manager, Registration Manager, Data Recovery Manager, or Online Certificate Status Manager serves the appropriate HTML forms for agent tasks. For details, see Agent Services Interface.
The remote administration interface supports a GUI-based administration tool called iPlanet Console that provides the general administration and management interface for Certificate Management System. For details, see Chapter 9 "Administration Tasks and Tools."
Administrators can use this tool to perform day-to-day operational and managerial duties, such as changing the server configuration, stopping and restarting the server, requesting and installing certificates, managing resources (certificates and requests), and setting up privileged-user information and associated access controls.
Agent Services Interface
As an administrator, you can designate privileged users, called agents, for each subsystem. Agents are responsible for the day-to-day operation of requests from end entities. For details, see Agents.
To enable agents to accomplish their duties, Certificate Management System provides a set of HTML forms for Certificate Manager, Registration Manager, Data Recovery Manager, and Online Certificate Status Manager agents. Collectively, these forms are called the Agent Services interface.
Depending on the choices you made during installation, a combination of the following agent services will be installed:
Certificate Manager Agent Services The sections that follow give an overview of these interfaces. For a complete list of agent forms and output templates that come with Certificate Management System, see CMS Customization Guide.
For tasks associated with Agent Services interface, see CMS Agent's Guide. For information on locating this guide, see Where to Go for Related Information.
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.
Figure 1-5    Certificate Manager Agent Services interface
Using the default forms, a Certificate Manager agent can accomplish tasks such as these:
Listing deferred certificate requests from end entities and process them
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.
Figure 1-6    Registration Manager Agent Services interface
Using the default forms, a Registration Manager agent can list deferred certificate requests from end entities and process them.
Data Recovery Manager Agent Services
The Data Recovery Manager Agent Services interface enables a Data Recovery Manager agent to interact with the Data Recovery Manager (the server). Figure 1-7 shows the Data Recovery Manager Agent Services interface.
Figure 1-7    Data Recovery Manager Agent Services interface
Using the default forms, a Data Recovery Manager agent can search for and recover end users' encryption private keys from the key archive. (Key recovery requires authorization from key recovery agents; see Key Recovery Process.)
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-8    Online Certificate Status Manager Agent Services interface
Using the default forms, a Online Certificate Status Manager agent can perform tasks such as checking which CAs are currently configured to publish their CRLs to the Online Certificate Status Manager, identifying a Certificate Manager to the Online Certificate Status Manager, adding CRLs directly to the Online Certificate Status Manager, and viewing the status of OCSP service requests submitted by OCSP-compliant clients.
End-Entity Services Interface
Certificate Management System provides HTML forms for various entitiespeople, routers, servers, and othersthat use certificates to identify themselves and that need to be able to request certificate issuance and management operations. These forms, collectively identified as End-Entity Services Interface, use different protocols and life-cycle management procedures for different kinds of end entities. For example, the Certificate Manager provides separate certificate enrollment forms for clients such as Netscape Navigator 3.x, versions of Netscape Communicator later than 4.5, and Microsoft Internet Explorer. The reason for this is that end entities running Navigator 3.x and Communicator versions earlier than 4.5 present an enrollment form based on the use of the HTML tag KEYGEN to generate keys; end entities running Internet Explorer present a form based on PKCS #10, the RSA standard for certificate request syntax.
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.
Figure 1-9 shows the end-entity services interface of a Certificate Manager.
Figure 1-9    End-entity services interface
Note that the Data Recovery Manager and Online Certificate Status Manager do not provide end-entity interfaces because end entities do not directly interact with these servers. For a complete list of the end-entity formsfor enrollment, renewal, retrieval, revocation, and key recoverythat come with Certificate Management System, see CMS Customization Guide.
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.
Figure 1-10    CMS architecture
Public-Key Cryptography Standard (PKCS) #11 specifies an API used to communicate with devices that hold cryptographic information and perform cryptographic operations. Because it supports PKCS #11, Certificate Management System works with a wide range of hardware and software devices intended for such purposes.
One or more PKCS #11 modules must be available to any CMS subsystem instance. As shown in Figure 1-10, a PKCS #11 module (also called a cryptographic module or cryptographic service provider) manages cryptographic services such as encryption and decryption via the PKCS #11 interface. PKCS #11 modules can be thought of as drivers for cryptographic devices that can be implemented in either hardware or software. Netscape provides a built-in PKCS #11 module with Certificate Management System; see Installing Level 2 External Tokens.
A PKCS #11 module always has one or more slots, which can be implemented as physical hardware slots in some form of physical reader (for example, for smart cards) or as conceptual slots in software. Each slot for a PKCS #11 module can in turn contain a token, which is the hardware or software device that actually provides cryptographic services and optionally stores certificates and keys.
Netscape provides two built-in modules with Certificate Management System:
Default Netscape Internal PKCS #11 Module. This comes with two built-in tokens:
The Internal Crypto Services token performs all cryptographic operations, such as encryption, decryption, and hashing.
The Internal Key Storage token ("Certificate DB token" in Figure 1-10) handles all communication with the certificate and key database files (called certX.db and keyX.db, respectively, where X is a version number) that store certificates and keys.
FIPS 140-1 module. This module complies with the FIPS 140-1 government standard for implementations of cryptographic modules. Many products sold to the US government must comply with one or more of the FIPS standards. The FIPS 140-1 module includes a single, built-in FIPS 140-1 Certificate DB token (see Figure 1-10), which handles both cryptographic operations and communication with the certX.db and keyX.db files. Any PKCS #11 module can be used with Certificate Management System. The server uses a file called secmod.db to keep track of the modules that are available. You can modify this file with the Security Module Database Tool explained in the CMS Command-Line Tools Guide. For example, you need to modify secmod.db if you are installing hardware accelerators for use in signing operations.
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:
As shown in Figure 1-10, NSS communicates with PKCS #11 modules through the PKCS #11 interface and in turn provides the foundation for Java Security Services and higher Java layers.
JSS and the Java/JNI Layer
Java Security Services (JSS) provides a Java interface for security operations performed by NSS. JSS and higher levels of the Certificate Management System architecture are built with the Java Native Interface (JNI), which provides binary compatibility across different versions of the Java Virtual Machine (JVM). This design allows customized subsystem services to be compiled and built just once and run on a range of platforms.
Middleware/Java 2 Layers
A middleware layer above JSS and the Java/JNI layer provides a range of services required by the Registration Manager, Certificate Manager, Data Recovery Manager, and Online Certificate Status Manager. The middleware layer is based on Java 2.0, SDK 1.3.0, and it underlies both the manager subsystems and the APIs available to third-party developers for building custom authentication and policy modules. The default authentication and policy modules provided with Certificate Management System are built from the same Java classes.
Authentication and Policy Modules
The top layer of Figure 1-10 consists of authentication and policy modules. Several default modules ship with Certificate Management System; third parties can create their own custom modules using the APIs provided above the middleware and subsystem layers. Modules for all three subsystems work the same way and are interchangeable.
This section summarizes the standard message formats and protocols supported by Certificate Management System.
Certificate Management Formats and Protocols
Certificate Management System supports the following certificate management formats and protocols. For more details about the proposed PKIX standards listed here, see http://www.ietf.org/html.charters/pkix-charter.html(under Internet Drafts).
Certificate Enrollment Protocol (CEP). A certificate management protocol jointly developed by Cisco Systems and VeriSign, Inc. CEP is an early implementation of CMC (described later in this list). CEP specifies how a device communicates with a CA, including how to retrieve the CA's public key, how to enroll a device with the CA, and how to retrieve a CRL. CEP uses PKCS #7 and PKCS #10.
Certificate Request Message Format (CRMF). A message format used to convey a request for a certificate to a Registration Manager or Certificate Manager. A proposed standard from the Internet Engineering Task Force (IETF) PKIX working group.
Certificate Management Message Formats (CMMF). Message formats used to convey certificate requests and revocation requests from end entities to a Registration Manager or Certificate Manager and to send a variety of information to end entities. A proposed standard from the IETF PKIX working group. CMMF is subsumed by another proposed standard, CMC (next item).
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.
PKIX Certificate and CRL Profile (PKIX Part 1). The first part of the four-part standard under development by the IETF for a public-key infrastructure for the Internet. Part 1 deals with specifications for certificates and CRLs. Certificate Management System will support the other PKIX parts as they are finalized. For more information about PKIX Part 1, see ftp://ftp.isi.edu/in-notes/rfc2459.txt.
Security and Directory Protocols
Certificate Management System supports the following security and directory protocols:
FIPS PUBS 140-1. Federal Information Standards Publications (FIPS PUBS) 140-1 is a US government standard for implementations of cryptographic modulesthat is, hardware or software that encrypts and decrypts data or performs other cryptographic operations (such as creating or verifying digital signatures).
KEYGEN tag. An HTML tag supported by Netscape browsers that generates a key pair for use with a certificate. For more information, see http://www.netscape.com/eng/security/comm4-keygen.html.
Lightweight Directory Access Protocol (LDAP) v2, v3. A directory service protocol designed to run over TCP/IP and across multiple platforms. LDAP is a simplified version of Directory Access Protocol (DAP), used to access X.500 directories. LDAP is under IETF change control and has evolved to meet Internet requirements.
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.
Previous Contents Index Next
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.
Last Updated October 07, 2002