Since NoMachine version 9.0.188, the client is able to use a host certificate and private key signed by a Certificate Authority (CA). The NoMachine Player can then verify the host’s identity using the CA’s certificate. In addition, NoMachine Player supports the use of a Certificate Revocation List (CRL) to detect and reject revoked certificates.
 

Starting from NoMachine v10.2.3 and v9.10.1, the client is able to use the Windows certificate store for CA verification.

Table of Contents

1. Host configuration: installing a CA-signed certificate and key or creating your own

2. Client configuration: trusting a CA

2.1. Client configuration: trusting a CA via Windows certifcate store

3. Client configuration: using a Certificate Revocation List (CRL)

4. Server configuration: CA and CRL verification in multi-node environments

5. Server configuration: CA and CRL verification for web connections

6. Cluster configuration: installing a CA-signed certificate

1. Host configuration: installing a CA-signed certificate and key or create your own

IMPORTANT
In a cluster configuration, the host certificate described in this section is not used for connections to the master and slave cluster IPs. To configure a CA-signed certificate for cluster connections, follow the steps in section 6, “Cluster configuration: installing a CA-signed certificate.”
 

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
The default files: 
nx_host_rsa_key (private key)
nx_host_rsa_key.crt (certificate)

are in the following directories:
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\  for 64bit packages on 64bit systems or C:\Program files (x86)\NoMachine\etc\keys\host\ for 32bit packages

Make a backup of the original files and place the new files in the appropriate NoMachine directory, replacing the existing default ones.
 
Ensure that the private key file has restricted permissions and is readable only by the nx user, as the original one.

Step 3: Restart the NoMachine Server
You can do that via UI, or from command line.

On Linux/macOS, from a terminal:
sudo /etc/NX/nxserver --restart

On Windows, from CMD prompt run as administrator:
%ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe --restart

Creating your own CA and server certificate
For internal environments or testing scenarios, you may want to generate your own certificate authority and sign server certificates.

Step 1: Create the CA private key
openssl genrsa -out ca.key 4096

Step 2: Generate the CA certificate
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt

Step 3: Generate the server key
openssl genrsa -out server.key 2048

Step 4: Create a SAN configuration file

Create a file named 'san.cnf' and define the Subject Alternative Names required for your environment.
[ 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 ]
DNS.1 = my.server.com
DNS.2 = localhost
IP.1  = 10.0.3.22
IP.2  = 127.0.0.1

Step 5: Generate the certificate signing request
openssl req -new -key server.key -out server.csr -config san.cnf

Step 6: Sign the server certificate with the CA
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out server.crt -days 365 \
  -extensions req_ext -extfile san.cnf

Step 7: Install the certificate on the server
Copy the generated files to the NoMachine host key directory:
server.crt   → etc/keys/host/nx_host_rsa_key.crt
server.key → etc/keys/host/nx_host_rsa_key

The private key must have restricted permissions and be readable only by the nx user. Incorrect permissions may prevent the server from starting or could expose the private key to unauthorized access.
 

2. Client configuration: trusting a CA

Starting with version 9, the NX connection protocol includes support for verifying connections through a Certificate Authority (CA). 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.

Supported Certificate Format
CA certificates must use the PEM format, which is the Base64 encoded ASCII representation of an X.509 certificate.

Each certificate block follows this structure:
-----BEGIN CERTIFICATE-----
...base64 encoded certificate...
-----END CERTIFICATE-----

A single file may contain several certificates.

File Format and Requirements
Format: PEM (Base64-encoded X.509)
Content: One or more CA certificates
Accepted extensions: .pem, .crt, .ca-bundle
Comments and whitespace outside the certificate blocks are allowed

How Certificate Matching Works
When the configured CA path points to a directory, the client scans the available certificates until a suitable issuer certificate is found or the list is exhausted.
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

If the two fields correspond, the CA certificate is considered a potential issuer.

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

These identifiers help OpenSSL to choose the correct issuer when multiple CA certificates share the same subject name.

Once a potential issuer certificate is found, OpenSSL verifies the certificate signature using the issuer’s public key. If the signature verification succeeds, the chain building process continues until a trusted root certificate is reached.

If no valid issuer can be found in the configured CA paths, certificate verification fails and the connection is rejected.

Default CA Paths
NoMachine Player attempts to load certificates from standard system locations when available.

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.

Configuring CA Paths in player.cfg

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:
<option key="Certificate authority" value="certificate-store" />

If this option is not set, the client automatically falls back to the platform’s default CA locations.

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.

Relevant information about behavior in OpenSSL certificate selection
In environments where multiple CA certificates share the same subject name, OpenSSL may encounter ambiguity when selecting the correct issuer certificate.
During chain building, OpenSSL searches the available CA certificates for candidates whose Subject  matches the  Issuer field of the certificate being verified. If several certificates match this condition, OpenSSL attempts to use them as potential issuers while building the certificate chain.
When certificates are loaded from a bundle file, their order in the file may influence which certificate is tried first.
If an expired or otherwise invalid certificate is encountered before a valid replacement with the same subject, the verification process may fail depending on the chain that OpenSSL attempts to build.
This situation may occur when:
- an older CA certificate has expired
- a newer replacement certificate exists with the same subject
- both certificates are present in the same CA bundle or directory

