Skip to main content
Version: Early Access

Protect Integrations with SSL

Register SSL Certificates​

If you use certificates that are generated in-house, self-signed, or signed by a non-established Certificate Authority, they must be registered with each client system that will connect to the TeamForge server. Registration consists of importing custom certificates into the Java runtime's global keystore on each server.

warning

This affects any other Java applications on the server that use the same Java runtime.

  1. Collect the server certificates from all servers. On RHEL, CentOS and other RedHat-based distributions, these are contained in /etc/httpd/conf/ssl.crt/server.crt.

    important

    Be sure to use exactly this path, as there are other files with similar names, plus server certificates are not really secret, but some other files are. So, files must be copied (e.g., via scp) to the same directory, and renamed if necessary to avoid conflicts. It's recommended that you use the short server name of the corresponding server for this.

    This is PATH_TO_JAVA/jre/lib/security/cacerts. For example, this may be /usr/local/j2sdk1.4.2_10/jre/lib/security/cacerts.

  2. Locate the Java keytool utility.

    This is PATH_TO_JAVA/bin/keytool For example, /usr/local/j2sdk1.4.2_10/bin/keytool.

  3. Import each server certificate into the keystore.

    PATH_TO_JAVA/bin/keytool -import -keystore PATH_TO_JAVA/jre/lib/security/cacerts -file <server>.crt -alias <server>
    note

    Any value is accepted for server in -alias <server>.

  4. At the password prompt, use changeit. Confirm that you trust the certificate by typing yes.

  5. Verify that all your certificates are added.

    PATH_TO_JAVA/bin/keytool -list -keystore PATH_TO_JAVA/jre/lib/security/cacerts |less
note

The list will contain many more certificates. These are top-level CA certificates, provided with Java.

  1. If you are running more than one separate server, repeat these steps for each server.
  2. Restart TeamForge

From now on, you can select the Use SSL check box, if required, when creating an SCM integration.

Encrypt Database Network Traffic (On Sites with Remote Database Servers)​

To prevent your data from being exposed in a readable format on the network, use the Secure Socket Layer (SSL) to encrypt the network traffic between the Application and the Database servers.

If you have a dedicated database server (operational database or datamart), encrypt the data traffic between the application and database servers and between the ETL and datamart servers.

important

The following steps are relevant for a distributed setup only.

  1. Stop TeamForge.

    important

    Stop TeamForge on all the servers in a distributed setup.

    teamforge stop
  2. If the operational database or datamart is running on a separate server, include the token DATABASE_SSL=on.

In addition, set the following tokens with the location of the SSL cert and key files of the TeamForge PostgreSQL database server.

POSTGRES_SSL_CERT_FILE=/var/ops/ssl/<dbserver.crt>
POSTGRES_SSL_KEY_FILE=/var/ops/ssl/<dbserver.key>

In case you have TeamForge Baselines, set the following tokens with the location of the cert and key files of the TeamForge Baselines PostgreSQL database server.

POSTGRES_BASELINE_SSL_CERT_FILE=/var/ops/ssl/<baselinedb-server.crt>
POSTGRES_BASELINE_SSL_KEY_FILE=/var/ops/ssl/<baselinedb-server.key>
note

It is mandatory to include these tokens on all the servers.

  1. Provision services.

    teamforge provision
  2. Verify that your PostgreSQL database is running in the SSL mode.
    1. Log on to the Database Server and run the following command: 
      grep "ssl = " var/lib/pgsql/13.15/data/postgresql.conf
      Observe:"ssl = on"