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 System (CMS), a highly configurable set of software components and tools for creating, deploying, and managing certificates. Based on open standards for certificate management, Certificate Management System leverages Netscape Directory Server and Netscape Console to provide a complete, scalable, high-performance certificate management solution for extranets and intranets.

Whether you are looking for a security solution for your enterprise or setting up an independent certificate authority (CA) service, Certificate Management System offers a robust, customizable, and scalable foundation for your public-key infrastructure (PKI).

The chapter has the following sections:

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 RSA public-key algorithm for signing and encryption, DSA public-key algorithm for signing, and MD2, MD5, and SHA-1 for hashing.

  • Supports signature key lengths of up to 1024 bits (DSA) and 4096 (RSA) on both hardware and software tokens. For details, see Appendix C "Export Control Information."

  • Supports multiple message formats, such as KEYGEN/SPAC, CRMF/CMMF, CRS/CEP/SCEP, and PKCS #10 and CMC for certificate requests. All requests are delivered to Certificate Management System over HTTP or HTTPS; in the case of CRS/CEP/SCEP protocol, the delivery method is always over HTTP. For a description of the acronyms, see "Standards Summary".

  • 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.

  • 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."

  • Publishes certificates and CRLs to a flat file for importing into other resources. For example, the sample code for Flat File CRL and certificate publisher can be customized to store certificates and CRLs in an Oracle RDBMSTM. For more information, see Chapter 20 "Publishing Certificates and CRLs to a File."

  • Publishes CRLs to an online validation authority (or OCSP responder), enabling real-time verification of certificates by OCSP-compliant clients. For more information, see Chapter 21 "Setting Up an OCSP Responder."


Separate subsystems for certificate and key operations

Certificate Management System includes four servers, the Certificate Manager, Registration Manager, Data Recovery Manager, and Online Certificate Status Manager.

  • The Certificate Manager functions as the certificate authority (CA); it is the entity named in the issuer field of a certificate. The Certificate Manager can sign and revoke certificates and generate CRLs. It can accept certificate requests directly from end entities and via Registration Managers to which it has delegated certain certificate management functions, such as authentication of an end entity. The Certificate Manager also maintains a database of issued certificates so that it can track renewal, expiration, and revocation.

  • The Registration Manager is an optional component in the PKI; it is a subordinate server to which a Certificate Manager can delegate some certificate management functions. For example, a Registration Manager may act as a front end to a Certificate Manager, performing tasks such as end-entity authentication and formulation of the certificate request for the Certificate Manager.

  • The Data Recovery Manager is an optional component in the PKI. It provides key archival and recovery services for end users' encryption private keys.

  • The Online Certificate Status Manager is an optional, but important component in the PKI. It enables real-time verification of certificates issued by one or more Certificate Managers.

For an overview of these subsystems, see "CMS Subsystems or Managers".


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. For a complete list of vendors, check this site:

http://www.iplanet.com/products/infrastructure/dir_security/cert_sys/index.html

You can configure the server to use different PKCS #11 modules to generate and store key pairs (and certificates) for the Certificate Manager, Registration Manager, and Data Recovery Manager. Using hardware for key storage (especially for Certificate Manager and Data Recovery Manager key pairs) reduces the risk of key compromise, because hardware tokens don't reveal keys or provide means for them to be revealed, once the keys are generated in the hardware. Note that PKCS#11 hardware devices also provide key backup and recovery features for backup and recovery of the key material stored on the hardware token. Be sure to refer to the PKCS #11 vendor documentation on this subject.

For information on configuring Certificate Management System to use hardware tokens for generating and storing its key pairs and certificates, see "Tokens for Storing CMS Keys and Certificates".


Support for Netscape client and server products; client independence for non-Netscape products

Certificates issued by Certificate Management System work with existing Netscape client and server products that support SSL. The certificates also work (out of the box) with a variety of non-Netscape, standards-compliant applications. For a complete list of these products, see the information available at this URL:

http://www.iplanet.com/products/infrastructure/dir_security/cert_sys/index.html


Highly scalable certificate data store

Certificate Management System uses a highly scalable, high-performance certificate storage facility—a preconfigured version of Netscape Directory Server 4.x that's automatically installed with Certificate Management System—enabling you to issue and manage a large number of certificates. For more information, see Chapter 12 "Setting Up Internal Database."


Flexible end-entity registration services framework

The registration services framework for end entities includes the most commonly expected PKI features: manual, directory-based, directory- and PIN-based, NIS-based, and portal enrollments; certificate-authenticated renewals and revocations (based on SSL client authentication); certificate life-cycle operations that include automated certificate renewal and expiration notifications. These features are available out of the box for both Certificate Manager and Registration Manager.

For information on enrollment, renewal, and revocation operations, see Chapter 15 "Setting Up End-User Authentication." For information on automated notifications, see Chapter 16 "Setting Up Automated Notifications."


Built-in plug-in modules for authentication, policy, job scheduling, and publishing

Certificate Management System simplifies the details involved in certificate issuance and management with its built-in, configurable, and extensible authentication, policy, job scheduling, and publishing components. Each of these components come with a set of default modules that enable you to configure Certificate Management System for your PKI requirements. For example, you can configure policy modules to determine the outcome of operations, such as certificate formulation (extensions, signing algorithm, key length, validity period, and so on), issuance, renewal, and revocation.

For information about all plug-in modules (such as authentication, job, policy, and publishing modules) that are provided for Certificate Management System, see "Plug-in Modules".


Single administration point achieved via LDAP-compliant directory integration

Certificate Management System works seamlessly with any LDAP-compliant directory services for easy distribution of certificates and CRLs, thus lowering the cost of information management. The shared directory architecture enables you to manage users, including their security credentials and other shared data, at a single place. Certificate Management System can do the following:

  • Authenticate users based on the information that exists in the LDAP directory.

  • Integrate certificate-related information with the user and group information that exists in the LDAP directory.

  • Automatically publish certificates (when they are issued) and CRLs (when created or on a periodic basis) to the LDAP directory, from which they can be easily distributed to clients and servers.

  • Automatically delete expired and revoked certificates from the directory.

  • Connect to the directory using password-based (basic) or certificate-based (in the context of LDAP over SSL) authentication using a digital certificate.


