Knowledge Base
Searching in : Article
ID: AR10X01393
Applies to: NoMachine Software
Added on: 2026-10-16
Last Update: 2026-10-19
Custom host certificates for NoMachine failover cluster (v9 or later)
Table of Contents
3. Requirements for Certificate Validation
4. Installing a host CA-signed certificates and private keys
5. Installing and propagation of a cluster CA-signed certificate and private key
6. Trusting a CA by the client
9. Trusting a CA via Windows certifcate store
10. Certificate Revocation List (CRL)
11. Trusting a CA between peers and in the multi-node environment
12. Certificates used in connection
A NoMachine failover cluster consists of two Enterprise Cloud Server Cluster (ECSC) or two Enterprise Terminal Server Cluster (ETSC) servers that provide high availability for the centralized infrastructure. The cluster operates in an active-active configuration.
There are two physical IP addresses used for continuous monitoring between peers:
- primary physical IP,
- secondary physical IP,
and two public virtual IP addresses which must be reachable by the client:
- master virtual IP - entry point for client connections,
- slave virtual IP - used when connections are redirected to the other peer.
Clients must initially connect to the master virtual IP. The master peer distributes connections between the two peers. The slave virtual IP is not used for direct client connections, with the exception of NoMachine remote admin GUI connections. When load-balancing of connections is applied, the client could be redirected to the slave virtual IP together with a token that authorises the connection.
In a cluster environment, NoMachine uses two certificate and private key pairs, and one RSA authentication key pair, each serving a different purpose.
Host certificate and private key:
- nx_host_rsa_key.crt (certificate)
- nx_host_rsa_key (private key)
Each peer has its own certificate and private-key pair used to identify/authenticate the host during a connection.
Cluster certificate and private key:
- nx_cluster_rsa_key.crt (certificate)
- nx_cluster_rsa_key (private key)
This pair is the same on each peer and it is used for connections through both the master virtual IP and the slave virtual IP, regardless of which peer originally generated it or currently holds either virtual IP. Synchronising the certificate and private key across hosts ensures that, from the client’s perspective, the cluster endpoint always has the same identity.
Cluster private and public RSA key pair:
- cluster.id_rsa
- cluster.id_rsa.pub
They are also the same on both peers. Cluster use a RSA key pair to connect and synchronize database. This key pair is valid only for the nx user, a special system account created during the installation of the NoMachine server software and reserved for internal operations.
The certificates and private key pairs are located in:
- on Linux: /usr/NX/etc/keys/host/
- on macOS: /Applications/NoMachine.app/Contents/Frameworks/etc/keys/host/
- on Windows: C:\Program Files\NoMachine\etc\keys\host\
The RSA key pair is in:
- on Linux: /usr/NX/etc/keys/
- on macOS: /Applications/NoMachine.app/Contents/Frameworks/etc/keys/
- on Windows: C:\Program Files\NoMachine\etc\keys\
By default, all of these files are generated by the NoMachine install procedure. If it is necessary, for version v9.5 and later, NoMachine supports using host and cluster CA-signed certificate and private key. There is also a possibility to replace the default RSA key-pair by generating your own key-pair.
In a PKI-based infrastructure, our implementation of a separate cluster certificate, used only for connections to the cluster virtual IPs, seems unnecessary. When NoMachine Player trusts the CA that issued both host certificates, a connection through a new virtual IP on either peer would still be trusted, provided that the host certificate’s SAN includes that IP address. Using an additional certificate, nx_cluster_rsa_key.crt, synchronized between the hosts seems like an extra safeguard in this case. However, in the current version, we do not have a simple way to avoid using the cluster certificate for connections through the virtual IPs.
3. Requirements for Certificate Validation
File Format and Requirements
Format: PEM (Base64-encoded X.509)
Content: One or more CA certificates
Accepted extensions: .pem, .crt, .ca-bundle
Each certificate block follows this structure:
-----BEGIN CERTIFICATE-----
...base64 encoded certificate...
-----END CERTIFICATE-----
Comments and whitespace outside the certificate blocks are allowed.
DNS and IP requirements
When TLS verification is enabled, the IP addresss and/or hostnames used to connect to the server must be present in the Subject Alternative Name (SAN) field of the server certificate. This means that every address used to reach the server must be explicitly defined in the certificate configuration. In the cluster environment this means that:
- the SAN of the host certificate (nx_host_rsa_key.crt), which identifies the individual host, should contain peer's physical IP address,
- the SAN of the cluster certificate (nx_cluster_rsa_key.crt), which is used for connections through the cluster virtual IPs, should contain both master and slave virtual IP addresses.
For example, if the IP addresses look like:
- primary peer physical IP: 10.0.179.63
- secondary peer physical IP: 10.0.151.155
- master virtual IP: 10.0.250.240
- slave virtual IP: 10.0.250.241
SAN field should contain at least
- for nx_host_rsa_key.crt on the primary host
[ alt_names ]
DNS.1 = localhost
IP.1 = 10.0.179.63
- for nx_host_rsa_key.crt on the secondary host
[ alt_names ]
DNS.1 = localhost
IP.1 = 10.0.151.155
- for nx_cluster_rsa_key.crt on both peers
[ alt_names ]
DNS.1 = localhost
IP.1 = 10.0.250.240
IP.2 = 10.0.250.241
If the environment does not use the DNS system, the SAN file should not contain any names, such as hostnames, but only IP addresses.
Please note that, for the time being, NoMachine requires that one DNS entry must always be present. If you are not using any DNS name, the entry might contain just one of the accessible IP.
4. Installing a host CA-signed certificates and private keys
Steps below should be applied to each of the cluster peers.
Step 1: Obtain certificate and key
Use a certificate and private key issued by a trusted Certificate Authority (CA). You will need:
- the host’s private key file (e.g. host.key)
- the host’s certificate file (e.g. host.crt), signed by the CA
Step 2: Replace host key and certificate
Make a backup of the original files and place the new files in the appropriate NoMachine directory, replacing the existing default ones.
Step 3: Check permissions
Ensure that the private key file has restricted permissions and is readable only by the nx user, as the original one.
For example on Linux they should look like:
-rw------- 1 nx root 1675 2013-11-18 12:18 nx_host_rsa_key
-rw-r--r-- 1 nx root 1090 2013-11-18 12:18 nx_host_rsa_key.crt
and on macOS:
-rw------- 1 nx wheel 1679 Apr 8 16:21 nx_host_rsa_key
-rw-r--r-- 1 nx wheel 1090 Apr 8 16:21 nx_host_rsa_key.crt
5. Installing and propagation of a cluster CA-signed certificate and private key
For cluster certificate and private key run the following steps on the master peer.
Step 1: Obtain certificate and key
Use a certificate and private key issued by a trusted Certificate Authority (CA). You will need:
- the cluster’s private key file (e.g. cluster.key)
- the cluster’s certificate file (e.g. cluster.crt), signed by the CA
Step 2: Replace cluster key and certificate
Make a backup of the original files and place the new files in the appropriate NoMachine directory, replacing the existing default ones.
Step 3: Check permissions
Ensure that the private key file has restricted permissions and is readable only by the nx user, as the original one.
For example on Linux they should look like:
-rw------- 1 nx root 1675 2013-11-18 12:18 nx_cluster_rsa_key
-rw-r--r-- 1 nx root 1090 2013-11-18 12:18 nx_cluster_rsa_key.crt
and on macOS:
-rw------- 1 nx wheel 1679 Apr 8 16:21 nx_cluster_rsa_key
-rw-r--r-- 1 nx wheel 1090 Apr 8 16:21 nx_cluster_rsa_key.crt
Once the cluster certificate and private key are in place on the master, they can be propagated to the slave by using the 'nxserver --clusteredit' command. This command will also propagate changes in server.cfg file (which is the same on each peer).
Alternatively, the certificate and private key files can be copied manually to the slave host: place them in the host keys directory with the same restricted permissions as on the master.
After replacing the files, restart nxserver on both peers for the changes to take effect.
If the cluster has not yet been configured, the CA-signed cluster certificate can be placed in the host keys directory before the cluster is first set up. In this case, NoMachine will use the provided certificate from the begin.
6. Trusting a CA by the client
This feature relies on the OpenSSL library, the implementation works across platforms and uses native OpenSSL functions to validate certificates. The client can load CA certificates from either individual files or directories containing multiple certificates.
NoMachine Player attempts to load certificates from standard system locations when available.
Android /system/etc/security/cacerts/
macOS /etc/ssl/cert.pem
Linux /etc/ssl/certs/ca-certificates.crt
Linux /etc/pki/tls/certs/ca-bundle.crt
Windows Windows certificate store supported since v10.2.3 and v9.10.1
iOS Not supported
iOS doesn't provide CA stores in a format directly compatible with OpenSSL. Users need therefore to supply preconverted PEM certificates on this platform.
On Windows, certificates in .crt format are supported since v10.2.3 and 9.10.1. For previous versions of the client, provide certificates in PEM format.
By default the client on Linux and MacOS will look for the certificates in the standard system locations.
The CA location is defined in the client configuration by the 'Certificate authority' option inside the 'player.cfg' file. If a custom CA certificate file is required, it must be specified manually there. You can specify either files or directories, in a comma-separated list.
Up to v10.1 and v9.9, on Windows it is necessary to specify manually the path to the certificate in the 'Certificate authority' key.
Fresh new installation of later versions of the client set the 'Certificate authority' key to value "certificate-store" for enabling the client to use the Windows certificate store for CA verification. The update of previous installations of the client will not set that value automatically and it will be necessary to set the 'Certificate authority' key manually.
The player.cfg file is placed in the user's home/.nx/config directory:
- on Linux and macOS: $HOME/.nx/config/player.cfg,
- on Windows: %USERPROFILE%\.nx\config\player.cfg
Note that the .nx folder is hidden on Windows. To find it, write: %USERPROFILE%\.nx in the address bar of the browser.
Example of configuration:
<option key="Certificate authority" value="/etc/ssl/certs/ca-certificates.crt,/etc/pki/tls/certs/ca-bundle.crt" />
On Windows, for certificate store, you could use:
<option key="Certificate authority" value="certificate-store" />
<option key="Certificate authority" value="certificate-store" />
Known Limitations
- Only up to five CA paths or files can be configured.
- The number of certificates processed inside each file or directory depends on the version of the installed OpenSSL.
- OpenSSL 3.0.15 does not enforce strict limits, though very large certificate collections can slow down connection initialization.
- Only X.509 PEM certificates encoded in Base64 ASCII are supported.
9. Trusting a CA via Windows certifcate store
To verify the server certificate using the Windows certificate store, you need the certificate of the trusted **root Certificate Authority (CA)**. Obtain the CA certificate from your administrator or another trusted source, and verify that it is the certificate you intend to trust before importing it. A '.crt' file is suitable; Windows also supports other certificate file formats.
Add the certificate for the current user
1. Press **Win + R**, enter 'certmgr.msc', and press **Enter**. This opens **Certificates - Current User**.
2. Expand **Trusted Root Certification Authorities** and select **Certificates**.
3. Select **Action → All Tasks → Import**.
4. In the Certificate Import Wizard, select the CA certificate file.
5. Choose **Place all certificates in the following store** and confirm that the selected store is **Trusted Root Certification Authorities**.
6. Complete the wizard and accept the trust prompt if one appears.
7. Confirm that the certificate appears under **Trusted Root Certification Authorities → Certificates**.
This installs the certificate for the current Windows user. If the application runs under a different account or the certificate must be available to all users, open 'certlm.msc' and follow the same steps under **Certificates - Local Computer**. Importing into the local computer store may require administrator privileges.
You can also double-click the certificate file and select **Install Certificate**. In that wizard, check both the store location (**Current User** or **Local Machine**) and the destination store before completing the import.
If your certificate chain includes an **intermediate CA**, import its certificate into **Intermediate Certification Authorities**, not **Trusted Root Certification Authorities**.
10. Certificate Revocation List (CRL)
The Certificate Revocation List (CRL) is used to identify certificates that have been revoked by the issuing CA.
Only one file can be used for CRL validation, that file may contain multiple CRL entries.
File Format
Format: PEM
Content:
-----BEGIN X509 CRL-----
(Base64-encoded CRL data)
-----END X509 CRL-----
Line breaks, whitespace, and comments outside the BEGIN/END markers are ignored.
There is not a default CRL location for client. To enable CRL checking, explicitly add the path to the CRL file, for example:
<option key="Certificate revocation list" value="/path/to/crl/list.pem" />
11. Trusting a CA between peers and in the multi-node environment
Each peer acts as a client in failover cluster. If you are using a CA-signed host certificate and private key, you need to configure the path to the CA certificate file used to validate the certificate presented by the other cluster peer.
This configuration is done in server.cfg by using two dedicated keys:
- CertificateAuthorityFile - it specifies the absolute path to a PEM CA certificate that nxserver will use to verify the identity of other peer,
- CertificateRevocationListFile - it specifies the absolute path to a PEM file containing the Certificate Revocation List (CRL).
Note that the files must be accessible to the nx user.
In multi-node environment cluster acts as a client when connecting to the nodes. When the nodes present CA-signed host certificates, they must also be configured to trust the same Certificate Authority as the cluster.
The 'CertificateAuthorityFile' configuration key can contain only path to one certificate file. If you are using more than one CA certificate, you should add all of them to the one .pem file.
12. Certificates used in connection
Certificates used during the connection with load-balancing enabled.
Client
|
v
Master virtual IP
|
Cluster Master
|
+---- cluster communication ----+ Cluster Slave
|
v
Slave virtual IP
This connection could be described in below steps:
1. The client connects through the master virtual IP
2. The nx_cluster_rsa_key.crt is used to authenticate
3. The load-balancing algorithm selects the peer on which the connection will be established
4. If the slave is chosen, the token is created through a command operating on the master/slave database
5. In this diagram, 'cluster communication' refers to the shared database of both peers; when the slave connects to the master, it authenticates itself using the cluster RSA key pair
6. The client is redirected to slave virtual IP with created token
In case of the failover:
1. The client connects through the master virtual IP
2. The nx_cluster_rsa_key.crt is used to authenticate
3. The master fails so the slave takes over the master role and the master virtual IP
4. The client reconnects through the master virtual IP
5. The same nx_cluster_rsa_key.crt is presented
13. Example of creating, installing your own certificates and private keys and configuring the cluster
This example was tested on two Linux hosts (Ubuntu 26.04.1 LTS and Mint 21.3 LTS) and two Windows 11 Home computers with NoMachine version 10.2.3.
The IP addresses for this example:
- primary peer physical IP: 10.0.179.63
- secondary peer physical IP: 10.0.151.155
- master virtual IP: 10.0.250.240
- slave virtual IP: 10.0.250.241
The NoMachine server log files are located in:
- on Linux: /usr/NX/var/log/server.log
- on macOS: /Library/Application\ Support/NoMachine/var/log/server.log
- on Windows: %PROGRAMDATA%/NoMachine/var/log/server.log
Step 1: Create the CA private key
openssl genrsa -out ca.key 4096
Step 2: Check the CA private key
openssl rsa -in ca.key -check
RSA key ok
Step 3: Generate the CA certificate
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt
Step 4: Check the CA certificate
openssl x509 \
-in ca.crt \
-noout \
-subject \
-issuer \
-dates \
-text
subject=C=PL, ST=dolnoslaskie, L=Wroclaw, O=NoMachine, CN=NoMachine-CA
issuer=C=PL, ST=dolnoslaskie, L=Wroclaw, O=NoMachine, CN=NoMachine-CA
notBefore=Oct 13 10:34:07 2026 GMT
notAfter=Oct 10 10:34:07 2036 GMT
You should check if the validity dates, the subject and issuer are properly set.
Step 5: Generate the host and cluster keys
openssl genrsa -out primary.key 2048
openssl genrsa -out secondary.key 2048
openssl genrsa -out cluster.key 2048
Step 6: Check each of the hosts and cluster keys
openssl rsa -in primary.key -check
RSA key ok
openssl rsa -in secondary.key -check
RSA key ok
openssl rsa -in cluster.key -check
RSA key ok
Step 7: Create a SAN configuration file for each certificate
Create files named 'san-primary.cnf', 'san-secondary.cnf', 'san-cluster.cnf' and define the Subject Alternative Names required for your environment. See the "DNS and IP requirements" section.
[ req ]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext
prompt = no
[ req_distinguished_name ]
C = PL
ST = dolnoslaskie
L = Wroclaw
O = Test
CN = test.test.com
[ req_ext ]
subjectAltName = @alt_names
[ alt_names ]
...
- for creating host certificate for primary host
[ alt_names ]
DNS.1 = localhost
IP.1 = 10.0.179.63
- for creating host certificate for secondary host
[ alt_names ]
DNS.1 = localhost
IP.1 = 10.0.151.155
- for creating cluster certificate
[ alt_names ]
DNS.1 = localhost
IP.1 = 10.0.250.240
IP.2 = 10.0.250.241
Step 8: Generate the certificates signing requests
openssl req -new -key primary.key -out primary.csr -config san-primary.cnf
openssl req -new -key secondary.key -out secondary.csr -config san-secondary.cnf
openssl req -new -key cluster.key -out cluster.csr -config san-cluster.cnf
Step 9: Check each of the certificates signing requests
openssl req \
-in primary.csr \
-noout \
-subject \
-text
openssl req \
-in secondary.csr \
-noout \
-subject \
-text
openssl req \
-in cluster.csr \
-noout \
-subject \
-text
You should check if the subject and SAN are properly set.
Step 10: Sign the certificates with the CA
openssl x509 -req \
-in primary.csr \
-CA ca.crt -CAkey ca.key \
-CAcreateserial \
-out primary.crt -days 365 \
-extensions req_ext \
-extfile san-primary.cnf
Signature ok
subject=/C=PL/L=dolnoslaskie/O=Test/CN=test.test.com
Getting CA Private Key
openssl x509 -req \
-in secondary.csr \
-CA ca.crt -CAkey ca.key \
-CAcreateserial \
-out secondary.crt -days 365 \
-extensions req_ext \
-extfile san-secondary.cnf
Signature ok
subject=/C=PL/L=dolnoslaskie/O=Test/CN=test.test.com
Getting CA Private Key
openssl x509 -req \
-in cluster.csr \
-CA ca.crt -CAkey ca.key \
-CAcreateserial \
-out cluster.crt -days 365 \
-extensions req_ext \
-extfile san-cluster.cnf
Signature ok
subject=/C=PL/L=dolnoslaskie/O=Test/CN=test.test.com
Getting CA Private Key
Step 11: Check the certificates
openssl x509 \
-in primary.crt \
-noout \
-subject \
-issuer \
-dates \
-ext subjectAltName
subject=C=PL, ST=dolnoslaskie, L=Wroclaw, O=Test, CN=test.test.com
issuer=C=PL, ST=dolnoslaskie, L=Wroclaw, O=NoMachine, CN=NoMachine-CA
notBefore=Oct 13 10:39:15 2026 GMT
notAfter=Oct 13 10:39:15 2027 GMT
X509v3 Subject Alternative Name:
DNS:localhost, IP Address:10.0.179.63
openssl x509 \
-in secondary.crt \
-noout \
-subject \
-issuer \
-dates \
-ext subjectAltName
subject=C=PL, ST=dolnoslaskie, L=Wroclaw, O=Test, CN=test.test.com
issuer=C=PL, ST=dolnoslaskie, L=Wroclaw, O=NoMachine, CN=NoMachine-CA
notBefore=Oct 13 10:39:55 2026 GMT
notAfter=Oct 13 10:39:55 2027 GMT
X509v3 Subject Alternative Name:
DNS:localhost, IP Address:10.0.151.155
openssl x509 \
-in cluster.crt \
-noout \
-subject \
-issuer \
-dates \
-ext subjectAltName
subject=C=PL, ST=dolnoslaskie, L=Wroclaw, O=Test, CN=test.test.com
issuer=C=PL, ST=dolnoslaskie, L=Wroclaw, O=NoMachine, CN=NoMachine-CA
notBefore=Oct 13 10:41:02 2026 GMT
notAfter=Oct 13 10:41:02 2027 GMT
X509v3 Subject Alternative Name:
DNS:localhost, IP Address:10.0.250.240, IP Address:10.0.250.241
You should check if the validity dates, the subject and issuer and the SAN are properly set.
Step 12: Check the certificates chain
openssl verify -CAfile ca.crt primary.crt
primary.crt: OK
openssl verify -CAfile ca.crt secondary.crt
secondary.crt: OK
openssl verify -CAfile ca.crt cluster.crt
cluster.crt: OK
Step 13 Install the hosts and cluster pairs of certificate and private key
Make a backup of the original files and copy the generated files to the NoMachine host key directory.
On the primary host:
primary.crt → etc/keys/host/nx_host_rsa_key.crt
primary.key → etc/keys/host/nx_host_rsa_key
cluster.crt → etc/keys/host/nx_cluster_rsa_key.crt
cluster.key → etc/keys/host/nx_cluster_rsa_key
On the secondary host:
secondary.crt → etc/keys/host/nx_host_rsa_key.crt
secondary.key → etc/keys/host/nx_host_rsa_key
Check if the private keys have restricted permissions and are readable only by the nx user.
Step 14: Install the CA certificate
Copy the certificate to the chosen location on both hosts. For example:
On Linux:
ca.crt → /etc/ssl/certs/nomachine-ca.crt
On MacOS:
ca.crt → /etc/ssl/nomachine-ca.crt
On Windows:
ca.crt → C:\ProgramData\NoMachine\certs\nomachine-ca.crt
If you want to add the certificate to the Windows certificate store:
Import-Certificate -FilePath "ca.crt" -CertStoreLocation "Cert:\LocalMachine\Root"
On Linux:
ca.crt → /etc/ssl/certs/nomachine-ca.crt
On MacOS:
ca.crt → /etc/ssl/nomachine-ca.crt
On Windows:
ca.crt → C:\ProgramData\NoMachine\certs\nomachine-ca.crt
If you want to add the certificate to the Windows certificate store:
Import-Certificate -FilePath "ca.crt" -CertStoreLocation "Cert:\LocalMachine\Root"
Step 15: Set the proper values of the server configration keys
On primary host in server.cfg file:
"CertificateAuthorityFile /path/to/cert/ca.crt"
For example:
On Linux:
"CertificateAuthorityFile /etc/ssl/certs/nomachine-ca.crt"
On MacOS:
"CertificateAuthorityFile /etc/ssl/nomachine-ca.crt"
On Windows:
"CertificateAuthorityFile C:\ProgramData\NoMachine\certs\nomachine-ca.crt"
if the certificate is in the Windows store:
"CertificateAuthorityFile certificate-store"
If you want to specify a PEM file containing the CRL set:
"CertificateRevocationListFile /path/to/crl/list.pem"
"CertificateAuthorityFile /path/to/cert/ca.crt"
For example:
On Linux:
"CertificateAuthorityFile /etc/ssl/certs/nomachine-ca.crt"
On MacOS:
"CertificateAuthorityFile /etc/ssl/nomachine-ca.crt"
On Windows:
"CertificateAuthorityFile C:\ProgramData\NoMachine\certs\nomachine-ca.crt"
if the certificate is in the Windows store:
"CertificateAuthorityFile certificate-store"
If you want to specify a PEM file containing the CRL set:
"CertificateRevocationListFile /path/to/crl/list.pem"
Step 16: Set-up the primary host
On the primary host:
nxserver --clusteradd --local 10.0.179.63 --master 10.0.250.240 --slave 10.0.250.241
NX> 909 Local host '10.0.179.63' added to the cluster.
NX> 911 The main configuration for the cluster is set. Run 'nxserver --clusteradd' again to add secondary machine.
Step 17: Set-up the secondary host
On the primary host:
nxserver --clusteradd 10.0.151.155
[...]
NX> 917 Please restart both cluster servers to apply the changes.
NX> 913 Cluster add process finished.
Step 18: Restart both hosts
On both hosts:
nxserver --restart
Step 19: Check if the cluster is running
On the primary host:
nxserver --clusterstatus
NX> 1370 Master (this machine) is running.
NX> 1372 Slave is running.
nxserver --clusterlist
NX> 903 Cluster list:
Host Interface Netmask Role Status UUID
-------------------------- --------- ------------- ------ ------- ------------------------------------
10.0.179.63 (this machine) en0 255.255.255.0 master running 5ad8ddb8-0ef9-4d61-897c-89c2a540549d
10.0.151.155 en0 255.255.255.0 slave running 0360fdb1-f783-48c7-91e7-31b5aec3f86a
You should be able to see in column 'Status' value 'running'.
By default the primary host will take the master role.
The relevant log entries in the NoMachine server logs file on master peer:
ACTION! Going to choose the active node.
ACTION! New active is local.
The relevant log entries in the NoMachine server logs file on slave peer:
ACTION! Going to choose the active node.
ACTION! New active node '10.0.179.63'.
ACTION! Inform about slave mode.
Step 20. Install the CA certificate on client side
Copy the certificate to the chosen location on each of the client hosts.
ca.crt → /etc/ssl/certs/nomachine-ca.crt
Step 21: Set the proper values of the client configration keys
In the player.cfg file set:
<option key="Certificate authority" value="/etc/ssl/certs/nomachine-ca.crt" />
If you want to specify a PEM file containing the CRL set:
<option key="Certificate revocation list" value="/path/to/crl/list.pem" />
Step 22: Test the failover
For a situation in which the primary host is the master peer.
a. Check if the connection to the cluster through master virtual IP is working
b. On the primary (master) host:
nxserver --shutdown
c. Verify whether the secondary host takes the master role
On the secondary host:
nxserver --clusterstatus
NX> 1370 Master (this machine) is running.
NX> 1379 Slave is not running.
nxserver --clusterlist
NX> 903 Cluster list:
Host Interface Netmask Role Status UUID
--------------------------- --------- ------------- ------ ----------- ------------------------------------
10.0.179.63 en0 255.255.255.0 slave unreachable 5ad8ddb8-0ef9-4d61-897c-89c2a540549d
10.0.151.155 (this machine) en0 255.255.255.0 master running 0360fdb1-f783-48c7-91e7-31b5aec3f86a
d. Check if the connection to the cluster through master virtual IP is working
The relevant log entries in the NoMachine server logs file on secondary host:
ACTION! Setting timeout for '10.0.179.63' failure.
ACTION! Setting timeout for '10.0.250.240' failure.
ACTION! Setting new active node '10.0.151.155'.
ACTION! Replacing hanging master '10.0.179.63' in context B.
ACTION! Failing over the server.
Step 23: Start the shutdown peer
On the primary host:
nxserver --startup
The relevant log entries in the NoMachine server logs file on primary host:
ACTION! Going to choose the active node.
ACTION! New inactive node '10.0.179.63'.
ACTION! Inform about slave mode.
ACTION! New active node '10.0.151.155'.
## The topology in the example described earlier
Certificate Authority
Signs certificates:
primary.crt
secondary.crt
cluster.crt
|
|
+-----------------------------------+
| |
| |
Primary host Secondary host
Physical IP: 10.0.179.63 Physical IP: 10.0.151.155
Initial role: master Initial role: slave
Initially holds master virtual IP: Initially holds slave virtual IP:
10.0.250.240 10.0.250.241
| |
| |
Host certificate: Host certificate:
nx_host_rsa_key.crt nx_host_rsa_key.crt
SAN: 10.0.179.63 SAN: 10.0.151.155
| |
| |
Shared cluster certificate on both hosts:
nx_cluster_rsa_key.crt
SAN: 10.0.250.240, 10.0.250.241
| |
| |
+-----------------------------------+
|
|
Client
The client trusts the issuing CA and initially connects to the master virtual IP.
If load balancing redirects it to the slave virtual IP, the destination presents the same cluster certificate.
During failover, the surviving peer takes over the master role and master virtual IP.
Clients reconnecting through that master virtual IP receive the same cluster certificate, whose SAN contains both virtual IP addresses.
NoMachine supports both configurations comprising only a Root CA and those with additional intermediate CAs.
Intermediate CAs are supported as part of the normal X.509 certificate-chain validation. During verification, OpenSSL attempts to build a certificate chain from the server certificate to a trusted root certificate.
The matching process is primarily based on the relationship between:
- the Issuer: field of the certificate being verified,
- the Subject: field of the candidate CA certificate.
When available, OpenSSL may also use the following extensions to select the correct certificate:
- Authority Key Identifier (AKI) in the server or intermediate certificate,
- Subject Key Identifier (SKI) in the CA certificate.
In practice, for a chain such as:
Root CA
│
v
Intermediate CA
│
v
NoMachine host certificate
the client needs access to the certificates necessary to build the chain, with the Root CA acting as the trust anchor.
NoMachine supports also CA bundles. The CA configuration can point either to:
- an individual CA certificate file,
- a file containing multiple CA certificates,
- a directory containing multiple CA certificates.
The certificates must be in PEM format, files with extensions such as .pem, .crt and .ca-bundle are accepted. A single file can contain multiple BEGIN CERTIFICATE / END CERTIFICATE blocks. For example:
file ca-bundle.pem
-----BEGIN CERTIFICATE-----
Root CA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Intermediate CA
-----END CERTIFICATE-----
## Certificate Validation
### Checking the private key
openssl rsa -in ca.key -check
### Checking the certificate request
openssl req \
-in cluster.csr \
-noout \
-subject \
-text
### Checking the certificate content
openssl x509 \
-in cluster.crt \
-noout \
-subject \
-issuer \
-dates \
-ext subjectAltName
### Checking the certificate chain
If there is only Root CA:
openssl verify \
-CAfile ca.crt \
cluster.crt
If there is also Intermediate CA:
openssl verify \
-CAfile ca.crt \
-untrusted ca-intermediate.crt \
cluster.crt
cluster.crt: OK