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.
 

Table of Contents

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

2. Client configuration: trusting a CA

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

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

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/macOS, /usr/NX/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.

Windows and iOS do not provide CA stores in a format directly compatible with OpenSSL. Users need therefore to supply preconverted PEM certificates on these platforms.

Configuring CA Paths in player.cfg
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.

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

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.

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.