Supports many methods for verifying the revocation status of certificates

Revocation status of a certificate can be made available to PKI entities by publishing the CRL to various repositories. To aid you in this process, the Certificate Manager supports publishing of CRLs to the following repositories:

Applications in your enterprise may use any of these repositories to verify the revocation status of a certificate.


Supports certificate generation for dual key pairs—separate key pairs for signing and encrypting mail messages

To support separate key pairs for signing and encrypting data, Certificate Management System supports generation of dual certificates for end entities capable of generating dual key pairs. If a client makes a certificate request for dual key pairs, the server issues two separate certificates.

For more information, see "Clients That Can Generate Dual Key Pairs".


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 unavailable—as, for instance, in the following cases:

  • An employee loses an encryption private key (for example after a disk crash or by forgetting the password to the key file) and is unable to read previously encrypted data.

  • An employee leaves the company, and company officials need to perform an audit that requires gaining access to the employee's encrypted data.

For more information, see Chapter 22 "Setting Up Key Archival and Recovery."


Encrypted key storage and password-protected recovery

Certificate Management System stores users' encryption private keys in an encrypted key repository. Keys can be retrieved only by authorized key recovery agents. The key repository is encrypted using a Data Recovery Manager's storage private key, which is protected with one or more recovery agents' passwords. Only these designated recovery agents can authorize and initiate a key recovery process.

For more information, see "Where the Keys are Stored".


Extensive audit and log records for detection of tampering

Certificate Management System maintains audit trails for all events—certificate requests and issuance, revocation requests, CRL publication, and so on. These audit records enable you to detect any unauthorized access or activity. In addition, extensive system and error logs record various events and system errors so that you can monitor and debug the system. All log records are stored in your local file system for quick and easy retrieval.

For more information, see Chapter 23 "Managing CMS Logs."


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:

  • Authentication—for authenticating end entities during certificate enrollment.

  • Policy—for setting the rules applied by the individual subsystems.

  • Jobs—for PKI-related jobs that run with the individual systems.

  • Mapper and publisher classes—for publishing certificates and CRLs to an LDAP-compliant directory, flat file, and an OCSP responder.

For information about writing custom plug-ins, see "CMS SDK".

For information on customizing end-entity and agent interfaces (HTML forms and templates), see CMS Customization Guide.


Easy upgrade from previous versions of Certificate Management System

Certificate Management System provides an easy upgrade path from its previous version. For more information, see "Upgrading From a Previous CMS Installation".


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".



System Overview


Certificate Management System provides a highly scalable, easily deployable certificate infrastructure for supporting encryption, authentication, tamper detection, and digital signatures in networked communications. It is based on open standards and protocols that include the following:

  • Public-Key Cryptography Standard (PKCS) #11

  • Secure Sockets Layer (SSL)

  • Lightweight Directory Access Protocol (LDAP)

  • Online Certificate Status Protocol (OCSP)

  • Wireless Transport Layer Security (wTLS)

  • X.509 certificate formats recommended by the International Telecommunications Union (ITU)

  • Public-Key Infrastructure (X.509) (PKIX) standards proposed by the PKIX working group of the Internet Engineering Task Force (IETF).

  • Federal Information Standards Publications (FIPS PUBS) 140-1.

Certificate Management System leverages Netscape Directory Server and Netscape Console to provide a complete, scalable, high-performance certificate management solution for extranets and intranets. Its strong support for existing and evolving standards makes Certificate Management System especially well-suited for large heterogeneous extranets that must support a variety of platforms, client and server software, hardware devices such as routers and hardware tokens, virtual private network (VPN) implementations, existing intranet security systems, wireless applications, and so on. It can be customized and configured to fit widely varying deployment scenarios, permitting rapid integration with existing client and server software, customer databases, security systems, and authentication procedures.

You can use Certificate Management System to set up and manage your own public-key infrastructure or to deploy a public certification authority. Certificate Management System meets the needs of an enterprise, leveraging your existing enterprise resources and services, and will grow with your business needs to meet the demand of Internet-scale deployments.

With Certificate Management System, you can do the following operations:

  • Process certificate requests from various end entities, such as web browsers, servers, routers, and virtual private network (VPN) clients, and issue certificates that conform to X.509 version 3 standard. The server can also process certificate requests from wireless applications and issue certificates that conform to wTLS standard.

  • Employ specific authentication methods for end-entity certificate enrollment, renewal, and revocation.

  • Specify policy restrictions on certificate-related operations, such as certificate formulation, issuance, renewal, and revocation.

  • Specify policy restrictions on key-related operations, such as archival and recovery of end users' encryption private keys.

  • Revoke certificates, and maintain and publish a list of revoked certificates.

  • Enable real-time verification of certificates by OCSP-compliant clients.

  • Search for certificates issued by the server.

  • Set up hierarchies of certificate authorities—multiple subordinate CAs chained up to a root CA. (Certificate Management System can also chain under popular public CAs that are already pretrust in popular client and server products.)

  • Publish certificate information to an LDAP-compliant directory, such as Netscape Directory Server, and maintain this information. Publish the list of revoked certificates (CRLs) to an LDAP-compliant directory, a flat file, and an online-validation authority.

This chapter describes the basic features and capabilities of Certificate Management System. Chapter 3 "Default Demo Installation" describes how to install a simple demo that uses some of these features.


Public-Key Infrastructure

The standards and services that facilitate the use of public-key cryptography and X.509 version 3 certificates in a networked environment are collectively called public-key infrastructure (PKI). In any PKI, a certificate authority (CA) is a trusted entity that issues, renews, and revokes certificates. An end entity (EE) is a person, router, server, or other entity that uses a certificate to identify itself.

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".


Certificate Manager

A Certificate Manager functions as a root or subordinate certificate authority. This subsystem issues, renews, and revokes certificates, generates certificate revocation lists (CRLs), and can publish certificates to an LDAP directory and a file, and CRLs to an LDAP directory, a file, and an OCSP responder. The Certificate Manager can be configured to accept requests from end entities, Registration Managers, or both, and can process requests either manually (that is, with the aid of a person, identified in this document as Certificate Manager agent) or automatically (based entirely on customizable policies and procedures).

