Installing and configuring Janus Network Security

Before you can start using secured communications with Janus Network Security, preliminary tasks must be completed. Some of these tasks may be performed by different people, but they should occur in the following sequence:

Install the Sirius Mods, which contains Janus Network Security support.
Note: This requirement does not apply if your version of Model 204 is 7.5 or higher.
This step would probably be done by the person responsible for installing and supporting Model 204 at your site. If you are already running Janus Web Server, this step involves some minor updates for support of Janus Network Security.
Install or update RKTools.
Make an initial connection to a port that uses the Rocket-provided internal certificate.
1. Define and start the SSL port.
2. Give appropriate user(s) correct privileges.
3. Download internal certificate as CA to browser.
In step 2 you test the success of your first connection, using the Rocket-provided internal certificate (discussed in Self-signed certificates).

Each of these steps is further described below.

Install Janus TCP/IP Base

As mentioned earlier, Janus Network Security is generally installed as an addition to Janus Web Server. It can also be installed without it, for use by other non-web Janus products. In either case, some of the steps in the following subsections may have already been completed. You should confirm each one before proceeding to the next step.

Install Sirius Mods

Note: This requirement does not apply to versions of Model 204 after 7.4.

The Sirius Mods are a combination of features which provide a base of support for most Sirius products, and they must be installed prior to proceeding.

You can confirm whether the Sirius Mods are installed and at the current release by entering the following command at the Model 204 command line:

SIRIUS

This will display various information regarding the configuration of Sirius products in this online, including the current release of the Sirius Mods.

Install or update RKTools

A base portion of RKTools is required for Janus Network Security, so RKTools must be installed prior to proceeding. More information is available in RKTools installation.

Note: As part of RKTools installation, you should allocate and initialize a file called JANSSL, which has the correct characteristics for storing an SSL private key. The JANSSL file should be a minimum of 1050 pages; the RKTools SIRIUS file contains a sample CREATE.JANSSL deck. RKTools installation also creates a subsystem called JANSSL, which provides components for the certificate management application. The SIRIUS file that contains the definition is SUBSYS.DEF.JANSSL. As described later (Add appropriate users to the JANSSL subsystem), you may need to update the subsystem.

Make an initial SSL connection

