Chapter 3

Certificate Manager

---

The Certificate Manager subsystem provides the services of a Certificate Authority (CA) in the PKI. It can issue, renew, and revoke certificates; create and issue CRLs; and publish certificates and CRLs.

This chapter discusses the Certificate Manager subsystem. It provides an overview of the subsystem including the decisions you need to make before installing the subsystem, complete installation instructions, an overview of the Certificate Manager processes including information on configuring those processes, information about FBCA, and details on configuring a cloned CA.

This chapter contains the following sections:

• Certificate Manager Deployment Considerations
• Installing a Certificate Manager
• Configuring the Certificate Manager
• How The Certificate Manager Works
• Federal Bridge CA
• Cloning a CA

Certificate Manager Deployment Considerations

This section describes the decisions you make during installation of the Certificate Manager that will apply to your initial configuration of the subsystem.

Self-Signed Root vs. Subordinate CA

A Certificate Manager can be set up as a self-signing root CA. You set up a self-signing root CA by choosing this option when you install. A self-signing root CA issues and signs its own certificates. The subsystems are then issued certificates by this self-signing CA.

A Certificate Manager can be setup as a subordinate CA. It can either be subordinate to a public CA that signs its certificates, or to another CS CA that signs its certificates. A subordinate CA is restricted in the types of certificates it can issue, and what the content of those certificates are by the contents and settings of the CA signing certificate issued to it.

For the purposes of an initial pilot, it is easiest to make the CA a self-signed root, so that you won't need to apply to a third party and wait for the certificate to be issued. Before deploying a full-blown PKI, however, you will need to consider this question carefully.

Understanding Certificate Manager Subordination

A Certificate Manager (or CA) is subordinate to another CA because its CA signing certificate, the certificate that allows it to issue certificates, is issued by another CA. The CA that issued the subordinate CA signing certificate controls the CA through the contents of the CA signing certificate. The CA can constrain the subordinate CA through the kinds of certificates that it can issue, the extensions that it is allowed to include in certificates, the number of level of subordinate CAs the subordinate CA can create, and the validity period of certificates it can issue, as well as the validity period of the subordinate CAs signing certificate.

Although a subordinate CA can create certificates that violate these constraints, a client authenticating a certificate that violates those constraints will not accept that certificate.

Subordination to a Public CA

If you want your CA to chain up to a third-party public CA, you must carefully consider the restrictions that public CAs place on the kinds of certificates your CA can issue and the nature of the certificate chain. For example, a CA that chains up to a third-party CA might be restricted to issuing only Secure Multipurpose Internet Mail Extensions (S/MIME) and SSL client authentication certificates; but not SSL server certificates. In addition, a CA that chains up to a third-party CA might not be allowed to have any subordinate CAs and might have to obey certain restrictions on its use of certificate extensions. These and other restrictions may be acceptable for some PKI deployments but not for others.

One benefit of chaining up to a public CA is that the third party is responsible for getting the root CA certificate into the browser or other client software. This can be a major advantage if you are deploying an extranet that involves certificates used by different companies whose browsers you cannot control. Alternatively, if you create your own CA hierarchy from scratch, you are responsible for getting your root certificate into all the browsers used with the certificates you issue. If you are using Netscape Communicator as your client, you can accomplish this task within an intranet by using tools such as Mission Control Desktop or with the aid of Personal Security Manager, but extranet deployments can be more complicated.

Subordination to Another CS CA

If you set up a CA using CS that has subordinate CAs, you control the subordinate CAs by setting policies that control the contents of the CA signing certificate issued. A subordinate CA issues certificates evaluating its own authentication, policy, and certificate profile configuration, it is completely unaware of its parents set up for these configurations.

A Certificate Manager cannot issue a certificate that has a validity period longer than the validity period of the CAs' CA signing certificate. Any requests that are for a period longer than this will result in certificates issued only to the validity period of the CAs' CA signing certificate.

Cloned CA

A Certificate Manager can also be cloned so that more than one CA shares the same set of keys and certificates allowing more than one CA issue certificates with the same issuer name and keys. Each clone CA issues a different set of serial numbers. Where the relationship between a self-signed CA and its subordinates is hierarchical, a CA and its clones function together, effectively forming a single Certificate Manager with failover support (and, potentially, load balancing on the front end). For details about a CA, see "Cloning a CA," on page 127.

Certificate Manager Certificates

When you install the Certificate Manager, the keys for the CA signing certificate, SSL server certificate, and OCSP signing certificate are created and a certificate request is made for the CA signing certificate and the SSL server certificate. The OCSP signing certificate is created by the CA itself.

You submit this request either as a self-signing request to the CA itself which will then issue the certificates, this is how you create a self-signing root CA, or you submit the request to a third party public CA and then install the certificate you receive from the CA during the rest of the installation.

About the CA Key Pairs and Certificates

This section describes the key pairs and certificates associated with the Certificate Manager.

CA Signing Key Pair and Certificate

Every Certificate Manager you install has a Certificate Manager CA signing certificate, whose public key corresponds to the private key the Certificate Manager uses to sign the X.509 certificates and CRLs it issues. This certificate is created and installed when you install the Certificate Manager. The default nickname for the certificate is caSigningCert cert-<instance_id>, where <instance_id> identifies the CS instance in which the Certificate Manager is installed, and the default validity period for the certificate is two years.

