Administrator's Guide Netscape Certificate Management System

Previous      Contents      Index      DocHome      Next

Chapter 9   Authorization

This chapter explains how to set up authorization for access to the administrative, agent services, and end-entity interfaces and contains the following sections:

• About Authorization
• Setting up Administrators, Agents, and Auditors
• Setting Up a Trusted Manager
• Agent Certificates
• Modifying CMS User Entries
• Creating a New Group
• Authorization for CMS Users
• ACL Reference

About Authorization

---

Authorization is the process of allowing access to certain tasks associated with Netscape Certificate Management System (CMS). The authorization model is very flexible allowing you to configure it to your needs.

In order to authorize users, you create users in CMS. These users are specific to the subsystem in which you create them, each subsystem has its own set of users independent of any other subsystem you may have installed. The user's are placed in groups that are either predefined, or that you have created. Privileges are assigned to a group through ACLs. There are ACLs associated with the areas in the administrative, agent services interface, and end-entity interface that perform an authorization check before allowing an operation to be performed in that area. Access Control Instructions (ACI s) in each of the ACLs are created that specifically allow or deny one or more possible operations for that ACL to specified users, groups, or IP addresses.

The ACLs contain a default set of ACIs for the default groups that are created. You can change those ACIs to change the privileges of those predefined groups, or create groups of your own assigning the new group privileges by adding or modifying ACI's for the new group in the ACLs.

How Authorization Works

The following is the process that defines authorization:

1. Users authenticates to the interface they are trying to access either using their CMS user ID and password or with a certificate.
2. The server authenticates them either by matching their user ID and password with the one stored in the database, or by checking their certificate against one stored in the database. With certificate-based authentication, the server also checks that the certificate is valid, and finds the group membership of the user by associating the DN of the certificate with a user and determining the user's group membership. With password based authentication, the server checks the password against the user ID, and then finds the group membership of the user by associating that user ID with the user ID contained in the group.
3. When the user tries to perform an operation, the authorization mechanism checks that the user ID of the user, the group in which the user belongs, or the IP address of the user is allowed to perform that operation by checking the ACLs for this process to determine if an ACI exists that allows this operation to be performed by this user, group, or IP address.

Default Groups

A user's privileges are determined by the group membership of the user. When you install the subsystem you are given the choice of whether to allow membership of users in more than one group. The default setting allows users to belong to more than one group. If you changed this setting in the install wizard, users are not allowed to belong to more than one group.

The following groups are created by default:

Administrators. This group is given full access to all of the tasks available in the administrative interface.

Agents. This group is given full access to all of the tasks available in the agent services interface.

Note: There is more than one agent group. A separate agent group is created for each of the subsystem with a different name. Be careful to use the correct agent group name when modifying ACLs. See "Groups for Agents".

Auditors. This group is given access to view the signed audit logs. This group does not have any other privileges.

Trusted Managers. A trusted manager is a subsystem that has a trusted relationship with another subsystem. This group is given access to connect with and submit requests to the subsystem in which it is a trusted manager.

Administrators

Administrators have permissions to perform all the administrative tasks. You create administrators by creating a user entry for the administrator and adding them to the group called Administrators, every member of this group has administrative privileges for this instance of CMS.

At least one administrator must be defined for each CMS instance, there is no limit to the number of administrators an instance can have. You specify the user ID and password of the first administrator during installation.

Authentication of Administrators

Administrators are authenticated using their CMS user ID and password.

You can change the method of authentication for an administrator to SSL client authentication. See "Setting up Certificate Authentication for the CMS Console" for complete details.

Auditors

An auditor can view the signed audit logs. An auditor is set up to audit the operation of the system. The auditor cannot administer the server in any way except to view the audit logs.

You set up an auditor by creating a user, adding them to the Auditors group, and storing the auditors certificate. The auditors certificate is used to encrypt the private key of the key pair used to sign the audit log.

An auditor group is set up when you configure a subsystem. No auditors are assigned to this group during configuration.

Authentication of Auditors

Auditors are authenticated into the CMS console by using their login and password. Once authenticated, they can only view the audit logs, they are not able to edit other parts of the system.

You can change the method of authentication for an auditor to SSL client authentication. See "Setting up Certificate Authentication for the CMS Console" for complete details.

Agents

Agents are users who have been assigned end-entity certificate- and key-management privileges. Agents can access the agent services interface, and perform tasks associated with their subsystem in that interface. For a complete list of agent tasks, see the CMS Agent's Guide.

You create agents by creating a user, assigning membership in the appropriate agent group, and identifying certificates that the agents must use for SSL client authentication to the subsystem (for it to service requests from the agents).

Each CMS subsystem has its own agents whose role is defined by the subsystem. Each subsystem installed in a CMS instance must have at least one agent, and there is no limit to the number of agents a subsystem can have.

Authentication of Agents

CMS identifies and authenticates a user with agent privileges by checking the user's SSL client certificate in its internal database. See "Agent Certificates".

For information on obtaining and revoking agent certificates, see "Revocation Status Checking of Agent Certificates".

Groups for Agents

Each substystem has its own agent group:

• Certificate Manager Agents group is the agent group for a Certificate Manager. During installation the administrator can be designated as the first agent; you are given a choice to add the administrator to the agents group. Note that this choice also enables or disables the ability to add users to multiple groups. If you choose to enable this feature, users can be assigned to more than one group. If you disable this feature, users will not be allowed to be added to more than one group.
• Registration Manager Agents group is the agent group for a Registration Manager. No members are added to this group during installation, you must add members after installation.
• Data Recovery Manager Agents group is the agent group for a Data Recovery Manager. No members are added to this group during installation, you must add members after installation.
• Online Certificate Status Manager Agents group is the agent group for an Online Certificate Status Manager. No members are added to this group during installation, you must add members after installation.

Trusted Managers

One subsystem can allow another subsystem to communicate via its agent port and perform certain functions for that subsystem by forming a trust between the two. The subsystem that is trusted is called a trusted manager.

The trusted manager relationship is set up in the following way:

• The subsystem that trusts sets up the other subsystem as a trusted manager by creating a user ID for the subsystem, adding it to the trusted manager group, and storing its SSL client authentication certificate.
• The trusted manager sets up a connector to subsystem it trusts, allowing it to communicate with the subsystem. It does this by specifying the agent services port information for that subsystem.

