Configuration options for the Nomad server on Domino

Configure TLS using CertMgr on Domino

  1. Follow the instructions in the Domino documentation for setting up a manual or Let's Encrypt certificate for the Domino server.
  2. Ensure that the document for the certificate configuration lists the current Domino server as usable.
  3. Ensure there is a replica of certstore.nsf on the Domino server you are configuring, and that it is up-to-date with any previous changes.
  4. Set the ini setting NOMAD_WEB_HOST on the Domino server to the hostname in your certificate.

    For example, if your Domino server's certificate hostname is, use console command: set config Wildcards certificates also work. If you have a wildcard certificate, use the wildcard hostname as the ini value.

  5. Re-launch nomad task. For example: restart task nomad

Configuration file

You may place a nomad-config.yml file in your Domino data directory. This is a YAML file.

The values listed here, as indicated, are the default values. You do not need to set them unless you want to change them.

Setting the ip address and port to listen on
# these are the defaults
host: ''
port: 9443

Setting the servers addresses and ports

Nomad server on Domino should be able to lookup and connect to the other Domino servers in your domain by default, but if you do run into errors related to connecting to the other Domino servers (for example, Nomad: nwsp:wss:error Error: connect ETIMEDOUT), you may specify the servers: option with a line for each canonical name follow by the ip address and port:

If you are having issues related to IPv6 such as nwsp:wss:error Error: connect ECONNREFUSED ::1:1352 and you do not want to generally enable IPv6 in Domino nor change the operating system's preference to be IPv4 over IPv6, you may specify all of your Domino servers in this section with the IPv4 addresses.

Setting the default mail servers

During initial configuration of the Nomad client, the user's information will be attempted to be obtained via the user's mail server. If the user has an assigned mail server, nothing more needs to be done. But if the user does not have an assigned mail server, a default server, randomly chosen from the defaultMailServers list, can be utilized instead:
  - CN=domino1/O=EXAMPLE
  - CN=domino2/O=EXAMPLE

Setting the number of worker processes

Default: number of cores on your system

  forks: 3

Setting the directory where temporary files are stored

By default, temporary files (for example, the deploy nsf file) will be stored in the operating system's temp directory. To have the files stored in a different directory, specify cacheFiles.
cacheFiles: '/where/you/want'

Configuring the session cookie

You can check here to see all available options.

If not set, the server generates a random secret on startup. This interferes with clustering. If you are (http) clustering the Nomad server on Domino, you need to set the same session cookie secret on all servers.

Pick a random string for the secret. You may change this as often as you like. Changing the value invalidates everyone's session.

# these are the defaults
  secret: # default: randomly generated 32 character value
  sameSite: lax
  secure: true

Configuring LTPA for use behind SafeLinx

If you have a custom cookie name, you can set this.

# these are the defaults
  cookieName: LtpaToken2

Configuring specific TLS options for the web server

You can see all possible values here.

In order to set secureOptions, use a string value representing a bitwise OR of the constant names that start with SSL_OP. For example: "SSL_OP_NO_TLSv1 | SSL_OP_NO_TLSv1_1"

# these are the defaults
  honorCipherOrder: true
  secureOptions: SSL_OP_NO_TLSv1 | SSL_OP_NO_TLSv1_1

Configure how frequently the server will check CertMgr for updated certificate

# these are the defaults
tlsPoll: 3600000 # one hour in milliseconds

Configure SAML

Configuring SAML is very similar to configuring SAML for SafeLinx. You need to supply your values here.
    # Any claim you place here and map to a SAML claim will be read for the user
    # email: # default
  idp: # see
For more information, see Nomad federated login in the Domino documentation.
Note: Administrators do not need to complete steps relating to "deploy.nsf" in Nomad federated login. Administrators can follow the instructions in Configure SAML authentication (in the SafeLinx documentation) with a few exceptions:
  • The config file in Step 4B is nomad-config.yml.
  • nomad-config.yml goes in the Domino data directory.
  • All of the config needs to be under a SAML property.
  • secret and port should not be used within the context of the SAML object.

Nomad federated login

For federated login to work, you must place your deploy.nsf at <nomad-files>/config/deploy.nsf.

<nomad-files> refers to the location where the Nomad for web browsers client files were unzipped as part of the Nomad server file being unzipped in Installation. By default, <nomad-files> are placed in <Domino program directory>/nomad-files/.

For more information, see Configuring Nomad federated login.

Configure TLS certificate

If you did not configure TLS using CertMgr (recommended), you can also configure the TLS certificate via the config file.

Note: The ca value may be omitted if your cert contains a full pem chain.
ca: # file location or contents of the ca's certificate pem file
cert: # file location or contents of the certificate pem file
key: # file location or contents of the certificate key pem file

Configuring optional HTTP headers

You may configure optional HTTP headers to be included in the response. Defaults are set for security purposes, but you may add to or modify this list by uncommenting them and changing them here. These default security headers are also included in the documentation page with SafeLinx as the Nomad server. For more information, see Optional headers.

# HTTP headers added to the server response
  # Defaults:
  # Strict-Transport-Security: max-age=7776000; includeSubDomains
  # X-Content-Type-Options: nosniff
  # Referrer-Policy: strict-origin-when-cross-origin
  # X-Frame-Options: DENY
  # X-XSS-Protection: 1; mode=block
  # Permissions-Policy: "accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(self), display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(), fullscreen=(), geolocation=(self), gyroscope=(), hid=(), idle-detection=(), magnetometer=(), microphone=(), midi=(), navigation-override=(), payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), serial=(), sync-xhr=(), usb=(), web-share=()"
  # Non-defaults:
  # Content-Security-Policy: "default-src 'self'; script-src 'self' 'unsafe-inline' 'wasm-unsafe-eval'; script-src-elem 'self' 'unsafe-inline'; style-src 'unsafe-inline'; style-src-elem 'self' 'unsafe-inline'; img-src 'self' blob: data:; font-src 'self' data:; frame-src 'self'"

Configuring HTTP port for use behind a reverse proxy

Nomad server on domino HTTP port is defined by the “httpPort” option (default value is 9080).

By default, Nomad server on Domino will redirect all HTTP requests to their corresponding HTTPS URLs.

With the "trustProxy" option configured according to the guidelines specified in Express behind proxies, Nomad server on Domino can directly handle incoming HTTP requests without redirecting to HTTPS.
# these are the defaults
# httpPort: 9080
# trustProxy: false

# trust proxy from localhost
# trustProxy: [“loopback”]

The HTTP listener can be turned off by setting the “httpPort” option to 0. The HTTPS listener can also be turned off by setting the “port” option to 0.

Support Let’s Encrypt HTTP-01 challenge requests

Nomad server on Domino can work with Domino CertMgr to handle Let’s Encrypt HTTP-01 challenge requests.

Upon receiving HTTP-01 challenge requests, Nomad server on Domino will query the response from the certstore.nsf database and respond back to complete the challenge. When no response is found in the certstore.nsf database, Nomad server on Domino will respond with a 404 status code.

The following example displays a successfully request/response:

# HTTP-01 challenge request:

# Nomad server response:

For complete flow of requesting a certificate from the Let's Encrypt CA with Domino CertMgr, see Requesting a certificate from the Let's Encrypt CA.

For more information on Let’s Encrypt HTTP-01 challenge, see this article.