Red Hat CERTIFICATE SYSTEM 8.0 - ADMINISTRATION, Руководство администратора

Страница: 30 / 564

Chapter 1. Overview of Red Hat Certificate System Subsystems
8
1.2.6. Token Key Service
The Token Key Service (TKS) uses a master key to derive specific, separate keys for every smart
card. The TPS uses these secret keys to communicate with each smart card securely, since all
communication between the TPS and the smart card is encrypted.
The only Certificate System subsystem which the TKS interacts with is the TPS.
1.2.7. Enterprise Security Client
The Enterprise Security Client is not a subsystem since it does not perform any operations with
certificates, keys, or tokens. The Enterprise Security Client, as the name implies, is a user interface
which allows people to manage certificates on smart cards very easily. The Enterprise Security Client
sends all token operations, such as certificate requests, to the TPS, which then sends them to the CA.
1.3. A Look at Managing Certificates
Certificates are used in many applications, from encrypting email to accessing websites. There are
two major stages in the lifecycle of the certificate: the point when it is issued (issuance and enrollment)
and the period when the certificates are no longer valid (renewal or revocation). There are also ways
to manage the certificate during its cycle. Making information about the certificate available to other
applications is
publishing
the certificate and then backing up the key pairs so that the certificate can be
recovered if it is lost.
The core of the Certificate System PKI is the Certificate Manager, a certificate authority. The CA
receives certificate requests, issues all certificates, and handles revocation and publishing CRLs. If a
client needs to verify whether a certificate is valid, then it can check for the certificate's status against
the CA's internal online certificate status protocol (OCSP) responder.
Figure 1.1. CA Only Certificate System
One operation the CA cannot perform, though, is key archival and recovery. A very real scenario is
that a user is going to lose a certificate — the certificate could be deleted from a browser database, a
smart card could be left at home. Depending on the policies in the company, there probably has to be
a way to recover the keys in order to regenerate a replacement certificate. That requires a DRM, the
subsystem which specially archives and retrieves keys.