Possible Trusted Relationships

The Registration Manager and Certificate Manager can function as a trusted manager; the Data Recovery Manager and Online Certificate Status Manager cannot function as a trusted manager. The following trusted relationships can be created:

• A Registration Manager or a Certificate Manager as a trusted manager to a Certificate Manager. This would usually be a Registration Manager, but a Certificate Manager could be a trusted manager to another Certificate Manager in a cloned-CA setup. See "Cloning a CA" for more information.

You can configure a Certificate Manager to delegate its end-entity interactions to a trusted Registration Manager or Certificate Manager, for reasons of localizability (proximity to end entities), customizability, security reasons, and CA scalability; the Certificate Manager trusts the Registration Manager and processes all certificate requests sent by this Registration Manager.
 

• Registration Manager or a Certificate Manager as a trusted manager to a Data Recovery Manager.

You can configure a Data Recovery Manager to delegate its end-entity interactions to a trusted Certificate Manager or Registration Manager for security reasons; the Data Recovery Manager trusts the Certificate Manager or Registration Manager and services all key archival and recovery requests initiated by this subsystem.
 

Trusted Manager's Certificate for SSL Client Authentication

A Registration Manager or Certificate Manager that has been set up to function as a trusted manager uses its SSL server certificate for SSL client authentication to the subsystem that trusts it.

Setting up Administrators, Agents, and Auditors

---

To set up an administrator, agent, or auditor, you create a user in the CMS instance where you want to give this user privileges and assign the user to the group having those privileges. For an agent or auditor, you also need to get a certificate and store the certificate in the internal database. If you set up the CMS console for SSL client authentication, you must also import a certificate for all administrators.

Creating a User and Assigning Them to a Group

The following procedure can be used to create any user and assign them to any group. There is also an automated process for creating an agent. See "Setting up Agents Using the Automated Process" for information about this process.

To set up a trusted manager, see "Setting Up a Trusted Manager". The process for setting up trusted managers varies somewhat from this process.

To create a CMS user and assign them to a group:

1. Log in to the CMS console, see Logging Into the CMS Console.
2. In the navigation tree, select Users and Groups. Click Add.

The Edit User Information dialog appears.
 

3. Specify the following information in the Edit User Information dialog:

User ID. Type a user ID for the user. The user ID can be an alphanumeric string of up to 255 characters. This is the user ID used to log into the CMS console.
 

Full name. Type the user's full name. The name can be an alphanumeric string of up to 255 characters.
 

Password. Type a password of up to eight characters for the user. This is the password used to log into the CMS console for this user ID.
 

Confirm password. Retype the password.
 

Email. Type the user's complete email address.
 

Phone. Type the user's phone number.
 

Group. Select the correct group.
 

4. Click OK.

You are returned to the Users tab. The user you just added will be displayed in the list of users, and the user ID now has the privileges of the group they are assigned in this instance of CMS.
 

5. Click Refresh to view the updated configuration.
6. Store the user's certificate if the user is an agent or auditor, or if the user is an administrator and SSL client authentication is enabled for the CMS console. See "Storing a User's Certificate" for details about storing a user's certificate.

Storing a User's Certificate

To store the certificate of a user:

1. Log in to the CMS console (see Logging Into the CMS Console).
2. In the navigation tree, select Users and Groups.

The Users tab appears.
 

3. In the Users tab, click Certificates.

The Manage User Certificates dialog opens.
 

4. Click Import.

The Import Certificate dialog opens.
 

5. Click inside the text area, and paste the user's certificate in base-64 encoded form.

Be sure to include the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines.
 

6. Click OK.

You are returned to the Manage User Certificates window. The certificate you imported should now be listed in this window.
 

7. To view the certificate you imported, select it and click View.

The certificate information appears.
 

8. Click Done.

You are returned to the Users tab.
 

9. Click Refresh to view the updated configuration.

Setting up Agents Using the Automated Process

(Not for certificate profile enrollment)

CMS automates the process of setting up agents if agents request their certificate using the manual enrollment form. The automated process is built into the request-approval form in the Agent Services interface and it enables those who have both Certificate Manager agent and Administrator privileges to create new agents for a Certificate Manager subsystem—this automated process does not work for the other subsystems. If this option is selected when an agent approves the request, the user is automatically created in the database, is assigned to the correct agent group, and their certificate is stored in the database.

Note: This process will not work if you create a custom agents group.

If you want to test this feature, follow these steps:

1. Have the agent access the end-entity interface.
2. In the Enrollment tab, under Browser, they select Manual.
3. In the enrollment form that appears, have the agent enter the data and submit the request.
4. You then access the Certificate Manager Agent Services interface.
5. Click List Requests.
6. In the page that displays, select "Show pending requests" and click Find.
7. In the list of certificate signing requests that displays, select the request the agent submitted.
8. In the request approval form for user enrollment requests, verify the request. If required, adjust some of the parameters such as the subject name and validity period.
9. Select "This certificate is for a Certificate Manager agent", specify a user ID for the new agent, and approve the certificate request.

The Certificate Manager processes the request, issues the certificate to the user, and automatically adds the user to the agent group, copies the user's client certificate to the database, and associates the certificate with the new user's entry.
 

10. To verify, log in to the CMS console for the Certificate Manager.
11. In the navigation tree, click Users and Groups. The user ID you specified for the new agent will be listed there.
12. To view the certificate issued to the new agent, select the user ID and click Certificates.

Setting Up a Trusted Manager

---

You can set up a trusted manager in two ways. The first is an automated processes that creates the trusted relationship when the certificate for the subsystem is approved. The automated processes is not available with the certificate profile enrollment. The second is a manual process of creating a user ID, assigning the user ID to the Trusted Manager group, and storing the certificate of the trusted manager.

Setting up Trusted Managers Using the Automated Process

(Not for certificate profile enrollment)

The automated process for setting up a trusted manager is contained in the request-approval form in the agent services interface of the Certificate Manager allowing an agent, who also has administrative privileges to this Certificate Manager, to designate a subsystem a trusted manager when the subsystem gets its certificate. Once the subsystem has been designated a trusted manager in the certificate request, and the request has been approved, the Certificate Manager automatically creates a user ID for the subsystem, adds this user ID to the Trusted Managers group, copies the certificate to the database, and associates the certificate with the subsystem's user entry.