The subject name of the CA signing certificate reflects the name of your certificate authority (CA) as specified during the installation. All certificates signed or issued by the Certificate Manager include this name to identify the issuer of the certificate.

The Certificate Manager's status as a root or subordinate CA is determined by whether its CA signing certificate is self-signed or is signed by another CA.

• If the Certificate Manager is a root CA, its CA signing certificate is self-signed-that is, the subject name and issuer name of the certificate is the same.
• If the Certificate Manager is a subordinate CA, its CA signing certificate is signed by another CA, usually the one that is a level above in the CA hierarchy (which may or may not be a root CA). If you have deployed the Certificate Manager as a subordinate CA in a CA hierarchy, you must import your root CA's signing certificate into individual clients and servers before you can use the Certificate Manager to issue certificates to them.

Note	You cannot change the CA name; doing so would make all previously issued certificates invalid. Similarly, reissuing a Certificate Manager's CA signing certificate with a new key pair invalidates all certificates that have been signed by the old key pair.

OCSP Signing Key Pair and Certificate

Irrespective of whether you chose to enable the OCSP service feature, the Installation Wizard transparently generates a key pair and a corresponding certificate identified as the OCSP signing certificate.

The wizard uses the key type, key size, key algorithm, and validity period you provided for the CA signing key pair to generate the OCSP signing key pair. The subject name of the OCSP signing certificate is in the form CN=OCSP cert-<CS_instance_id>, and it contains extensions, such as OCSPSigning and OCSPNoCheck, required for signing OCSP responses.

The default nickname for the OCSP signing certificate is
ocspSigningCert cert-<instance_id>, where <instance_id> identifies the CS instance in which the Certificate Manager is installed.

The Certificate Manager uses the private key (that corresponds to the public key used to generate the OCSP signing certificate) to sign the OCSP responses it sends to the OCSP-compliant clients when queried about the revocation status of certificates.

SSL Server Key Pair and Certificate

Every Certificate Manager you install has at least one SSL server certificate. The first time you generated this certificate is when you installed the Certificate Manager. The default nickname for the certificate is
Server-Cert cert-<instance_id>, where <instance_id> identifies the CS instance in which the Certificate Manager is installed.

The Certificate Manager's SSL server certificate was issued by the CA to which you submitted the certificate signing request. You might have submitted the request to the Certificate Manager itself, another internally deployed CA, or a public CA.

By default, the Certificate Manager uses a single SSL server certificate for authentication purposes. However, you can request and install additional SSL server certificates for the Certificate Manager. For example, you can configure the Certificate Manager to use separate server certificates for authenticating to the End-Entity Services interface and Agent Services interface. See "Managing Certificates and the Certificate Database" on page 103 for more details.

If you configure the Certificate Manager for SSL-enabled communication with a publishing directory, the Certificate Manager also uses its SSL server certificate for SSL client authentication to the publishing directory. This is the default configuration. You can configure the Certificate Manager to use an alternate certificate for this purpose. See "Managing Certificates and the Certificate Database" on page 103 for more details.

If you configure the Certificate Manager to function as a trusted manager to a Data Recovery Manager, the Certificate Manager also uses its SSL server certificate for SSL client authentication to the Data Recovery Manager. For details on trusted managers, see "Trusted Managers" on page 317. You can also configure the Certificate Manager to use an alternate certificate for this purpose. See "Managing Certificates and the Certificate Database" on page 103 for more details.

Certificate Considerations

This section explains some of the decisions you need to make about the certificates you get for the Certificate Manager when you install the subsystem.

CA's Distinguished Name

The core elements of a CA consist of a signing unit and the Certificate Manager's own identity. The signing unit digitally signs certificates requested by end-entities that use a specified enrollment process to establish their identities. Regardless of how related Registration Managers or Data Recovery Managers are configured, any Certificate Manager must have its own distinguished name (DN), which is listed in every certificate it issues.

Like any other X.509 version 3 certificate, a CA certificate binds a DN to a public key. A DN is a series of name-value pairs that in combination uniquely identify an entity. For example, the following DN might be used to identify a hypothetical Certificate Manager for the Engineering department of a corporation named Example Corporation: cn=demoCA, o=Example Corporation, ou=Engineering, c=US

Many combinations of name-value pairs are possible for the Certificate Manager's DN. The DN must be unique and readily identifiable, since any end entity can examine it. For more information about DNs, see Managing Servers with Red Hat Console.

CA Signing Certificate's Validity Period

Every certificate, including a Certificate Manager signing certificate, must have a validity period. CS does not restrict the validity period you can specify. In general it's a good idea to specify as long a validity period as possible, depending on your plans for certificate renewal, the place of the CA in the certificate hierarchy, and the requirements of any public CAs that you may want to include in your PKI.

Serial Number Ranges for the CA

You can designate the starting and ending serial numbers that a CA can issue during the configure of the CA. This is especially useful when you are installing cloned CAs. Each cloned CA is given a specific range of serial numbers that it can issue. In this way, none of the cloned CAs can issue the same serial number.

Signing Key Type and Length

If you wish, you can import the signing key and certificate used in a previous version of CS installation rather than generating a new signing key pair. For information on how to do this, check the migration information.

If you decide to generate a new signing key, one of the first decisions you need to make is whether to use the RSA or DSA algorithm. If you use DSA, the software can generate and verify the PQG value. PQG values are used to create the DSA signing key pair. For more information about the way they are used, see the following document: http://www.itl.nist.gov/div897/pubs/fip186.htm.

