Installing and configuring Janus Network Security

Before you can start using secured communications with Janus Network Security, some preliminary tasks must be completed. The tasks should occur in the following sequence:

1. 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 in support of Janus Network Security.

2. Install or update RKTools.
3. 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) access privileges.
   3. Download internal certificate as CA to browser.

   Your initial connection will be a test of the setup to this point, using the Rocket-provided internal certificate (discussed in Self-signed certificates).

Each of these steps is further described below.

Install Sirius Mods

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

The Sirius Mods are a set of features providing a base of support for most the products formerly owned by Sirius - they must be installed before proceeding.

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

SIRIUS

The resulting display will include the current release of the Sirius Mods.

Install or update RKTools

A few components of RKTools are 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, the JANSSL file should be allocated and initialized. JANSSL is used to store SSL certificates, certificate requests and private keys. The JANSSL file should have a minimum of 1050 pages; the RKTools SIRIUS file contains a sample CREATE.JANSSL deck. RKTools installation also creates the JANSSL subsystem, which is the certificate management application. The procedure containing the JANSSL apsy definition is SUBSYS.DEF.JANSSL - it is in file SIRIUS for releases prior to RKTools 7.7, and in M204PROC for 7.7 and later. 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 your first SSL connection, you can use the Rocket-provided internal certificate, which was distributed with Janus Network Security (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 following subsections describe how to set up and connect to a Janus Web Server port. If you are configuring a different type of Janus port, like an SSL-protected client socket port, for example, the same sequence of steps would apply except for the last subsection, and the keywords denoting the port type - WEB and WEBSERV - in the JANUS command examples would be replaced by CLSOCK.

Define and start an SSL port

To define an initial SSL web port using the Rocket-provided internal certificate. a user with system manager or system administrator privileges must issue a command like:

JANUS DEFINE [portName] 443 WEBSERV 5 SSL [sslInfo]

where:

• [portName] can be replaced by an arbitrary port name up to 30 characters in length.
• 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.
• [sslInfo] Using a '*' indicates that the internal, Rocket-generated, certificate and private key is to be used. When a certificate from a certifying authority is being used, you replace the [sslInfo] with the file name and procedure name that contains the certificate - so, something like, "SSL MYFILE MYCERTIFICATE.CERT" - 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 who 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 SSLthread. (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 allows you to feel confident that this is not a problem, and for some reason, it is not possible for your browser to work 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 specify "https" rather than "http" in the URL.

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."

See also

• Janus Network Security
• Installing and configuring Janus Network Security
• Implementing a server certificate
• Verifying a client certificate