Red Hat CERTIFICATE SYSTEM 8 - DEPLOYMENT Deployment Manual page 74

Hide thumbs Also See for CERTIFICATE SYSTEM 8 - DEPLOYMENT:
Table of Contents

Advertisement

Chapter 5. Planning the Certificate System
OCSP, and other CAs — must become members of the security domain by supplying the security
domain URL when configuring the subsystem.
Each subsystem within the security domain shares the same trust policies and trusted roots which can
be retrieved from different servers and browsers. The information available in the security domain is
used during configuration of a new subsystem, which makes the configuration process streamlined
and automated. For example, when a TPS needs to connect to a CA, it can consult the security
domain to get a list of available CAs.
Each CA has its own LDAP entry. The security domain is an organizational group underneath that CA
entry:
ou=Security Domain,dc=server.example.com-pki-ca
Then there is a list of each subsystem type beneath the security domain organizational group, with a
special object class (pkiSecurityGroup) to identify the group type:
cn=KRAList,ou=Security Domain,dc=server.example.com-pki-ca
objectClass: top
objectClass: pkiSecurityGroup
cn: KRAList
Each subsystem instance is then stored as a member of that group, with a special pkiSubsystem
object class to identify the entry type:
dn: cn=drm.example.com:10444,cn=KRAList,ou=Security Domain,dc=server.example.com-pki-ca
objectClass: top
objectClass: pkiSubsystem
cn: drm.example.com:10444
host: server.example.com
SecurePort: 10444
DomainManager: false
Clone: false
SubsystemName: Data Recovery Manager
If a subsystem needs to contact another subsystem to perform an operation, it contacts the CA which
hosts the security domain (by invoking a servlet which connects over the administrative port of the
CA). The security domain CA then retrieves the information about the subsystem from its LDAP
database, and returns that information to the requesting subsystem.
The subsystem authenticates to the security domain using a subsystem certificate.
Consider the following when planning the security domain:
• The CA hosting the security domain can be signed by an external authority.
• Multiple security domains can be set up within an organization. However, each subsystem can
belong to only one security domain.
• Subsystems within a domain can be cloned. Cloning subsystem instances distributes the system
load and provides failover points.
• The security domain streamlines configuration between the CA and DRM; the DRM can push
its KRA connector information and transport certificates automatically to the CA instead of
administrators having to manually copy the certificates over to the CA.
64

Advertisement

Table of Contents
loading

Table of Contents