In general, longer keys are considered to be cryptographically stronger than shorter keys. However, longer keys also require more time for signing operations.

Many people no longer consider an RSA key of length less than 1024 bits to be cryptographically strong. Export and other regulations permitting, it may be a good rule of thumb to start with 1024 bits and consider increasing the length to 4096 bits for certificates that provide access to highly sensitive data or services. However, the question of key length has no simple answers. Every organization must make its own decision based on its own security requirements. For more information on key length and encryption strength, see Appendix D of Managing Servers with Red Hat Console.

Certificate Manager Interfaces

When you install a Certificate Manager, three interfaces are enabled. The installation wizard lets you choose the ports these interfaces listen on. The following interfaces, and associated ports will be created:

• An Administrative interface that is accessible by default only to members of the Administrator and Auditor group. You specify the first administrator when you install the subsystem. Administrators can configure any of the settings of the server. Most basic functionality and subsystem specific configuration to the subsystem can be done using the administrative interface.

The administrative interface listens to requests on the SSL Administration Port. This is the port the CS administrative interface listens to, and that is accessed by administrators and auditors using the Java based CS Console GUI application.

• An Agent Services interface that is accessible by default only to members of the Agent group. You can choose to include the first administrator to also be the first agent when you install the subsystem. Agents are users who can perform tasks associated with the processing of requests and management of certificates. A Certificate Manager Agent can change the status, change the details, reject or approve certificate and revocation requests, revoke certificates, and approve and configure certificate profiles. The agent's services interface is an HTML interface accessible through HTTPS that authenticates agents using their certificate. The default interface provides all the functionality needed by agents for a Certificate Manager and is completely customizable.

The agent services interface listens to requests and communicates on the SSL Agent Services Port. This is the port that the agent goes to in order to access the agent services interface. The agent services interface is accessible at the following location:

https://<CS_host_dnsname>:<port_number>

For example:

https://services.example.com:7878

• An End-Entity interface that is accessible by anyone who can access that URL. The end-entity interface is an HTML interface accessible through either HTTPS or HTTP (there are two ports set up by default). The default interface provides forms for the various types of enrollment and other tasks an end entity can perform and is completely customizable. The end-entity interface listens for requests on the SSL or Non-SSL End Entity Ports. Both are configured during installation.

https://<CS_host_dnsname>:<port_number>

For example:

https://services.example.com:7878

Password Storage

Each subsystem stores passwords for its internal database, and for the tokens containing its keys and certificates. See "System Passwords," on page 244 for information on how these passwords are stored.

Internal Database

Each Certificate Manager instance contains an internal database that stores certificates, certificate requests and the like.

During installation, you set up this database by either choosing to create a new database, or use an existing database, providing user IDs and passwords for special users of the database, and the port the database will listen to requests on. You can choose to use the same internal database for more than one subsystem by specifying this when running the installation wizard to configure that subsystem. You should carefully consider whether you want to store this information in a separate internal database for each subsystem or use one internal database for all subsystems installed on the host.

It's recommended that you do not use this Directory Server instance for any other purposes; the directory schema is configured for storing CS data.

Tokens

You choose either the internal token (if you plan to use the internal/software token) or an external token to store the signing certificate and key pair and the SSL signing certificate and key pair.

If you are using an external token, you will need to install it before you run the Installation Wizard. In the wizard, you can select from a list of already installed and available tokens. For example, SmartCard. For installation instructions, see "External Token" on page 306.

Installing a Certificate Manager

You install the subsystems by installing the CS software on each host in which you will install a subsystem, and then creating an instance of CS in that installation for each subsystem you want to configure on that host. CS provides an Installation Wizard that allows you to choose which subsystem you are installing in a particular instance, and allows you to make some configuration choices for the subsystem, and get and install the certificates used by the subsystem. Once the Certificate Manager is installed, it is set up with a default set of configuration settings. You can change the default settings to meet the needs of your PKI.

Installing a Certificate Manager as a Root CA

To configure the Certificate Manager as a root CA:

1. Log into Red Hat Console as the administrator, see "Red Hat Console" on page 237.
2. Select the CS instance and then either click Open, or double click this instance.

The Installation Wizard launches.

3. Installation Wizard Introduction. Click Next to continue.
4. Logon Token. Choose either internal (if you plan to use the internal/software token) or the name of an external token to store the Certificate Manager signing certificate and key pair. If you have not previously initialized the token's password, you must do so in this screen. See "Tokens," on page 84 for more information.
5. Internal Database. Choose to either create a new internal database for this instance or to use an existing Directory Server instance as the internal database for this instance. Next, specify the information for that Directory Server instance. See "Internal Database," on page 84 for more information.

Click Next to continue. The wizard sets up the new internal database, which takes some time.

6. Administrator. Type the user ID, name, and password for the CS administrator. This user ID will be set up as the administrator who can access the CS window and control all CS settings.

Allow Multiple Roles for Users. Select if you want to allow users to belong to more than one group, thus assuming more than one role. Deselect if you want to restrict users from being able to belong to more than one role. This setting only applies to the default administrator, agent, auditor, and trusted manager roles.

If you select this, allowing users to assume multiple roles, the administrator you set up in this window will be added to the agents group. This administrator will be both an administrator and an agent.

Click Next to continue.

7. Subsystems. Choose the subsystem you want to install.

Select Certificate Manager.

Click Next to continue.

