Version: 7.2405.x.x LTS

Server configuration

You can configure the technical server properties in the nevisauth.yml file, see the following list for details. The file format is YAML. Every full stop (".") in the property names represents one level of indentation in the nevisauth.yml YAML file. For example, server.tls.keystore is represented as follows in the YAML file:

YAML format
server:
 tls:
  keystore: /var/opt/keybox/default/node_keystore.jks

server.name
Example value: <instance>
Name of the server. Give each server a unique name for the identification. This name will also be logged.
sever.protocol
Default value: https
Enumeration: https, http
Set this property to https if you plan to use TLS.
server.port
Default value: 8991
Configures the port where the server listens for incoming authentication requests
server.host
Example value: localhost
Configures the hostname on which the server listens for incoming authentication requests
server.tls.keystore
Example value: /var/opt/keybox/default/node_keystore.jks
Keystore object used for the TLS.
server.tls.keystore-passphrase
Example value: keystorepassword
server.tls.truststore
Example value: /var/opt/keybox/default/truststore.jks
Truststore object used for the TLS.
server.tls.truststore-passphrase
Example value: truststorepassword
server.tls.client-auth
Example value: required
Default valie: disabled
Enumeration: required, requested, disabled
- required is the successor of the server.tls.require-client-auth: true setting. It means that client authentication is required.
- requested allows client authentication if the client certificate is sent. If the client certificate was not sent, no client authentication will be performed.
- disabled is the successor of the server.tls.require-client-auth: false setting.
server.tls.verify-hostname
Example value: true
Default value: false
If set to true and a two-way TLS connection is required, the server verifies that the IP address in the certificate presented by the client matches the IP address of the client.
info
The IP address is specified in the Subject Alternative Names field of the certificate.
A required two-way TLS connection corresponds with the following setting: server.tls.client-auth=required
In the TLS connection setups of Nevis, nevisProxy acts as a client whereas nevisAuth acts as a server. Hostname verification is a client-side feature by design, which allows for a stricter verification of the server identity. On the server side, there is not enough information: You can verify the IP address only, because the hostname is not available. Therefore, to use the hostname verification feature in a Nevis TLS setup, the client, that is nevisProxy, needs a fixed IP address. Alternatively, regenerate the certificates each time the IP address changes.
It is recommended leaving this configuration disabled: set the property server.tls.verify-hostname to false. Instead, enable the client-side hostname verification in the EsAuth4ConnectorServlet of nevisProxy. For more information, see the chapter "EsAuth4ConnectorServlet" in the nevisProxy reference guide.
If you set this property to true, you may need to regenerate the client certificates used to connect to nevisAuth. See the section Creating Self-Signed Certificates with Subject Alternative Names below. Typically, the Subject Alternative Name (SAN) is not included in the certificates by default.
server.tls.verify-sni
Example value: false
Default value: true
By default, nevisAuth validates the SNI hostname. Due to a bug in the JRE java-based clients connecting to nevisAuth can potentially fail the SNI validation in case the hostname does not contain a dot (.) as Java will not send the SNI to nevisAuth. Usual Nevis setups using nevisAdmin4 and automated key management are not affected. In case your setup is affected, Jetty will report it with a BadMessageException: org.eclipse.jetty.http.BadMessageException: 400: Invalid SNI. Note that this error message does not automatically means that this is the problem. The SNI error from Jetty can also happen if the hostname used to connect to nevisAuth does not match the hostname used in the certificates used by nevisAuth. (Configured in the nevisauth.yml server configuration) In this case either the connection hostname should be changed or the certificate should be regenerated using the proper hostname.
server.tls.supported-protocols
Default value: TLSv1.2
Provides a list of protocols that are accepted by the client when trying to initiate a connection with TLS.
server.tls.cipher-suites
Default Value:
```
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
```
Provides a list of ciphers that are accepted by the client when trying to initiate a connection with TLS.
The cipher name format is the one used in the Java Cryptography Architecture Oracle Providers Documentation for JDK 8.
server.max-threads
Default value: 200
Number of threads used to process incoming requests.
server.max-http-header-size
Default value: 8192 (8 kilobytes)
Defines the maximum size in bytes of the request and response HTTP headers.
Larger headers allow for more and/or larger cookies as well as more form content encoded in a URL. However, larger headers consume more memory and can make a server more vulnerable to denial of service attacks.
management.server.port
Default value: 9000
The port where the server exposes the liveness endpoint used by Kubernetes. Currently only HTTP is supported. This property is experimental and may change in future releases.
management.healthchecks.enabled
Default value: false
Shows whether the liveness health endpoint is enabled. This property is experimental and may change in future releases.

Variable syntax

The property values in the file nevisauth.yml can be expressions that will be replaced. The next list shows the available syntax:

${exec:command}

Example
server.tls.keystore-passphrase: ${exec:/var/opt/keys/own/instance/keypass.sh}
server.host: ${exec:hostname -f}

Executes the given command and uses its output as the value

${env:variablename}
Example
```
server.host: ${env:HOSTNAME}
```
Uses the value of the specified environment variable

Creating Self-Signed Certificates with Subject Alternative Names (SAN)

The commands in the following code block generate certificates that you can use in a test environment including a nevisAuth instance with two-way client authentication and hostname verification.

The neviskeybox command creates a keystore with two Subject Alternative Names (SANs): One of type DNS, and the other of type IP. You can use this keystore in nevisProxy to connect to nevisAuth.

info

Note that nevisAuth uses the DNS name in the SAN to verify the IP only. It does not verifyclient identity.

The following code sample shows the expected syntax:

neviskeybox certreq -slot default -label node -subject 'cn=siven.ch,ou=auth,o=o=nevis-security,dc=com' -subjectAltName 'DNS:siven.ch,IP:10.0.0.1'
neviskeybox sign -ca testCA -out /tmp/node_new_cert.pem -file /var/opt/keybox/default/node_request.pem
neviskeybox import -file /tmp/node_new_cert.pem
neviskeybox access -slot default -label node -group nvbgroup -user nvpuser
neviskeybox passwd -keep -slot default -label node

Server configuration

Variable syntax​

Creating Self-Signed Certificates with Subject Alternative Names (SAN)​

Variable syntax

Creating Self-Signed Certificates with Subject Alternative Names (SAN)