5.5. Planning for Network and Physical Security

There are two considerations about using firewalls with Certificate System subsystems:

The CA, KRA, and TKS are always placed inside a firewall because they contain critical information that can cause devastating security consequences if they are compromised.

The TPS and OCSP can be placed outside the firewall. Likewise, other services and clients used by the Certificate System can be on a different machine outside the firewall. In that case, the local networks have to be configured to allow access between the subsystems behind the firewall and the services outside it.

The LDAP database can be on a different server, even on a different network, than the subsystem which uses it. In this case, all LDAP ports (389 for LDAP and 636 for LDAPS, by default) need to be open in the firewall to allow traffic to the directory service. Without access to the LDAP database, all subsystem operations can fail.

As part of configuring the firewalls, if iptables is enabled, then it must have configured policies to allow communication over the appropriate Certificate System ports. Configuring iptables is described in the Red Hat Security Guide.

Because of the sensitive data they hold, consider keeping the CA, KRA, and TKS in a secure facility with adequate physical access restrictions. Just as network access to the systems needs to be restricted, the physical access also needs to be restricted.

Along with finding a secure location, consider the proximity to the subsystem agents and administrators. Key recovery, for example, can require multiple agents to give approval; if these agents are spread out over a large geographical area, then the time differences may negatively impact the ability to retrieve keys. Plan the physical locations of the subsystems, then according to the locations of the agents and administrators who will manage the subsystem.

Each Certificate System server uses up to four ports:

All of the service pages and interfaces described in the Red Hat Certificate System User Interfaces section in the Red Hat Certificate System Administration Guide (Common Criteria Edition) are connected to using the instance's URL and the corresponding port number. For example:

https://server.example.com:8443/ca/ee/ca

To access the admin console, the URL specifies the admin port:

pkiconsole https://server.example.com:8443/ca

All agent and admin functions require TLS client authentication. For requests from end entities, the Certificate System listens on both the TLS (encrypted) port and non-TLS ports.

The ports are defined in the server.xml file. If a port is not used, it can be disabled in that file. For example:

<Service name="Catalina">
    <!--Connector port="8080" ... /-->  unused standard port   
    <Connector port="8443" ... />

Whenever a new instance in installed, make sure that the new ports are unique on the host system.

To verify that a port is available for use, check the appropriate file for the operating system. Port numbers for network-accessible services are usually maintained in a file named services. On Red Hat Enterprise Linux, it is also helpful to confirm that a port is not assigned by SELinux, by running the command semanage port -l to list all ports which currently have an SELinux context.

When a new subsystem instance is created, any number between 1 and 65535 can be specified as the secure port number.