Your browser does not allow this site to store cookies and other data. Some functionality on this site may not work without them. See Privacy Policy for details on how we would use cookies.

PreviousNextUp[Front page] [Index]

Starting and Stopping SSH Tectia Certifier in Unix

This section describes how to start SSH Tectia Certifier on Unix platforms (Linux, Solaris, and HP-UX).

After running the full-installation script, all of the SSH Tectia Certifier processes can be stopped and started manually.

When you want to start all processes at the same time, simply use the startup script that was generated during installation:

./ssh-ca-start

When you want to stop the processes, you can use the termination script generated during installation:

./ssh-ca-stop

Given without parameters, this script starts the processes in the background as daemons, that is, they detach from the terminal and all their diagnostic output is sent to the system log, using the syslog facility LOCAL0 for the Engine and the Database and LOCAL1 for the Server.

The startup script can be given with any combination of the arguments:

  • insecure (insecure maintenance mode without TLS protection)
  • X (run the processes in their own xterms instead of daemonizing)
  • debug (more diagnostic output).
  • database
  • engine
  • server

For example, the following command starts the three processes in separate xterm windows with debug info enabled:

./ssh-ca-start X debug

If you want to start the processes individually, first you must start the Database if it is not already running. It is started by running the following command in the certifier directory:

./ssh-ca-start database

Then run commands like the following in the certifier directory:

./ssh-ca-start engine
./ssh-ca-start server

The following command sequence would start the engine in the foreground:

./ssh-ca-start ENGINE

The following command sequence would start the server in the foreground:

./ssh-ca-start SERVER

Renewing Expired TLS Certificates

If ssh-ca-server has been down long enough, so that TLS certificate has expired and the new one has not been enrolled automatically, a new certificate for engine communication must be enrolled. This is achieved my starting ssh-ca-server with the following command sequence:

./bin/ssh-ca-server -E "secret" conf/server.conf

(where secret has to be replaced with the correct pre-shared secret key generated for the Server Entity)

If the Certifier system has been down long enough, so that all servers running admin services have expired TLS certificates, and you do not have and cannot generate pre-shared keys (PSK) for the servers, then Certifier Engine and Certifier Server must both be started without TLS protection of the internal communication between the processes. Use the following command:

./ssh-ca-start insecure

Using this set-up, create a PSK for a server running admin service, stop Certifier, and enroll a certificate for the server as described above.

Renewing an Expired Internal CA Certificate

If the SSH Certifier Internal CA certificate is about to expire or has expired (by default this happens two years after the installation), run the following command to renew the TLS CA, and to enroll a new certificate for the server running on the same installation as the engine:

./bin/ssh-ca-repair

The ssh-ca-repair fixes several other things as well. See ssh-ca-repair.

Master Password

When the SSH Tectia Certifier master password is in use, ssh-ca-start will prompt for it when run interactively. If the engine is started automatically at reboot, or the password is not given when starting it with ssh-ca-start, the engine will start in locked mode, that is, no private-key operations are possible. In this mode, the master password can be given in the Administration GUI.

Server Password

When the SSH Tectia Certifier server password is in use, the server will not start automatically after system reboot. ssh-ca-start will prompt for the server password when run manually. If no password is given, the server will not start. See Section Setting the Server Password.

Please note that if both master password and server password are used, it will not be possible to enter the master password with the Administration GUI after reboot, as the server running the Administration Service cannot start automatically.


PreviousNextUp[Front page] [Index]

===AUTO_SCHEMA_MARKUP===