---
canonical: https://safekit.evidian.com/wp-content/uploads/downloads_safekit/version-82/safekituserguidehtml/documentation/safekituserguideen.htm
---

# 11.          Securing the SafeKit web service

![*](safekituserguideen_fichiers/image001.png)      
Section 11.1 “Overview”

![*](safekituserguideen_fichiers/image001.png)      
Section 11.2 “HTTP setup”

![*](safekituserguideen_fichiers/image001.png)      
Section 11.3 “HTTPS setup”

![*](safekituserguideen_fichiers/image001.png)      
Section 11.4 “User authentication setup”

## 11.1          Overview

The SafeKit web service is mainly used by:

·        
the web console (see section 3)

·        
the distributed command line interface (see section 9.8)

 

SafeKit provides different setups for this
web service to enhance the security of the SafeKit web console and distributed
commands.

![Securing the SafeKit web service](safekituserguideen_fichiers/image317.png)

|  |  |  |
| --- | --- | --- |
| Protocol | Authentication | Role management |
| ü  HTTP  ü  HTTPS | ü  None (http only)  ü  File based  ü  LDAP/AD  ü  OpenID Connect | ü  Admin  ü  Control  ü  Monitor |

 

The most secure setups are based on HTTPS
and user authentication. SafeKit provides a “private” certification authority
(the SafeKit PKI). This allows SafeKit to be quickly secured without the need
for an external PKI (enterprise PKI or commercial PKI) that provides trusted
certification authority.

SafeKit offers also optional role
management based on 3 roles:

|  |  |
| --- | --- |
| Admin role | This role grants all administrative rights by allowing access to    Configuration and  Monitoring in the navigation sidebar |
| Control role | This role grants monitoring and control rights by allowing access only to   Monitoring in the navigation sidebar |
| Monitor role | This role grants only monitoring rights, prohibiting actions on modules (start, stop…) in Monitoring in the navigation sidebar. |

 

### 11.1.1      Default setup

The default setup is the following:

|  |  |  |
| --- | --- | --- |
| Setup | Protocol | Authentication  Role management |
| Default | ü  HTTP | ü  File-based authentication (username/password stored in an Apache file)  ü  Initialization with a single user named admin with the Admin role     *       To configure, see section 11.2.1 |

### 11.1.2      Predefined setups

The predefined setups are as follows:

|  |  |  |
| --- | --- | --- |
| Setup | Protocol | Authentication  Role management |
| Unsecure | ü  HTTP | ü  No authentication  ü  Same role for all users  For troubleshooting purpose only.  *       To configure, see section 11.2.2 |
| File-based | ü  HTTP  ü  HTTPS        To configure HTTPS with:  *       the SafeKit PKI, see section 11.3.1  *       an external PKI, see section 11.3.2 | ü  username/password stored in a local Apache file  ü  Optional role management stored in a local Apache file  *       To configure, see section 11.4.1 |
| LDAP/AD | ü  HTTP  ü  HTTPS     To configure HTTPS with:  *       the SafeKit PKI, see section 11.3.1  *       an external PKI, see section 11.3.2 | ü  LDAP/AD authentication  ü  Optional role management     *       To configure, see section 11.4.2 |
| OpenID Connect | ü  HTTPS     To configure HTTPS with:  *       the SafeKit PKI, see section 11.3.1  *       an external PKI, see section  11.3.2 | ü  OpenID Connect authentication  ü  Optional role management     *       To configure, see section 11.4.3 |

 

|  |  |
| --- | --- |
| Commentaire important contour | On Linux, for all files added under SAFE/web/conf, change their rights with:  chown safekit:safekit SAFE/web/conf/<filename>  chmod 0440 SAFE/web/conf/<filename>. |

## 11.2          HTTP setup

By default, after the SafeKit install, the
web service is configured for HTTP with file-based authentication that must be
initialized.

This default configuration can be extended
as described in section 11.2.1.

It can also be replaced by the unsecure
setup described in section 11.2.2 or anyone of
the predefined setups.

### 11.2.1      Default setup

The default setup relies on HTTP with
file-based authentication. It requires some initialization described below. It
is a mandatory step.