This automated process can be used to set up trusted managers when either a Certificate Manager makes its SSL server certificate request to a Certificate Manager that will trust it, or when a Registration Manager makes its signing certificate request to a Certificate Manager that will trust it. This automated process cannot be used to establish a trusted relationship with a Data Recovery Manager; you must set up a trusted relationship with a Data Recovery Manager manually.

To use the automated process, the following has to happen:

• The subsystem that will be trusted makes its signing certificate request to the Certificate Manager.
• A user who has both administrator and agent privileges with the Certificate Manager providing trust designated this subsystem as a trusted manager by doing the following:
• Selecting "This certificate is for a Trusted Manager" in the request-approval form for this certificate.
• Providing a user ID for the subsystem.
• Approving the request.

Setting Up a Trusted Managers Manually

If you set up a Certificate Manager or a Registration Manager using the automated process either during or after installation, you do not need to perform any of the manual setup for a trusted manager.

To set up a Certificate Manager or Registration Manager as a trusted manager for a Certificate Manager or Data Recovery Manager:

1. Log in to the CMS console for the Certificate Manager or a Data Recovery Manager in which this Registration Manager or Certificate Manager will be a trusted manager, see Logging Into the CMS Console.
2. In the navigation tree, select Users and Groups. Click Add.

The Edit User Information dialog opens.
 

3. Specify information as appropriate.

The information you enter here is to help you keep track of the Registration Manager or Certificate Manager; the subsystem never uses it. The subsystem relies solely on the Registration Manager's signing certificate or Certificate Manager's SSL client certificate for authentication.
 

User ID. Type the Registration Manager's or Certificate Manager's instance ID. The ID can be an alphanumeric string of up to 255 characters.
 

Full name. Type the fully qualified host name of the Registration Manager or Certificate Manager.
 

Group. Select Trusted Managers.
 

4. Click OK.

You are returned to the Users tab. The Registration Manager or Certificate Manager you just added appears in the list of users.
 

Next you need to store the Registration Manager's signing certificate or Certificate Manager's SSL client certificate in the internal database of the subsystem.
 

5. In the Users tab, select the user entry you just added for the Registration Manager or Certificate Managerand click Certificates.

The Manage User Certificates dialog opens.
 

6. Click Import.

The Import Certificate dialog opens.
 

7. Click inside the text area, and paste the Registration Manager's or Certificate Manager's certificate in base-64 encoded form.

Be sure to include the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines.
 

8. Click OK.

You are returned to the Manage User Certificates window. The certificate you imported should now be listed in this window.
 

9. To view the certificate you imported, select it and click View.

The certificate information appears. Verify that the certificate you added is the correct one.
 

10. Click Done.

You are returned to the Users tab.
 

Next, you configure the connector settings of the Registration Manager or Certificate Manager. This enables the Registration Manager or Certificate Manager to utilize the agent port to communicate with the subsystem.
 

Note that during the installation of a Certificate Manager, you were prompted to specify the host name and port number of the Data Recovery Manager to which the Certificate Manager will be connected. If you specified this information, the connection has already been made, you do not need to perform the rest of this procedure.
 

11. Log in to the CMS console for the Registration Manager or Certificate Manager (see Logging Into the CMS Console).
12. In the navigation tree, select Registration Manager or Certificate Manager.

The General Settings tab appears in the right pane.
 

13. Select the Connectors tab.
14. In the "List of connectors" select the connector:
• If you are connecting the Registration Manager or Certificate Manager to a Certificate Manager, select Certificate Manager Connector and click Edit.
• If you are connecting the Registration Manager or Certificate Manager to a Data Recovery Manager, select Data Recovery Manager Connector and click Edit.

The Edit Connector dialog opens.
 

15. Select Enable to enable the connector configuration, and enter the appropriate information:

Host. Type the fully qualified host name of the subsystem that trusts this Registration Manager or Certificate Manager.
 

Port. Type the number of the TCP/IP port number of the agent port for the subsystem that trusts this Registration Manager or Certificate Manager.
 

Timeout. Specify the connection timeout. The default is 30 seconds.
 

16. Click OK.

You are returned to the Connectors tab.
 

17. To save your changes, click Save.

Agent Certificates

---

All agents must have an agent's certificate. This certificate is used to sign all requests made by the agent. This section details the procedure for getting agent certificates, and turning on the revocation status checking of agents' certificates.

There is a special form for an administrator to get the first agent certificate from CMS for the Certificate Manager administrator set up during installation to be able to access the agent's services interface. See "First Agent Certificate for a Certificate Manager" for details.

A generalized procedure for getting an agent certificate from a public CA or from CMS is included here for your convenience. See "Getting an Agent's Certificate from a Public CA" and "Getting an Agent's Certificate from Certificate Management System".

You can set up a feature that checks the revocation status of agent certificates. See "Revocation Status Checking of Agent Certificates" for details about setting up this feature.

First Agent Certificate for a Certificate Manager

CMS adds the administrator set up during installation of a Certificate Manager as the first agent if this option is selected during installation. A special agent enrollment form is provided for this administrator to get the agent certificate. This form is automatically disabled after this initial request is approved and the certificate is issued. This is done so that no one else can acquire a certificate without agent approval or some form of automated authentication.

To get the first agent certificate:

1. Go to the following URL: https://<hostname>:<admin_port>/ca/adminEnroll.html

where:

<hostname>	Is the fully qualified name of the machine on which CMS is installed; for example, CAmachine.example.com.
<admin_port>	Is the TCP port specified during installation for administration over SSL.


 

2. Fill in the following fields of the Administrator/Agent Certificate Enrollment form:

Authentication Information
 

User ID. Type the ID you entered for the CMS administrator during installation.
 

Password. Type the password you specified for the CMS administrator during installation.
 

Subject Name
 

The subject name is the distinguished name (DN) that identifies the certified owner of the certificate.
 

Full name. Type the name of the administrator/agent.
 

Login name. Type the user ID of the administrator/agent.
 

Email address. Type the email address of the administrator/agent.
 

Organization unit. Type the name of the organization unit to which the administrator/agent belongs.
 

Organization. Type the name of the company or organization the administrator/agent works for.
 

Country. Type the two-letter code for the administrator/agent's country.
 

Validity.
 

Set certificate validity period by selecting dates, for which certificate is not valid before and not valid after.
 

