Computing service – enabling HTTPS

The computing service recalculates attendance. If it runs on a different machine than the application server, it sends data to it over the network – and in that case, it is advisable to encrypt the connection using HTTPS. This guide describes the manual setup for version 5.3.

Administrator tip: The installer does not configure HTTPS automatically, but it preserves manual configuration during updates.

When You Need HTTPS

The application server sends the service a shared key with every request in the X-Calculation-Key header. Without HTTPS, both the key and the request contents are transmitted over the network unencrypted.

In version 5.3, only the application server calls the calculation service (eNext's server API goes through it). Therefore, the configuration only needs to be changed in two places: in the service and in the application server configuration.

Before you begin

Procedure at a glance

1. Machine running the service: find the certificate name.

2. Machine running the service: create the appsettings.Production.json file with the HTTPS settings.

3. Machine running the service: firewall – no action is required; optionally, you can narrow the rule.

4. Machine running the application server: change the service address to https://….

5. Both machines: restart the services and verify the connection.

Step 1 – certificate (machine running the service)

In PowerShell, list the certificates in the computer store. You will need the name from the Subject field:

Get-ChildItem Cert:\LocalMachine\My | Format-List Subject, NotAfter, Thumbprint, HasPrivateKey

Check that the certificate has not expired (NotAfter) and has a private key (HasPrivateKey = True). The service runs under the LocalSystem account, so it can access the key in the computer store without any additional configuration.

Step 2 – Configure the service (machine running the service)

In the service folder {instalace}\CalculationService, create a file named appsettings.Production.json with the following contents (adjust the certificate name and ports as needed):

{
  "Kestrel": {
    "Endpoints": {
      "Http": { "Url": "http://localhost:2223" },
      "Https": {
        "Url": "https://*:2224",
        "Certificate": {
          "Subject": "vypocet.firma.local",
          "Store": "My",
          "Location": "LocalMachine"
        }
      }
    }
  }
}

What each section means:

• Http – redirects unencrypted access to this machine only (localhost). Do not omit this line: without it, the original address http://*:<port> from the installation would remain open to the network alongside HTTPS. Keep the port the same as during installation.

• Https.Url – the asterisk means all network interfaces. If the machine has multiple network cards, it is better to specify a specific IP address.

• Certificate.Subject – the name from the certificate in step 1. The certificate can also be loaded from a file (Path + Password), but the password would be readable in the file – so we recommend using the certificate store.

• Caller authentication does not change – key-based pairing configured by the installer remains in place.

Administrator tip: Why this particular file? The installer rebuilds appsettings.json with every installation. It leaves appsettings.Production.json untouched, and its values take precedence – so the HTTPS configuration survives updates.

Step 3 – firewall (machine running the service)

You do not need to configure anything new. The installer added the AktionNEXT.CalculationService rule for the service program, so it applies to all its ports. For a multiple installation, the rule name is followed by the instance name in parentheses.

Optionally, you can restrict the rule to the application server address only:

Set-NetFirewallRule -DisplayName 'AktionNEXT.CalculationService' -RemoteAddress 10.0.0.15

Step 4 – service address (machine with the application server)

In the file {instalace}\AppServer\AppServer.exe.config, change the service address to HTTPS:

<add key="DochazkaVypocetSluzbaUrl" value="https://vypocet.firma.local:2224" />

• The name in the address must match the certificate. An IP address will work only if it is included in the certificate.

• Do not change the DochazkaVypocetSluzbaKlic and DochazkaVypocetVlastnik keys.

• You can also enter the address in the installer wizard—the service address field on another computer also accepts https://.

• The TLS protocol version is determined by the Windows settings. No further configuration is needed on the application server.

Step 5 – restart both services

Restart-Service 'AktionNEXT.CalculationService'   # machine with the service
Restart-Service 'AktionNext.AppServer'            # machine with the application server

For a multi-instance installation, both service names have the suffix $INSTANCE.

Verification

Run the checks from the machine with the application server – this also verifies the network path and trust in the certificate.

[Net.ServicePointManager]::SecurityProtocol = 'Tls12'   # only in Windows PowerShell 5.1

# 1) availability and valid certificate: 200 + header X-Calculation-Owner: Service
Invoke-WebRequest https://vypocet.firma.local:2224/health -UseBasicParsing |
    Select-Object StatusCode, Headers

# 2) the unencrypted port is no longer accessible from the network: TcpTestSucceeded = False
Test-NetConnection vypocet.firma.local -Port 2223

The connection is working correctly when:

1. The first request returns 200 and the X-Calculation-Owner header. Any certificate error will show up here.

2. The second test will fail – port 2223 is now listening locally only.

3. In the application server log ({instalace}\AppServer\AppServer.log), after startup there is the line “Calculation service https://vypocet.firma.local:2224/ is ready.” This confirms both the encrypted connection and the key.

4. In the service log (CalculationService\logs\calculation-<datum>.log), there is a line “Authentication: scheme ApiKey, caller authorization: …” with the caller AppServer (calc-admin).

5. Manually recalculating one person from the client completes without error – the entire process, including verification, succeeds.

What happens during an update

Tip for administrators: Repeat the checks in the Verification chapter after each update.

Common issues

Limitations

• The warning about unencrypted access is not displayed when installing from the installer. The service startup check does not recognize an address with an asterisk (http://*:<port>). Therefore, do not rely on the log—the port test in the Verification chapter is what matters.

• The application server may not verify certificates. Calendar synchronization with Exchange or Kerio and DataPro disables certificate checks for the entire application server. The connection is then encrypted, but the other party is not verified, and an invalid certificate will not be reported.

• Windows account authentication (Negotiate) will not survive an update. The application server installer with the service on another machine writes the key during every installation, and the server will not authenticate using an account when a key is specified. Therefore, use a key + HTTPS for a service on another machine.

• The key is stored in readable form—in the configuration of both sides and in the database. Manual encryption (dpapi:) is overwritten by the installer during the next installation. The service does not limit the number of attempts to sign in with the key.

• Starting with version 5.4, eNext's server API will also call the service directly. If it runs on a different machine than the service, the same HTTPS requirement applies, and it must be added to the allowed callers in appsettings.Production.json.