This default configuration can be extended:

·        
to add users and assign them a role as described
in section 11.4.1.1

·        
to switch to HTTPS with:

![*](safekituserguideen_fichiers/image001.png)      
the SafeKit PKI described in section
11.3.1

![*](safekituserguideen_fichiers/image001.png)      
an external PKI described in section 11.3.2

After the
installation of SafeKit, the configuration and restart of the web service is
not necessary since this is the default configuration and the web service has
been started with it.

#### 11.2.1.1  Reset to default HTTP Setup

If you have
changed the default user authentication configuration and want to revert to it,
see section 11.4.1.

If you want to revert to HTTP from HTTPS, on all SafeKit servers:

1.   
Remove SAFE/web/conf/ssl/httpd.webconsolessl.conf

2.   
Run safekit webserver restart

 

(where SAFE=C:\safekit in
Windows if System Drive=C:   and SAFE=/opt/safekit in Linux).

You can also
run the command SAFE/web/bin/rmcerts, which, in addition to performing the previous operations, deletes
all files related to certificates.

#### 11.2.1.2  Initialization for the web console and distributed command

SafeKit provides a command to get the web
console and distributed commands up and running quickly.

If you opted-in for automatic configuration
during SafeKit package installation, the initialization has already been done.

If you opted-out for automatic
configuration, you must execute this command.

In both cases, you will have to give the
password value, *pwd* for the admin
user.

|  |  |
| --- | --- |
| SAFE/private/bin/webservercfg -passwd *pwd*     where  SAFE=C:\safekit (if %SYSTEMDRIVE%=C:) in Windows  SAFE=/opt/safekit in Linux | On all nodes:  1.    Open a PowerShell/shell window as administrator/root  2.    Run SAFE/private/bin/webservercfg -passwd *pwd*  pwd is the password value  You must set the same password on all nodes. |

 

|  |  |
| --- | --- |
| Commentaire important contour | The password must be identical on all nodes that belong to the same SafeKit cluster. Otherwise, web console and distributed commands will fail with authentication errors. |

 

Once this initialization is done on all the
cluster nodes:

·        
you can authenticate in the web console with the
name admin and the password you provided.  The role is Admin by default
(unless you change the default behavior by providing the group.conf
file as described in section 11.4.1.1)

On
authentication failure in the web console, you may need to reinitialize the admin password. For this, run again SAFE/private/bin/webservercfg -passwd *pwd*
on all nodes.

·        
you can run distributed commands. It is based on
a dedicated user rcmdadmin with the Admin role. It is managed in a different, private user
file that you do not have to change.

On
authentication failure for distributed commands, you may need to reset rcmdadmin
password. To reset only this one, without changing the admin password, run SAFE/private/bin/webservercfg
-rcmdpasswd *pwd* on all nodes.

#### 11.2.1.3  Test the web console and distributed command

The setup is complete; you can now test
that it is operational.

·        
Test the web console

1.    Start a browser on the user’s workstation

2.    Connect it to the default URL http://host:9010 (where host is the name or
Ip address of one of the SafeKit nodes)

3.    In the login page, enter admin as user’s name and the password
you gave on initialization (the value for *pwd*)

4.    The loaded page authorizes
accesses that corresponds to the Admin role by default

 

·        
Test the distributed command

1.    Connect on S1 or S2 as administrator/root

2.    Open a system console (PowerShell, shell, …)

3.    Change directory to SAFE

4.    Run safekit
-H "\*" level

that
should return the level for all nodes

### 11.2.2      Unsecure setup based on identical role for all

It is based on the configuration of a
single role that is applied to all users without requiring authentication. This
solution can only be implemented in HTTP and is incompatible with user
authentication methods. It is intended to be used for troubleshooting only.

#### 11.2.2.1  Configure and restart the web service

To configure where SAFE=C:\safekit in
Windows if System Drive=C: ;  and SAFE=/opt/safekit in
Linux):

|  |  |
| --- | --- |
|  | On S1 and S2:  1.    edit SAFE/web/conf/httpd.conf file  2.    comment all authentication variants (usefile, useldap, useopenid)  #Define usefile  …  #Define useldap  …  #Define useopenid  3.    select the desired role by uncommenting the associated line (httpadmin for Admin role, httpcontrol for Control role); if both lines are commented, the default role is **Monitor.**  Define httpadmin  #Define httpcontrol |
|  | On S1 and S2, disable HTTPS if you had configured it:  4.    remove the file SAFE/web/conf/ssl/httpd.webconsolessl.conf |
|  | On S1 and S2:  5.    run safekit webserver restart |

#### 11.2.2.2  Test the web console and distributed command

The setup is complete; you can now test
that it is operational.

·        
Test the web console

1.    Start a browser on the user’s workstation

2.    Connect it to the default URL http://host:9010 (where host is the name or
Ip address of one of the SafeKit nodes)

3.    The loaded page
authorizes only the actions corresponding to the selected role

 

·        
Test the distributed command

1.    Connect on S1 or S2 as administrator/root

2.    Open a system console (PowerShell, shell, …)

3.    Change directory to SAFE

4.    Run safekit
-H "\*" level

that
should return the level for all nodes

## 11.3          HTTPS setup

The HTTPS web
service relies on the existence of a set of certificates listed below:

 

|  |  |
| --- | --- |
|  | The certificate of the Certification Authority CA used to issue the server certificate for S1 and S2 |
|  | The server certificate of S1 and S2 used to assert the nodes’ identity |

 

Apply one of the following 2 procedures to
configure HTTPS and associated certificates:

![*](safekituserguideen_fichiers/image001.png)      
section 11.3.1 “HTTPS setup using the SafeKit PKI”

Go to
this section to quickly setup HTTPS with the SafeKit “private” certification
authority.

![*](safekituserguideen_fichiers/image001.png)      
section 11.3.2 “HTTPS setup using an external PKI”

Go to
this section to setup HTTPS with an external PKI (enterprise PKI or commercial
PKI) that provides trusted certification authority.

 

At the end of HTTPS setup, you must
implement one of the authentication methods described in section 11.4.

### 11.3.1      HTTPS setup using the SafeKit PKI

First,
verify that the system clock is correctly set to the current date and time on
all SafeKit nodes and workstations that will run the HTTPS SafeKit web console.
Certificates are timestamped, and any time discrepancy between systems may
affect their validity.

Next, choose one SafeKit node to act as the
Certificate Authority (CA) server. This node will hereafter be referred to as
the CA server (e.g., S1). The other cluster nodes will be referred to as non-CA servers (e.g., S2).

Finally, follow the procedure described
below to activate the HTTPS configuration using the SafeKit PKI.

|  |  |
| --- | --- |
| **CA server:** | **Non-CA server:**  Une image contenant capture d’écran, Rectangle, conception  Le contenu généré par l’IA peut être incorrect. |
| On S1:  1.    “Start the CA web service on the CA server” (see section 11.3.1.1)  2.    “Generate Certificates on the CA server” (see section 11.3.1.2) |  |
|  | On S2:  3.    “Generate certificates on non-CA server” (see section 11.3.1.3) |
| On S1:  4.    “Stop the CA web service on CA server” (see section 11.3.1.4) |  |
| On S1 and S2:  5.    “Enable HTTPS on CA server and non-CA server” (see section 11.3.1.5)  6.    “Configure the firewall on CA server and non-CA server” (see section 11.3.1.6) | |
| On S1, S2 and all workstations running the SafeKit web console:  7.    “Set the HTTPS SafeKit Web console” (see section 11.3.1.7) | |

 

In case of a malfunction in the HTTPS
setup, you can fully reset it by following the procedure described in in section 11.3.1.8.1, and
then restart it from the beginning.

|  |  |
| --- | --- |
| Commentaire important contour | The HTTPS setup fails if you have started the CA web service on non-CA servers (e.g., S2). |

#### 11.3.1.1  Start the CA web service on the CA server

On the CA server (e.g.,
S1):

1.    Log in as administrator/root and open a command shell window

2.    Change to the directory SAFE/web/bin

3.    Run the command ./startcaserv