3. Click Submit.
4. Follow the instructions your browser presents as it generates a key pair.
5. If authentication is successful, the new certificate will be imported into your browser.

You should make a backup of this certificate. If this is not the computer you will use to access the agent services interface, you should import this certificate into the browser on the computer you will use.
 

This certificate allows you to access the Agent Services pages.

Important

After you submit the initial Administrative Enrollment form and the certificate is issued, the form is no longer available from the administration port. If something goes wrong and you are unable to obtain the administrator/agent certificate, you must reset a parameter in the configuration file to make the initial administrative enrollment form available again.

To reset the Administrative Enrollment form:

1. Stop the server instance.
2. Go to the following directory:

<server_root>/cert-<instance_id>/config
 

3. Open the file CMS.cfg in a text editor.
4. Change the value of the following parameter from false to true:

cmsgateway.enableAdminEnroll=false
 

5. Save the file.
6. Start the server instance.
7. The next time you access the administration port, the Administrator/Agent Certificate Enrollment form will be available again.

Getting an Agent's Certificate from a Public CA

The following general guidelines explain how a user can get a client certificate from a public CA and how you can copy that certificate (in base-64 encoded form) to the internal database of the appropriate subsystem:

1. Have the user send a client certificate request to a public CA from the computer they will use to access the subsystem from the Agent Services interface. It is important that they generate and submit this request from the computer they will use later to access the subsystem, because part of this request process generates a private key on the local machine. Alternatively, if location independence is required, they can use a hardware token, such as a smart card, to generate and store the key pair (and the certificate when they receive it from the public CA).
2. When they receive the certificate from the public CA, have them import the certificate into the web browser used to access the subsystem. It is a good idea to ask the user to inform you that the certificate has been installed.
3. Ask the user to send you the certificate information sent by the public CA. In the information that you receive, locate the user's certificate in base-64 encoded form.

You can also get the user's certificate from the public CA that issued it. Access the public CA site, search for the user's certificate, and locate the certificate in base-64 encoded form.
 

4. Copy the base-64 encoded certificate, including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines, to a text file.
5. Save the text file and use it to store a copy of the certificate in a subsystem's internal database. See "Setting up Administrators, Agents, and Auditors"

Getting an Agent's Certificate from Certificate Management System

The following general instructions explain how a user can get a client certificate from CMS and how you can copy that certificate (in base-64 encoded form) to the internal database of a subsystem:

1. The user sends a client certificate request to CMS from the computer that they will use to access the subsystem from the Agent Services interface. It is important that user generate and submit this request from the computer they will use later to access the subsystem, because part of this request process generates a private key on the local machine. Alternatively, if location independence is required, the user can also use a hardware token, such as a smart card, to generate and store the key pair (and the certificate when the user receives it from the public CA).
2. Depending on how your system is configured for certificate issuance, one of the following events happen:
• If CMS is configured for manual certification, an issuing agent must process the request and approve it for issuance. Once the request is approved, the server issues the client certificate to the user.
• If CMS is configured for automated certification and the request passes authentication and policy checks, the server automatically issues the client certificate to the user.
3. When the user receives the certificate, the user must import the certificate into the web browser they will use to access the subsystem. It is a good idea to ask the user to inform you that the certificate has been installed.

After the user imports the certificate into the web browser, you need to copy the certificate (in base-64 encoded form) in order to be able to add it to a subsystem's internal database.
 