When set up to work with a separate Registration Manager, the Certificate Manager processes requests and returns the signed certificates to the Registration Manager for distribution to the end entities. (For an overview of the role of certificate authorities and related concepts of public-key cryptography, see Appendix D of Managing Servers with Netscape Console.

Basic capabilities of the Certificate Manager (as distinct from the Registration Manager) include the following:

  • Can be configured as either a root CA or a subordinate CA

  • Can accept certificate requests from end entities and Registration Managers

  • Can issue end-entity, Registration Manager, and Certificate Manager certificates

  • Can issue single key-pair or dual key-pair certificates

  • Can notify users and administrators of approaching certificate expiration

  • Can notify agents of requests pending in the queue

  • Can renew certificates

  • Can revoke certificates

  • Can publish certificates to an LDAP directory (LDAP 2.0 or higher) and to files

  • Can publish CRLs to an LDAP directory (LDAP 2.0 or higher), a file, and the Online Certificate Status Manager.

Note that the publishing tasks can be performed by the Certificate Manager only. The Certificate Manager also has a built-in OCSP service, enabling OCSP-compliant clients to directly query the Certificate Manager about the revocation status of a certificate that it has issued. For example, if you plan to deploy a PKI comprising a master CA and many clone CAs, you can enable the OCSP service of the master CA. This way, all clients in your PKI setup can verify the revocation status of a certificate by querying the master Certificate Manager.

The Certificate Manager can issue certificates with the following characteristics:

  • X.509 version 3

  • Internationalized subject names

  • Customized components in subject names

  • Customized extensions

The Certificate Manager supports the following signing algorithms for both certificates and CRLs: RSA with MD2, RSA with MD5, RSA with SHA-1, and DSA with SHA-1.

The Certificate Manager can issue X.509 v1 or v2 CRLs. A CRL can be automatically updated whenever a certificate is revoked or at specified intervals.

CRL extensions supported include the following:

  • Authority key identifier. Identifies the public key to be used to validate the digital signature on the certificate.

  • CRL number. A sequential number unique to each CRL issued by a given CRL issuer. This number allows CRL-checking software to ensure that all previous CRLs have been received.

  • Issuer alternative name. Associates the CRL issuer with an Internet style identity, such as Internet electronic mail address, a DNS name, an IP address, or a uniform resource indicator (URI).

  • Issuing distribution point. The URL at which this CRL is maintained.

The Delta CRL indicator extension is not supported.

CRL entry extensions supported include the following:

  • Hold instruction code. Indicates the action to be taken for an entry that appears on the CRL because it has been placed on hold.

  • Reason code. Indicates the reason the certificate was revoked.

  • Invalidity date. Indicates the date on which the private key corresponding to the public key certified by the certificate was (or is suspected to have been) compromised.


Registration Manager

A Registration Manager is an optional component in the PKI, enabling you to separate the registration process from the certificate-signing process. A Registration Manager is typically installed on a different machine from the Certificate Manager that it serves. During installation, you connect the Registration Manager to a Certificate Manager and configure the Certificate Manager to trust the Registration Manager. Once the trust is established, the Registration Manager can perform a subset of the end-entity tasks performed by the Certificate Manager, such as enrollment or renewal, on behalf of the Certificate Manager. A Registration Manager cannot issue or revoke certificates by itself; instead, it evaluates end-entity requests and forwards them to a Certificate Manager for action, such as the issuing of a certificate. The Certificate Manager processes the requests and issues the certificates. The Registration Manager then distributes the certificates to the end entities.

Note that you can run multiple Registration Managers remotely, all reporting to a single CA—a Certificate Manager—to verify user identities and process certificate signing requests. The Certificate Manager's ability to support multiple Registration Managers makes it more scalable and also adds an extra layer of security for the CA. For example, you can set a policy that requires all clients to go through a remote Registration Manager, and then have the remote Registration Manager route all client requests to the Certificate Manager located inside a firewall.

The Registration Manager is designed to handle certificate life-cycle management tasks—that is, the tasks required to maintain a certificate throughout its life cycle, including the following:

  • Enrolling end entities (initial authentication and initiation to the PKI)

  • Enforcing policies such as request validation requirements, authentication requirements, and certificate formulation

  • Distributing issued certificates

  • Coordinating certificate renewal

  • Coordinating storage of end users' private encryption keys with a Data Recovery Manager

A Registration Manager's default forms for end-entity interactions can be used as is or customized. For more information about default Registration Manager forms, see "End Entities and Life-Cycle Management".


Data Recovery Manager

A Data Recovery Manager performs the long-term archival and recovery of private encryption keys for end entities. A Certificate Manager or Registration Manager can be configured to archive end entities' private encryption keys with a Data Recovery Manager as part of the process of issuing new certificates. End-entities do not have direct access to the Data Recovery Manager.

The Data Recovery Manager is useful only if end entities are encrypting data (using applications such as S/MIME email) that the organization may need to recover someday. It can be used only with client software that supports dual key pairs—that is, two separate key pairs, one for encryption and one for digital signatures. This service is available in newer clients only; for example, Communicator versions 4.7x (with Personal Security Manager installed) and Netscape 6 support generation of dual key pairs. Dual key pairs allow an end entity to get a new signing certificate and signing key pair without changing the encryption certificate or encryption key pair.

Note that the Data Recovery Manager archives encryption keys. It does not archive signing keys, since such archival would undermine nonrepudiation properties of dual-key certificates. This crucial element of a PKI allows an authorized key-recovery agent to recover an encryption key that has been lost or corrupted without changing the signing certificate or signing key pair. For example, if agents or administrators are authorized to perform key recover operations, they can recover encryption keys for employees who have left the company or who are unavailable for some other reason. In either case, once the encryption key has been recovered, the user or administrator can use it to decrypt any data (such as saved email messages) that was encrypted with that key.

The Data Recovery Manager uses two special key pairs in the process of archiving an end entity's encryption key: a transport key pair (and certificate) and a storage key pair. The end entity must also have two key pairs: a signing key pair and an encryption key pair. The roles of all these keys are summarized in Table 1-1.


Table 1-1    Key pairs used by end entities and key pairs used by the Data Recovery Manager  

End-entity key pairs

Data Recovery Manager key pairs

Signing key pair

Encryption key pair

Transport key pair

Storage key pair

Public signing key: used by recipients to validate digital signature  

Public encryption key: used by others to encrypt messages sent to owner  

Public transport key: used by end-entity software to encrypt the end entity's private encryption key before sending it to Certificate Management System for storage.  

Public storage key: used to decrypt an end entity's stored private encryption key after m of n recovery agents have authorized the recovery operation.  

Private signing key: used by owner to digitally sign messages  

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 end entity's private encryption key  

Private storage key: used to encrypt an end entity's private encryption key for long-term storage  


Online Certificate Status Manager

A Online Certificate Status Manager performs the task of an online certificate validation authority, by enabling OCSP-compliant clients to do real-time verification of certificates. The Online Certificate Status Manager can receive CRLs from multiple Certificate Managers and clients can query the Online Certificate Status Manager for the revocation status of certificates issued by all these Certificate Managers. For example, if you plan to create a CA hierarchy comprising a root CA and many subordinate CAs, you can configure each of these CAs to publish their CRLs to the Online Certificate Status Manager. This way, all clients in your PKI deployment can verify the revocation status of a certificate by querying the Online Certificate Status Manager.

Note that an online certificate-validation authority is often referred to as OCSP responder.


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.

  • KEYGEN tag. An HTML tag supported by Netscape browsers that generates a key pair stored in the client and formats an HTTP GET string to send off to a CA as part of the enrollment process.

  • Public-Key Cryptography Standard (PKCS) #7. An encrypted data and message format developed by RSA Data Security to represent digital signatures, certificate chains, and encrypted data. This format is used to deliver certificates to end entities.

  • Public-Key Cryptography Standard (PKCS) #10. A message format developed by RSA Data Security for certificate requests. This format is supported by many server products and by Microsoft Internet Explorer.

These are the standard transport methods used for all of the data formats described above:

  • Hypertext Transport Protocol (HTTP) and Hypertext Transport Protocol Secure (HTTPS). Protocols used to communicate with web servers.

For more information about end-entity data formats and protocols used by Certificate Management System, see End Entities and Life-Cycle Management 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 HTTPS—that 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.

  1. After the user completes and submits an enrollment form, the end entity generates dual key pairs and sends two certificate requests to the Registration Manager, which detects a request for key archival and requests the private encryption key from the end entity. The end entity then encrypts (or "wraps") its newly minted private encryption key with the Data Recovery Manager's public transport key (obtained from a copy of the transport certificate embedded in the enrollment form) and sends the wrapped private key to the Registration Manager.

  2. The Registration Manager sends the end entity's wrapped private encryption key to the Data Recovery Manager as part of a key storage request (which also includes the end entity's public encryption key).

  3. The Data Recovery Manager uses its private transport key to decrypt the end entity's private encryption key. After confirming that the private encryption key corresponds to the end entity's public encryption key, the Data Recovery Manager encrypts the private encryption key with its private storage key and stores the private encryption key in the CMS internal database.

  4. The Data Recovery Manager signs a proof-of-archival token with its private transport key and sends the token to the Registration Manager.

  5. The Registration Manager verifies the token and sends the certificate requests on to the Certificate Manager.

  6. The Certificate Manager issues the signing and encryption certificates and sends them back to the Registration Manager.

  7. The Registration Manager delivers the certificates to the end entity.

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 Netscape Directory Server (version 4.x) installed transparently at the time of CMS installation. In this guide, the Directory Server instance used by a subsystem for storing its data is called an internal database. For example, the Certificate Manager uses its internal database for storing certificates and certificate requests; the Registration Manager uses its internal database for storing certificate requests (but not certificates, which are stored by the Certificate Manager only); the Data Recovery Manager uses its internal database for storing archived encryption keys; and the Online Certificate Status Manager uses its internal database for storing CRLs published by Certificate Managers. Using Netscape Directory Server as an internal database allows Certificate Management System to leverage the scalability and industry-leading performance of Directory Server, replacing the Relational Database Management System (RDBMS) used in Certificate Server 1.0x.