To reduce the risk of verification failures, expired certificates should be removed from CA paths that also contain valid replacements.

DNS and IP Requirements for Certificate Validation
When TLS verification is enabled, the hostname or IP address used by the client 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.

Relevant rules:
- Every IP address used to connect to the server must appear in the SAN list.
- This includes local addresses such as `127.0.0.1`.
- Every hostname used for the connection must also be listed.
- If the connection is performed using `localhost`, this name must appear in the certificate SAN.
- If the connection uses the NoMachine Network service, the NoMachine Id must be included in the certificate SAN.

For example, if a server can be reached through multiple addresses such as:
`my.server.com`
`localhost`
`10.0.3.22`
`127.0.0.1`
`k2-1l-c1-85-z8`

then each of these identifiers must be present in the certificate configuration:
[ alt_names ]
DNS.1 = my.server.com
DNS.2 = localhost
DNS.3 = k2-1l-c1-85-z8
IP.1  = 10.0.3.22
IP.2  = 127.0.0.1

If a client connects using an address that is not present in the SAN list, certificate verification will fail and the connection will be rejected.

For this reason, environments that rely on multiple hostnames, local addresses, or NoMachine Network identifiers must ensure that all of them are properly defined both in DNS and in the certificate SAN configuration.

CA Related Log Messages
The following warnings may appear in the client logs when CA loading fails:

Encryptable: WARNING! Failed to allocate string for CA list.
Encryptable: WARNING! Failed to load CA list from path 'path'.

These messages usually indicate configuration errors or invalid certificate paths.

2.1. Client configuration: 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**.
 

3. Client configuration: using a 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.

CRL Configuration via player.cfg
There is not a default CRL location.

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" />

If the CRL file is invalid or missing, the revocation checking will be skipped.

4. Server configuration: CA and CRL verification in multi-node environments

This is available for NoMachine v9.5 or later.

Each server acts as a client when initiating connections to remote nodes.

When the nodes present CA-signed host certificates (as configured in paragraph 1. 'Host configuration'), the connecting server must also be configured to trust the same Certificate Authority.
 
This configuration is done in server.cfg by using two dedicated keys:
CertificateAuthorityFile - it specifies the absolute path to a PEM CA certificates that nxserver will use to verify the identity of remote nodes it connects to.

CertificateRevocationListFile - it specifies the absolute path to a PEM file containing the Certificate Revocation List (CRL).

5. Server configuration: CA and CRL verification for web connections

This is available for NoMachine v9.5 or later.

When connecting via the NoMachine Web Player, the browser verifies the identity of the server using its CA-signed host certificate. The Web Player uses the same server.cfg keys used by nxserver (see par. 4. 'Server configuration:CA and CRL verification in multi-node environments'):

CertificateAuthorityFile - it specifies the absolute path to a PEM file containing certificates used for certificate verification.

CertificateRevocationListFile - it specifies the absolute path to a PEM file containing the Certificate Revocation List (CRL).
 

6. Cluster configuration: installing a CA-signed certificate

This is available for NoMachine v9.5 or later.

You can find below a general procedure, for more detailed instructions refer to https://kb.nomachine.com/AR10X01393.

Premise: set up the Certificate Authority file
Configure the path to the CA certificate file used to validate the certificate presented by the other cluster peer or node.
This is done by setting the path to the CA certificate file in the CertificateAuthorityFile key in server.cfg.
The file must be accessible to the nx user.

In a cluster environment, clients connecting through either the master virtual IP or the slave virtual IP are presented with the cluster certificate, nx_cluster_rsa_key.crt. Both peers must use the same cluster certificate and private key,
regardless of which peer currently holds either virtual IP.
 
If one peer takes over the master role and master virtual IP after a failure,
clients reconnecting through that virtual IP are presented with the same cluster certificate.

The relevant files are:
nx_cluster_rsa_key (private key)
nx_cluster_rsa_key.crt (certificate)

located in the same directory as the host keys:
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\

Generating the cluster certificate
The cluster certificate must be generated by following the same procedure described in Section 1, with one important difference: the SAN must include the IP addresses and hostnames of both the master and slave.

Installing the cluster certificate
Make a backup of the original nx_cluster_rsa_key and nx_cluster_rsa_key.crt files.

Then replace them with the CA-signed key and certificate, applying the same restricted permissions as for the host key.

Once the certificate is in place on the master, it can be propagated to the slave by using the 'nxserver --clusteredit' command.

Alternatively, the certificate 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.

Installing the certificate before cluster creation
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.