How to configure SSL and Corporate Certificates

Nipper OmniSight supports two independent certificate configurations:

1. Web Application SSL Certificates – used to secure browser connections to the OmniSight web interface.
2. Corporate Trust Certificates – used to allow OmniSight to trust HTTPS services within your organisation, such as VPN-protected resources, internal APIs, authentication services, and other systems signed by your corporate PKI.

These configurations serve different purposes and can be used independently or together.

Important

SSL certificates and corporate CA certificates should be provisioned before starting Nipper OmniSight for the first time.

If you intend to use certificates issued by your organisation’s PKI or need OmniSight to trust internal HTTPS services, place the required certificate files in the appropriate provisioning directories before starting the application.

If Nipper OmniSight has already been started, stop the application before making certificate changes and restart it after the updated certificates have been provisioned.

Web Application SSL Configuration

Overview

Nipper OmniSight includes a default self-signed certificate if no certificate is provided before first startup.

The certificate is generated for the hostname defined by the HOST_NAME setting in:

/opt/app/nipper-omnisight/.conf

Browsers accessing OmniSight must trust the certificate authority that issued the server certificate to avoid certificate warnings.

For production environments, Titania recommends using certificates issued by your organisation’s PKI.

Note: Automatic self-signed certificate generation supports hostnames only. If HOST_NAME is configured as an IP address, a certificate must be provided manually.

Using Certificates from Your Organisation’s PKI

If your organisation provides SSL certificates, place the required files in the locations below before starting OmniSight.

The certificate should include Subject Alternative Names (SANs) for all hostnames and IP addresses that users may use to access OmniSight.

Most enterprise-managed devices will already trust certificates issued by the organisation’s PKI.

Generating a Self-Signed Certificate

If your organisation does not provide SSL certificates, OmniSight includes a helper script that can generate a self-signed certificate and Root CA.

Run the following command:

/opt/app/nipper-omnisight/scripts/generate-ssl.sh

The script generates all required SSL files and places them in the appropriate provisioning directories.

After generation, browsers accessing OmniSight must trust the generated Root CA certificate to avoid certificate warnings.

Note: Self-signed certificates are suitable for evaluation, testing, and environments where certificates issued by an organisational PKI are not available.

Corporate CA Configuration

Overview

OmniSight may need to establish HTTPS connections to systems within your organisation, including:

• VPN-protected services
• Internal APIs
• Authentication providers
• Internal PKI services
• Other HTTPS endpoints secured by corporate certificates

If these systems use certificates issued by a private or internal certificate authority, the CA certificate must be provided to OmniSight so that outbound HTTPS connections can be validated successfully.

This configuration affects only outbound connections made by OmniSight and does not affect the certificate presented by the OmniSight web interface.

Providing Corporate CA Certificates

Place the required corporate CA certificates in:

/opt/app/nipper-omnisight/docker/provisioning/corporate-certs/

Any certificates placed in this directory will be added to the OmniSight trust store during provisioning.

The certificates should be supplied in PEM or CRT format and should include any root or intermediate certificate authorities required to validate the certificates used by your organisation’s internal services.