Configuring Ipv6 Support; Scaling The Tps And Its Support Subsystems - Red Hat CERTIFICATE SYSTEM 8.0 - ADMINISTRATION Admin Manual

conn.drm1.servlet.TokenKeyRecovery=/kra/TokenKeyRecovery
conn.drm1.retryConnect=3
conn.drm1.SSLOn=true
conn.drm1.keepAlive=false
3. Also edit the smart card profiles in the TPS CS.cfg file.
The TPS CS.cfg file has a section defining each type of smart card profile to maintain. In the
default configuration, the userKey is defined under the op.enroll.userKey subsection. The
keyGen subsection of the userKey profile defines each type of key/certificate pair allowed for that
type of smart card. In the default configuration, one of the key/certificate pairs is encryption. Set
the following parameters to enable server-side key generation and to archive keys:
op.enroll.userKey.keyGen.encryption.serverKeygen.enable=true
op.enroll.userKey.keyGen.encryption.serverKeygen.drm.conn=drm1
op.enroll.userKey.keyGen.encryption.serverKeygen.archive=true
op.enroll.userKey.keyGen.encryption.serverKeygen.encryptPrivKey=true
4. Restart the TPS subsystem.
service instance_ID start

5.7.6. Configuring IPv6 Support

By default, the TPS listens over both its IPv4 and IPv6 address. This is configured in the nss.conf
file in the Listen directive:
Listen 7889
Listen 7890
To restrict the TPS its IPv4 address, then edit Listen line to specify an IPv4-style address:
Listen 0.0.0.0:7889

5.8. Scaling the TPS and Its Support Subsystems

When the TPS is configured, it is configured to work with a specific instance of a CA, TKS, and,
optionally, DRM subsystems. It is possible after the configuration process to edit the TPS CS.cfg file
to provide backup CA, TKS, and DRM subsystems so that there is failover support in case the primary
subsystem is unavailable. There are two good reasons for failover:
• To provide fail-over support. The TPS can be configured to communicate with multiple instances
of CA, TKS, or DRM subsystems, so if one instance is unavailable, the TPS can still process user
operations initiated through the Enterprise Security Client. The instances in these cases all have the
same policies in effect. This is described in
• 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
"Configuring Multiple Support Subsystem Instances for Different
Section 5.8.1, "Configuring Failover
Functions".
Configuring IPv6 Support
Support".
Section 5.8.2,
163