8. Remote Data Recovery Manager. Select the appropriate options:
   • Select No if you don't want to connect the Certificate Manager to a remote Data Recovery Manager.
   • Select Yes if you have already installed a remote Data Recovery Manager that you want the Certificate Manager to use for archiving end users' encryption private keys. Then, enter the remote Data Recovery Manager's host name, agent SSL port number, and the Time-out in seconds in the associated fields.

Click Next to continue.

9. CA's Serial Number Range. Specify the range for the serial numbers for the certificates that this CA will issue. In the "Starting serial number" field, type the lowest serial number the CA should assign to a certificate. If you plan to only use one CA server, you can leave the "Ending serial number" field blank to indicate no upper limit. If you plan to clone the CA to distribute load, you must specify an upper limit. (For cloned CAs, you must make sure that the range of serial numbers does not overlap with any other CA server.)

Click Next to continue.

10. Internal OCSP Services. Select to enable the internal OCSP services.

See "Setting Up a Certificate Manager with OCSP Service," on page 161 for more information.

Click Next to continue.

11. Network Configuration. Type the port numbers for the ports used by this instance, or accept the defaults.

See "Certificate Manager Interfaces," on page 83 for more information.

Click Next to continue.

12. CA Signing Certificate. Select the "Create self-signed CA certificate" option.

Click Next to continue.

13. Key-Pair Information for Certificate Manager CA Signing Certificate.
    • Token. Enter either internal (if you plan to use the internal/software token) or the name of an external token to store the Certificate Manager signing certificate and key pair. If you have not previously initialized the token's password, you must do so now. See "Tokens," on page 84 for more information.
    • Key Type. Choose RSA or DSA.
    • Key Length. Available key sizes for RSA are 512, 768, 1024, 2048, 4096, or Custom. Available key sizes for DSA are 512, 1024, or Custom (which must be in increments of 64 bits only).

See "Signing Key Type and Length" on page 82 for more information.

Click Next to continue.

14. Message Digest Algorithm. Select the algorithm to use for computing the certificate signature. The choices are: MD2, MD5, or SHA-1.

Click Next to continue.

15. Subject Name for Certificate Manager CA Signing Certificate. Type values for the subject DN components; these values identify the root CA signing certificate.

A DN is a series of name-value pairs that in combination uniquely identify an entity. The subject DN identifies the CA signing certificate. You are not required to enter all the values.

See "CA's Distinguished Name" on page 82 for more information.

Click Next to continue.

16. Validity Period for Certificate Manager CA Signing Certificate. Select the validity period for the CA signing certificate. The default validity is two years. The validity period determines how soon you will have to renew the certificate, which can be a complex procedure.

See "CA Signing Certificate's Validity Period" on page 82 for more information.

Click Next to continue.

17. Certificate Extensions for Certificate Manager CA Signing Certificate. Select the required extensions. The default settings should work for most deployments. If necessary, you can add an additional extension by pasting its base-64 encoding in the space provided on this screen.

CS provides command-line tools for generating extensions to include in CA and other certificate requests. For details about these tools, check this directory: <server_root>/bin/cert/tools

Note that the certificate extension text field accepts a single extension blob. If you want to add multiple extensions, you should use the ExtJoiner program, which is also provided in the tools directory. For details on using the ExtJoiner program, see the CS Command-Line Tools Guide.

For more information about extensions, see Appendix G, "Certificate and CRL Extensions."

Click Next to continue.

18. Certificate Manager CA Signing Certificate Creation. Click Next to generate and install the certificate.
19. SSL Server Certificate. Select the "Sign SSL certificate with my CA signing certificate" option. This option enables the wizard to generate an SSL Server Certificate signed with the local CA signing certificate, the root Certificate Manager's CA signing certificate you just created.

Click Next to continue.

20. Key-Pair Information for SSL Server Certificate.
    • Token. Enter either internal (if you plan to use the internal/software token) or the name of an external token. If you have not previously initialized the token's password, you must do so in this screen. See "Tokens," on page 84 for more information.
    • Key Type. Choose RSA.
    • Key Length. Available key sizes for RSA are 512, 768, 1024, 2048, 4096, or Custom. Available key sizes for DSA are 512, 1024, or Custom (which must be in increments of 64 bits only).

See "Signing Key Type and Length" on page 82 for more information.

Click Next to continue.

21. Message Digest Algorithm. Select the algorithm to use for computing the certificate signature. The choices are: SHA-1, MD2, or MD5.

Click Next to continue.

22. Subject Name for SSL Server Certificate. Type the values for the subject DN components; these values identify the root CA's SSL server certificate. The CN must be the fully-qualified host name of the machine on which you're installing the Certificate Manager.

Click Next to continue.

23. Validity Period for SSL Server Certificate. Select the validity period for the SSL server certificate. The validity period determines how soon you will have to renew the certificate.

Click Next to continue.

24. Certificate Extensions for SSL Server Certificate. Select the required extensions. The default settings should work for most deployments. If necessary, you can add an additional extension by pasting its base-64 encoding in the space provided on this screen (see Step 17).

Click Next to continue.

25. SSL Server Certificate Creation. This informational screen tells you that the configuration wizard has all the required information to generate a key pair and its corresponding certificate.

Click Next to generate the certificate.

26. Single Sign-on Summary. Check the summary and select whether to retain or delete the password.conf file. For details, see "Token Password Storage" on page 244.

Click Next to continue.