When prompted,
enter a password to protect the access to this service for the CA\_admin
user (for instance, PasW0rD). This command starts the safecaserv service.

|  |  |
| --- | --- |
| Commentaire, ajouter contour | Remember this password since it will be required to connect to this service in next steps.  The CA web service running on the first server is also accessed by the additional non-CA servers. |

 

|  |  |
| --- | --- |
| Commentaire important contour | Since the service listens to TCP port 9001, make sure TCP port 9001 is not used, and is allowed in the firewall configuration. On Linux, the TCP 9001 port is automatically opened in local firewall by the startcaserv command. In Windows, the SAFE/private/bin/firewallcfg add command opens safecaserv service communications. |

#### 11.3.1.2  Generate Certificates on the CA server

During this step, the environment for
generating certificates is set up: certificate authority, local server and
client certificates are created; and server-side certificates are installed in
their expected location.

On the CA server (e.g.,
S1):

1.    Log in as administrator/root and open a command shell window

2.    Change to the directory SAFE/web/bin

3.    List server DNS names and IP addresses

By default, the
server certificate includes all the locally defined IP addresses, DNS names and
host name. They are listed into the files: SAFE/web/conf/ipv4.json and SAFE/web/conf/ipv6.json and SAFE/web/conf/ipnames.json.

For building
these files, run the command:

·         
In Linux

./getipandnames 

·         
In Windows

./getipandnames.ps1

|  |  |
| --- | --- |
| Commentaire important contour | If the service will be accessed using another DNS name or IP address, edit the corresponding file to insert the new value before executing the initssl command. This is required for instance in the clouds using NAT, where the server has a public address mapped on a private address. |

4.   
Run the command:

./initssl sca

 This command:

·         
Create a CA certificate conf/ca/certs/cacert.crt and its associated key conf/ca/private/cacert.key

·         
Create server certificate conf/ca/certs/server\_<HOSTNAME>.crt and its corresponding key conf/ca/private/server\_<HOSTNAME>.key

·         
Install the CA certificate, server certificate
and key in the conf directory

|  |  |
| --- | --- |
| Commentaire important contour | This command creates a Certificate Authority certificate with the default subject name (that is “SafeKit Local Certificate Authority”). To customize the subject name, run the command with an extra parameter:  ./initssl sca "/O=My Company/OU=My Entity/CN=My Company Private Certificate Authority". |

#### 11.3.1.3  Generate certificates on non-CA server

During this step, on non-CA servers, local
certificate requests are created, signed certificates are retrieved from the CA
server, and finally certificates are installed at their expected locations.

Apply the following procedure sequentially
on each non-CA servers (e.g., S2):

1.    Log on as administrator/root and open a command shell window

2.    Change to the directory SAFE/web/bin

3.    List server DNS names and IP addresses

By default, the
server certificate includes all the locally defined IP addresses, DNS names and
host name. They are listed into the files: SAFE/web/conf/ipv4.json, SAFE/web/conf/ipv6.json and SAFE/web/conf/ipnames.json.
For building these files, run the command:

·         
In Linux

./getipandnames 

·         
In Windows

./getipandnames.ps1

|  |  |
| --- | --- |
| Commentaire important contour | If the service will be accessed using another DNS name or IP address, edit the corresponding file to insert the new value before executing the initssl command. This is required for instance in the clouds using NAT, where the server has a public address mapped on a private address. |

4.   
Run the command:

./initssl req
https://CAserverIP:9001 CA\_admin

where CAserverIP
is the DNS name or IP address of the CA server.

Then enter, each
time it is required, the password you specified when
you started the CA web service on the CA server (for instance, PasW0rD)

Or

./initssl req https://CAserverIP:9001
CA\_admin:PasW0rD

|  |  |
| --- | --- |
| Commentaire important contour | If necessary, set the environment variables HTTPS\_PROXY and HTTP\_PROXY to adequate values. |
| Commentaire, ajouter contour | If you get the error "Certificate is not yet valid", it means the system clock of the server is not synchronized with the system clock of the CA server. You should synchronize your server clocks and re-run the initssl command if the time difference is not acceptable. |

