Red Hat CERTIFICATE SYSTEM 7.2 - MIGRATION GUIDE, Руководство администратора

Страница: 22 / 512

Chapter 1. Overview
2
1.1.2. Interfaces
Each of the subsystems contains interfaces for interaction with various portions of the subsystem. The
CA, DRM, OCSP, and TKS subsystems have an administrative console to manage and configure the
subsystem itself, such as adding users and certificates and viewing logs. The CA, OCSP, DRM, and
TPS subsystems have an agent interface specific to that subsystem which allows agents to perform
the tasks assigned to them. A Certificate Manager has an end-entity services interface for end entities
to enroll in the PKI.
Note
Not all subsystems have all types of interfaces. The TKS subsystem does not have an
agent interface. The TPS subsystem does not have an administrative console, but rather
has administrative functions that are accessible through the HTML agent services page.
Only a CA has an end-entities page.
The three types of interfaces are described as follows:
•
Administrative Interface
- The administrative interface, a Java
™
application called the Console,
provides a GUI interface for performing administrative tasks and configuring plug-in modules. This
interface is similar for subsystems. The administrative interface requires user ID and password
authentication and can be configured for SSL certificate-based authentication.
•
Agent Services Interface
- The agent services interface is a customizable HTML interface used to
perform agent tasks, such as editing and approving requests for issuing or revoking certificates. The
agent services interface for a CA, DRM, OCSP, and TPS are specific to those subsystems.
•
End-Entity Services Interface
- The end-entity interface is a customizable HTML interface used
by end entities to enroll in the PKI, request certificates, revoke certificates, and pick up issued
certificates. It contains forms for different types of enrollments and for enrolling different types of end
entities. The Certificate Manager has an end-entity services interface; the other subsystems do not.
1.1.3. Logging
The Certificate System and each subsystem produce extensive system and error logs that record
system events so that the systems can be monitored and debugged. All log records are stored in
the local file system for quick retrieval. Logs are configurable, so logs can be created for specific
types of events and at the desired logging level. Custom logs can be created using the CS SDK. See
Section 3.9, “Logs”
for details.
1.1.3.1. Signing Logs
Certificate System allows logs to be signed digitally before archiving them or distributing them
for auditing. This feature enables log files to be checked for tampering after being signed. See
Section 3.9.10, “Signing Log Files”
for details.
1.1.4. Auditing
The Certificate System maintains audit logs for all events, such as requesting, issuing and revoking
certificates and publishing CRLs. These logs are then signed. This allows authorized access or activity
to be detected. An outside auditor can then audit the system if required. The assigned auditor user
account is the only account which can view the signed audit logs. This user's certificate is used to