Chapter 2   Certificate Enrollment and Life-Cycle Management


This chapter explains how you can use iPlanet Certificate Management Server (CMS) for issuing certificates to end entities such as we browsers, servers, routers, and so on.

The chapter has the following sections:

• Steps in End-Entity Enrollment

• Some Enrollment Scenarios

• End Entities and Life-Cycle Management

This chapter assumes that you've read the previous chapter, Chapter 1 "Introduction to Certificate Management System."

Steps in End-Entity Enrollment

---

The following steps take place when a Registration Manager or a Certificate Manager handles an enrollment request from an end user. Figure 2-1 shows a simplified view of how this works.

1. Submit form. When the user first interacts with the CMS manager (either the Registration Manager or the Certificate Manager), the user specifies the kind of request to be made, fills in the form for that request, and submits it to the servlet via HTTP or HTTPS. The servlet then processes the form. In the figure, a certificate request is being sent to an enrollment servlet. It could also be a renewal or revocation request being sent to one of the other servlets.

2. Authenticate user. Authentication can be either automatic or manual. If the CMS manager is configured for automatic authentication, the servlet uses the authentication module specified by the form to validate the information provided by the user. For example, the directory authentication module that comes with Certificate Management System validates the user ID and password by comparing it to the user's entry in an LDAP directory. Custom authentication modules can be used to take advantage of existing databases, security systems, or other methods of authentication. If the CMS manager is configured for manual authentication, the servlet routes the request to the request queue and informs the user (via a web page) that approval has been deferred. The request remains in the queue until an agent approves it or rejects it.

3. Process policies. If authentication is successful, policies specified for this CMS manager are applied to the request for the purpose of formulating the contents of the certificate to be issued and to enforce certain rules, such as name constraints. Custom policy modules can be used to enforce specialized certificate extensions and other requirements.

4. Service request. After policy processing, the servlet's work is finished and the CMS manager services the request (assuming that a policy has not triggered deferral)—for example, by issuing a certificate.

5. Notify user. If the CMS manager has been configured for automatic authentication and issuance, the manager delivers the signed certificate to the user via a web page. If the request has been deferred (for example, for manual approval) or rejected, the user is informed of the request's status. When the request has been approved and the certificate issued, the CMS manager notifies the user (for example, with an email) and provides a URL where the certificate can be picked up.

Since all three CMS managers use the same architecture for authentication and policy processing, it's possible to reuse any authentication and policy modules with any manager. For information on the relationship of policy modules to the APIs exposed by Certificate Management System, see System Architecture.

Figure 2-1    Roles of servlets, authentication modules, and policy modules in end-entity enrollment

Some Enrollment Scenarios

---

Successful PKI deployment requires flexible and easy enrollment for end entities as well as ongoing support for certificate life-cycle management—that is, management of each certificate from enrollment through encryption key storage (if necessary), renewal, and revocation. The preceding section describes the internal flow of control among servlets, authentication modules, and policy modules in a CMS manager (see Figure 2-1 for a summary). The examples that follow illustrate the flexibility that the CMS architecture supports among end entities, Registration Managers, Certificate Managers, and existing customer databases, security systems, and directories.

• Firewall Considerations

• Extranet/E-Commerce: Acme Sales Corp.

• PIN Registration: Atlas Manufacturing

• VPN Client Enrollment and Revocation

• Router Enrollment and Revocation

For the sake of simplicity, these examples do not show the role of the Data Recovery Manager. For more information about data recovery, see Data Recovery Manager.

For more information about certificate life-cycle management, see End Entities and Life-Cycle Management.

Firewall Considerations

Most of the examples that follow show a Certificate Manager inside the firewall and a Registration Manager outside the firewall. Other variations are possible, but this arrangement is often appropriate. These are some of the advantages:

• The most sensitive elements of the deployment—the Certificate Manager, internal databases, directories, and so on—have the additional protection of the firewall.

• The Certificate Manager can have additional physical protection, if desired—such as storage in a locked room and agent authentication by means of smart cards.

• All communication between the Registration Manager and the Certificate Manager takes place over SSL with mutual authentication—that is, both client and server authentication via X.509 v3 certificates.

• The Registration Manager provides only a subset of the capabilities of the Certificate Manager—those required for processing end-user requests. If the Registration Manager is compromised, the Certificate Manager can revoke its signing certificate (thus invalidating all subsequent requests from that Registration Manager) and issue a new one after the problem has been addressed.

Administrative and physical arrangements are closely related to firewall issues. The flexibility of CMS deployment options makes it possible to divide functions among existing administrative groups or physical locations, requiring minimal disruption for an organization.