#### 11.3.1.4  Stop the CA web service on CA server

Once all SafeKit servers have been
configured, it is recommended to bring the CA web service (safecaserv
service) offline on the CA server, to limit the risk of accidental or malicious
access.

For stopping the SafeKit CA web service
with the command line on the CA server (e.g., S1):

1.    Log in as administrator/root and open a command shell window

2.    Change to the directory SAFE/web/bin

3.    Run the command ./stopcaserv

|  |  |
| --- | --- |
| Commentaire, ajouter contour | On Windows, this command also removes the service entry to prevent any accidental start of the service afterwards. On Linux, the 9001 port is automatically closed on local firewall. |

When all foreseeable
certificate generation and installation is done, it is a good practice to make
sure files unnecessary at production time are not accessible. This step is not
mandatory.

The files that constitute the CA, i.e., the
SAFE/web/conf/ca file tree (especially the private keys stored under SAFE/web/conf/ca/private/\*.keys) should be stored for future use on a removable storage media and
removed from the server. Store the removable media in a secure place (i.e., a
vault). This also applies to the files located under the SAFE/web/conf/ca directory of non-CA servers. The CA files should be restored into
the same location before using the CA again (for example, if adding a new
SafeKit cluster node).

The CA certificate (cacert.crt
file) located in SAFE/web/conf/ca/certs
must be imported into the browser that runs the SafeKit
web console. The import procedure is described into the section 11.3.1.7.

#### 11.3.1.5  Enable HTTPS on CA server and non-CA server

To enable
HTTPS, on all SafeKit servers (e.g., S1 and S2):

1.   
copy SAFE/web/conf/httpd.webconsolessl.conf
to SAFE/web/conf/ssl/httpd.webconsolessl.conf

2.   
On Linux run:  
chown safekit:safekit
SAFE/web/conf/ssl/httpd.webconsolessl.conf

chmod 0440
SAFE/web/conf/ssl/httpd.webconsolessl.conf

3.   
run safekit webserver restart

(where
SAFE=C:\safekit in Windows if System Drive=C:   and SAFE=/opt/safekit in Linux)

#### 11.3.1.6  Configure the firewall on CA server and non-CA server

When the SafeKit web service is running in HTTPS
mode, it is safe to allow network communication with this server and to configure
the firewall, if not already done. For this, apply on all servers (e.g., S1 and S2), the instructions
described in section 10.3.

#### 11.3.1.7  Set the HTTPS SafeKit Web console

If the CA certificate has not been imported, the browser will
display security warnings when the user connects to the web console. If the
import has not yet been performed, follow the procedure below for Windows:

1.    Log in to the workstation that runs the web console (e.g., S1, S2 or
any remote workstation)

2.    Download from the CA server (e.g., S1) the CA certificate (cacert.crt
file) located in SAFE/web/conf/ca/certs

 

|  |  |  |  |
| --- | --- | --- | --- |
| 3.    Click on the downloaded cacert.crt file for opening the certificate window. Then click on Install Certificate button | | |  |
| 4.    It opens the Certificate Import Wizard. Select Current User and click on the Next button | |  | |
| 5.    Browse stores to select the Trusted Root Certification Authorities store. Then click on Next button |  | | |
| 6.    Then complete the certificate import. |  | | |
|  |  |  |  |

#### 11.3.1.8  SafeKit PKI advanced configuration

##### 11.3.1.8.1             Removing certificates

If you want to revert to HTTP from HTTPS and remove all files
related to certificates, on all SafeKit servers:

1.    Log in as administrator/root and open a command shell window

2.    Navigate to the directory SAFE/web/bin

3.    Run the command ./stopcaserv
if it is running

4.    Run the command ./rmcerts
CA (since SafeKit 8.2.5)

|  |  |
| --- | --- |
| Commentaire, ajouter contour | Before SafeKit 8.2.5, run the command ./rmcerts  and delete the folder SAFE/web/conf/ca. |

This procedure must also be applied to fully reinitialize the HTTPS
configuration following a failure, enabling a fresh setup.

##### 11.3.1.8.2             Renewing certificates

