Managing Multiple HTTP and HTTPS Servers

Introduction

The Sage X3 Web platform can run on multiple Web servers. Each Web server can handle several node.js instances, which are managed by a load balancer. A dedicated nanny process handles the load balancer.

A Web server can be accessed from several ports. The setup for each port can be different (for example, a port can be on HTTP or HTTPS).

All Web servers can connect to the same repository if they share the same MongoDB instance. The setup of the different servers is defined by the host entity.

Architecture

The following diagram summarizes the architecture:

Each server S can have N ports and manage M node instances.

If a server is dedicated to the Web server layer, at least one node.js process per processor core should run.

When a direct exposition on the Web is necessary:

  • It is preferable and more secure to use one or more reverse proxies instead of opening ports directly on a LAN server.
  • We strongly recommend that you use HTTPS connections, and that you correctly set up the DMZ and firewalls (or any other security equipment).

It is possible to have both HTTP and HTTPS connections on two different ports of the same server.

Performing an installation

When performing an installation on a Web server:

  • Installing the first Web server and connecting it to a MongoDb instance initiates and populates the database like for any installation.
  • You can connect a second or third Web server to the same MongoDb instance to build a cluster.
  • Use a single CA certificate per Web server cluster, used by all instances. It can be automatic during installation if you decide to use the same shared directory for the generation of the certificate using the generation tool (it can be a network location or a USB device).
  • Install all the certificate public keys (*.pem files) generated in the correct key directory of the X3 server (usually in the runtime\keys directory).

Using HTTPS connections

To run the server in HTTPS:

  • Define which services are set up in SSL during server configuration.
  • Buy or generate the appropriate certificates for the client, and then select them.
  • If the certificates used have been self-generated, install the CA certificate for the browsers that use the HTTPS connection.

Note: PKCS #1 and PKCS#8 formats are accepted (in PEM format, not in DER format) for private keys, either unencrypted or with traditional SSLeay-compatible encryption. The supported encryption mechanisms at the PEM level are DES-EDE3-CBC and DES-CBC (DES and triple-DES). Encryption at the ASN.1 level is not supported yet.

When you have a private key in PEM format:

  • It is OK if the first line of the file contains -----BEGIN PRIVATE KEY----- or -----BEGIN RSA PRIVATE KEY-----
  • It is not OK, if it contains -----BEGIN ENCRYPTED PRIVATE KEY-----.

Conversion between the formats can be done using openssl (or other tools).

Example: You can convert a private key in PKCS #8 format, with encryption to a format that can be handled (on Microsoft Windows) with this code:

openssl pkcs8 -in privatekey1 -out tempfile 
openssl rsa -in tempfile -des3 -out privatekey2 
del tempfile

Where privatekey1, privatekey2, and tempfile must be replaced with the name of the existing private key file in PKCS #8 format, the name of the file to be created, and a temporary file name, respectively. The temporary file contains the private key without encryption, and should be deleted as soon as possible.