4. Access the end entities interface.
5. Click the Retrieval tab.
6. In the left frame, click either the List Certificates or Search For Certificates link, and search for the user's certificate.
7. In the page listing the results of your search, click the Details button (next to the corresponding user's entry) to see detailed information about the certificate.
8. Scroll down to the Installing This Certificate in a Client section containing the user's certificate in base-64 encoded form.
9. Copy the base-64 encoded certificate, including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines, to a text file.
10. Save the text file and use it to store a copy of the certificate in a subsystem's internal database. See "Setting up Administrators, Agents, and Auditors".

Revocation Status Checking of Agent Certificates

You can configure a Certificate Manager and Registration Manager to check the revocation status of an agent's certificate the server receives during SSL client authentication. You can configure a Data Recovery Manager (or Online Certificate Status Manager) to check the revocation status of its agents' certificates only if you have deployed an OCSP responder and have issued agent certificates with Authority Information Access extension pointing to the OCSP responder. For information about adding Authority Information Access extension to certificates, see Configuring Policy Rules for a Subsystem. For information about setting up an OCSP responder, see Chapter 5 "OCSP Responder."

Note	The CMS configuration file (CMS.cfg) includes a parameter named jss.ocspcheck.enable, which enables you to specify whether a CMS manager should use Online Certificate Status Protocol (OCSP) to verify the revocation status of the certificate it receives as a part of SSL client or server authentication (from clients or servers it makes connections with). If you change the value of this parameter to true, the CMS manager reads the Authority Information Access extension in the certificate and verifies the revocation status of the certificate from the OCSP responder specified in the extension.

The configuration files of both Certificate Manager and Registration Manager include parameters that enable you to specify whether the server should do the revocation checking and if it should, at what interval. Note that the revocation-status verification works for only those agent certificates that have been issued by the Certificate Manager (and not by any third-party CAs).

To configure a Certificate Manager or Registration Manager to verify the revocation status of its agents' certificates:

1. Stop the CMS instance; see Starting, Stopping, and Restarting CMS Instances.
2. Go to the following directory:

<server_root>/cert-<instance_id>/config
 

3. Open the CMS.cfg file in a text editor.
4. Edit the following parameters as appropriate.

revocationChecking.bufferSize	Specifies the total number of last-checked certificates the server should maintain in its cache. For example, if you configure the buffer size to be 2, the server retains the last two certificates it checked in its cache. By default, the server caches the last 50 certificates.
revocationChecking.<subsystem>	Specifies the name of the CMS instance. <subsystem> indicates whether the subsystem is a Certificate Manager (ca) or Registration Manager (ra). You must not change the default values.
revocationChecking.enabled	Specifies whether revocation checking is enabled or disabled. To enable the feature, enter true; to disable the feature, enter false. By default, the feature is enabled.
revocationChecking. unknownStateInterval	The default interval is 0 seconds.
revocationChecking. validityInterval	Specifies how long, in seconds, the cached certificates are considered valid. Be judicious when choosing the interval, especially when configuring a Registration Manager. For example, if you configure the validity period to be 60 seconds, the server discards the certificates in its cache every minute and attempts to retrieve them from their source—the Certificate Manager uses its internal database to retrieve and verify the revocation status of the certificates, whereas the Registration Manager retrieves certificates from its own internal database and then requests the Certificate Manager for the revocation status of these certificates. The default validity period is 120 seconds (2 minutes).




5. Save your changes, and close the configuration file.
6. Start the CMS instance; see Starting, Stopping, and Restarting CMS Instances.

Modifying CMS User Entries

---

You can change a user entry, delete the user, or change the certificate associated with the user.

Changing a CMS User's Login Information

To change a CMS user's login information:

1. Log in to the CMS console (see Logging Into the CMS Console).
2. In the navigation tree, select Users and Groups.

The Users tab appears in the right pane.
 

3. In the User ID list, select the user you want to edit, and click Edit.

The Edit User Information dialog opens.
 

4. Make the appropriate modifications.
5. Click OK.

You are returned to the Users tab.
 

6. Click Refresh to view the updated configuration.

Changing a CMS User's Certificate

To change a CMS user's certificate:

1. Log in to the CMS console (see Logging Into the CMS Console).
2. In the navigation tree, select Users and Groups.

The Users tab appears in the right pane.
 

3. In the User ID list, select the user whose certificate information you want to change, and click Certificates.

The Manage User Certificate dialog opens.
 

4. Take the appropriate action:
• To view a certificate, select the certificate and click View.
• To delete a certificate, select the certificate and click Delete.
• To add a new certificate for this user to the internal database, click Import. In the Import Certificate window that appears, paste the new certificate in the text area. Be sure to paste the entire base-64 encoded block, including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines.
5. Click Done.

You are returned to the Users tab.
 

6. Click Refresh to view the updated configuration.

Changing Members in a Group

You can add or remove members from all groups. Keep in mind that the group for administrators must have at least one user entry.

To change a group's members:

1. Log in to the CMS console (see Logging Into the CMS Console).
2. In the navigation tree, select Users and Groups.

The Users tab appears in the right pane.
 

3. Click the Groups tab.
4. In the Group Name list, select the group you want to change, and click Edit.

The Edit Group Information dialog opens.
 

5. Make the appropriate changes:
• To change the group description, type a new description in the "Group description" field.
• To remove a user from the group, select the user and click Delete.
• To add users, click Add User. In the Select window that appears, select the users you want to add and click OK. You are returned to the Edit Group Information window.
6. Click OK when you are done with the changes.

You are returned to the Groups tab.
 

7. Click Refresh to view the updated configuration.

Deleting a CMS User

You can delete CMS users from the internal database. Deleting a user from the internal database deletes that user from all groups to which the user belongs. If you want to delete a user from specific groups, you should modify the appropriate groups; for details, see Changing Members in a Group.

To delete a privileged user from the internal database:

1. Log in to the CMS console (see Logging Into the CMS Console).
2. In the navigation tree, select Users and Groups.

The Users tab appears in the right pane.
 

3. In the User ID list, select the user you want to delete, and click Delete.
4. When prompted, confirm your action.

If you click YES, the user entry is deleted from the internal database.

Creating a New Group

---

To create a new group:

1. Log in to the CMS console for CMS instance, see Logging Into the CMS Console.
2. In the navigation tree, select Users and Groups.
3. Select the Group tab.
4. Click Edit.

The Edit Group Information window appears.
 

5. Specify information in the following fields:

Group name. Type a name for this group.
 

Group description. Type a description for this group.
 

Users. Select users to add to this group by clicking Add and adding users from the Add User window. You can only add users who already exist in the internal database.
 

6. Edit the ACLs to give this group the privileges you want this group to have. See "Authorization for CMS Users" for complete information. If you don't add ACIs to the ACLs giving this group permissions, the group will have no access permissions to any part of CMS.
7. Click Refresh to view the new group.

Authorization for CMS Users

---

Authorization is the mechanism that checks whether or not a user is allowed to perform a certain operation. Authorization points are defined in certain groups of operations that requiring an authorization check of the user.

Access Control Lists (ACLs)

Access Control Lists (ACLs) are the mechanism that specifies the authorization to each of the sets of operations that require authorization. An ACL exists for each set of operations where an authorization check occurs. You can define additional operations to a ACL, or additional sets of operations by adding this checking to that resource using the CMS SDK.

Access Control Instructions (ACIs)

The ACL contains Access Control Instructions (ACIs) which specifically allow or deny operations such as read or modify for this set of operations. The ACI also contains an evaluator expression. The default implementation of ACLs specifies only users, groups, and IP addresses as possible evaluator types, although you could create others using the CMS SDK. Each ACI in an ACL specifies that access is allowed or denied, what the specific operator is being allowed or denied, and which user(s), group(s), or IP address(es) is being allowed or denied to perform the operation.

Changing Privileges

You can change the privileges of CMS users by changing the Access Control Lists (ACL) that are associated with the group in which the user is a member, for the users themselves, or for the IP address of the user. You can also create groups and assign access control to each group by adding that group to the access control lists. For example, you can create a group for administrators who are only authorized to view logs. You could name the group LogAdmins and modify the ACLs relevant to logs to allow read or modify access to this group. If you did not add this group to any other ACLs, members of this group would only have access to the logs.

How ACIs are Formed

You change the access for a user, group, or IP address by editing the ACI entries in the ACLs. You can change who is allowed or denied access by adding a user, group, or IP address to the ACIs in an ACL entry. In the ACL interface, each ACI is shown on a line of its own. In this interface window, the ACI has the following syntax:

allow|deny (operator) user|group|IP="name"

For example, the following is an ACI that allows Administrators to perform the read operation for the tasks associated with this ACL:

allow (read) group="Administrators"

An ACI can have more than one operator. The operators are separated with a comma with no space on either side. For example:

allow (read,modify) group="Administrators"

An ACI can have more than one group, user, or IP address by separating them with two pipe symbols (||) with a space on either side. For example:

allow (read) group="Administrators" || group="Auditors"

In the CMS console interface, you create or modify ACIs in an editor that allows you to do this in a graphical environment. You choose from allow or deny in the Allow and Deny field, then you choose one of the operations that are possible for this ACL in the Operations field, and then you list those groups, users, or IP addresses that are being granted or denied this access in the Syntax field.

Allow and Deny

An ACI can either allow an operation for the specified group, user ID, or IP address, or deny the operation for the specified group, user ID, or IP address.

Generally, you do not have to create ACIs to deny access. If a group, user ID, or IP address is not allowed access to an operation—that is, there are no allow ACIs that when evaluated, would include the user ID, group, or IP address—the group, user ID, or IP address is denied access.

If a user is not allowed access to any of the operations for a resource, then this user is considered denied; they do not specifically need to be denied access. For example, user JohnB is a member of the group Administrators. If an ACL has only the following ACI, JohnB would be denied any access since he does not match any of the allow ACIs:

Allow (read,modify) group="Auditors" || user="BrianC"

As you can see, there usually is not a need to include a deny statement. There might, however, be cases where you would need to specify one. For example, say that user JohnB has just been fired. JohnB was a member of the Administrators Group. You might want to specifically deny access to JohnB if you cannot delete the user immediately. Another case might be that you want to set the user BrianC up as an administrator, but you do not want him to be able to change some resource. Since you do want to allow the Administrators group access to this resource, you could specifically deny access to BrianC by creating an ACI that denies this user access.

Operations

When you are creating an ACI, you specify the operation that this ACI is allowing or denying. To allow or deny access to more than one operator in a single ACI, select the first operator from the list, and then hold down Ctrl while selecting other operators.

Syntax

The syntax field of the ACI editor is where you specify the evaluator for the expression. The ACL feature allows for the evaluator types of group, name, and IP address. You add one of these along with the name of the entity, separated by either by = (equals) or != (does not equal).

Group Syntax

The syntax for a group is:

group="groupname" to specify that the group named is to be allowed or denied access to the operation specified.

group!="groupname" to specify that any group except for the group named is to be allowed or denied access to the operation specified.

For example:

group="Administrators"

group!="Auditors"

User Syntax

The syntax for a user is:

user="userID" to specify that the user ID named is to be allowed or denied access to the operation specified.

user!="userID" to specify that any user ID except for the user ID named is to be allowed or denied access to the operation specified.

For example:

user="BobC"

user!="JaneK"

Note: To specify all users, provide the value anybody. For example:

user="anybody"

IP Address Syntax

The syntax for an IP address is:

ipaddress="ipaddress" to specify that the IP address specified is to be allowed or denied access to the operation specified. An IP address is specified using its numeric value, DNS values are not permitted.

ipaddress!="ipaddress" to specify that any IP address except for the IP address specified is to be allowed or denied access to the operation specified. An IP address is specified using its numeric value, DNS values are not permitted.

For example:

ipaddress="12.33.45.99"

ipaddress!="23.99.09.88"

Stringing Values

You can create a string with more than one value. You do this by separating each value with two pipe characters (||) with a space on either side. For example:

user="BobC" || group="Auditors" || group="Administrators"

Agents

There are four agent groups, one for each subsystem. When specifying an agent group, you must either specify the agent group for the particular manager, or all four agent groups. The agent groups are Certificate Manager Agents, Registration Manager Agents, Online Certificate Status Manager Agents, and Data Recovery Manager Agents.

Editing ACLs

ACLs are stored in the internal database and can only be modified in the CMS console interface.

To edit the existing ACLs:

1. Log in to the CMS console (see Logging Into the CMS Console).
2. In the navigation tree, select Access Control List.

The Access Control List tab appears in the right pane.
 

3. Select the ACL and then click Edit. See "ACL Reference" for detailed information about each ACL.

That ACL will open in the Access Control Editor window. This window contains two fields:
 

ACI Entries. This field contains the ACIs for this ACL. You can select each ACI individually, and then edit or delete it. You can also add acis.
 

Description. A description of this ACL. You can change the text in this field.
 

4. To delete an ACI, select it in the ACI Entries list and click Delete.
5. To add an ACI, click Add in the ACI Entries field. The ACI Editor opens. To create the ACI:
1. Select Allow or Deny from the Access field to allow or deny the operation specified in this ACI to the group(s), user(s) or IP address(es) specified. For more information about allowing or denying access, see "Allow and Deny".
2. Select one operator from the possible operators in the Operators list. You can select more than one operator for this ACI by holding down Ctrl and selecting all operators that will be included in the ACI.
3. Specify the user, group, or IP address that will be granted or denied access to the selected operators by providing the correct syntax in the Syntax field. See "Syntax" for details on syntax.
4. Click OK.
6. To modify an ACI, select the ACI and click edit. The ACI Editor opens. To edit the ACI:
1. Select Allow or Deny from the Access field to allow or deny the operation specified in this ACI to the group(s), user(s) or IP address(es) specified. For more information about allowing or denying access, see "Allow and Deny".
2. Select one operator from the possible operators in the Operators list. You can select more than one operator for this ACI by holding down Ctrl and selecting all operators that will be included in the ACI.
3. Specify the user, group, or IP address that will be granted or denied access to the selected operators by providing the correct syntax in the Syntax field. See "Syntax" for details on syntax.
4. Click OK.
7. Click Refresh when you are done.

ACL Reference

---

This section lists all ACL resources defined for all subsystems, describes what each resource controls, lists the possible operations describing the outcome of those operations, and provides the default ACIs for each ACL resource defined. Each subsystem you install will contain only those ACLs that are relevant to that subsystem.

certServer.acl.configuration

Allow or deny a read or modify operation to the ACL configuration.

Operations

read	Viewing ACL resources and listing ACL resources, ACL listing evaluators, and ACL evaluator types.
modify	Adding, deleting, and updating ACL evaluators.

Default ACIs

allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Data Recovery Manager Agents" || group="Online Certificate Status Manager Agents" || group=Auditors

allow (modify) group="Administrators"

Agents, administrators, and auditors can read ACL configuration; only administrators can modify ACL configuration.

certServer.admin.certificate

This entry is associated with the CA administration interface and is ONLY available during the setup configuration of the target of evaluation (TOE), and is unavailable after the CA is up and running.

Operations

import

Importing a Certificate Authority administrator certificate.

Default ACIs

allow (import) user="anybody"

Anyone can import a certificate.

certServer.admin.request.enrollment

This entry is associated with the CA administration interface and is ONLY available during the setup configuration of the target of evaluation (TOE); it is unavailable after the CA is up and running. Allow or deny submit, read, or execute operations for an administrator enrollment request.

Operations

submit	Submitting a CA Administrator certificate enrollment request.
read	Viewing a CA Administrator certificate enrollment request.
execute	Executing a CA Administrator certificate enrollment request.

Default ACIs

allow (submit) user="anybody"

allow (read,execute) group="Certificate Manager Agents"

Anyone can submit an enrollment request; only Certificate Manager Agents may read or execute request.

certServer.auth.configuration

Allow or deny a read or modify operation to the authentication configuration.

Operations

read	Viewing authentication plug-ins, authentication type, configured authentication manager plug-ins, and authentication instances. Listing authentication manager plug-ins and authentication manager instances.
modify	Adding or deleting authentication plug-in and authentication instance. Modifying authentication instance.

Default ACIs

allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Data Recovery Manager Agents" || group="Online Certificate Status Manager Agents" || group="Auditors"

allow (modify) group="Administrators"

Administrators, agents, and auditors are allowed to read authentication configuration; administrators are allowed to modify authentication configuration.

certServer.ca.certificate

Allow or deny an import, unrevoke, revoke, and read operation for certificates in the agents services interface.

Operations

import	Retrieving a certificate by serial number.
unrevoke	Changing the status of a certificate from revoked.
revoke	Revoking certificates, or approving certificate revocation requests.
read	Retrieving certificates based on associated request ID and displaying certificate details for a certificate, based on associated request ID

Default ACIs

allow (import,unrevoke,revoke,read) group="Certificate Manager Agents"

Certificate Manager Agents can import, unrevoke, revoke, and read a certificate.

certServer.ca.certificates

Allow or deny a revoke or list operation to certificates in the agent services interface.

Operations

revoke	Revoking certificates, or approving certificate revocation requests.
list	Listing certificates based on a search. Retrieving details about a range of certificates based on providing a range of serial numbers.

Default ACIs

allow (revoke,list) group="Certificate Manager Agents"

Only Certificate Manager Agents can revoke or list certificates.

certServer.ca.configuration

Allow or deny a read or modify operation to the general configuration for a Certificate Manager.

Operations

read	Viewing CRL plug-in information, general CA configuration, CA connector configuration, CRL Issuing Points configuration, CRL configuration, request notification completion configuration, revocation notification completion configuration, request in queue notification configuration, and CRL extensions configuration. Listing CRL extensions configuration and CRL Issuing Points configuration.
modify	Adding and deleting CRL Issuing Points. Modifying general CA settings, CA connector configuration, CRL Issuing Points configuration, CRL configuration, request notification completion configuration, revocation notification completion configuration, request in queue notification configuration, and CRL extensions configuration.

Default ACIs

allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Data Recovery Manager Agents" || group="Online Certificate Status Manager Agents" || group="Auditors"

allow (modify) group="Administrators"

Administrators, auditors, and agents are allowed to read CA configuration; only administrators are allowed to modify CA configuration.

certServer.ca.connector

Allow or deny a submit operation for a connection to the CA.

Operations

submit

Submitting requests from remote trusted managers.

Default ACIs

allow (submit) group="Trusted Managers"

Trusted Manager can submit requests to this interface.

certServer.ca.clone

Allow or deny a submit operation for a connection to the CA by a cloned CA.

Operations

submit

Submitting information about a revoked certificate from a cloned CA.

Default ACIs

allow (submit) group="Certificate Manager Agents"

Trusted Manager can submit requests to this interface.

certServer.ca.crl

Allow or deny a read or update operation for CRLs in the agent services interface.

Operations

read	Displaying CRLs.
update	Updating CRLs.

Default ACIs

allow (read,update) group="Certificate Manager Agents"

Certificate Manager agents can read or update CRLs.

certServer.ca.directory

Allow or deny an update operation to the directory.

Operations

update

Publishing CA certificates and user certificates to the LDAP directory.

Default ACIs

allow (update) group="Certificate Manager Agents"

Certificate Manager agents can update the directory.

certServer.ca.group

Allow or deny an update operation to add a group.

Operations

add	Adding groups.

Default ACIs

allow (add) group="Administrators"

Only administrators are allowed to add group.

certServer.ca.ocsp

Allow or deny a read operation for OCSP information in the agent services interface.

Operations

read	Retrieving OCSP usage statistics.

Default ACIs

allow (read) group="Certificate Manager Agents"

Only Certificate Manager Agents can read OCSP usage statistics.

certServer.ca.profiles

Allow or deny a list operation for certificate profiles in the agent services interface.

Operations

list    Listing certificate profiles.

Default ACIs

allow (list) group="Certificate Manager Agents"

Certificate Manager agents can list certificate profiles.

certServer.ca.profile

Allow or deny a read or approve operation for certificate profiles in the agent services interface.

Operations

read	Viewing the details of a certificate profile.
approve	Approving, and thus enabling, a certificate profile.

Default ACIs

allow (read,approve) group="Certificate Manager Agents"

Certificate Manager agents can view and approve certificate profiles.

certServer.ca.requests

Allow or deny a list operation for requests in the agents services interface.

Operations

list	Retrieving details on a range of requests.

Default ACIs

allow (list) group="Certificate Manager Agents"

Only Certificate Manager Agents can list requests.

certServer.ca.request.enrollment

Allow or deny a submit, read, execute, assign, or unassign operation for enrollment requests.

Operations

submit	Submitting an enrollment request.
read	Viewing an enrollment request.
execute	Modifying the approval state of a request.
assign	Assigning a request to a Certificate Manager Agent.
unassign	Changing the assignment of a request.

Default ACIs

allow (submit) user="anybody"

allow (read,execute,assign,unassign) group="Certificate Manager Agents"

Anyone can submit an enrollment request; only Certificate Manager Agents can read or execute enrollment requests.

certServer.ca.request.profile

Allow or deny an approve or read operation for certificate profile-based requests.

Operations

approve	Modifying the approval state of a certificate profile-based certificate request.
read	Viewing a certificate profile-based certificate request.

Default ACIs

allow (approve,read) group="Certificate Manager Agents"

Only Certificate Manager agents can view or modify the approval state of certificate profile-based requests.

certServer.ca.systemstatus

Allow or deny an approve or read operation from viewing statistics.

Operations

read	Viewing statistics.

Default ACIs

allow (read) group="Certificate Manager Agents"

Only Certificate Manager agents may view statistics.

certServer.ee.certificate

Allow or deny a renew, revoke, read, or import operation in the end-entity interface.

Operations

renew	Submitting a certificate for a renewal of an existing certificate.
revoke	Submitting a revocation for a user's own certificate.
read	Retrieving and viewing certificates based on certificate serial number. Retrieving and viewing certificates based on request ID.
import	Importing a certificate into a client.

Default ACIs

allow (renew,revoke,read,import) user="anybody"

Anyone can request a renewal or revocation, anyone can import and read a certificate

certServer.ee.certificates

Allow or deny a revoke or list operation in the end-entity interface.

Operations

revoke	Submitting a revocation of a list of certificates.
list	Search for certificates matching specified criteria.

Default ACIs

allow (revoke,list) user="anybody"

Anyone can revoke and list certificates.

certServer.ee.certchain

Allow or deny a download or read operation for the CA's certificate chain in the end-entity interface.

Operations

download	Downloading the CA's certificate chain.
read	Viewing the CA's certificate chain.

Default ACIs

allow (download,read) user="anybody"

Anyone can read or download a CA's certificate chain.

certServer.ee.crl

Allow or deny a read or add operation for CRLs in the end-entity interface.

Operations

read	Retrieving and viewing the certificate revocation list.
add	Adding CRL to the OCSP server.

Default ACIs

allow (read,add) user="anybody"

Anyone can add or read a CRL.

certServer.ee.profile

Allow or deny a submit or read operation for certificate profiles in the end-entity interface.

Operations

submit	Submitting a certificate request through a certificate profile.
read	Displaying details of a certificate profile.

Default ACIs

allow (submit,read) user="anybody"

Anyone can read and submit certificate profiles.

certServer.ee.profiles

Allow or deny a list operation for certificate profiles in the end-entity interface.

Operations

list	Listing of certificate profiles.

Default ACIs

allow (list) user="anybody"

Anyone can list certificate profiles.

certServer.ee.facetofaceenrollment

Allow or deny a list operation for certificate profiles to read face to face enrollment pages.

Operations

read	Read face to face enrollment page.

Default ACIs

allow (read) user="anybody"

Anyone can read face to face enrollment page.

certServer.ee.request.enrollment

Allow or deny a submit operation for certificate enrollment in the end-entity interface.

Operations

submit

Submitting a request for a new certificate.

Default ACIs

allow (submit) user="anybody"

Anyone can submit an enrollment request.

certServer.ee.request.facetofaceenrollment

Allow or deny to submit face to face enrollment

Operations

submit

Submiting face to face enrollment.

Default ACIs

allow (submit) user="anybody"

Anyone can submit face to face enrollment.

certServer.ee.request.ocsp

Allow or deny to submit ocsp requests.

Operations

submit

Submitting OCSP requests.

Default ACIs

allow (submit) user="anybody"

Any clients can submit OCSP requests

certServer.ee.request.revocation

Allow or deny a submit operation for certificate revocation requests in the end-entity interface.

Operations

submit

Submitting a request to revoke a certificate.

Default ACIs

allow (submit) user="anybody"

Anyone can submit a revocation request.

certServer.ee.requestStatus

Allow or deny a read operation for the request status available from the end-entity interface.

Operations

read	Retrieving the status of a request, and serial numbers of any certificates that have been issued against that request.

Default ACIs

allow (read) user="anybody"

Anyone can read a request status.

certServer.general.configuration

Allow or deny a read or modify operation to the general configuration of the subsystem.

Operations

read

Viewing operating environment, LDAP configuration, SMTP configuration, server statistics, encryption, token names, subject name of certificates, certificate nicknames, all subsystems that have been loaded by the server, get CA certificates, and get all certificates for management.

modify

Modifying LDAP database configuration, SMTP configuration, and encryption. Performing server stop/start/restart operations. Issuing import certificate, trusting/untrusting CA certificate, importing cross-certification certificate, installing certificates, and deleting certificates. Logging all tokens and checking token status. Running self tests on demand. Getting certificate information. Processing certificate subject name. Validating certificate subject name, certificate key length, and certificate extension.

Default ACIs

allow (read) group="Administrators" || group="Auditors" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Data Recovery Manager Agents" || group="Online Certificate Status Manager Agents"

allow (modify) group="Administrators"

Administrators, auditors, and agents are allowed to read CMS general configuration; only administrators are allowed to modify CMS general configuration.

certServer.job.configuration

Allow or deny a read or modify operation to the jobs configuration.

Operations

read	Viewing basic job settings, job instance settings, and job plug-in settings. Listing job plug-ins and job instances.
modify	Adding and deleting job plug-ins and job instances. Modifying job plug-ins and job instances.

Default ACIs

allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Data Recovery Manager Agents" || group="Online Certificate Status Manager Agents" || group="Auditors"

allow (modify) group="Administrators"

Administrators, agents, and auditors are allowed to read job configuration; only administrators are allowed to modify job configuration.

certServer.kra.certificate.transport

Allow or deny a read operation to display the key transport certificate.

Operations

read	Displaying the Key Transport Certificate.

Default ACIs

allow (read) user="anybody"

Anyone can view the key transport certificate.

certServer.kra.configuration

Allow or deny a read or modify operation to the Data Recovery Manager configuration.

Operations

read	Viewing automatic key recovery automatic configuration, key recovery archive configuration, and notification request in queue configuration.
modify	Modifying automatic key recovery archive configuration, agent passwords, MxN scheme, and notification request in queue configuration.

Default ACIs

allow (read) group="Administrators" || group="Auditors" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Data Recovery Manager Agents" || group="Online Certificate Status Manager Agents"

allow (modify) group="Administrators"

Administrators, auditors, and agents are allowed to read Data Recovery Manager general configuration; only administrators are allowed to modify Data Recovery Manager configuration.

certServer.kra.connector

Allow or deny to submit requests.

Operations

submit

Submitting requests.

Default ACIs

allow (submit) group="Trusted Managers"

Only Trusted Managers can submit requests.

certServer.kra.key

Allow or deny a read, recover, or download operation for the Data Recovery Manager.

Operations

read	Displaying a key recovery request.
recover	Indicating that a Data Recovery Manager has approved the key recovery. Finalizing a key recovery operation.
downl