Every certificate has an expiration date.
The default expiration date of the CA certificate is set to 20 years after the
CA installation date. The default expiration date of the server certificates is
set to 20 years after the certificate request date.

Expired server certificates will trigger
warnings when the browser connects to the server. Expired CA certificates
cannot be used to validate issued certificates.

It is possible to renew certificates using
the original certificate requests and the private keys stored under the SAFE/web/conf/ca directory tree. You may also create a new certificate request using
the existing private key. The procedure to do so is beyond the scope of this
document, see OpenSSL (or your certificate authority) documentation.

Creating a new set of certificates (and
private keys) will have the side effect of renewing all certificates. To create
a new set of certificates:

1.    Erase the web/conf/ca directory on all SafeKit servers related to the CA, including the
CA SafeKit server itself

2.    Suppress existing certificates from the client machines certificate
stores

3.    Apply the full procedures described in  section 11.3

##### 11.3.1.8.3             Revoking certificates

It is possible to modify the SafeKit web
service configuration to use a CRL containing the revoked certificates list.
Setting up such a configuration is beyond the scope of this document. Refer to
the Apache and OpenSSL documentation.

Creating a new set of certificates and
replacing the old set with the new one will have the side effect of effectively
revoking the previous certificate set, since the CA certificate is different.

##### 11.3.1.8.4             Commands for certificate generation

These commands are located, and must be run
from, the SAFE/web/bin directory.

All paths below are relative to SAFE/web
directory.

initssl sca [<subject>]

**Parameters**

<Subject>: the optional CA certificate subject, that identify in human
readable form the owner of the CA.

**Examples**

initssl sca "/O=My
Company/OU=My Unit/CN=My Company Private Certificate Authority"

**Description**

This command:

·         
Create a CA certificate conf/ca/certs/cacert.crt and its associated key conf/ca/private/cacert.key

·         
Create server  certificate conf/ca/certs/server\_<HOSTNAME>.crt and its corresponding key conf/ca/private/server\_<HOSTNAME>.key

·         
Install the CA certificate, server certificate
and key in the conf directory

It initializes a conf/ca file tree needed
for the SafeKit PKI related commands.

|  |  |
| --- | --- |
| Commentaire, ajouter contour | Note that the best practice is to protect private keys with a password, but it needs more complex configuration on the server and is beyond the scope of this document. See the Apache and OpenSSL documentation for more information. |

initssl rca

**Description**

As initssl sca, but reuse the existing CA infrastructure to reissue the server
certificate and key (re)install the CA certificate , server certificate and key
in the conf directory

initssl req  <url>
<user>[:<password>]]

**Parameters**