In order to implement and test the success of your first SSL connection, you can use the Rocket-provided internal certificate, which was distributed with the Janus Network Security tape (and discussed further in Self-signed certificates Ultimately, you will probably want to arrange to receive a certificate from a commercial certifying authority, as described later in Implementing a server certificate.

The steps in the subsections that follow describe how to set up and connect to a Janus Web Server server port. If you are configuring a Janus CLSOCK SSL port, for example, the same sequence of steps apply (except for the last subsection), but the keywords WEB and WEBSERV in the JANUS command examples must be replaced as necessary by CLSOCK.

Define and start an SSL port

Your SSL port definition indicates that connections to the port are to use the Rocket-provided internal certificate. In the server Online, a user with system manager or system administrator privileges must issue a command like:

JANUS DEFINE SSLWEB 443 WEBSERV 5 SSL *

where:

SSLWEB can be replaced by an arbitrary port name.
443 can be replaced by an arbitrary port number (although 443 is the default for HTTPS).
5 can be replaced by a different maximum thread value.
SSL * indicates that the internal certificate and private key is to be used. When a certificate from a certifying authority is being used, you replace the * with the location and name of the procedure that contains the certificate, as shown in Defining and starting a port.

For more information about the JANUS DEFINE command, see JANUS DEFINE.

To start the port, enter:

JANUS START SSLWEB

where SSLWEB is the port name specified on the JANUS DEFINE command. The port is started and SSL is enabled.

Add appropriate users to the JANSSL subsystem

When the RKTools installation is done, the user doing the install is given privileges to run JANSSL. If the user that did the RKTools installation is not the one that will manage certificates and private keys, the latter user must be added as a JANSSL subsystem user (probably using SUBSYSMGMT). For example, if MARY installed RKTools but CURTIS is going to manage certificates, CURTIS must be added as a JANSSL subsystem user.

In addition, while using SUBSYSMGMT, make sure that the JANSSL subsystem communication global is NEXT, the exit value is LOG, and the procedure file is SIRIUS.

Add web rule to authorize user access to the port

When the web port using the internal private key is defined, Janus Web Server rules are automatically created so that the defining user can access any resource on the SSL port. If the user that issued the JANUS DEFINE command (in Define and start an SSL port) is not the one that will manage certificates and private keys, a rule must be added to allow the latter user to access resources on the SSL port.

For example, if MORT issued the JANUS DEFINE command for the SSL port but TAMARA is going to manage certificates, add a rule like the following to the SSL port definition to allow TAMARA to access resources on that port:

JANUS WEB SSLWEB ALLOW * USER TAMARA

This is the best way to protect the server. The following subsections describe three other ways that you can authorize users to access the SSL port. Though you may be tempted to use them, each of the following is discouraged, as described below. For additional comments about access, see Many alternatives for restricting or permitting access.

Allowing any valid logged-in user

The preceding paragraphs described how to add a web server rule to authorize an individual user to access the secured port. An even simpler approach is to modify the rule as follows to allow any valid userid to access data on the SSL port:

JANUS WEB SSLWEB ALLOW * USER *

Although it is not recommended, note that this rule does not expose a security hole: without being a JANSSL subsystem user, there is not much a user can do on the SSL thread as shipped by Rocket. (Remember, JANSSL is the subsystem installed with Janus Network Security that provides support for the certificate management application.)

However, this degree of access might become an issue as you add your own applications to the SSL port, at which point it is up to you whether to enforce security through web rules, subsystem access rules, or internal application checks. The appropriate security mechanism for your site in this case is beyond the scope of this document.

Accessing JANSSL through non-SSL ports

It is possible to access the JANSSL subsystem through a non-SSL port by specifying a rule such as this:

JANUS WEB WEBPORT ALLOW /JANWEB/JANSSL* USER *

where WEBPORT is not your Janus SSL port. While possible, this is strongly discouraged, because the above web rule will result in unencrypted Model 204 passwords being sent over the network as JANSSL verifies access privileges.

The only reason to allow access to JANSSL like this might be that there is local network security that makes you feel confident that this is not a problem, and for some reason, it is impossible to get your browser working with the internal Janus certificate.

Making WEBUSER a JANSSL subsystem user

Perhaps the worst way to provide access to the certificate management application is one of the following:

Define as a JANSSL subsystem user the default Model 204 account ID (normally WEBUSER) that is used for logons of URLs that require no user ID.
Make the JANSSL subsystem public.

These approaches let anyone with a browser generate (and overlay) private keys and certificates in the JANSSL file. Security is completely gone, and you might as well not use SSL. You could perhaps make this somewhat secure by limiting access to certain URLs based on IP address, but this is still considered risky from a security perspective.

Connect to the SSL port from a browser

Having defined and configured an SSL port, you can now attempt a connection. As described in How a browser should connect, the difference between connecting to an SSL-secured port and an unsecured one is in the designation of the service in the URL sent from the browser.

To reach a secured port, you simply specify "https" rather than "http" in the URL that points to your server.

If you chose to define the port with a number other than the default of 443, you must specify that number as well. For example, for a site that is testing the secured port 8443, specify:

https://www.yourdomain.com:8443

If you have yet to generate an internal certificate, Janus Network Security produces by default an out of date Sirius self-signed certificate. In response, your browser will probably initially display one or more notices informing you that the default Sirius certificate has expired, that Sirius is an unknown certifying authority, or that the domain name you specified does not match the name on the certificate. For more information about certificates and certificate authorities, see Certificates and Certifying authorities.

At the browser, you can view the certificate for supporting evidence that it is indeed from Sirius, then choose to accept it. Next, you are prompted for your Model 204 user ID and password.

Finally, accessing this SSL port for the first time invokes the Default Janus Web Home Page. You are taken to this page as the result of default JANUS WEB ON rules supplied with the Janus Web Server (and viewable via the JANUS DISPLAYWEB command). You can change the default page by defining a JANUS WEB ON rule for your secured port that points to another page (see JANUS WEB ON for more information).

On the default home page, a link in the introduction ("configure and manage Janus SSL support") points to a page that describes Janus SSL and which restates much of the document you are now reading. This link and those in the Janus certificate application are also resolved by default JANUS WEB ON rules.

Implementing a server certificate describes how to get an SSL certificate for your site from a certifying authority. If you want to generate an update to the default Janus internal certificate, that is, generate a self-signed certificate that will bear your own site's current information and date, you also use the request form described in "Implementing a server certificate."