27. Configuration Status. This screen should indicate that your configuration has been successful.

Click Done to exit the Installation Wizard.

28. You now need to create the first agent user for the Certificate Manager. See "Agent Certificates," on page 324 for details.

Installing a Certificate Manager as a Subordinate CA

To install the Certificate Manager as a subordinate CA:

1. Log into Red Hat Console as the administrator, see "Red Hat Console" on page 237.

The main window of Red Hat Console appears.

2. Select the CS instance and then either click Open, or double click this instance.

The Installation Wizard launches.

3. Installation Wizard Introduction. Click Next to continue.
4. Logon Token. Enter either internal (if you plan to use the internal/software token) or the name of an external token to store the Certificate Manager signing certificate and key pair. If you have not previously initialized the token's password, you must do so in this screen. See "Tokens," on page 84 for more information.
5. Internal Database. Choose to either create a new internal database for this instance or to use an existing Directory Server instance as the internal database for this instance. Next, specify the information for that Directory Server instance. See "Internal Database," on page 84 for more information.

Click Next to continue. The wizard sets up the new internal database, which takes some time.

Click Next to continue.

6. Administrator. Type the user ID, name, and password for the CS administrator. This user ID will be set up as the administrator who can access the CS window and control all CS settings.

Allow Multiple Roles for Users. Select if you want to allow users to belong to more than one group, thus assuming more than one role. Deselect if you want to restrict users from being able to belong to more than one role. This setting only applies to the default administrator, agent, auditor, and trusted manager roles.

If you select this, allowing users to assume multiple roles, the administrator you set up in this window will be added to the agents group. This administrator will be both an administrator and an agent.

Click Next to continue.

7. Subsystems. Choose a subsystem you want to install.

Select Certificate Manager.

Click Next to continue.

8. Remote Data Recovery Manager. Select the appropriate options:
   • Select No if you don't want to connect the Certificate Manager to a remote Data Recovery Manager.
   • Select Yes if you have already installed a remote Data Recovery Manager that you want the Certificate Manager to use for archiving end users' encryption private keys. Then, enter the remote Data Recovery Manager's host name, agent SSL port number, and the Time-out in seconds in the associated fields.

Click Next to continue.

9. CA's serial number range. Specify range for the serial numbers for the certificates that this CA will issue. In the "Starting serial number" field, type the lowest serial number the CA should assign to a certificate. If you only use one CA server, you can leave the "Ending serial number" field blank to indicate no upper limit. If you plan to clone the CA to distribute load, you must specify an upper limit. (For cloned CAs, you must make sure that the range of serial numbers does not overlap with any other CA server.)

Click Next to continue.

10. Internal OCSP Services. Select to enable the internal OCSP services.

See "Setting Up a Certificate Manager with OCSP Service," on page 161 for more information.

11. Network Configuration. Type the port numbers for the ports to be used by the CS instance.

See "Certificate Manager Interfaces," on page 83 for more information.

Click Next to continue.

12. CA Signing Certificate. Select the "Create subordinate CA certificate request" option.

Click Next to continue.

13. Key-Pair Information for Certificate Manager CA signing certificate.
    • Token. Enter either internal (if you plan to use the internal/software token) or the name of an external token to store the Certificate Manager signing certificate and key pair. If you have not previously initialized the token's password, you must do so in this screen. See "Tokens," on page 84 for more information.
    • Key Type. Choose RSA or DSA.
    • Key Length. Available key sizes for RSA are 512, 768, 1024, 2048, 4096, or Custom. Available key sizes for DSA are 512, 1024, or Custom (which must be in increments of 64 bits only).

See "Signing Key Type and Length" on page 82 for more information.

Click Next to continue.

14. Message Digest Algorithm. Select the algorithm to use for computing the certificate signature. The choices are: MD2, MD5, or SHA-1.

Click Next to continue.

15. Subject Name for Certificate Manager CA Signing Certificate. Type values for the subject DN components; these values identify the subordinate CA signing certificate.

A DN is a series of name-value pairs that in combination uniquely identify an entity. The subject DN identifies the CA signing certificate. You are not required to enter all the values.

See "CA's Distinguished Name" on page 82 for more information.

Click Next to continue.

16. Validity Period for Certificate Manager CA Signing Certificate. Select the validity period for the subordinate CA signing certificate. The default validity is two years. The validity period determines how soon you will have to renew the certificate, which can be a complex procedure.

See "CA Signing Certificate's Validity Period" on page 82 for more information.

Click Next to continue.

17. Certificate Extensions for Certificate Manager CA Signing Certificate. Select the required extensions. The default settings should work for most deployments. If necessary, you can add an additional extension by pasting its base-64 encoding in the space provided on this screen.

CS provides command-line tools for generating extensions to include in CA and other certificate requests. For details about these tools, check this directory: <server_root>/bin/cert/tools

Note that the certificate extension text field accepts a single extension blob. If you want to add multiple extensions, you should use the ExtJoiner program, which is also provided in the tools directory. For details about using the ExtJoiner program, see Chapter 5, "Extension Joiner Tool" of CS Command-Line Tools Guide.

For more information about extensions, see Appendix G, "Certificate and CRL Extensions."

Click Next to continue.

