4.5.3. Planning Ports

The subsystems are installed and configured with a separate TCP/IP port for each service, called port separation. Each Certificate System subsystem uses up to five ports:
  • A standard port
  • An SSL port for end users services
  • An SSL port for agent services
  • An SSL port for the administrative console or admin services
  • A web server port (Tomcat for CA, DRM, OCSP, and TKS subsystems, Apache for the TPS and RA subsystems)
All of the service pages and interfaces described in Section 2.5, “Red Hat Certificate System Services” are connected to using the instance's URL and the corresponding port number. For example:
To access the admin console, the URL specifies the admin port:
pkiconsole https://server.example.com:9445/ca
All agent and admin functions require SSL client authentication. For requests from end entities, the Certificate System listens on both the SSL (encrypted) port and non-SSL ports.
The ports for the different services to use are defined in the server.xml file for the CA, OCSP, DRM, and TKS and in the httpd.conf and nss.conf files for the RA and TPS. If a port is not used, it can be disabled in that file. For example:
<Service name="Catalina">
    <!--Connector port="9180" ... /-->  unused standard port   
    <Connector port="9443" ... />
Whenever a new instance in installed, it can be configured to have a single SSL port or to use three separate SSL ports for the different interface. Whichever way you choose, 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.