The examples that follow do not address the role of the Data Recovery Manager or the potential use of multiple Registration Managers and Certificate Managers. For example, in some circumstances it might make sense to have some Registration Managers outside the firewall and some inside; in other cases different CMS subsystems might be located in entirely different physical locations, each with their own firewalls.

In general, iPlanet recommends that the Certificate Manager handle all certificate and CRL publishing functions. If it's necessary for some entries in a directory to be available outside the firewall, iPlanet recommends using the partial replication feature of Directory Server to replicate the relevant portion of the directory.

Extranet/E-Commerce: Acme Sales Corp.

Acme Sales is a high-end mail-order catalog service that is launching an online shopping service. Many of Acme's affluent customers make very expensive purchases, so Acme has decided to use certificate-based authentication for its new web site.

Acme has 100,000 existing customers and expects to attract many new customers through its online service. The company wants to use its existing relational database to authenticate and enroll existing customers with minimal effort on their part. For new customers, Acme wants to establish a manual process entailing out-of-band credit checks (that is, checks that don't involve an electronic network), identity verification, and a personal phone call before an online certificate request can be granted. In addition, Acme plans to issue certificates to contract workers, suppliers, and employees who routinely access parts of the company's internal network by using Kerberos.

The sections that follow describe how Acme uses Certificate Management System to achieve these goals:

• Enrolling Existing Customers

• Enrolling New Customers

• Enrolling Extranet Users

In all cases, Acme has decided to place its Certificate Manager behind the firewall and its Registration Manager outside the firewall, for reasons summarized in Firewall Considerations .

Enrolling Existing Customers

Acme has decided on the following process for registering its existing customers, as shown in Figure 2-2.

1. Request certificate. The customer fills in and submits a form (over SSL) that specifies account information and other personal details stored in the existing customer database.

2. Custom authentication. The Registration Manager uses a custom authentication module to verify the customer's account and status against the existing customer database.

3. Request certificate. If authentication against the customer database is successful, the Registration Manager performs policy processing and, if processing is successful, forwards the request to the Certificate Manager.

4. Issue certificate. The Certificate Manager performs its own policy processing and, if processing is successful, issues the certificate and delivers it to the Registration Manager.

5. Deliver certificate. If the Certificate Manager successfully issues the certificate, the Registration Manager delivers it to the end user in the same session. If the request is unsuccessful for any reason, the Registration Manager displays a web page to the customer explaining the problem and what to do about it.

Figure 2-2    Custom authentication against an existing customer database

Enrolling New Customers

The following process will be used for enrolling new Acme customers. In this case, the Registration Manager uses manual authentication to validate every certificate request personally before issuing the certificate. Figure 2-3 illustrates the steps in this process.

1. Request certificate. The customer fills in and submits a certificate request form for new Acme customers.

2. Deferral notice. The Registration Manager immediately informs the customer (via a web page) that the request has been deferred and that Acme will be in touch soon. Meanwhile, the certificate request waits in a queue for attention from the Registration Manager agent.

3. Manual approval. The Registration Manager administrator may configure the Registration Manager to notify the agent via email whenever a new request is added to the request queue. In any case, when the agent processes the requests in the queue, he or she follows Acme's procedure for processing credit checks and validating other customer information, including making a personal phone call. If all authentication procedures are successful, the agent approves the request.

4. Request certificate. The Registration Manager performs policy processing and, if the processing is successful, sends the approved request to the Certificate Manager.

5. Issue certificate. The Certificate Manager performs its own policy processing on the request and, if processing is successful, issues the certificate and delivers it to the Registration Manager.

6. Email notice of issuance. The Registration Manager sends an email containing a URL to the new customer, asking the customer to pick up the certificate.

7. Pick up certificate. The customer goes to the specified Registration Manager URL and picks up the certificate.

Figure 2-3    Manual authentication of new customers

Enrolling Extranet Users

Acme wants its new, certificate-enabled extranet applications to be available to contract workers, suppliers, employees, and others who routinely access parts of the company's internal network. In general, this can be achieved by using Kerberos or other non-PKI security systems as the authentication mechanism for requesting a certificate. To authenticate them for the purposes of PKI enrollment, Acme uses a third-party authentication module from DASCOM that takes advantage of its existing Kerberos system without disturbing its current functions.

For example, to get a certificate, a contractor provides an ID and password to the Registration Manager, which uses the Kerberos system to verify them before passing on the certificate request to the Certificate Manager. This arrangement involves the following steps, illustrated in Figure 2-4. (The details of the existing security system don't matter: third-party or custom CMS authentication modules can be used for Kerberos, NIS, and many other security systems. Extranet users can continue to use applications based on the old security systems while they use their certificates to take advantage of new certificate-based applications.)

1. Request certificate. A user of Acme's existing extranet fills in and submits a certificate request (over SSL) using a customized form that requires a Kerberos ID and password.

2. Authentication. The Registration Manager uses a third-party authentication module to validate the user's identity using the existing internal Kerberos system.

3. Request certificate. If authentication against Kerberos is successful, the Registration Manager performs policy processing and, if processing is successful, forwards the request to the Certificate Manager.

4. Issue certificate. The Certificate Manager performs its own policy processing on the request and, if processing is successful, issues the certificate and delivers it to the Registration Manager.

5. Deliver certificate. If the Certificate Manager issues the certificate, the Registration Manager delivers it to the end user in the same session. If the request is unsuccessful for any reason, the Registration Manager displays a web page to the user explaining the problem and what to do about it.

Figure 2-4    Custom authentication against an existing Kerberos security system

PIN Registration: Atlas Manufacturing

Atlas Manufacturing has decided to put information for its employees, suppliers, dealers, and customers—a total of nearly 500,000 people, including individual consumers and employees of several dozen other companies—on an extranet. Atlas already uses iPlanet Directory Server to store names, addresses, and other information about the various groups of people who will need access to the extranet. To register all these people at once, Atlas uses the directory-based PIN Generator tool that comes with Certificate Management System to generate PINs in bulk. The PINs are then stored in the directory and delivered to the end users via a batch mailer program, an employee payroll stub, a customer invoice, or some other means of physical delivery.

PINs are salted and hashed before storage in the directory. Salting refers to the inclusion of additional information from the distinguished name (DN) with the PIN to ensure unique hashing. Hashing, in this case, involves generating a number of fixed length from the PIN and DN information. Even if the security of the directory is breached, it is very difficult to reconstruct the PIN from the value that results from salting and hashing. When customers use the PIN to enroll in the Atlas PKI, the PIN is automatically removed from the directory. Enrollment PINs are therefore more reliable than passwords, which must be protected over a long period of time.

Acme's process involves the following steps (illustrated in Figure 2-5):

1. Generate PINs. The CMS administrator runs the CMS PIN Generator against the existing directory, populating each entry with a unique PIN.

2. Write out PIN records. The CMS administrator uses the CMS PIN Generator to write out PIN records for use by an out-of-band delivery mechanism.

3. Out-of-band delivery. The user receives the PIN via a batch mailing system, payroll stub, invoice form, or other out-of-band delivery mechanism.

4. Request certificate (using PIN). The user goes to a specified Registration Manager URL, fills in name and PIN, and submits a certificate request.

5. Authentication (using PIN). The Registration Manager uses the standard CMS PIN-based directory authentication module to verify the PIN against the directory.

6. Request certificate. If authentication against the directory is successful, the Registration Manager performs policy processing and, if this succeeds, forwards the request to the Certificate Manager.

7. Issue certificate. The Certificate Manager performs its own policy processing and, if all goes well, issues the certificate.

8. Deliver certificate. If the Certificate Manager issues the certificate, the Registration Manager delivers it to the end user in the same session. If the request is unsuccessful for any reason, the Registration Manager displays a web page to the user explaining the problem and what to do about it.

Figure 2-5    PIN-based enrollment

VPN Client Enrollment and Revocation

Virtual private network (VPN) client software runs on a user's desktop, outside the firewall, and uses the IP Key Management Protocol (IPKMP) or IP Security (IPSec) protocol to establish encrypted communication with VPN hardware that straddles the firewall. These protocols allow VPN hardware to authenticate VPN client software using the client's certificate, in much the same way that the SSL protocol allows a server to authenticate client browser software.

VPN client software can use several different protocols over HTTP or HTTPS to handle enrollment and other life-cycle management tasks. Certificate Management System supports the Certificate Enrollment Protocol (CEP) used by Cisco routers. CEP runs over HTTP and provides its own form of encryption.

The following steps explain how VPN client software can use the Registration Manager and Certificate Manager to enroll in a PKI and what happens when the client's certificate is revoked. These steps are shown in Figure 2-6.

1. Enroll in PKI. The VPN client sends a certificate request to the Registration Manager via CEP, and the Registration Manager processes the request and forwards it to the Certificate Manager inside the firewall. (Any of the authentication methods discussed in the previous sections can be used during enrollment to authenticate the client.)

2. Issue certificate. The Certificate Manager issues the certificate, and the Registration Manager delivers it to the VPN client. The VPN client can now authenticate itself to the VPN hardware and establish an encrypted channel using IPKMP or IPSec. All TCP/IP communication passes through this encrypted channel. From the point of view of the VPN client, it appears to be directly connected to the TCP/IP network inside the firewall.

3. Publish certificate. The Certificate Manager publishes the certificate to a directory (this is an optional step).

4. Revoke certificate. After some time has passed, the Certificate Manager agent revokes the certificate (for example, after the certificate owner leaves the company).

5. Publish CRL. The Certificate Manager publishes a new CRL to the directory specified as the CRL distribution point in the original certificate.

6. Verify certificate. The VPN hardware checks the CRL as part of its authentication process. Certificates listed in the CRL are not authenticated, and VPN clients presenting them cannot establish a connection.

Figure 2-6    VPN client enrollment and revocation

The certificate includes information about a CRL distribution point, which is a directory that the VPN hardware can check for the latest CRL published by the Certificate Manager.

Router Enrollment and Revocation

Cisco routers support the use of certificates for authentication, encryption, and tamper detection with the IP Security (IPSec) protocol. Cisco routers also support CEP for certificate life-cycle management, as discussed in the previous section.

The following steps describe how two routers can use a Certificate Manager to enroll in a PKI and what happens when a router's certificate is revoked. These steps are shown in Figure 2-7.

1. Enroll in PKI. The routers each send a certificate request to the Certificate Manager via CEP, and the Certificate Manager issues them certificates. (Any of the authentication methods discussed in the previous section can be used during enrollment to authenticate the client.)

2. Publish certificates. As part of the issuing process, the Certificate Manager publishes the certificates to the directory. (Publishing occurs only if the router's DN exists in the publishing directory. This is important for some Cisco routers that must fetch their certificates from an LDAP directory because flash memory is not large enough to hold them.) The routers can now authenticate each other and establish an encrypted channel using IPSec. All TCP/IP communication passes through this encrypted channel. From the point of view of other connections to each router, they all appear to be sharing the same TCP/IP network.

3. Revoke a certificate. After some time has passed, the Certificate Manager agent revokes one of the certificates (for example, after the certificate owner leaves the company).

4. Publish CRL. The Certificate Manager publishes the CRL to the directory.

5. Verify certificate. The routers check the CRL as part of their mutual authentication process. Certificates listed in the CRL are not authenticated, and routers presenting them cannot establish a connection.

Figure 2-7    Router enrollment and revocation

End Entities and Life-Cycle Management

---

Certificate Management System provides default web forms for all end-entity interactions involved in managing the life cycle of a certificate. It also provides forms, collectively called Agent Services, for agent interactions. These forms can be used as is or customized. The Netscape Personal Security Manager is a software that improves the PKI abilities of Netscape Communicator 4.7x versions.

The sections that follow introduce the end-entity forms and protocols.

• Life-Cycle Management Formats and Protocols

• Access to Subsystems

• HTML Forms for End Users

• Netscape Personal Security Manager

Life-Cycle Management Formats and Protocols

The Registration Manager and Certificate Manager provide default HTML forms that use different protocols and life-cycle management procedures for different kinds of end entities. For example, end entities running Navigator 3.x and versions of Communicator earlier than 4.5 need to be presented with an enrollment form based on the use of the HTML tag KEYGEN to generate keys. End entities running Microsoft Internet Explorer require a form containing VBScript XENROLL commands. These various tags, scripts, and protocols result in enrollment messages that are sent back to the Certificate Manager or Registration Manager in a variety of nonstandard and standards-based formats.

Table 2-1 summarizes the message formats, cryptographic algorithms, and key pairs (single or dual) supported by Certificate Management System for the main categories of end-entity software. Note that, for the purposes of enrollment, CMS managers are also end entities. CMS managers installed in different instances need SSL client and SSL server certificates to identify themselves. For more information about the standards listed in Table 2-1, see Standards Summary.

Table 2-1    End entities, message formats, algorithms, and key pairs supported by Certificate Management System

End entity software	Enrollment message format over HTTP or HTTPS	Cryptographic algorithms	No. of key pairs
Navigator 3.x Communicator 4.0 to 4.5	KEYGEN tag	Signing and encryption: RSA Signing only: RSA, DSA	Single key pair
Internet Explorer 3.x and 4.x	PKCS #10	Signing and encryption: RSA Signing only: RSA	Single key pair
Internet Explorer 5.x	PKCS #10	Signing and encryption: RSA Signing only: RSA, DSA	Single or dual key pairs
Communicator 4.7x and later versions	CRMF and CMMF based on new JavaScript API	Signing and encryption: RSA Signing only: RSA, DSA	Single or dual key pairs
iPlanet servers (including CMS managers) and other servers	PKCS #10	Signing and encryption: RSA	Single key pair
Cisco routers (version IOS 12.04) and VPN clients	CEP	Signing and encryption: RSA	Single key pair

Access to Subsystems

Three kinds of entities can access CMS subsystems: administrators, agents, and end entities. Administrators are responsible for the initial setup and ongoing maintenance of the subsystems. Agents manage the day-to-day operations of each subsystem, such as responding to requests from end entities. End entities access Registration Manager or Certificate Manager subsystems to enroll in a PKI and to take part in other life-cycle management operations, such as renewal or revocation.

Figure 2-8 shows the ports used by administrators, agents, and end entities. All agent and administrator interactions with CMS subsystems occur over HTTPS.

End-entity interactions can take place over HTTP or HTTPS. For example, routers using CEP, which includes its own encryption scheme, uses HTTP rather than HTTPS. For a more detailed discussion of these ports and examples of hands-on use, see Chapter 3 "Default Demo Installation."

Figure 2-8    Access ports for Certificate Management System

HTML Forms for End Users

Each type of end-entity form provided by a Registration Manager or Certificate Manager determines the type of client, such as Communicator or Internet Explorer, and presents the appropriate input page. Each form also specifies both an authentication module and an output template. The authentication module is used by the servlet to authenticate the end entity; the output template is an HTML page that returns information from the servlet to the end entity.

Figure 2-9 shows the default manual enrollment form as it is presented to end users running Communicator 4.5. Users can click items in the left menu and tabs to access other HTML forms. Server administrators, including CMS administrators, can also access forms for enrolling servers or subsystems. Any of these forms can be customized to reflect an organization's requirements.

Figure 2-9    Default manual enrollment form for end users

Table 2-2 shows the protocols supported by the default CMS life-cycle management servlets. Any of the HTML forms and their HTML help text can be customized. The Registration Manager also supports the creation of new forms. Some output templates can also be customized.

Table 2-2    Default CMS life-cycle management servlets and supported protocols

Life-cycle management servlet	Message syntax/procedures for end entities
Certificate enrollment form	User certificates: KEYGEN for Navigator/Communicator, VBScript/XENROLL and PKCS #10 for Internet Explorer
	Server certificates: PKCS #10 (cut and paste; also URI for Administration Server 3.5 and 4.1)
Certificate renewal form	User certificates: SSL client authentication
	Server certificates: PKCS #10 (cut and paste)
Certificate revocation form	User certificates: SSL client authentication
	Server certificates: agent initiated
Encryption key storage and recovery form	Not supported for Navigator/Communicator 4.x; CRMF for Communicator 5.0 (based on new JavaScript API).

For more information about the standards listed in Table 2-1, see Standards Summary.

Netscape Personal Security Manager

Netscape Personal Security Manager is a standards-based, client-independent application that performs PKI operations on behalf of Netscape Communicator 4.7 and other applications. Personal Security Manager provides advanced cryptographic capabilities while at the same time hiding the complexity of PKI operations from end users. In particular, Personal Security Manager simplifies certificate deployment with Certificate Management System by taking advantage of the following CMS features:

• One-click issuance of certificates.

• Forced certificate backup by end users after certificate issuance.

• Issuance and management of separate signing and encryption certificates.

• Automatic storage of encryption private keys with the Data Recovery Manager at the time a certificate is issued, if requested by the Registration Manager.

• Automatic revocation checking each time Personal Security Manager verifies a certificate.

Behind the scenes, Personal Security Manager supports the following cryptographic capabilities:

• SSL v2 and v3. SSL authentication, encryption, and tamper detection.

• S/MIME. Signed and encrypted email (using separate signing and encryption keys if desired)

• PKCS #5. Encryption for private key storage.

• PKCS #7. Signing operations.

• PKCS #11. Communication with PKCS #11 modules and associated cryptographic tokens (such as smart cards).

• PKCS #12. Export and import of certificates and associated private keys.

• CRMF/CMMF. Direct commmunication between Personal Security Manager and a CA, simplifying enrollment processes and making one-click issuance possible.

• Online Certificate Status Protocol (OCSP). Real-time revocation checking.

Keep in mind that Personal Security Manager works only with Netscape Communicator, version 4.7x, which can be downloaded from this site: http://home.netscape.com/download/