18. Certificate Manager CA Signing Certificate Creation. This is an informational screen that tells you that the wizard has all the information required to generate the key pair and certificate request. In the previous screen, if you chose to include the Subject Key Identifier extension in the certificate, you'll be given the choice to select the format for the certificate request. Otherwise, the request format will be PKCS #10.
    • If you want the wizard to generate the certificate request in PKCS #10 format, select the "Generate PKCS10 request" option.
    • If you want the wizard to generate the certificate request in CMC format, select the "Generate CMC full enrollment request" option.

Click Next to generate the request. The wizard creates a certificate request that you must submit to another CA.

19. Submission of Request. Select whether you want to submit the request manually or send the request to a remote Certificate Manager automatically.
    • To automatically submit the request to a remote Certificate Manager (or for automatic enrollment), follow these steps:
      1. Select the "Send the request to a remote CS now" option.
      2. Enter the host name and end-entity port number of the remote Certificate Manager, and select whether this end-entity port is SSL enabled.
      3. Click Next to submit the request.

The Certificate Request Result screen appears, confirming that the request has been submitted. Note the request ID provided in the response message. (You can use it later to retrieve the certificate, once it has been issued, from the end-entity port.)

Note that the request you submitted gets added to the agent queue of the remote Certificate Manager for approval by that Certificate Manager's agent. If you've permission to access that Certificate Manager's Agent interface, you can follow the instructions below to issue the certificate. Otherwise, you should wait for the other agent to approve your request and issue the certificate.

