Authentication is the process of verifying the identity of a user that is requesting a service from Netscape Certificate Management System (CMS). More specifically, authentication involves acquiring and verifying the values of the configured attributes of the user. For example, the user might be prompted to log in with a user name and password, and then the server would look in a preconfigured database to verify that the user's password was correct.
Administrators--privileged users who connect to the server to do system or server administration tasks
Agents--privileged users who connect to the server to do agent operations
End-Entity Authentication
When an administrator makes an administrative request to Certificate Management System (from the CMS window within Netscape Console or from any command-line tool), the server needs to authenticate the administrator before processing the request. To facilitate this, Certificate Management System supports an authentication method that includes user ID- and password-based authentication from the client and SSL server authentication from the server.
Figure 9.1 CMS authentication of a user with administrator privileges
If the user ID and password bind successfully to a user entry, authentication succeeds; otherwise, it fails.
If authentication succeeds, the server checks the user's access rights (based on group memberships) to determine whether the user is authorized to perform the requested operation.
If both authentication and authorization succeed, the server services the request. Otherwise, it rejects the request and logs the reason for the rejection.
Authentication of Agents
When an agent makes a request to Certificate Management System (from the appropriate Agent Services interface), the server needs to authenticate the agent before processing the request. To facilitate this, Certificate Management System supports a certificate-based authentication method.
Figure 9.2 shows how a Registration Manager authenticates and authorizes a Registration Manager agent.
Figure 9.2 Registration Manager authentication of a user with Registration Manager agent privileges
Upon receiving the certificate, the Registration Manager performs the following authentication and authorization process:
Note that the Registration Manager verifies the revocation status of the agent certificate if it has been issued by the Certificate Manager to which the Registration Manager is connected to; the Certificate Manager keeps a record of all the certificates it has issued and their current status in its internal database. However, if the agent certificate is issued by any other CA, the Registration Manager cannot verify the revocation status of the certificate; it can only verify that the certificate is valid and that it has been issued by a CA that the Registration Manager trusts. For details on configuring the Certificate Manager or Registration Manager to check the revocation status of its agents' certificates, see "Revocation Status Checking of Agent Certificates".
If the internal database contains an invalid certificate for an agent, the server rejects all requests from that agent. For the server to accept requests from that agent, you would have to replace the agent's invalid certificate in the internal database with a valid one. For details on how to do this, see "Changing a Privileged User's Certificate".
The Registration Manager reads the user's subject name (in DN form) and the issuer name from the certificate. This combination is unique. It then finds the login name corresponding to this unique combination in its privileged-users list, which is stored in the internal database. If a login name is associated with the certificate, the Registration Manager proceeds. Otherwise, it rejects the request.
The Registration Manager then checks the group memberships of the login name and the corresponding access rights to determine whether the user is authorized to perform the requested service.
If both authentication and authorization succeed, the Registration Manager services the request. Otherwise, it rejects the request and logs a reason for the rejection.
When an end entity submits a certificate request, a Certificate Manager or Registration Manager's first task is to identify and authenticate the end entity. The server must perform this task before it can register the end entity for certificate issuance. This task includes verifying the end entity's identity based on information the end entity provides and returning enough information about the end entity so that the subject name for the certificate can be constructed.
When an end user submits a certificate renewal request, the first step in the renewal process is for the Certificate Manager or Registration Manager to identify and authenticate the end user. This step includes making sure that the end user's current certificate is either "valid" or "expired" ("revoked" is not acceptable).
If the renewal request is processed by a Registration Manager, the end-user certificate presented must be issued by a Certificate Manager that the Registration Manager knows and is connected to; the Registration Manager forwards certificate requests to this Certificate Manager for signing.
The certificate being presented by the end user for renewal must be currently valid or must have expired; it cannot have been revoked.
The validity period of a renewed certificate is determined by the policy rule explained in "Renewal Validity Constraints Policy". If the renewal lead time does not permit renewing, the server rejects the renewal request. Also, if the policy is disabled, renewal of certificates fails.
If the certificate being presented by the end user has already been renewed, the server displays the URL for downloading the certificate.
This situation may occur if the end user forgets to download the renewed certificate. It can also happen if the end user maintains two identical certificate databases on two machines, renews the certificate from one machine, and then tries to renew the same certificate from the other machine.
The End Entity Services interface of the Certificate Manager and Registration Manager includes a default HTML form for renewing end users' certificates. The form is accessible from the Renewal tab as shown in Figure 9.3.
Figure 9.3 Certificate renewal form for end users
Certificates can be revoked by administrators, agents, and end users. When an end user submits a certificate revocation request, the first step in the revocation process is for the Certificate Manager or Registration Manager to identify and authenticate the end user. The reason for this is when an end user attempts to revoke a certificate, the server needs to verify that the user is attempting to revoke his or her own certificate, not a certificate belonging to someone else.
This method requires an end user to present a valid or revoked certificate that has the same subject name as the one he or she wants to revoke. Without the certificate, the user won't be able to revoke the certificate.
This method requires an end user to enroll for a personal certificate using the manual enrollment method. The reason for this is, by default, only the manual enrollment form includes fields for entering the challenge password when requesting a certificate; see "Enrollment Forms". None of the other enrollment forms, for example directory-based or NIS server-based forms, by default allow end users to specify a challenge password.
You can use the manual-enrollment form (ManUserEnroll.html) as a model and introduce the input fields for entering the challenge password in any of the other end user enrollment forms. Keep in mind that this feature is available for end-user certificates only; the feature is not available for other types of certificates.
Revoking a certificate using the challenge password is useful in certain situations. For example, if you issue a single certificate to a user and the user is unable to use the certificate due to loss of corresponding key pair, it's not possible for the user to revoke his or her own certificate using the SSL client authenticated revocation method. If the user has a challenge password for the certificate, he or she can use it to revoke the certificate the server maintains in its database.
If the revocation request is processed by a Registration Manager, it must be connected as a trusted manager to the Certificate Manager that has issued the certificate the user is attempting to revoke; the Registration Manager forwards certificate revocation requests to this Certificate Manager. For information on trusted managers, see "Trusted Managers".
The certificate the user attempts to revoke must be currently valid or must have expired; it cannot have been already revoked.
At the time of revocation, the user can also specify additional details, such as the date of revocation and revocation reason, for each certificate or for the list as a whole.
In an SSL client authenticated revocation method, the server expects the end user to present a certificate that has the same subject name as the one he or she wants to revoke and uses that for authentication purposes. The server verifies the authenticity of a revocation request by mapping the subject name in the certificate being presented for client authentication to certificates in its internal database. The server revokes the certificate only if the certificate maps successfully to one or more valid or expired certificates in its internal database.
If the revocation request is processed by a Registration Manager, the certificate presented for SSL client authentication must be issued by a Certificate Manager that the Registration Manager knows about and is connect to (the Registration Manager forwards certificate requests to this Certificate Manager for signing).
The certificate being presented by the user for revocation must be currently valid or must have expired; it cannot have been already revoked.
The user can revoke only certificates that contain the same subject name as the one in the certificate presented for authentication.
A challenge password is a unique, alphanumeric string that the end user specifies when requesting a certificate; the user is expected to keep this password confidential and use it to authenticate to the server when revoking the certificate. When the server issues the certificate, it associates the password with the certificate, stores both the certificate and password in its internal database, and uses them later for authenticating any revocation requests.
The user must have requested the certificate using the manual enrollment method--only the default manual enrollment form includes fields for entering the challenge password when requesting a certificate; see "Enrollment Forms".
The user can revoke only those certificates that contain the specified serial number with the corresponding challenge password. For example, if there is a mismatch between the challenge password and serial number, the server rejects the revocation request.
The End Entity Services interface of the Certificate Manager and Registration Manager includes default HTML forms for both the SSL client authenticated revocation and challenge-password-based revocation. The forms are accessible from the Revocation tab. Figure 9.4 shows the form that enables end users to revoke their certificates using a challenge password. You can view the form that enables SSL client authenticated revocation by clicking the User Certificate link.
Figure 9.4 Form for SSL client authenticated certificate revocation
UserRevocation.html (the form that allows SSL client authenticated revocation of client or personal certificates)
Previous
