Skip to main content
Version: 7.2402.x.x RR

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.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