
Chapter 7. Token Processing System
152
•
To perform different operations under different policies.
The TPS can route its jobs to different
subsystem instances when there are different types of tokens or operations. For example,
enrollment requests for temporary tokens can be sent to one CA with one set of policies while
enrollments for regular tokens are sent to a different CA. This is described in
Section 7.1.2,
“Configuring Multiple Instances for Different Functions”
.
7.1.1. Configuring Failover Support
The subsystem instance to which the TPS connects is set in the
conn.
subsystem#
.hostport
parameter of the
CS.cfg
configuration file. For example, the CA instance is set in the following
parameter:
conn.ca1.hostport=aCA.example.com:9443
To configure failover support, list multiple instances in the
conn.
subsystem#
.hostport
parameter,
separated by spaces. For example:
conn.ca1.hostport=aCA.example.com:9443 bCA.example.com:9543 cCA.example.com:9643
For failover support to be properly configured, all of the subsystem instances must have the same
policies and configuration; this means all of the subsystems must be clones. For example, if the TPS
is configured to communicate with three CAs, the three CAs must be clones of each other. This means
that the values of the other configuration parameters are the same between the instances.
The CA configuration parameters are listed in
Table 7.2, “CA Connection Settings”
. The TKS
configuration parameters are listed in
Table 7.3, “TKS Connection Settings”
. The DRM configuration
parameters are listed in
Table 7.4, “DRM Connection Settings”
.
7.1.2. Configuring Multiple Instances for Different Functions
Along with configuring multiple instances for failover support, the TPS can be configured to use
multiple instances of a subsystem to perform different functions for different TPS profiles. For instance,
the TPS can be configured to use CA1 to enroll temporary tokens (type
userKeyTemporary
) and
CA2 to enroll regular tokens (type
userKey
).
1. Open the TPS
CS.cfg
file.
2. Create additional instance entries.
Each subsystem configured for the TPS has its own set of parameters, beginning with
conn.
subsystem#
. To configure multiple instances of a subsystem, create a new set of
connection parameters, and increment the
#
. For example:
conn.ca1.clientNickname=subsystemCert cert-rhpki-tps
conn.ca1.hostport=aCA.example.com:9443
conn.ca1.keepAlive=true
conn.ca1.retryConnect=3
conn.ca1.servlet.enrollment=/ca/ee/ca/profileSubmitSSLClient
conn.ca1.servlet.revoke=/ca/subsystem/ca/doRevoke
conn.ca1.servlet.unrevoke=/ca/subsystem/ca/doUnrevoke
conn.ca1.timeout=100
conn.ca2.clientNickname=subsystemCert cert-rhpki-tps
conn.ca2.hostport=bCA.example.com:9543
Summary of Contents for CERTIFICATE SYSTEM 7.2 - MIGRATION GUIDE
Page 36: ...Chapter 1 Overview 16 Figure 1 4 Certificate System Architecture ...
Page 144: ...124 ...
Page 160: ...140 ...
Page 208: ...188 ...
Page 210: ...190 ...
Page 256: ...236 ...
Page 282: ...Chapter 12 Certificate Profiles 262 Parameter IssuerName_n IssuerType_n ...
Page 285: ...Freshest CRL Extension Default 265 Parameter PointName_n PointIssuerName_n ...
Page 362: ...342 ...
Page 376: ...356 ...
Page 436: ...416 ...
Page 490: ...470 ...
Page 504: ...484 ...