The Compass robot is designed to mimic the
behaviour of a user/web browser combination when accessing SSL sites.
In order to understand the robot's behaviour and configuration for SSL,
there are several different scenarios that must be considered:
a site may or may not be trusted;
a site's certificate may be signed
by either a "standard" or "nonstandard" Certificate Authority (a standard
CA is one whose public key is preconfigured into products
like Netscape Communicator);
a site's CA may or may not be trusted;
a site may or not require certificate based client authentication;
etc.
The Web Server administration server can configure certificate "aliases" for
the servers that it manages, however this capability falls short of the robot's
requirements, especially with respect to user certificates for client
authentication. As a result, the Compass robot is best configured for
SSL using Netscape Communicator itself.
To configure a certificate database for the Compass robot you
should configure a Communicator browser for access to the SSL sites
you wish to robot. All of the normal options are available,
including direct trust of SSL sites, indirect trust through trusted
CAs, etc. When the robot accesses an SSL site it will
behave in exactly the same way as Communicator with the exception
that the robot will not prompt to trust, or accept connections to,
unknown sites. With Compass 3.01C and later, the robot's default
behaviour is to trust all SSL servers without checking their
certificate credentials, however, you can override this behaviour
to enforce server/CA trust checking (see below).
For sites requiring client authentication, you must obtain a
user certificate and add that to your Communicator certificate database.
Many such certificates can be added, for all of the different sites
you intend to robot. Unlike Communicator, the robot will not prompt
for a certificate when a site requests client authentication.
Instead, the robot will automatically choose a user certificate that it knows
to be trusted by the server. This choice is based on the server's list of
trusted CAs, which is exchanged as part of the SSL handshake protocol.
You should therefore be careful to configure both your sites (that are
under your control) and the robot so that client auth requests
are unambiguous. An example of an ambiguous client auth
request would be a site that trusts
standard CAs but which will actually only accept certificates signed by a
nonstandard CA. This situation often goes overlooked because browser users
typically select the correct certificate when prompted for such a site.
Communicator can protect its certificate database with a password.
You can choose to leave this password empty, or you can set a password.
If you do use a password for the certificate database, then you must
add a corresponding line to the robot's config file
serverhome/https-instance/config/process.conf
.
This line should take the form:
ssl-certdb-password="your_password_here"
To enforce SSL server/CA trust validation, add this line to process.conf:
ssl-validate-servers="true"
To install Communicator's certificate database for the Compass robot, simply
copy the files communicator_home_directory/cert7.db,key3.db,secmod[ule].db
to the serverhome/https-instance/config/
directory.
The secmodule file must be named secmodule.db
for use by te robot.
You must ensure that the certificate database files are
readable by the server user. Eg, if Compass is installed as root/nobody,
then the three files should have rw-r--r-- permissions.
It is also possible to leave SSL "unconfigured" for the robot.
In this case, a default certificate database will be created in
the serverhome/https-instance/config/
directory the
first time the robot runs. Client authentication will fail because
the robot has no user certificates, and only sites signed by
standard CAs will be trusted and accessible.