1. Open a web browser window.
2. Enter the URL for the remote Certificate Manager's Agent Services page. (You must have a valid agent's certificate.)
3. Select List Requests, then click Show Pending Requests and click Find. The pending request list is displayed.
4. Locate your request, click Details to see it, and make any changes. Then, scroll down to the bottom of the form and click Do It.
5. After the certificate is generated, click Show Certificate.
6. When the certificate is displayed, scroll down to the base-64 encoded version of the certificate, highlight all the text (including -----BEGIN CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to the clipboard or to a text file.

Be sure to not make any changes to the certificate. You're required to paste the encoded certificate into the Installation Wizard screen next. So, once you've copied the certificate, go back to the wizard screen (Step 20).

• To submit your certificate request manually to a remote Certificate Manager, follow these steps:
  1. Open a web browser window.
  2. Go to the end-entity URL for the remote Certificate Manager that will issue the subordinate CA's signing certificate.

For example, if you assigned the port number 17006 to the non-SSL end-entity port for your root CA, you would go to the URL http://<hostname>:17006 to bring up the Certificate Manager page for end entities.

1. Click Manual Certificate Manager Signing Certificate Enrollment.

In the resulting form, choose the request type from the pull down menu, paste the request into the request field, and fill in the other information in the form.

1. Click Submit.
2. The request gets added to the agent queue of the remote Certificate Manager for approval by that Certificate Manager's agent. If you've permission to access that Certificate Manager's Agent interface, you can follow the instructions below to issue the certificate. Otherwise, you'll have to wait till the remote Certificate Manager's agent approves your request.
3. In the web browser window, enter the URL for the remote Certificate Manager's Agent Services page. (You must have a valid agent's certificate.)
4. Select List Requests, then click Show Pending Requests and click Find.
5. In the pending request list, locate your request, click Details to see the request, and make any changes. Then, scroll down to the bottom of the form, and click Do It.
6. After the certificate is generated, click Show Certificate.
7. When the certificate is displayed, scroll down to the base-64 encoded version of the certificate, highlight all the text (including -----BEGIN CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to the clipboard or to a text file.

Be sure to not make any changes to the certificate. You're required to paste the encoded certificate into the Installation Wizard next. So, once you've copied the certificate, go back to the wizard screen (Step 20).

• To submit your certificate request manually to a third-party CA, follow these steps:
  1. Make sure that the certificate request (including -----BEGIN NEW CERTIFICATE REQUEST ----- and -----END NEW CERTIFICATE REQUEST -----) is highlighted, and click the Copy to Clipboard button.
  2. This action copies the certificate request to the clipboard. In addition to the copy on the clipboard, the screen informs you that the certificate request has been saved to a file. You can use either the copy on the clipboard or the copy in the file to transfer your request to the CA that will issue the subordinate CA's signing certificate.
  3. Submit your certificate request to a third-party CA, following the instructions provided by that CA.

Click Next when you are ready to proceed.

20. CA Signing Certificate Installation. Depending on whether you have the certificate ready for pasting into the Installation Wizard screen, click Yes or No.
    • Select No if you have submitted your request to a third-party CA or to a remote Certificate Manager for which you do not have agent privileges, you may have to wait days or weeks before you receive the certificate. Continue as far as you can with the configuration, and resume after you receive the certificate. The default selection is No.
    • Select Yes if you have the certificate ready in its base-64 encoded format.

Click Next to continue.

• If you selected No, you will be presented with the "SSL Server Certificate" screen (Step 24).
• If you selected Yes, the "Location of Certificate" screen appears (Step 21).
21. Location of Certificate. Specify the location of the certificate. You can use any of these options:
    • If you copied the encoded certificate to a file, select the "The certificate is located in this file" option and then type the file path, including the filename, in the text field.
    • If you copied the certificate to the clipboard, select the "The certificate is located in the text area below" option and then paste in a base-64 encoded certificate (including the header and footer) in the text area provided.
    • If you noted the request ID of your request and know the host name and end-entity port number of the remote Certificate Manager that issued the certificate, select the "The certificate is at the CS server where the request was sent" option and then specify the required details.

Click Next to continue.

22. Certificate Details. This is an informational screen that shows the certificate so you can inspect its contents. Notice the nickname assigned to the certificate and verify that you're installing the correct certificate.

Click Next to continue.

23. Import Certificate Chain. This screen appears only if you need to import the CA certificate chain. If the CA that issued the certificate is a Certificate Manager, follow these steps:
    1. Go to the end-entity URL for the Certificate Manager that issued the subordinate CA's signing certificate.
    2. Select the Retrieval tab, and then choose Import CA Certificate Chain.
    3. Select the "Display the CA certificate chain in PKCS#7 for importing into a server" option, and then click Submit.
    4. Copy the certificate chain to the clipboard.
    5. Return to the Installation Wizard.
    6. Paste the certificate chain into the text box.

Click Next to continue.

24. SSL Server Certificate. Select the appropriate option:
    • If you want to get the SSL server certificate signed by the subordinate CA itself, select the "Sign SSL certificate with my CA signing certificate" option.
    • If you want to submit the SSL server certificate request to another CA, for example to the CA that signed the subordinate CA's signing certificate, select the "Create request for submission to another CA" option.

Click Next to continue.

25. Key-Pair Information for SSL Server Certificate.
    • Token. Enter either internal (if you plan to use the internal/software token) or the name of an external token. If you have not previously initialized the token's password, you must do so in this screen. See "Tokens," on page 84 for more information.
    • Key Type. Choose RSA.
    • Key Length. Available key sizes for RSA are 512, 768, 1024, 2048, 4096, or Custom. Available key sizes for DSA are 512, 1024, or Custom (which must be in increments of 64 bits only).

See "Signing Key Type and Length" on page 82 for more information.

Click Next to continue.

26. Message Digest Algorithm. Select the algorithm to use for computing the certificate signature. The choices are: SHA-1, MD2, or MD5.

Click Next to continue.

27. Subject Name for SSL Server Certificate. Type the values for the subject DN components; these values identify the subordinate CA's SSL server certificate. The CN must be the fully-qualified host name of the machine on which you're installing the Certificate Manager.

Click Next to continue.

28. Certificate Extensions for SSL Server Certificate. Select the required extensions. The default settings should work for most deployments. If necessary, you can add an additional extension by pasting its base-64 encoding in the space provided on this screen. (For details, see Step 17 of this section.)

Click Next to continue.

29. SSL Server Certificate Request Creation. This is an informational screen that tells you that the wizard has all the information required to generate the key pair and certificate request. In the previous screens, if you chose to generate a certificate request and include the Subject Key Identifier extension in the certificate, you'll be given the choice to select the format for the certificate request. Otherwise, the request format will be PKCS #10.
    • If you want the wizard to generate the certificate request in PKCS #10 format, select the "Generate PKCS10 request" option.
    • If you want the wizard to generate the certificate request in CMC format, select the "Generate CMC full enrollment request" option.

Click Next to generate the certificate or the request:

• If you chose to get the certificate signed by the subordinate CA itself, the wizard generates the SSL server certificate. You'll be presented with the "Create Single Sign-on Password" screen (Step 35).
• If you chose to generate a request for submission to another CA, the wizard generates an SSL server certificate request that you must submit to another CA. You'll be presented with the "Submission of Request" screen (Step 30).
30. Submission of Request. Select whether you want to submit the request manually or send the request automatically to a remote Certificate Manager.
    • To automatically submit the request to a remote Certificate Manager (or for automatic enrollment), follow these steps:
      1. Select the "Send the request to a remote CS now" option.
      2. Enter the host name and end-entity port number of the remote Certificate Manager, and specify whether the end-entity port is SSL enabled.
      3. Click Next to submit the request.

The Certificate Request Result screen appears, confirming that the request has been submitted. Note the request ID provided in the response message. (You can use it later to retrieve the certificate, once it has been issued, from the end-entity port.)

Note that the request gets added to the agent queue of the remote Certificate Manager for approval by that Certificate Manager's agent. If you've permission to access that Certificate Manager's Agent interface, you can follow the instructions below to issue the certificate. Otherwise, you should wait for the remote Certificate Manager's agent to approve your request and issue the certificate.

1. Open a web browser window.
2. Enter the URL for the remote Certificate Manager's Agent Services page. (You must have a valid agent's certificate.)
3. Select List Requests, click Show Pending Requests, and then click Find.
4. In the pending request list, locate your request, click Details to see the request, and make any changes. Then, scroll down to the bottom of the form, and click Do It.
5. After the certificate is generated, click Show Certificate.
6. When the certificate is displayed, scroll down to the base-64 encoded version of the certificate, highlight all the text (including -----BEGIN CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to the clipboard or to a text file.

Be sure to not make any changes to the certificate. You're required to paste the encoded certificate into the Installation Wizard next. So, once you've copied the certificate, go back to the wizard screen (Step 31).

• To submit your certificate request manually to a remote Certificate Manager, follow these steps:
  1. Open a web browser window.
  2. Go to the end-entity URL for the remote Certificate Manager that will issue the subordinate CA's SSL server certificate.

For example, if you assigned the port number 17006 to the non-SSL end-entity port for your root CA, you would go to the URL http://<hostname>:17006 to bring up the Certificate Manager page for end entities.

1. Click Manual Server Certificate Enrollment, or click Agent-Based Server Certificate Enrollment if you have an agent certificate. If you choose Agent-Based Server Certificate Enrollment and you have an agent certificate, the certificate will be automatically issued once you submit the request.

In the resulting form, choose the type of request from the pull down menu, paste the request in the request field, and fill in the other fields on the form.

1. Click Submit.
2. If you used the Agent-Based Server Certificate Enrollment and you have an agent certificate, the certificate will be automatically issued once you submit the request.

If you used the Manual Server Certificate Enrollment request, the request gets added to the agent queue of that Certificate Manager for approval by that Certificate Manager's agent. If you've permission to access that Certificate Manager's Agent interface, you can follow the instructions below to issue the certificate. Otherwise, you'll have to wait for the Certificate Manager's agent to approve your request and issue the certificate.

To approve the request, do the following:

In the web browser window, enter the URL for the Certificate Manager's Agent Services page. (You must have a valid agent's certificate.)

