Enabling HTTPS access to the Admin Console

Learn how to configure the container system.properties file to enable HTTPS access to the Admin Console.

Note: This document references the version of the Admin Console that is the default up to and including version 2022.1.0, but does not show the redesigned Admin Console available as an option in version 2022.1.0. For an overview of the new user interface, plus illustrations, see Admin Console 2022.1.0—Overview.

Table of Contents

Introduction

You can set up HTTPS access to the Admin Console by enabling an HTTPS port.

All you need to do is define the HTTPS listener in the system.properties file for the container.

Configuration

There is one basic configuration step, and one additional step you can take to further restrict assess:

Step 1: Add HTTPS listener in properties file

To enable an HTTPS listener, you must update the system.properties file in the {release_directory}/instances/{containername} folder, as shown below. In this example, we use port 9446.

With the settings below, access to the Admin Console is limited to the specified HTTPS listener.

To modify the system.properties file to enable an HTTPS listener

  1. Open the {release_directory}/instances/{containername}/system.properties file in a text editor. An example is shown below.

    Admin Console folder structure: location of system.properties file

  2. Remove the following settings:
    • org.osgi.service.http.port=9000
    • com.soa.http.bind.all=true
  3. Add the following settings:
    • org.osgi.service.http.port.secure=9446
    • com.soa.http.bind.all.secure=true
  4. Save changes.
  5. Restart the container.

Step 2: Optional additional configuration to restrict Admin Console access to ports defined in the system.properties file

When you've modified the properties in the system.properties file as covered in Step 1 above, the Admin Console is accessible:

  • To the port you defined in the system.properties file.
  • To any other ports defined for that container in Policy Manager.

If you want to further restrict access to the Admin Console, so that it is only accessible via the port defined in the system.properties file, there is an additional configuration step you can take. By modifying a specific configuration property in the Admin Console, it will not be available to additional ports defined for the container in Policy Manager.

To do this, follow the steps below.

To restrict Admin Console access to ports defined in the system.properties file

  1. When the container is up and running, log in to the Admin Console (https://localhost:{port}/admin/).
  2. Go to Configuration > Configuration Categories and choose the com.soa.admin.console category as shown below.

    Configuration Categories: com.soa.admin.console

  3. Change the admin.console.access.restricted property from false (the default) to true.

    For details about this property, see admin.console.access.restricted property settings below.

  4. Save changes.

admin.console.access.restricted property settings

The admin.console.access.restricted setting has two possible values:

  • False (the default) means you can access the Admin Console:
    • Through the port defined in the system.properties file.
    • Through the listeners defined in the Policy Manager workbench (see About Listeners in the Policy Manager help).
  • True (more secure) means you can access the Admin Console:
    • Only through the port defined in the system.properties file.

      If you try to access the Admin Console using any port not defined in the system.properties file, the response will be a 404 error.

Troubleshooting

If everything appears to be configured correctly and you are still seeing 404 errors when you try to launch the Admin Console, review the following steps to attempt to troubleshoot the problem.

Step 1: Inspect Log

Inspect the container logs in the {release_directory}\instances\{containername}\logs folder and search for the following errors near the startup:

Caused by: java.net.BindException: Address already in use
  at java.net.PlainSocketImpl.socketBind(Native Method)
  at java.net.PlainSocketImpl.bind(Unknown Source)
  at java.net.ServerSocket.bind(Unknown Source)
  at java.net.ServerSocket.<init>(Unknown Source)

These errors mean that the container is trying to start its listener, but something is already listening on the port assigned in the system.properties file.

Step 2: Resolve

  1. Stop the container and check to make sure that nothing is running on the port that the container is configured to run on. If nothing is running, it means that the container is trying to start TWO listeners on the same port.
  2. Check system.properties in the container directory. It will specify listeners that the container uses on initial startup. For example: 
    com.soa.http.host=hostname
org.osgi.service.http.port.secure=9446
com.soa.http.bind.all.secure=true
  3. Compare the host, port, and bind settings above with the actual Policy Manager listeners defined in the Policy Manager Management Console. If the ports specified in the system.properties file are different from the ports specified in Policy Manager, the problem must exist elsewhere. If the port numbers match, then ONE of the following must occur:
    • com.soa.http.bind.all.secure in the system.properties file AND the Bind to All Interfaces option for the HTTPS container listener in the Policy Manager Management Console must both be set.
    • The com.soa.http.host value in the system.properties file and the hostname in the Policy Manager Management Console must match.

    The reason is that when Policy Manager starts its listener, it tries to determine whether one already exists on the same port and host. If it finds one already running, it uses that port. If the host names are different, or if they are not running on all interfaces, Policy Manager might not be able to find the listener already running, and might therefore try to start a new one on the same port.