·         
<url>: URL of the CA service.  (https://CA\_server:9001)

·         
<user>,<password>: user and password used to authenticate against the CA web service.

<user>
preconfigured value is CA\_admin. <password> is the one entered by the administrator at the start of CA web
service. If these optional field are not present, the password will be asked
interactively several times, when needed.

**Example**

initssl req
https://192.168.0.1:9001 CA\_admin:PasW0rD

**Description**

This command:

·        
Creates a certificate request for a server
certificate that includes all the locally defined IP addresses and DNS names.
The certificate request is stored in conf/ca/private/server\_<hostname>.csr. The corresponding key is stored in conf/ca/private/server\_<hostname>.key.

·        
Creates a certificate request for a client
certificate with the Admin role (to be used by the distributed commands). The
certificate request is stored in conf/ca/private/user\_Admin\_<hostname>.csr. The corresponding key is stored in conf/ca/private/user\_Admin\_<hostname>.key.

·        
Retrieves the CA certificate from the CA server

·        
Retrieves signed certificates corresponding to
the certificate requests above, from the CA server (using provided login)

·        
Installs certificates and keys in the conf
directory

·        
Checks certificates are OK

If no <url> is given, the command
stops after having generated the certificate requests corresponding to:

·        
The local server, in the conf/ca/private/server\_<hostname>.csr

·        
An Admin role client certificate, in conf/ca/private/user\_Admin\_<hostname>.csr

Those certificate requests are stored in a
base64 encoded file ready to be submitted to an external certificate authority
such as Microsoft Active Directory Certificate Services (refer to the Microsoft
documentation on how to submit a base64 encoded certificate request file).

makeusercert <name> <role>

**Parameters**

<name> is the subject's CN name of the certificate, usually the subject's
username.

<role>
is subject's role as a console user. The valid value is
Admin or Control or Monitor.

**Examples**

makeusercert
administrator Admin

makeusercert
manager Control

makeusercert
operator Monitor

**Description**

Creates a client certificate request (and
certificate + pkcs12 file containing certificate and key if started on the CA
SafeKit server) for the <name> and <role>.

When the pkcs12 file is generated, the
command asks twice for a password to protect the file. The generated
unencrypted private key is stored into conf/ca/private/user\_<role>\_<name>.key file. If applicable, the generated certificate and pkcs12 files are
stored into conf/ca/certs/user\_<role>\_<name>.crt and conf/ca/private/user\_<role>\_<name>.p12 files respectively.

Client certificates could  be used as an
authentication method on an HTTPS server. They are transmitted to the web
service by the browser and verified on the server as part of the HTTPS
connection handshake. A certificate corresponding to the desired role must be
installed in the browser certificate store before the SafeKit web console can
be used.

##### 11.3.1.8.5             SafeKit CA web service

The SafeKit CA web service configuration is
stored in SAFE/web/conf/httpd.caserv.conf file.

This service implements limited PKI.

CA certificates are accessible at the
https://CAserverIP>:9001/certs/<certificate name>.crt URL.

For example, the CA certificate is
accessible at https://CAserverrIP>:9001/certs/cacert.crt.

Certificate signature requests are
processed by posting a form at the URL: https://<CA server
IP>:9001/caserv .

The form takes the following parameters:

·        
action = signrequest

·        
name = <certificate name> 

·        
servercsr = <file content of the server
certificate request>

Or

·        
usercsr = <file content of the client
certificate request>

### 11.3.2      HTTPS setup using an external PKI

Apply steps below to setup HTTPS with your
trusted certification authority (your enterprise PKI or commercial PKI).

#### 11.3.2.1  Get and install server certificates

##### 11.3.2.1.1             Get certificate files

You must get server certificates from the
PKI with the expected format.

|  |  |
| --- | --- |
|  | The certificate of the Certification Authority CA used to issue the server certificates |
|  | The server certificate to assert the S1 identity. |
|  | The server certificate to assert the S2 identity. |
| s1.crt  s2.crt | Base-64 encoded X.509 certificate file (PEM format).  The subfield CN (Common Name) into the subject field, or the Subject Alternative Name field of the certificate, must contain:  ·          S1 name(s) and/or IP address(es) for s1.crt  ·          S2 names and/or IP address(es) for s2.crt      |  |  | | --- | --- | | Sous-titres contour | See the example in section 11.3.2.1.3. | | Commentaire important contour | Be aware that you must provide all names and/or IP addresses, for S1 and S2, which are used for HTTPS connections:  ·          those included into the SafeKit cluster configuration file  ·          Those used in the browser URL to load the web console from a cluster node, and which are not present into the cluster configuration | |
| s1.key  s2.key | The private, \*unencrypted\* key corresponding to the certificates s1.crt and s2.crt |

##### 11.3.2.1.2             Install files in SafeKit

Install the certificates as follow (where SAFE=C:\safekit in
Windows if System Drive=C: ;  and SAFE=/opt/safekit in
Linux):

|  |  |
| --- | --- |
| s1.crt  s1.key | On S1:  1.    copy s1.crt to SAFE/web/conf/server.crt  2.    copy s1.key to SAFE/web/conf/server.key |
| s2.crt  s2.key | On S2:  3.    copy s2.crt to SAFE/web/conf/server.crt  4.    copy s2.key to SAFE/web/conf/server.key |
| 5.    On Linux, on S1 and S2, run:  chown safekit:safekit SAFE/web/conf/server.crt SAFE/web/conf/server.key  chmod 0440 SAFE/web/conf/server.crt SAFE/web/conf/server.key | |

 

You can check the installed certificates
with:

cd SAFE/web/bin  
checkcert -t server

It returns a failure if an error is detected.

You can check that the certificate contains
some DNS name or IP address with:

checkcert -h "DNS
name value"

checkcert -i "Numeric
IP address value"

##### 11.3.2.1.3             Example

Consider the following architecture:

![](safekituserguideen_fichiers/image332.png)

The corresponding SafeKit cluster
configuration file, SAFEVAR/cluster/cluster.xml
must contain these values into addr field:

<?xml version="1.0"?>  
<cluster>  
<lans>  
  <lan name="default">

    <node
name="s1" addr="10.0.0.10"/>

    <node
name="s2" addr="10.0.0.11"/>

  </lan>

  <lan
name="private">

    <node
name="s1" addr="10.1.0.10"/>

    <node
name="s2" addr="10.1.0.11"/>

  </lan>

</lans>  
</cluster>

The server certificates must contain the
same values (DNS names and/or IP addresses) as those in the cluster
configuration and the values used to connect the web console. If not, the
SafeKit web console and distributed commands will not work properly.

To check that the certificate file is
correct:

1.   
Copy the .crt (or .cer) file
on a Windows workstation

2.    Double click on this file to open it with Crypto
Shell Extensions

3.    Click on the Details tab

4.    Verify the Subject Alternative
Name field

|  |  |
| --- | --- |
| Commentaire, ajouter contour | If you prefer the command line interface, you can run on each the SafeKit node:  SAFE/web/bin/openssl.exe x509 -text -noout -in SAFE/web/conf/server.crt  and look for the value after Subject Alternative Name. |

 

|  |  |
| --- | --- |
|  |  |

#### 11.3.2.2  Get and install the CA certificate

##### 11.3.2.2.1             Get certificate file

You must get these certificates from the
PKI with the expected format.

|  |  |  |
| --- | --- | --- |
| cacert.crt | The Certification Authority CA certificate used to issue the server certificates.  Base-64 encoded X.509 certificate file (PEM format).  The chain of certificates for the root and intermediates CA | Server certificates for S1 and S2 |

 

If you have trouble retrieving this file
from the PKI, you can build it using the procedure described in section 7.20.

##### 11.3.2.2.2             Install file in SafeKit

Install certificates files as follow (where SAFE=C:\safekit in
Windows if System Drive=C: ;  and SAFE=/opt/safekit in
Linux):

|  |  |
| --- | --- |
| cacert.crt | On S1 and S2:  1.    copy cacert.crt to SAFE/web/conf/cacert.crt  2.    On Linux, run:  chown safekit:safekit SAFE/web/conf/cacert.crt  chmod 0440 SAFE/web/conf/cacert.crt |

You can check the installed certificates
with:

cd SAFE/web/bin  
checkcert -t CA

It returns a failure if an error is
detected.

You must
also check that the cacert.crt contains the chain of certificates for the root and intermediates
Certification Authorities.

#### 11.3.2.3  Configure and restart the web service

To enable HTTPS, on all servers:

1.    copy
SAFE/web/conf/httpd.webconsolessl.conf to SAFE/web/conf/ssl/httpd.webconsolessl.conf

2.    On Linux, run:

chown safekit:safekit SAFE/web/conf/ssl/httpd.webconsolessl.conf

chmod 0440
SAFE/web/conf/ssl/httpd.webconsolessl.conf

3.    run safekit webserver
restart

where SAFE=C:\safekit in Windows if System
Drive=C: ;  and SAFE=/opt/safekit in Linux

#### 11.3.2.4  Change the firewall rules

You can run the firewallcfg command
to change the firewall rules. It set SafeKit rules into the operating system
default firewall (in Windows, Microsoft
Windows Firewall; in Linux, firewalld or iptables).

|  |  |
| --- | --- |
| Firewall | On S1 and S2:  1.    run SAFE/private/bin/firewallcfg add  where SAFE=C:\safekit in Windows if System Drive=C: ;  and SAFE=/opt/safekit in Linux |

 

Don’t run this command if you want to
configure the firewall yourself or if you use a different firewall than the
system one. For the list of SafeKit processes and ports, see section 10.3.