Select List Requests, then click Show Pending Requests and click Find. The pending request list is displayed.

Locate your request, click Details to see it, and make any changes. Then, scroll down to the bottom of the form, select the appropriate action.

1. After the certificate is generated, click Show Certificate.
2. When the certificate is displayed, scroll down to the base-64 encoded version of the certificate, highlight all the text (including -----BEGIN CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to the clipboard or to a text file.

Be sure to not make any changes to the certificate. You're required to paste the encoded certificate into the Installation Wizard next. So, once you've copied the certificate, go back to the wizard screen (Step 31 below).

• To submit your certificate request manually to a third-party CA, follow these steps:
  1. Make sure that the certificate request (including -----BEGIN NEW CERTIFICATE REQUEST ----- and -----END NEW CERTIFICATE REQUEST -----) is highlighted, and click the Copy to Clipboard button.

This action copies the certificate request to the clipboard. In addition to the copy on the clipboard, the screen informs you that the certificate request has been saved to a file. You can use either the copy on the clipboard or the copy in the file to transfer your request to the CA that will issue the subordinate CA's SSL server certificate.

1. Submit your certificate request to a third-party CA, following the instructions provided by that CA.

Click Next when you are ready to proceed to the next screen.

31. SSL Server Certificate Installation. Depending on whether you have the certificate ready for pasting into the Installation Wizard screen, click Yes or No.
    • If you have submitted your request to a third-party CA or to a remote Certificate Manager for which you do not have agent privileges, you may have to wait days or weeks before you receive the certificate. In this case, you should click No, continue as far as you can with the configuration, and resume after you receive the certificate. The default is No. If you selected No, you will be presented with the "Create Single Sign-on Password" screen.
    • Select Yes, only if you have the certificate ready in its base-64 encoded format.

Click Next to continue.

• If you selected Yes, the "Location of Certificate" screen appears (Step 32).
• If you selected No, you will be presented with the "Create Single Sign-on Password" screen (Step 35).
32. Location of Certificate. Specify the location of the certificate. You can use any of these options:
    • If you copied the encoded certificate to a file, select the "The certificate is located in this file" option and then type the file path, including the filename, in the text field.
    • If you copied the certificate to the clipboard, select the "The certificate is located in the text area below" option and then paste in a base-64 encoded certificate (including the header and footer) in the text area provided.
    • If you noted the request ID of your request and know the host name and end-entity port number of the remote Certificate Manager that issued the certificate, select the "The certificate is at the CS server where the request was sent" option and then specify the required details.

Click Next to continue.

33. Certificate Details. This is an informational screen that displays the certificate so you can inspect its contents. Notice the nickname assigned to the certificate and verify that you're installing the correct certificate.

Click Next to continue.

34. Import Certificate Chain. This screen appears only if you need to import the CA certificate chain. If the CA that issued the certificate is a Certificate Manager, follow these steps:
    1. Go to the end-entity URL for the remote Certificate Manager that issued the SSL server certificate.
    2. Select the Retrieval tab, and then in the left-hand frame, click Import CA Certificate Chain.
    3. Select the "Display the CA certificate chain in PKCS#7 for importing into a server" option, and then click Submit.
    4. In the resulting form, locate the CA certificate chain, in its base-64 encoded format, to the clipboard.
    5. Return to the Installation Wizard.
    6. Paste the certificate chain into the text box.

Click Next to continue.

35. Single Sign-on Summary. Check the summary and select whether to retain or delete the password.conf file. For details, see "Token Password Storage" on page 244.

Click Next to continue.

36. Configuration Status. This screen should indicate that your configuration has been successful.

Click Done to exit the Installation Wizard.

37. You now need to create the first agent user for the Certificate Manager. See "Agent Certificates," on page 324 for details.

Configuring the Certificate Manager

This section lists the areas that you can configure for the Certificate Manager, gives a description of that area, and points you to specific information on configuring that set of features.

Adding Users

Once the Certificate Manager is installed, you need to add users and assign them to the administrator, agent, or auditor roles. If you selected the option to have the administrator created during installation also act as an agent, then the administrator is your first agent. If you did not, you need to create an agent user who can access the agent services interface. See Chapter 9, "Authorization" for details on adding users and assigning them to groups.

Configuring Authorization

Each subsystem has a set of predefined roles that are assigned a default set of privileges. You create users in the CS database and then assign them to a group to give them the privileges of that group. The privileges assigned to a group are controlled by Access Control Instructions (ACIs) placed in Access Control Lists (ACLs). ACLs define points that need specific authorization. Generally, each defines a distinct set of functionality for the server. ACIs define what operations can or cannot be performed by a user, group, or IP address for that particula