Chapter 4. Certificate Manager
110
By default, the CA administrator is assigned as the security domain administrator, with the privileges to
manage the domain.
A
domain.xml
file is created in the CA instance
conf/
directory. This file contains all the important
information about the domain. The user and group information is stored in the internal database of CA
subsystem hosting the domain.
At the end of the configuration, the CA registers its information in the domain.
4.4.4. Joining a Security Domain
During configuration, if the
Join an existing security domain
option is selected, provide the
service URL to the security domain. This URL usually has the form
https://
host:port
and
requires credentials such as a UID and password. (It is not necessary to give the exact URL to the
domain.xml
file). The UID and password must be previously obtained from a security domain
administrator. The credential information must belong to a member of an enterprise subsystem
administrator group.
The browser is then redirected to the security domain for authentication. If authentication is successful,
an authentication token (cookie) is issued. The browser then transfers this cookie to the configuration
wizard, which uses the token to manage multiple subsystems as necessary. Each subsystem contacts
the security domain to validate the token before handling the request.
At the end of the configuration, the configuration registers the subsystem information to the security
domain.
4.4.5. Additional Security Domain Information
The following information can be considered 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.
• The Certificate System security domain allows an offline CA to be set up. In this scenario, the offline
root has its own security domain. All online subordinate CAs belong to a different security domain.
• The security domain streamlines configuration between the CA and OCSP. The OCSP can push
its information to the CA for the CA to set up OCSP publishing and also retrieve the CA certificate
chain from the CA and store it in the internal database.
4.5. Configuring the Certificate Manager Instance
After the installation and basic configuration of the CA subsystem, further configuration to features
such as logging and certificate contents can be made through the Certificate System administrative
console. This console allows user and group management, authorization settings, internal LDAP
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 ...