Basic Enterprise Application Realm

Basic Enterprise Application Realm Documentation

  • 1 About BEAR
  • 2 Release Notes
  • 3 Developer Toolkit
  • 4 Installation & Upgrades
    • 4.1 Installation Steps
    • 4.2 Network Requirements
    • 4.3 Application Server Initialization (First Run)
    • 4.4 Uninstallation
  • 5 Backend Adminitration
    • 5.1 Introduction
    • 5.2 Common Commands
    • 5.3 Application Server Commands
    • 5.4 Resource Monitor Commands
    • 5.5 Sharepoint Commands
    • 5.6 Database Commands
  • 6 Frontend Adminitration
    • 6.1 User Management
    • 6.2 Package Management
    • 6.3 Installing Documentation Packages
    • 6.4 Application Storage
    • 6.5 Resource Monitoring
    • 6.6 Resource Scaling
    • 6.7 Starting & Stopping BEAR
    • 6.8 Security
      • 6.8.1 TLS
    • 6.9 Physical Storage
      • 6.9.1 RAID
      • 6.9.2 File Systems
      • 6.9.3 Viewing the Storage Summary
      • 6.9.4 Decommissioning (wiping) Disks
      • 6.9.5 Storage Management
    • 6.10 Event Distribution
    • 6.11 Hostnames & Ports

6.8.1 TLS

February 16th, 2026

BEAR provides three interfaces which make user of TLS1.

Interface TLS usage
Public interface Dual HTTP and HTTPS
Admin interface Mandatory
API interface Optional

It is expected for public interfaces that TLS will both be offered and certificates will be signed by a trusted major CA2. Anything less is generally going to be considered unacceptable for public usage.

There is nothing BEAR specific about the use of TLS with BEAR. For this reason, this document is not a general purpose TLS training manual or primer.

When BEAR is first installed, a host level BEAR CA is created and certificates for both the Admin interface, Public user interface, and API interface are created and signed by the CA. This allows TLS to function, but will result in a web browser displaying an error message indicating that the site is "Not secure" which you must manually override in order to view the BEAR UI.

When a URL starts with https: and the browser displays a message that the site is "Not secure", this is referring to the fact that the browser does not trust the certificate. It does not mean that the connection is unencrypted. Encryption and trust are two separate things. As long as the page is visible with the https: protocol then traffic from your browser to BEAR is encrypted.

This article describes the following procedures:

6.8.1.1 Updating the Certificates

There are two paths to updating the certificates on BEAR: letting BEAR automatically handle the certificates or, providing custom certificates. From a purely cryptographic perspective, both ensure the same level of security. However, providing custom certificates is the only way to meet specific organization security policies around trust or ensuring public users can access your application without their browser displaying security warnings.

The current update method can be viewed as follows:

  1. Select HTTP Control from the Admin Tools list and then the TLS tab.

TLS certificates

  1. The currently active update method will be shown. For details about the current certificates, expand the Certificate details panel.
Automatic Updates
  1. Access the TLS tab as described above.
  2. Select Auto generate and click Update.

automatic TLS certificates

Manual Updates

Preparation

Ensure that the following files are provided in PEM encoded format.

  • A private key file.
  • A public signed X509 server certificate.
  • A public X509 certificate chain file. This should specifically contain:
  1. A public root CA certificate.
  2. Public intermediate CA certificates (if used)

Upload

  1. Access the TLS tab as described above.
  2. Select Update from files. The certificate upload fields will appear.

custom TLS certificates

  1. Attach each of the six required files and click Update

6.8.1.2 Advanced TLS Controls

Advanced settings for TLS are, as stated, advanced. The administrator must already be knowledgeable about the finer points of the TLS cipher suite and protocol versions. Changes made here must be supported by the end users' web browser and mistakes made in the configuration can cause the web interfaces to become completely unusable.

If you make a mistake that renders the web interface unusable, you can use the backend administration tool reset_https_ciphers to revert all security related settings to their default values.

In order to deal with security policies or vulnerability announcements, it may be necessary to manually adjust the TLS settings to meet those requirements. The admin interface and public interface TLS settings are controlled separately.

All the TLS controls are exposed by the currently installed version of the Apache httpd+ web server and current version of OpenSSL on the system.

Reviewing Changes Without Committing

It is not always obvious how changes to the TLS configuration will impact the actual cipher list available for client connections. For this reason, after making changes, but before Applying them, the Revalidate button can be used to update the Calculated cipher list table so that the ciphers that will actually become available can be viewed and verified before committing the change with the Apply button.

Baseline Security Levels

By default, BEAR has a suitable security level that is appropriate for most public facing web applications. However, without resorting to granular configuration of the ciphers, a broad security level of LOW, MEDIUM, or HIGH can be applied. To do so, simply set the level type to Modular and tick the desired level.

automatic TLS certificates

TLS Levels

Recommended TLS levels come and go over time. It is generally recommended to use higher TLS levels, but not all browsers (especially those on older systems) will support them. It is up to the administrator to decide whether certain levels should be enabled or disable.

Bear in mind that a client will automatically select the highest level mutually supported with the server. For this reason, enabling newer levels carries little risk. However, aggressively disabling older levels can render BEAR inaccessible for some users.

For example, if it is known that BEAR will be used for intranet applications in an organisation where the policy prohibits TLS levels below 1.3 and the IT department has ensured all workstations support TLS 1.3, then disabling TLS 1.0 to 1.2 makes sense. But for another organisation with a number of legacy systems, that might not be feasible.

Granular Configuration

Granular settings allow the administrator to control the use of every cipher within a TLS level. For each cipher or cipher class, there are three possible settings:

  • Inherit: Include or exclude the cipher automatically depending on what the current security level is (Default, LOW, MEDIUM, or HIGH).
  • Add: Explicitly add support for the cipher regardless of the security level.
  • Remove: Explicitly remove support for the cipher regardless of the security level.

Cipher Classes

For the four main components of a TLS session, Key Exchange (Kex), Authentication (Auth), Encoding (Enc), and Message Authentication Code (MAC), it is possible to add or remove classes of ciphers that should be allowed for that component.

Cipher List

At the most granular level, each individual cipher can be specified for each TLS level.

6.8.1.3 Further Reading

For more information about TLS and PKI security, please see the following external sources:

1 TLS, or Transport Layer Security is synonymous with the older SSL standard and is the means by which secure HTTPS access is provided.
2 Certificate Authority. This is the organisation which signs your server certificates so that a web browser or client application trusts you.
previous: Starting & Stopping BEAR next: RAID