Some deployments require installation of two subsystems in a single CMS instance on a single machine, for example, Certificate Manager and Data Recovery Manager, Registration Manager and Data Recovery Manager, or Data Recovery Manager and Online Certificate Status Manager. In these dual-manager installations, both subsystems use the same internal database for storing data and communication between the two subsystems takes place internally (that is, within the same running process) rather than via HTTPS. (Note that a Certificate Manager performs all Registration Manager tasks, including end-entity interactions. Registration Managers are required only for remote or delegated administration of the CA.)

Throughout this guide, the term CMS administrator describes the person who installs and configures one or more managers and sets up privileges for the users who manage those subsystems. The users who manage day-to-day interactions of end entities with each manager, as well as other aspects of the PKI, are called CMS agents collectively, or the Certificate Manager agent, Registration Manager agent, and Data Recovery Manager agent, and Online Certificate Status Manager agent. The role of an agent is to approve, defer, or reject requests using Agent Services web pages served by the CMS manager for which that agent has been assigned the necessary privileges. The privileges of each agent can be confined to a specific manager or can include several different managers.

System administrators set up CMS subsystems through Netscape Console, and agents manage end-entity requests and certificates through HTML pages. For more information about facilities available to administrators and agents, see Chapter 13 "Managing Privileged Users and Groups."


Plug-in Modules

Certificate Management System includes a plug-in architecture for code modules that authenticate user identities and code modules that enforce policies.

