Janus Network Security - Revision history

Admin: Admin moved page Introducing Janus Network Security to Janus Network Security without leaving a redirect: "Introducing" was superfluous

2017-04-10T15:47:00Z

Admin moved page Introducing Janus Network Security to Janus Network Security without leaving a redirect: "Introducing" was superfluous

← Older revision	Revision as of 15:47, 10 April 2017
(No difference)

JAL: add "See also"

2017-04-07T16:30:41Z

add "See also"

← Older revision		Revision as of 16:30, 7 April 2017
Line 583:		Line 583:
	certifying authority.		certifying authority.
	For more about this, see [[Implementing a server certificate#orgca\|Acting as an Organizational Certifying Authority]], which is implemented as the JANSSL subsystem.		For more about this, see [[Implementing a server certificate#orgca\|Acting as an Organizational Certifying Authority]], which is implemented as the JANSSL subsystem.

			==See also==
			{{Template:Janus Network Security topic list}}

	[[Category: Janus Network Security]]		[[Category: Janus Network Security]]

JAL: /* Janus Network Security documentation */ link repair

2017-03-03T21:58:14Z

Janus Network Security documentation: link repair

← Older revision		Revision as of 21:58, 3 March 2017
Line 46:		Line 46:
	Notes:		Notes:
	<ul>		<ul>
	<li>For messages related to <var class="product">Janus Network Security</var>, ~~please~~ refer to [[~~:Category:Sirius Mods~~ messages]]. </li>		<li>For messages related to <var class="product">Janus Network Security</var>, refer to [[List of Model 204 messages#msir\|MSIR. messages]]. </li>

	<li>See the [[M204wiki main page#Release notes, wishlists, and punch lists\|Model 204 release notes]] for information about <var class="product">Janus Network Security</var> product changes and Model 204 feature support. </li>		<li>See the [[M204wiki main page#Release notes, wishlists, and punch lists\|Model 204 release notes]] for information about <var class="product">Janus Network Security</var> product changes and Model 204 feature support. </li>

Alan at 13:20, 26 October 2016

2016-10-26T13:20:50Z

← Older revision		Revision as of 13:20, 26 October 2016
Line 573:		Line 573:
	</ul>		</ul>

	With its Certificate Management Application, described in detail		With its Certificate Management Application (aka JANSSL), described in detail
	in [[Implementing a server certificate]], <var class="product">Janus Network Security</var> helps you through this process.		in [[Implementing a server certificate]], <var class="product">Janus Network Security</var> helps you through this process.
	It provides an application for generating		It provides an application for generating
Line 582:		Line 582:
	The last of these applications is useful if a site wants to have a local		The last of these applications is useful if a site wants to have a local
	certifying authority.		certifying authority.
	For more about this, see [[Implementing a server certificate#orgca\|Acting as an Organizational Certifying Authority]].		For more about this, see [[Implementing a server certificate#orgca\|Acting as an Organizational Certifying Authority]], which is implemented as the JANSSL subsystem.

	[[Category: Janus Network Security]]		[[Category: Janus Network Security]]

ELowell at 20:09, 30 August 2016

2016-08-30T20:09:31Z

← Older revision		Revision as of 20:09, 30 August 2016
Line 18:		Line 18:
	intranet as well, protecting the integrity of information transmitted		intranet as well, protecting the integrity of information transmitted
	within the network.		within the network.
	~~Just because~~ an intranet protects an organization		Even though an intranet protects an organization
	from attacks by outsiders, it is imprudent to ignore potential		from attacks by outsiders, it is imprudent to ignore potential
	attacks by insiders ~~—~~ who may find such information even more valuable than outsiders.		attacks by insiders, who may find such information even more valuable than outsiders.

	==<b id="about"></b>About this topic==		==<b id="about"></b>About this topic==

JAL: remove auto comment

2016-06-02T19:48:55Z

remove auto comment

← Older revision		Revision as of 19:48, 2 June 2016
Line 1:		Line 1:
	~~<!--Page automatically generated by CMSTOWIK EXEC and will be~~
	automatically replaced -- any manual edits will be lost.
	~~You've been warned. .. (Page built by JAL at the SIRIUS VM; file: FUNPGNEW SYSUT2) -->~~
	~~<!-- Page name: Introducing Janus Network Security-->~~
	<var class="product">Janus Network Security</var> consists primarily of support for the SSL		<var class="product">Janus Network Security</var> consists primarily of support for the SSL
	(Secure Sockets Layer) and the TLS (Transport Layer Security) protocols,		(Secure Sockets Layer) and the TLS (Transport Layer Security) protocols,

JAL: /* Janus Network Security documentation */ remove pointer to methods

2016-05-31T21:53:38Z

Janus Network Security documentation: remove pointer to methods

← Older revision		Revision as of 21:53, 31 May 2016
Line 50:		Line 50:
	Notes:		Notes:
	<ul>		<ul>
	~~<li>[[Cryptographic methods]] describes the <var class="product">SOUL</var> methods~~
	~~that implement the basic <var class="product">Janus Network Security</var> hashing and encryption algorithms. </li>~~

	<li>For messages related to <var class="product">Janus Network Security</var>, please refer to [[:Category:Sirius Mods messages]]. </li>		<li>For messages related to <var class="product">Janus Network Security</var>, please refer to [[:Category:Sirius Mods messages]]. </li>

Admin: 1 revision: Janus Network Security pages

2016-05-31T21:47:21Z

1 revision: Janus Network Security pages

← Older revision	Revision as of 21:47, 31 May 2016
(No difference)

JAL: /* Janus Network Security documentation */ use template

2016-05-27T00:56:00Z

Janus Network Security documentation: use template

New page

<var class="product">Janus Network Security</var> consists primarily of support for the SSL
(Secure Sockets Layer) and the TLS (Transport Layer Security) protocols,
which provide secure communications for users of Janus products.
The TLS protocol, developed by the IETF Internet standards group,
is a more secure extension to SSL.
This topic will sometimes use "SSL" loosely to refer to SSL (V2 and V3) and
TLS, and it will also use the terms "SSL-like" and "SSL/TLS."

These protocols are most typically used to encrypt and authenticate the
communications of <var class="product">[[Janus Web Server]]</var> applications.
Used by web servers throughout the Internet,
SSL and TLS are industry standard approaches to secured communications that
enable users to transmit private
information, such as credit cards, with the confidence that the encrypted data
cannot be intercepted and that the authenticated recipient of the data is the intended one.

Secured communications can be valuable within an organizational
intranet as well, protecting the integrity of information transmitted
within the network.
Just because an intranet protects an organization
from attacks by outsiders, it is imprudent to ignore potential
attacks by insiders — who may find such information even more valuable than outsiders.

==About this topic==
This topic introduces the key SSL concepts, and
it addresses the use of SSL/TLS to
provide secure communications for connections to your
Janus Server sites via the Internet or via an organizational intranet,
as well as for connections to SSL servers from your <var class="product">[[Janus Sockets]]</var> clients.
Once <var class="product">Janus Network Security</var> is set up and tested, it operates
quietly in the background, and little further effort is required to have
fully secured communications.

Generally, <var class="product">Janus Network Security</var> is installed as an addition to <var class="product">Janus Web Server</var>.
It is also possible to install it without <var class="product">Janus Web Server</var>
(for use with other non-web Janus products).
For the sake of simplicity, this topic largely assumes that you will be using <var class="product">Janus Network Security</var> with
<var class="product">Janus Web Server</var>.

===Janus Network Security documentation===
This introductory page provides a technical background for the rest of the <var class="product">Janus Network Security</var>
topics, whose pages guide you through the implementation of <var class="product">Janus Network Security</var>
at your site:
{{Template:Janus Network Security topic list}}

Notes:
<ul>
<li>[[Cryptographic methods]] describes the <var class="product">SOUL</var> methods
that implement the basic <var class="product">Janus Network Security</var> hashing and encryption algorithms. </li>

<li>For messages related to <var class="product">Janus Network Security</var>, please refer to [[:Category:Sirius Mods messages]]. </li>

<li>See the [[M204wiki main page#Release notes, wishlists, and punch lists|Model 204 release notes]] for information about <var class="product">Janus Network Security</var> product changes and Model 204 feature support. </li>

<li>Much of the content of the Janus Network Security wiki pages is also reproduced in other HTML pages:
The [[Installing and configuring Janus Network Security#Connect to the SSL port from a browser|first time you connect]] to an Online using <var class="product">Janus Network Security</var>, a default home
page is displayed.
In the introduction on that page, a link ("configure and manage Janus SSL
support") leads to pages that restate much of this wiki document. </li>
</ul>

==About SSL==
SSL, the Secure Socket Layer, is a communication protocol that makes it
possible to safely transmit secure information over a non-secure
network. SSL accomplishes this primarily by encrypting communications.
It can also enable authentication of the server and/or the client to
ensure that each party is who they say the are.
These three components are described below.

===Encryption===
The primary means by which SSL accomplishes safe communications is
through encryption of the data that is sent between a client or browser and
a server.
This encryption makes it practically
impossible (or at least extremely difficult) for anyone other than the
intended recipient of the data to decrypt it, even if a third party has
access to the complete contents of the communication.
This is a way of defeating "snooping", the capturing
and retrieval of passwords and other sensitive information from
data packets
transmitted over a network and intended for another machine.

The SSL protocol is typically layered over the TCP protocol and
under the HTTP (web) protocol.
Information that would
normally pass between a web server and browser is encrypted by SSL
before being sent over the network via TCP/IP.
This means that
communications over a public TCP/IP network can be more secure
than that over a private VTAM network, because VTAM security
depends on the security of the physical network while
SSL security is based on mathematics.
The cost of this extra
security is the CPU processing that SSL requires,
especially on the server side.

===Authentication===
In addition to encryption, SSL also provides "authentication."
Authentication means either or both parties (client and server) can be
confident that the other is indeed who they say they are.

====Authentication of the server====
SSL server authentication provides information to the
client that can be examined by the end user to verify some basic
information about the server.

SSL typically provides the country, state or province, city or town,
organization name (Mega Industries, Hard Knocks University, Grand Duchy
of Liechtenstein, etc.), organizational unit (Department of
Obfuscation, Engineering, MIS, etc.) and a server name (Student Web
Server, Parts and Supplies Ordering Server, Sensitive Information
Server, etc.).

This authentication defeats "spoofing," the practice of
<ol>
<li>Setting up a server to intercept messages intended for another server,
responding to them in such a way that the end user is convinced he or
she is communicating with the correct server. </li>

<li>Capturing sensitive information such as passwords from the end user. </li>
</ol>
Spoofers sometimes simply pass information through to the correct server and
back from the server to the client, recording sensitive
information as it passes through.
This technique is sometimes known as a "man-in-the-middle attack."

SSL authentication defeats all forms of
spoofing, because it is practically impossible (or extremely difficult)
for a spoofing server to send the correct SSL authentication
information to the client.

Server authentication is enabled by way of certificates.
Certificates
are digital IDs that verify that a server has been certified by a
publicly recognized authority as being who they say they are.
A certificate is installed in the server and then recognized by client browsers.

<var class="product">Janus Network Security</var> comes with an initial certificate, provided by
Rocket Software specifically for use by your organization (Rocket has certified
the organization's identity).
You can also arrange to purchase a
certificate through widely recognized companies, called Certificate
Authorities, if it is important for your users to know that
your server's identity has been certified by such an organization.

====Authentication of the client====
SSL can also provide client authentication.
Using techniques like those used for server authentication,
it is possible for a server to verify the identity (more or less) of the
client with which it is communicating, without the use of a password
database on the server.

<var class="product">Janus Network Security</var> supports client certificates, which establish the identity of
the client.
These are acquired like server certificates and installed on
client machines — typically browsers but possibly a Janus SSL CLSOCK
machine, for example.
Not required by most web servers,
these certificates are requested and sent during the initial
connection negotiation between client and server, or
during a subsequent connection renegotiation.

For more information about Janus support for client certificates,
see [[Verifying a client certificate]].

In addition, client
authentication of a sort can be achieved by requiring a user to enter a
valid userid and password (as defined in the online
in which <var class="product">Janus Web Server</var> is running) when connecting to a protected
resource.

This optional feature, which can be set for all or for specific
applications on a server, is described in [[Installing and configuring Janus Network Security]].
Because of SSL/TLS
encryption of communications, such passing of userids and
passwords over the network is secure.

===When should SSL be used?===
The obvious answer is whenever secure data is to be transmitted.
Unfortunately, a myth has developed around SSL and security in general,
that one need only be concerned about it when communicating over the
Internet, home of socio-pathic hackers and criminal geniuses
whose days are spent trying to wreak havoc and steal information from
your system.

====Threats from company insiders====
The reality is that there is generally more opportunity and motivation
to steal information inside a company than outside.
Who, after all, is
more interested in personnel records than corporate insiders?
Who is more interested in the personal e-mail of a supervisor than the
supervisor's subordinates?

Furthermore, intranets tend to be made up of
one or more LAN segments where packets are transmitted freely for all to see.
This is a much easier environment in which to steal data by
capturing packets than the Internet, where it is now fairly difficult to
capture packets not intended for your local network.

Finally, it
doesn't take a criminal genius or a hacker to steal data sent over a
local network.
Any moderately skilled individual (someone who can use a
spreadsheet) armed with a network diagnostic tool (which incidentally
has a legitimate purpose) can capture any and all information sent over
a local network.

====Protecting transmission of passwords====
The bottom line is that SSL should be used on any
connection over which sensitive data is to be transferred.
Perhaps the
most important sensitive data in any <var class="product">Model 204</var> system is passwords.
Since passwords are used to protect other resources, access to a
password will compromise the security of all resources protected by that password.
Even worse, certain passwords such as system manager
passwords can be used to gain access to any resource in a <var class="product">Model 204</var> region.

A good rule of thumb, therefore, is that any connection over which a
password will pass should use SSL.
<var class="product">Janus Web Server</var> actually issues a warning
if you try to define a <var>JANUS WEB</var> rule that would result in a
password being transmitted over a non-SSL connection.
This would happen with any <var>JANUS WEB ALLOW</var> rule that has a <code>USER</code>
clause in it, since the <code>USER</code> clause indicates a user login,
hence userid/password are required for access to the URL specified by
the <var>JANUS WEB</var> rule.

====Protecting weak links====
A dangerous fallacy is that if a resource is only slightly private —
that is, while you want to limit access to the resource, it's not that
big a problem if someone gets access to it — you don't need to use SSL.
Remember, even if the resource you are protecting is not that
important, the password of the userid accessing that resource is likely
to be important.
Even worse, once a userid/password is used to access
any URL on a non-SSL <var class="product">Janus Web Server</var> port, that userid/password combination
will be sent by the browser (unencrypted) for all other URLs on that
port (just in case these require a login).
Thus by allowing a password
to be transmitted unencrypted for a single URL on a non-SSL port,
that password might be sent, unencrypted, hundreds of times over the
network.

Once again, a good basic rule of thumb is that if a login is required
to access a resource or URL, always force access to that
resource or URL to go through SSL.

==About Your SSL port==
This section introduces some of the ways that <var class="product">Janus Network Security</var>
can be configured to provide different access controls for
your users and applications.
It briefly describes how to make such
configurations, as well as how to make a connection from a web browser.

===Security alternatives===
<var class="product">Janus Network Security</var> is flexible and able to provide a variety of levels of security to
suit your needs.
This section describes the
different approaches available to you for securing (or not securing)
ports for your <var class="product">Janus Web Server</var> applications.

Before proceeding, it may be useful to clarify the term "port."
A port is a defined entrance into your server, which can permit
entry by one or more users.
You can have more than one port on a server.

====Secured and unsecured ports allowed on same server====
You can choose to force SSL-protected communications on all ports on
your server, or you could enable it only on specific ones.
That means
you could have a web site which provides some documents that are served
only on secured ports while allowing other documents to be served on
unsecured ports.

====Many alternatives for restricting or permitting access====
Several choices are available
to you in restricting or permitting access to your secured ports, both
in terms of applications and users.
These choices are set by the
configuration of the server port, described later in this document but
outlined briefly below.

Controlling access by application on a secured port:

On a given secured port you can decide whether to require SSL-enabled
communications for any or all applications served on that port.
That
means you can implement tighter security for one application that you
may for another. 

Controlling access by user validation:

For any or all applications, you can limit access by requiring that
users log in with a valid userid and password as defined in the <var class="product">Model 204</var>
online in which <var class="product">Janus Web Server</var> is running.
(Note that you can
instead permit access by users without userids, as described below.) 

By configuring the port to require client validation, the user would be
prompted when connecting to a web page or application defined for such
access control.
This choice of access control would mean that only
users who are defined in the online and who log in with a valid
password would be able to access the application.

Restricting access to one, several, or a group of users:

Having been validated, access can then further be restricted to one
user, a list of them, or a defined group of them.
The group of users
would be defined in the configuration of <var class="product">Janus Web Server</var>.


Permitting access to all web users:

Alternatively, you can permit any and all users on the Internet (or
intranet) to connect to an application, without requiring any log in at
all.
This approach is common on most commercial web sites
using SSL for secured communications.
In such a case, communications is still secured, but you do not expect to know in
advance the identity of all users who may be connecting to your server
(nor must you create logon IDs and passwords for them in the <var class="product">Model 204</var>
Online.) 

===Configuring the server port===
The use of SSL is a characteristic of a TCP/IP server port.
That is, either all communications to a given server port uses SSL, or none of it does.
(As described above, you can define multiple ports on a server,
so some can be secured while some are not.)
The use of SSL on a port is
specified on the <var>JANUS DEFINE</var> subcommand.

Janus commands are entered in the <var class="product">Model 204</var> Online in which <var class="product">Janus Web Server</var>
is running, generally by a system manager.
They define how a server port is to be configured, and they are described
further in the [[Janus Web Server]] pages.

For example, the following command
defines a port that is to use SSL on port number 443:
<nowiki>JANUS DEFINE WEBSSL 443 WEBSERV 10 SSL JANSSL MYCERT
</nowiki>
The <code>SSL</code> keyword is followed by the name of a file and a
procedure in that file that contains a certificate and
private key to be used by SSL for the port being defined.

Further information on port configuration is provided in
[[Installing and configuring Janus Network Security#sslport|Define and start an SSL port]].

More information about certificates and private keys is available in [[#keycert|About keys and certificates]].

===Defining private key decryption subtasks===
If you use SSL ports under MVS, you may want to configure one or more
private key decryption subtasks. These are real MVS subtasks which
are devoted to decrypting SSL private keys, a CPU intensive process. Moving
this work to real subtasks increases <var class="product">Model 204</var> maintask availability for other work.
These subtasks do not depend on the MP/204 feature, and they can be used whether
or not you have MP/204.

For a complete description of the decryption subtask parameters,
see <var>[[MAXRDS parameter|MAXRDS]]</var> and <var>[[ACTRDS parameter|ACTRDS]]</var>.

===How a browser should connect===
Browsers decide whether to use SSL based on the scheme or service part
of the URL to which they are connecting.
More specifically, if the service indicates http as in
<nowiki>http://rocketsoftware.com/football/scores
</nowiki>
then SSL will not be used.
If the service indicate https as in
<nowiki>https://rocketsoftware.com/personnel/salaries
</nowiki>
then SSL will be used.

This does not mean that a user can gain unsecured access to a secured
resource simply by specifying <code>http</code> rather than <code>https</code>.
On the contrary,
if the browser and the server are in disagreement over whether SSL is
to be used, a communication error will occur.

When a web browser connects to an SSL-secured port, the
browser displays an image of a connected key at the bottom of
the screen.
Depending on the browser and how it has been configured,
the user may also receive a message upon transmitting data to the
server that indicates that their communication is secured.

====Specifying a particular port====
When a port is defined for either secure or non-secure web server
access, a number is associated with it, called the port number.
The default port number for non-SSL web (HTTP) service is 80.
When attempting to connect to a web server at its default address,
you need not specify the number in the URL.
To access a non-SSL
web server port defined with a number other than 80, you must indicate
the number of that port on the URL.

Similarly, the default port for SSL web (HTTPS) service is 443.
Just as it is possible to make a connection to a specific port when not
using SSL, it is also possible to do so using SSL.
For example, the following URL
indicates an attempt to open SSL communications on port 1776:
<nowiki>https://rocketsoftware.com:1776
</nowiki>

==About keys and certificates==
In order to provide for secure communications and authentication, SSL
employs several features, including public and private keys for
encryption, and certificates and digital signatures for authentication.
Each of these is described in this section, which concludes with a
discussion of how to obtain and use certificates.

===Public key/private key cryptography===
An important component of SSL security is "public key/private
key" cryptography.
Such cryptography depends on the existence of pairs
of large numbers that can be used as inputs to a formula or program for
the purposes of encryption and decryption.
The actual nature of the
formula and numbers is beyond the scope of this document.
Furthermore, knowledge of the details of the public key/private key algorithms is
unnecessary for use of SSL.

Some important features of public and
private keys are useful to keep in mind, however:
<ul>
<li>Something encrypted with a public key can only be decrypted with
the private key. </li>

<li>Something encrypted with a private key can only be decrypted with
the public key. </li>

<li>It is (practically) impossible to derive the private key from the
public key. </li>

<li>If something correctly decrypts with the public key, it must have
been encrypted with the private key. </li>
</ul>

Given these four features, it is then possible to assert that the
holder of a private key can freely distribute the corresponding public
key, and can be sure that only he or she could decrypt anything encrypted
with that public key.
This, of course, depends on the private key being
protected from access by anyone other than its owner.

===Certificates===
One application of public/private key cryptography is the creation of
certificates, which authenticate the authority of a client or server.
A certificate is the formatted structure in which a public key is typically
distributed.
This structure also
contains some basic information about the holder of the private key
associated with the public key.

Server certificates used by SSL typically contain the country,
state or province, locality (city, town, village, etc.), organization,
and organizational unit of the holder of the private key.
In addition,
SSL server certificates contain the TCP/IP host name of the server that holds
the private key.

The information in a server certificate can normally be
viewed in a client application such as a browser, so an end user can
be sure that he or she is communicating with the correct server.
Note: An SSL client will automatically verify that the host name in a server
certificate matches the name of the host to which it is connecting.


A server may also request a sender's client certificate for
authentication.
The certificate contains information about the user, in addition to a unique
private-public key pair.
Client certificates, like server certificates, are obtained from a trusted source,
and they are stored on the sending computer and accessible from some
certificate management tool.

====Digital signatures====
One issue that arises is how to be sure that the information
in a certificate does, in fact, correctly reflect the holder of the
private key.
It would seem that anyone could create a private and public key, package
the public key in a certificate with phony information, and pass his or
herself off as another server owned by another company.
This problem is virtually eliminated by the use of
digital signatures.

A digital signature for a certificate is a hash of the certificate
encrypted with a private key.
Digital signatures have the following characteristics:
<ul>
<li>The hash function must be well-known and not reversible.
That is, it should not be possible to start with the hash and work
back to a certificate.
The well-known hash function usually used in SSL is <code>MD5</code>. </li>

<li>The public key associated with the private key used to create the
digital signature must be known by the receiver of the certificate.
If a certificate is to work with many different clients, it is helpful
for this public key to be "well known." </li>

<li>The private key used to create the digital signature must be well
protected, so only the private key's holder can digitally "sign"
a certificate. </li>

<li>The holder of the private key used for signing (sometimes
called a certifying authority, or CA)
makes an effort to verify that the information in the certificate
correctly identifies the holder of the associated private key.
For example, a CA should verify that the organization name in a certificate
actually matches the name of the organization that holds the associated
private key. </li>
</ul>

====Certifying authorities====
There are several certifying authorities whose public keys are shipped
with most browsers.
Chief amongst these is VeriSign, Inc., at http://www.verisign.com.
A certificate digitally signed by VeriSign has these benefits:
<ul>
<li>The holder of the private key associated with the
certificate is almost certainly correctly identified by the certificate. </li>

<li>Almost every SSL client will be able to verify the signature on the
certificate (because the VeriSign public key is so widely known). </li>
</ul>

Most browsers have a mechanism for adding a new CA to their database
of valid CAs.
This makes it possible to use certificates signed by
non-standard CAs.

====Self-signed certificates====
Some browsers accept a server's "self-signed" certificate.
That is, the private key used to sign the certificate is the private
key associated with the public key in the certificate.

Self-signed certificates have some problems associated with them:
<ul>
<li>Since the certificate is self-signed, there is no way to be
certain from just the certificate that the certificate correctly
describes the holder of the associated private key.
Fortunately, there
are often other means to validate this information. </li>

<li>Some browsers don't accept self-signed certificates, and
those that do, often require extra user interaction to use the
self-signed certificate (as they should). </li>
</ul>

Nevertheless, non-standard CAs and self-signed certificates can be
useful for testing and for establishing secure connections before a
certificate signed by a standard CA has been obtained.

For example, the <var class="product">Janus Web Server</var> application for generating a request for a certificate
signature (to VeriSign, Inc., or some other standard certifying
authority) should be run in secure mode, that is, over an SSL connection.
What certificate should be used to secure the connection
the first time this application is run?
The answer is a self-signed
certificate provided by Rocket Software with the <var class="product">Janus Network Security</var>
support.
(This is also referred to elsewhere in this document as the "internal certificate".)

====Certificate acquisition====
Getting a valid certificate and private key typically
involves a multi-step process like the following:
<ul>
<li>You generate a private key and an associated certificate request. </li>

<li>You send the certificate request to the certifying authority (CA). </li>

<li>The CA digitally signs the certificate and sends it back to you. </li>

<li>You receive the signed certificate, associating the signed certificate with the private key. </li>
</ul>

With its Certificate Management Application, described in detail
in [[Implementing a server certificate]], <var class="product">Janus Network Security</var> helps you through this process.
It provides an application for generating
private keys and certificate requests, and an application for receiving
signed certificates from a certifying authority.
It also provides an application for signing certificate requests.

The last of these applications is useful if a site wants to have a local
certifying authority.
For more about this, see [[Implementing a server certificate#orgca|Acting as an Organizational Certifying Authority]].

[[Category: Janus Network Security]]