Chapter 8. After Configuration: Checklist of Configuration Areas for Deploying Certificate System

The create-and-configure process sets up the subsystem instances so that they are running and fully functional. However, the details of deploying a PKI — like defining what kind of certificates to issue — must still be done.
The features and performance of Certificate System subsystems can be matched to the requirements of your specific deployment. The most common (and recommended) features to configure are listed in Table 8.1, “Certificate System Features to Configure after Setup”.

Table 8.1. Certificate System Features to Configure after Setup

Feature Why It's Useful Admin Guide Link Recommended or Required
Create agents and administrative users The setup process only creates a single administrative user account. To manage a PKI environment in real life requires a number more administrators and agents, which are created after the instance is set up.
  • Mandatory (agents only)
  • Recommended (administrators only)
  • Common Criteria required
Import the certificate chain into the browser. Any browser which will be used to access agent or admin services pages must have the client certificate and the CA certificate chain imported into its trust store. Importing certs
  • Optional
  • Common Criteria required
Set sudo permissions on PKI services for PKI administrators Granting sudo permissions for Certificate System and Directory Server services to PKI administrators makes it easier to manage the instances. Setting sudo permissions
  • Optional
  • Common Criteria required
Set up backup and restore procedures A reliable backup and restore strategy is vital for disaster and data recovery. Backup and restore
  • Recommended
  • Common Criteria required
Enable signed audit logs This can be done when an instance is first created by using the -audit_group option, but it can also be done post-installation.
  • Recommended
  • Common Criteria required
Configure LDAP publishing LDAP publishing publishes the certificates to specific entries within an LDAP database, so other clients can access the entries. LDAP publishing
  • Recommended
Configure client authentication with the backend Directory Server Client authentication allows the Certificate System instance to bind automatically to its backend Directory Server over SSL by presenting a recognized SSL client certificate (similar to the way agents connect to a subsystem instance). Client authentication
  • Recommended
Customize certificate profiles A certificate profile defines everything associated with issuing a particular type of certificate, including the authentication method, the authorization method, the certificate content (defaults), constraints for the values of the content, and the contents of the input and output for the certificate profile. Existing certificate profiles can be edited and new profiles added to allow deployment-specific certificates and tokens to be issued. Certificate profiles
  • Recommended
Enable revocation checking and OCSP responses There are two methods for checking whether a certificate is active (and not revoked): CRL checking and OCSP services. Checking the revocation status helps ensure that a revoked certificate isn't wrongly accepted just because it is within its validity period.
  • Recommended
  • Common Criteria required
Configure a timeout period for SSL sessions Using session timeouts prevents unauthorized users from accessing an open, but otherwise inactive, session with a subsystem. Session timeouts
  • Recommended
  • Common Criteria required
Use port fowarding The default URLs used by Certificate System subsystems can be very long, which makes it possible for users to mistype the URL. Port forwarding allows users to access a much simpler, more intuitive URL for a better experience. Port forwarding
  • Optional
Set up cross-pair certificates (also called FBCA or bridge certificates). Cross-pair certificates set up a trusted environment between two separate PKI environments, so that certificates issued in one PKI are automatically recognized and trusted by the other PKI environment. Cross-pair certificate profiles
  • Optional
Run self-tests Self-tests are subsystem type-specific diagnostics. These are usually run when the server starts, but they can also be run on demand. Additionally, self-test can be customized by creating new self-test plug-ins or to accommodate changes to the subsystem configuration like new certificates or changed certificate nicknames. Self-tests
  • Recommended
  • Common Criteria required
Remove the password.conf file. The password.conf file stores system passwords in plaintext. Running without the password.conf file
  • Recommended
  • Common Criteria required
Remove unused CA connection interfaces. Several legacy interfaces are included in the CA's web.xml. While these can be used for custom or legacy applications to connect to the CA, for secure environments, these deprecated interfaces should be removed from the CA configuration to prevent unauthorized access. Remove unused CA connection interfaces
  • Recommended
  • Common Criteria required
Assign POSIX system ACLs for PKI subsystem users. This provides finer control over the ACLs used for the subsystems' system users. Configuring POSIX system ACLs
  • Recommended
  • Common Criteria required