Each type of request from an end user—for certificate enrollment, renewal, revocation, or retrieval—is handled by a different servlet, a piece of Java code designed for that kind of request. Each servlet processes the request using the appropriate protocols (such as the KEYGEN HTML tag or PKCS #10) for each type of end entity. Additional servlets control interactions with administrators and agents.

The sections that follow provide an overview of the plug-in modules provided with Certificate Management System. For detailed information about all the plug-in modules, refer to CMS Plug-ins Guide.


Authentication Plug-in Modules

An authentication module is a set of rules (implemented as a Java class) for authenticating an end user, server, or other entity that needs to interact with a CMS manager. (Similar rules are used to authenticate agents and administrators, but they are built into Certificate Management System instead of being implemented as plug-in modules.) With a typical end-user enrollment, the user supplies the information requested by the Registration Manager on an enrollment form, and then the servlet uses an authentication module specified within the form to validate the information and authenticate the user's identity. This simple input value makes it possible to use custom authentication for any form without changing the corresponding servlet code.

Both the Certificate Manager and Registration Manager support client SSL certificate-based authentication (for both agents and end entities). Netscape Console supports user ID- and password-based authentication for administrators. Registration Managers and Certificate Managers can also be configured to use any of the authentication modules provided for authenticating end-users during certificate enrollments; see Table 1-2.


Table 1-2    Authentication plug-in modules for end-user enrollments  

Plug-in module name

Description

Manual authentication  

Requires manual approval by an agent. This authentication module is hardwired; you cannot configure it. This ensures that when the server receives requests that lack authentication credentials, it sends them to the request queue for agent approval. It also means that if you don't configure Certificate Management System for any other authentication mechanism, the server automatically sends all certificate-related requests to a queue where they await agent approval.  

Directory-based authentication  

Checks a user's name and password against the user's entry in a specified directory and uses the DN for that entry to formulate the subject name for the certificate.  

Directory-based PIN authentication  

Checks a user's name, password, and a special one-time PIN against the user's entry in a specified directory and uses the DN for that entry to formulate the subject name for the certificate. The PIN is stored in salted and hashed form, and is removed after being used once to authenticate a user during enrollment.  

NIS-based authentication  

Authenticates end users based on their user IDs and passwords stored in a NIS server. Optionally, uses an LDAP directory for formulating certificate subject names.  

Portal-style authentication  

Checks that a user's name is unique in an LDAP directory.  

When you configure a Registration Manager or Certificate Manager an authentication module, you can specify how the DN should be used to formulate the subject name. As a result, neither the user nor the agent needs to figure out or enter the subject name—its formulation is entirely automated.

You can also write custom authentication modules, for example to authenticate end entities by using existing customer databases or security systems.

Tutorials and sample code provided as a part of CMS software development kit (SDK) demonstrate how to write a custom authentication module. For details, see section "CMS SDK".

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.

  • A validity constraints policy checks that the certificate validity period falls within a specified period, and it rejects, defers, or adjusts the validity period in the request accordingly.

  • An extensions policy checks that a request includes a specified extension and adds the extension if it's missing.

For an introduction to the role of policy modules in the enrollment process, see Authentication and Policy Modules.

Certificate Management System supports the following constraints-specific policy modules out of the box. These policies establish rules or constraints that Certificate Management System must use to evaluate an incoming request. They can be used with either a Certificate Manager or a Registration Manager.


Table 1-3    Policy plug-in modules for checking and formulating certificate contents  

Plug-in module name

Description

AttributePresentConstraints  

Rejects a request if an LDAP attribute is not present in the enrolling user's directory entry or if the attribute does not have a specified value.  

DSAKeyConstraints  

Allows the server to certify only DSA keys of specified lengths.  

IssuerConstraints  

Allows the server to check for certificates that have been issued by a particular CA.  

KeyAlgorithmConstraints  

Allows the server to certify only those keys that are generated using one of the specified algorithms, such as RSA or DSA.  

RenewalConstraints  

Allows or rejects requests for renewal of expired certificates.  

RenewalValidityConstraints  

Enforces the number of days before which a currently active certificate can be renewed and a new validity period for the renewed certificate.  

RevocationConstraints  

Allows or rejects requests for revocation of expired certificates.  

RSAKeyConstraints  

Allows the server to certify only RSA keys of specified lengths.  

SigningAlgorithmConstraints  

Allows the server to specify the signature algorithm to be used by the CA (a Certificate Manager) to sign certificates.  

SubCANameConstraints  

Allows the server to check for issuer name uniqueness and prevents issuance of multiple subordinate CA certificates with same issuer names.  

UniqueSubjectNameConstraints  

Allows the server to check for certificate subject name uniqueness and prevents issuance of multiple certificates with same subject names.  

ValidityConstraints  

Causes the server to check whether the validity period of a certificate falls within a specified period.  

Certificate Management System supports the following policy modules out of the box for formulating certificate extensions. They can be used with either a Certificate Manager or a Registration Manager.


Table 1-4    Policy plug-in modules for setting extensions in certificates  

Plug-in module name

Description

AuthInfoAccessExt  

Adds the Authority Information Access extension to certificates. The extension specifies how the application validating the certificate can access information, such as on-line validation services and CA policy statements, about the CA that has issued the certificate in which the extension appears.  

AuthorityKeyIdentifierExt  

Adds the Authority Key Identifier extension to certificates of a specified type. The Authority Key Identifier extension identifies the public key corresponding to the private key used to sign a certificate. This extension is useful when an issuer has multiple signing keys (for example, due to CA certificate renewal).  

BasicConstraintsExt  

Adds the Basic Constraints extension to certificates of a specified type. This extension is used during the certificate chain verification process to identify CA certificates and to apply certificate chain path length constraints.  

CertificatePoliciesExt  

Adds the Certificate Policies extension to certificates. The extension contains a sequence of one or more policy statements, each indicating the policy under which the certificate has been issued and identifying the purposes for which the certificate may be used.  

CertificateRenewalWindowExt  

Adds the Certificate Renewal Window extension to certificates. The extension specifies how to renew a certificate automatically and when automatic renewal should be attempted.  

CertificateScopeOfUseExt  

Adds the Certificate Scope of Use extension to SSL client certificates. This extension specifies Internet addresses where the certificate can be presented for SSL client authentication. This restriction prevents any private information that might be contained in the certificate from being released to servers not explicitly contained in the scope of use.  

CRLDistributionPointsExt  

Adds the CRL Distribution Points extension to certificates. This extension identifies one or more locations from where the application that is validating the certificate can obtain the CRL information.  

ExtendedKeyUsageExt  

Adds the Extended Key Usage extension to certificates. The extension identifies one or more purposes—in addition to or in place of the basic purposes indicated in the key usage extension—for which the certified public key may be used.  

GenericASN1Ext  

Adds ASN.1 type custom extension to certificates. This policy enables you to configure Certificate Management System to add custom extensions to certificates.  

IssuerAltNameExt  

Adds the Issuer Alternative Name extension to certificates. This extension enables binding of or associating Internet style identities, such as Internet electronic mail address, a DNS name, an IP address, and a uniform resource indicator (URI), with the certificate issuer.  

KeyUsageExt  

Adds the Key Usage extension to certificates of a specified type. This extension defines the purpose of the key contained in the certificate. The Key Usage, Extended Key Usage, Basic Constraints, and Netscape Certificate Type extensions act together to specify the purposes for which a certificate can be used.  

NameConstraintsExt  

Adds the Name Constraints extension to certificates. The extension is used in CA certificates to indicate a name space within which subject names or subject alternative names in subsequent certificates in a certification path or chain should be located.  

NSCCommentExt  

Adds the Netscape Certificate Comment extension to certificates. The extension can be used to include textual comments in certificates.  

NSCertTypeExt  

Adds the Netscape Certificate Type extension to certificates of a specified type. This extension can be used to limit the purposes for which a certificate can be used. It has been replaced by the X.509 v3 extensions extKeyUsage and basicConstraints, but must still be supported in deployments that include Navigator 3.x clients.  

OCSPNoCheckExt  

Adds the OCSP No Check extension to certificates. The extension, which should be used in OCSP responder certificates only, indicates how OCSP-compliant applications can verify the revocation status of the certificate an authorized OCSP responder uses to sign OCSP responses.  

PolicyConstraintsExt  

Adds the Policy Constraints extension to certificates. The extension, which can be used in CA certificates only, constrains path validation in two ways. It can be used to prohibit policy mapping or to require that each certificate in a path contain an acceptable policy identifier.  

PolicyMappingsExt  

Adds the Policy Mappings extension to certificates. The extension lists one or more pairs of OIDs, each pair identifying two policy statements of two CAs. The pairing indicates that the corresponding policies of one CA are equivalent to policies of another CA.  

PrivateKeyUsagePeriodExt  

Adds the Private Key Usage Period extension to certificates. The extension allows the certificate issuer to specify a different validity period for the private key than the one specified for the corresponding certificate.  

RemoveBasicConstraintsExt  

Detects and removes the Basic Constraints extension in certificate requests.  

SubjectAltNameExt  

Adds the Subject Alternative Name extension to certificates of a specified type. This extension includes one or more alternative (non-X.500) names for the identity bound by the CA to the certified public key. It may be used in addition to the certificate's subject name or as a replacement for it.  

SubjectDirectoryAttributesExt  

Adds a Subject Directory Attributes extension to certificates. The extension is used to specify any desired directory attribute values for the subject of the certificate.  

SubjectKeyIdentifierExt  

Adds the Subject Key Identifier extension to certificates of a specified type. This extension identifies the public key certified by this certificate. It provides a way of distinguishing public keys if more than one is available for a given subject name, for example after the certificate has been renewed with a new key.  

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".

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.


Table 1-5    Plug-in modules for schedulable jobs  

Plug-in module name

Description

Renewal notification  

Notifies end entities by email that their certificates are about to expire and must be renewed. This job also sends a summary of such notices to agents. Available for Certificate Manager only.  

Request in queue  

Notifies agents at regular intervals of the state of the request queue. Alternatively, an event-driven notification can be sent whenever a request has been added to the request queue; see the next section for details. Available for Registration Manager or Certificate Manager.  

Directory expiration update  

Updates a specified LDAP publishing directory periodically by removing expired certificates. This can be useful for end entities such as Netscape Enterprise Server 3.x that rely on the presence or absence of the certificate for authentication purposes, or if you wish to ensure that only current, valid certificates can be found in the directory. This job also sends a summary of removed certificates to agents or administrators. Available for Certificate Manager only.  


Mapper and Publisher Plug-in Modules

Mapper and publisher plug-in modules enable Certificate Management System to establish a connection with the configured repository and publish certificates and CRLs. For example, LDAP-related mapper and publisher plug-in modules enable Certificate Management System to function seamlessly with an LDAP-compliant directory, such as Netscape Directory Server, that organizations typically use to maintain corporatewide data about user and group accounts and other network resources. You can set up Certificate Management System to automatically publish certificate information and CRLs to a directory. The advantage of publishing certificates and CRLs to the directory is multifold:

  • You can keep users' certificate-related information with the rest of the user information. This way, when you update the user information, the certificate-related information automatically gets updated. For example, when you delete a user entry, the security credentials of that user automatically gets deleted from the directory.

  • If you are using S/MIME-enabled clients (for example, Netscape Communicator), publishing all certificates to a central directory enables your users to import others' certificates from the global directory.

Figure 1-3    Seamless integration with any LDAP-compliant directory


Seamless integration with any LDAP-compliant directory (see Figure 1-3) makes possible the following:

  • Corporate IS organizations can generate and manage certificates as an integral part of their user and group management.

  • Independent CAs can issue and manage certificates to their users listed in any LDAP-compliant directory.

For more information on setting up Certificate Management System to publish certificates and CRLs, see Chapter 19 through Chapter 21.

Table 1-6 lists the mapper modules supported by Certificate Management System out of the box. Mapper modules help you configure a Certificate Manager to use specific rules to map or locate a specific entry, such as a CA's entry or an end-entity's entry, in a specified LDAP directory; once the correct entry is located, the server publishes the certificate or CRL to the correct attribute in the entry using a publisher module (explained later in this section). Because it's not required to map entries in a file and in an online validation authority, no mapper modules are provided for mapping objects in a file or a Online Certificate Status Manager.


Table 1-6    Default mapper plug-in modules for mapping certificates and CRLs  

Plug-in module name

Function

LdapCaSimpleMap  

Maps the CA certificate to the CA's directory entry by formulating the entry's DN from components specified in the certificate's issuer name and attribute variable assertion (AVA) constants. Optionally, the plug-in can also create an entry for the CA in the directory.  

LdapDNCompsMap  

Maps a certificate to a directory entry by formulating the entry's DN from components (such as CN, OU, O, and C) in the certificate's subject name and using it as the search DN to locate the entry in the directory.  

LdapDNExactMap  

Maps a certificate to a directory entry by searching for the entry whose DN exactly matches the certificate subject name.  

LdapSimpleMap  

Maps a certificate to a directory entry by formulating the entry's DN from components specified in the certificate's subject name and attribute variable assertion (AVA) constants.  

LdapSubjAttrMap  

Maps a certificate to a directory entry by searching for the entry that contains the LDAP attribute named certSubjNameAttr whose value exactly matches the certificate subject name.  

Table 1-7 lists the publisher modules supported by Certificate Management System out of the box. Publisher modules help you configure a Certificate Manager to publish certificates and CRLs to the mapped directory entries, to files, or to the Online Certificate Status Manager.


Table 1-7    Default publisher plug-in modules for publishing certificates and CRLs  

Plug-in module name

Function

FileBasedPublisher  

Publishes certificates and CRLs to a flat file (for exporting into other repositories).  

LdapCaCertPublisher  

Publishes or unpublishes a certificate to the caCertificate;binary attribute of the mapped directory entry as a DER encoded binary blob. Also converts the object class to a certificationAuthority if it's not one already; similarly, removes the certificationAuthority object class on unpublish if the CA has no other certificates.  

LdapCrlPublisher  

Publishes (replaces) a CRL to the certificateRevocationList;binary attribute of the mapped directory entry as a DER encoded binary blob. The entry should be a certificationAuthority object class.  

LdapUserCertPublisher  

Publishes or unpublishes a certificate to the userCertificate;binary attribute of the mapped directory entry as a DER encoded binary blob.  

OCSPPublisher  

Publishes CRLs to a Online Certificate Status Manager.  


Event-Driven Notifications

The Certificate Manager and Registration Manager support two kinds of event-driven notifications:

  • Request-completion status. Automatically notifies users by email that a requested certificate has been issued or that a request has been deferred or rejected. Available for Registration Manager or Certificate Manager.

  • Request-queue status. Automatically notifies agents by email when a request has been added to the request queue. Available for Registration Manager or Certificate Manager.

For more information, see Chapter 16 "Setting Up Automated Notifications."



Auxiliary Components


In addition to the core components that are discussed in the preceding sections, Certificate Management System also comes with command-line utilities or tools and Software Development Kit.


Command-Line Utilities

A number of command-line utilities or tools are bundled with Certificate Management System. These tools are useful for troubleshooting any problems that you may encounter with Certificate Management System. The binaries for all the utilities are located in this directory: <server_root>/bin/cert/tools

For detailed information about these utilities, see CMS Command-Line Tools Guide.


CMS SDK

CMS Software Development Kit (SDK) includes information that's useful for developing new plug-in modules and for customizing various aspects of Certificate Management System. During installation, files for CMS SDK are copied to this directory: <server_root>/cms_sdk/

Below is an overview of what's contained in the above directory:

  • CMS JDK, which includes Javadocs, Samples, and Tutorials for developing Java plug-ins:

    Javadocs—complete javadoc specification of the CMS Application Programming Interface (API).

    Samples—sample source code of various plug-in modules that are included in Certificate Management System out-of-the-box. This source code has been included for reference purposes only, and is only used to demonstrate how a particular CMS feature was implemented. Since a sample represents the actual code currently present in Certificate Management System, it does not require to be recompiled. You will find examples for the authentication, jobs, listeners, mappers, passwords, policies, publishers, and servlets modules.

    Tutorials—"How To" tutorial to help demonstrate how you can create your own plug-in modules for Certificate Management System. Each tutorial includes sample Java source code, environment and build scripts for both UNIX and Windows NT, and a detailed "cookbook" describing how to build and install these plug-in modules. Additionally, if necessary, some tutorials may also contain sample configuration files. A tutorial has been included for authentication, job, listener, mapper, password, policy, publisher, and servlet modules.

  • White papers about HTTP-related abilities of Certificate Management System including "How to add extra parameters to request from the Manual approval page" and "The CMS 4.x Bulk Generation Interface Specification".

  • Miscellaneous information about CMS features such as an AutoInstaller, an AutoRestart, script for UNIX, and a large zip file containing a sophisticated demonstration of ObjectSigning capabilities.

  • Examples of how to use Certificate Management System with some third-party products.



Entry Points for Various Types of Users

Certificate Management System provides entry points for various kinds of user interaction.

Figure 1-4    Entry points for different types of CMS users


As illustrated in Figure 1-4, the server provides three separate user entry points; each entry point addresses the needs of a specific user type. This is explained in Table 1-8.


Table 1-8    Certificate Management System user entry points  

User type

Component/Tool

CMS interface

End entity  

Web browser  

End Entity Services

This interface provides the general front end for end-entity interactions with the server. Through this interface, the Certificate Manager or Registration Manager serves the appropriate HTML forms for end-entity operations (the Data Recovery Manager and Online Certificate Status Manager do not have an end-entity interface). These include forms for certificate enrollment, retrieval, query, renewal, import, and revocation. For details, see "End-Entity Services Interface".  

Agent  

Web browser  

Agent Services

This interface provides the general front end for agent interactions with the server. Through this interface, a Certificate Manager, Registration Manager, Data Recovery Manager, or Online Certificate Status Manager serves the appropriate HTML forms for agent tasks. For details, see "Agent Services Interface".

Accessing Agent Services is a privileged operation; agents must use designated certificates for SSL client authentication to Certificate Management System.  

Administrator  

Netscape Console
(CMS window)  

The remote administration interface supports a GUI-based administration tool called Netscape Console that provides the general administration and management interface for Certificate Management System. For details, see Chapter 9 "Administration Tasks and Tools."

Administrators can use this tool to perform day-to-day operational and managerial duties, such as changing the server configuration, stopping and restarting the server, requesting and installing certificates, managing resources (certificates and requests), and setting up privileged-user information and associated access controls.

The CMS window can only be launched from within Netscape Console. Accessing this window is a privileged operation requiring a password-based authentication to Certificate Management System.  


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:

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.


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

  • 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.

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 entities—people, routers, servers, and others—that use certificates to identify themselves and that need to be able to request certificate issuance and management operations. These forms, collectively identified as End-Entity Services Interface, use different protocols and life-cycle management procedures for different kinds of end entities. For example, the Certificate Manager provides separate certificate enrollment forms for clients such as Netscape Navigator 3.x, versions of Netscape Communicator later than 4.5, and Microsoft Internet Explorer. The reason for this is that end entities running Navigator 3.x and Communicator versions earlier than 4.5 present an enrollment form based on the use of the HTML tag KEYGEN to generate keys; end entities running Internet Explorer present a form based on PKCS #10, the RSA standard for certificate request syntax.

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 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.

Figure 1-10    CMS architecture


PKCS #11

Public-Key Cryptography Standard (PKCS) #11 specifies an API used to communicate with devices that hold cryptographic information and perform cryptographic operations. Because it supports PKCS #11, Certificate Management System works with a wide range of hardware and software devices intended for such purposes.

One or more PKCS #11 modules must be available to any CMS subsystem instance. As shown in Figure 1-10, a PKCS #11 module (also called a cryptographic module or cryptographic service provider) manages cryptographic services such as encryption and decryption via the PKCS #11 interface. PKCS #11 modules can be thought of as drivers for cryptographic devices that can be implemented in either hardware or software. Netscape provides a built-in PKCS #11 module with Certificate Management System; see "Installing External Tokens".

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.


NSS

Network Security Services (NSS) is a set of libraries designed to support cross-platform development of security-enabled communications applications. Applications built with the NSS libraries support the SSL protocol for authentication, tamper detection, and encryption as well as the PKCS #11 interface for cryptographic token interfaces. Netscape uses NSS to support these features in a wide range of products, including Certificate Management System.

For more information about NSS, check this site:

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

As shown in Figure 1-10, NSS communicates with PKCS #11 modules through the PKCS #11 interface and in turn provides the foundation for Java Security Services and higher Java layers.


JSS and the Java/JNI Layer

Java Security Services (JSS) provides a Java interface for security operations performed by NSS. JSS and higher levels of the Certificate Management System architecture are built with the Java Native Interface (JNI), which provides binary compatibility across different versions of the Java Virtual Machine (JVM). This design allows customized subsystem services to be compiled and built just once and run on a range of platforms.


Middleware/Java 2 Layers

A middleware layer above JSS and the Java/JNI layer provides a range of services required by the Registration Manager, Certificate Manager, Data Recovery Manager, and Online Certificate Status Manager. The middleware layer is based on Java 2.0, SDK 1.3.0, and it underlies both the manager subsystems and the APIs available to third-party developers for building custom authentication and policy modules. The default authentication and policy modules provided with Certificate Management System are built from the same Java classes.


Authentication and Policy Modules

The top layer of Figure 1-10 consists of authentication and policy modules. Several default modules ship with Certificate Management System; third parties can create their own custom modules using the APIs provided above the middleware and subsystem layers. Modules for all three subsystems work the same way and are interchangeable.



Standards Summary


This section summarizes the standard message formats and protocols supported by Certificate Management System.


Certificate Management Formats and Protocols

Certificate Management System supports the following certificate management formats and protocols. For more details about the proposed PKIX standards listed here, see http://www.ietf.org/html.charters/pkix-charter.html (under Internet Drafts).

  • Certificate Enrollment Protocol (CEP). A certificate management protocol jointly developed by Cisco Systems and VeriSign, Inc. CEP is an early implementation of CMC (described later in this list). CEP specifies how a device communicates with a CA, including how to retrieve the CA's public key, how to enroll a device with the CA, and how to retrieve a CRL. CEP uses PKCS #7 and PKCS #10.

  • Certificate Request Message Format (CRMF). A message format used to convey a request for a certificate to a Registration Manager or Certificate Manager. A proposed standard from the Internet Engineering Task Force (IETF) PKIX working group.

  • Certificate Management Message Formats (CMMF). Message formats used to convey certificate requests and revocation requests from end entities to a Registration Manager or Certificate Manager and to send a variety of information to end entities. A proposed standard from the IETF PKIX working group. CMMF is subsumed by another proposed standard, CMC (next item).

  • Certificate Management Messages over CMS (CMC). A general interface to public-key certification products based on CMS and PKCS #10, including a certificate enrollment protocol for DSA-signed certificates with Diffie-Hellman public keys. A proposed standard from the IETF PKIX working group. CMC incorporates CRMF and CMMF. Future versions of Certificate Management System will support this standard as it is finalized.

  • Cryptographic Message Syntax (CMS). A superset of PKCS #7 syntax used for digital signatures and encryption. A proposed standard from the IETF PKIX working group.

  • PKIX Certificate and CRL Profile (PKIX Part 1). The first part of the four-part standard under development by the IETF for a public-key infrastructure for the Internet. Part 1 deals with specifications for certificates and CRLs. Certificate Management System will support the other PKIX parts as they are finalized. For more information about PKIX Part 1, see ftp://ftp.isi.edu/in-notes/rfc2459.txt.


Security and Directory Protocols

Certificate Management System supports the following security and directory protocols:

  • FIPS PUBS 140-1. Federal Information Standards Publications (FIPS PUBS) 140-1 is a US government standard for implementations of cryptographic modules—that is, hardware or software that encrypts and decrypts data or performs other cryptographic operations (such as creating or verifying digital signatures).

  • Hypertext Transport Protocol (HTTP) and Hypertext Transport Protocol Secure (HTTPS). Protocols used to communicate with web servers.

  • KEYGEN tag. An HTML tag supported by Netscape browsers that generates a key pair for use with a certificate. For more information, see http://www.netscape.com/eng/security/comm4-keygen.html.

  • Lightweight Directory Access Protocol (LDAP) v2, v3. A directory service protocol designed to run over TCP/IP and across multiple platforms. LDAP is a simplified version of Directory Access Protocol (DAP), used to access X.500 directories. LDAP is under IETF change control and has evolved to meet Internet requirements.

  • 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.


Previous     Contents     Index     Next     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated April 02, 2001