/
X-Road v6.24.0 Release Notes

X-Road v6.24.0 Release Notes

Release Info

Version number6.24.0
Release date31.08.2020
Supported versions
  • 6.240
  • 6.23.0
  • 6.22.1
Supported platforms

Central Server

  • Ubuntu 18.04 LTS

Configuration Proxy

  • Ubuntu 18.04 LTS

Security Server

  • Ubuntu 18.04 LTS
  • RHEL 7
  • RHEL 8
Official documentationhttps://github.com/nordic-institute/X-Road/tree/master/doc
Source codehttps://github.com/nordic-institute/X-Road/tree/master
Software licenseMIT
On this page:

Changes in This Release

On Ubuntu 18.04 LTS upgrading the Security Server from versions 6.22.1/6.23.0 to version 6.24.0 requires using apt install xroad-securityserver OR apt full-upgrade commands.

On RHEL7 upgrading the Security Server from versions 6.22.1/6.23.0 to version 6.24.0 is done using yum update.

Doing apt upgrade is not enough for this version upgrade since the command does not remove the xroad-jetty and xroad-nginx packages that are removed in the upgrade.

Please note that Security Server direct upgrade from versions < 6.22 to 6.24.0 is not supported. In case you’re running a Security Server version < 6.22, please upgrade to version 6.22.1 or 6.23.0 first, and then from version 6.22.1/6.23.0 to version 6.24.0.

Summary

  • New user interface provides improved user experience (UX) for Security Server administrators.
    • New intuitive user interface makes regular administrative tasks easier and supports streamlining the on-boarding process of new X-Road members.
    • More information related to the new user interface can be found in Appendix 1.
  • Common maintenance and configuration tasks can be automated using the management API.
    • Maintaining and operating multiple Security Servers can be done more efficiently as configuration and maintenance tasks require less manual work.
    • More information about the management API can be found in the Security Server User Guide.
    • The full OpenAPI 3 description of the API is available here.
  • Support for running Security Server on Red Hat Enterprise Linux 8 (RHEL8).
  • Technology updates and decreased technical debt.
  • Updates on operational monitoring protocols that enable monitoring of SOAP and REST services in more consistent manner.
    • N.B.! The updates cause breaking changes in the Operational Monitoring protocols.
  • Better support for using external database services on different platforms (e.g. Amazon Web Services, Microsoft Azure, Google Cloud Platform) for both Central Server and Security Server.
    • N.B.! Major changes in Central Server and Security Server database schemas.
  • Changes in allowed characters in X-Road system identifiers and improved validation of the identifiers.

Completed Issues

Access to the X-Road Backlog and issue details requires signing up for an account. Sign up now and get access to the backlog and issue details immediately.

Issue IDTypeSummary
XRDDEV-17Improvement

Add validation to client certificates expiration date. Before version 6.24.0 the Security Server does not validate the expiration date of a client information system's certificate. Starting from version 6.24.0 the expiration date of client certificates is validated, and in case the certificate is expired, a warning is logged in the proxy log by default. It is also possible to prevent the use of expired client certificates and block message processing in case an expired client certificate is detected. This can be achieved by adding the below configuration in "/etc/xroad/conf.d/local.ini" on Security Server:

/etc/xroad/conf.d/local.ini
[proxy]
enforce-client-is-cert-validity-period-check=true
XRDDEV-59Improvement

Update the date and time format used in the X-Road application logs to be based on the international standard ISO 8601 so that it's consistent. Starting from version 6.24.0 the date and time format used in the X-Road application logs is "yyyy-MM-ddTHH:mm:ss.SSSZ".

Dates in log messages and exceptions use ISO 8601 with timezone. Timestamp formats in file names remain unchanged.

XRDDEV-63FixFix signer-console reporting correctly closed akka connections as erros.
XRDDEV-68FixFix the usage of thread local variables in the Security Server.
XRDDEV-113ImprovementOptimize message log archiving performance. The database query logic used in the archival process was updated to use streaming instead of multiple separate queries.
XRDDEV-125Improvement

Improve the Security Server architecture documentation by adding a description of contracts and responsibilities of different Security Server modules. The information is available in the Security Server Architecture document (ARC-SS).

XRDDEV-142ImprovementAdd DNS name or IP that was used to register the Security Server to the Security Server UI. Starting from version 6.24.0 the DNS name or IP can be viewed in the Security Server UI by taking the mouse cursor over the Security Server name on the top banner.
XRDDEV-261Improvement

Improve Security Server's fault tolerance when internal load balancing is used. After the change requests are no longer being sent to Security Servers with a failing TLS handshake.

The fastest wins connection selection Security Server HA strategy was updated to take successful TLS handshake into account when choosing the winner. Before version 6.24.0 the fastest wins selection worked so that the Security Server that first responded to TCP connect request was selected as the winner. In case TLS handshake failed in a later phase of the message flow, the whole request failed. Starting from version 6.24.0 the fastest wins selection takes TLS handshake into account, and a Security Server with a failing TLS handshake cannot be selected as a winner. For example, a Security Server that is running without a valid authentication certificate or without PIN code being typed, does no longer receive requests from other Security Servers.

XRDDEV-377Improvement

Improve failover for timestamping requests so that failover works also when the TSA certificate is incorrect and/or expired. Before the change failover worked only in case connection to the TSA failed, but starting from version 6.24.0 the failover is done also when connection succeeds, but the TSA response is invalid. After the change timestamping is more robust since all the configured TSAs are tried until a valid response is received. In case any of the configured TSAs is not able to provide a valid response, timestamping fails. However, the failover requires that the Security Server has more than one configured TSA.

XRDDEV-440Improvement

Improve security and configurability by adding a separate database users for Security Server database migrations, so that the normal DB users used by the application cannot update the DB schema. Each Security Server database has its own admin user (by default serverconf_admin, messagelog_admin, opmonitor_admin) and normal DB user (by default serverconf, messagelog, opmonitor).

The migrations user is created on new installs, upgrades are not affected.

XRDDEV-546Improvement

Update operational monitoring implementation and protocols so that separate fields for storing the same metric for SOAP and REST messages are not used. After the change there's a single field for each metric that is used for both SOAP and REST messages.

getSecurityServerOperationalData

Changes in the "getSecurityServerOperationalData" response's "operational-monitoring-data.json.gz" attachment:

  • requestSoapSize → requestSize
  • responseSoapSize → responseSize
  • requestRestSize → requestSize
  • responseRestSize → responseSize
  • serviceType → this new field is returned with possible values WSDL, REST, OPENAPI3
  • soapFaultCode → faultCode
  • soapFaultString → faultString

getSecurityServerHealthData

Changes in the "getSecurityServerHealthData" response:

  • requestMinSoapSize → requestMinSize
  • requestAverageSoapSize → requestAverageSize
  • requestMaxSoapSize → requestMaxSize
  • requestSoapSizeStdDev → requestSizeStdDev
  • responseMinSoapSize → responseMinSize
  • responseAverageSoapSize → responseAverageSize
  • responseMaxSoapSize → responseMaxSize
  • responseSoapSizeStdDev → responseSizeStdDev

JMX

Changes in the JMX metrics:

  • requestSoapSize → requestSize
  • responseSoapSize → responseSize
  • serviceType → this new field is returned with possible values WSDL, REST, OPENAPI3


This is a major update to operational monitoring protocol (0.x → 1.0) which breaks compatibility with the previous version. The protocol is defined in the following documents: