The development of X-Road 8 “Spaceship” and further enhancing the X-Road 7 “Unicorn” has continued in parallel. The available development resources have been divided between the two major versions, but despite that, both versions have gained good progress. In May, the allocation of development resources was adjusted towards the X-Road 8 development team.
This blog post focuses on the latest changes in X-Road 7. A separate blog post about the latest developments in X-Road 8 was published recently.
X-Road version 7.7.0 was released in July 2025. Let’s see what the new version highlights are! The full release notes are available here.
Support for automatic activation of authentication and sign certificates
Since version 7.5.0, automating parts of the Security Server authentication and sign certificate management using the Automatic Certificate Management Environment (ACME) protocol has been possible. In version 7.6.0, support for automatic renewal of authentication and sign certificates originally issued using ACME was added.
In versions 7.5.0 and 7.6.0, the certificate management process is not fully automated, yet certificates ordered or renewed using ACME need to be manually activated by the Security Server administrator. Instead, version 7.7.0 adds support for the automatic activation of certificates that are ordered or renewed using ACME. In this way, the whole certificate renewal process can be fully automated.
Automatic activation is disabled by default, and the Security Server administrator can enable it. If email notifications are enabled, the Security Server administrator receives an email notification when a certificate is activated. Before a certificate is activated, the Security Server verifies that the certificate has a valid OCSP response. This applies to manual and automatic activation and prevents activating a certificate with a missing or invalid OCSP response.
Automatic activation can be turned on and off separately for authentication and sign certificates. When automatic activation of authentication certificates is enabled, manually ordered authentication certificates are also activated automatically once registered on the Central Server.
Instead, the automatic activation configuration of the sign certificate only affects sign certificates ordered using ACME. Manually ordered sign certificates are always activated automatically when imported to the Security Server, regardless of the automatic activation configuration status of the sign certificate. This behavior existed already before ACME support was initially added in version 7.4.0 and adding ACME support hasn’t introduced any changes to it.
More details are available in the Security Server User Guide.
Support for defining a full name for subsystems
Starting from version 7.7.0, X-Road supports defining a full name for subsystems. The name can be defined in a single language using the Central Server and Security Server UIs. Until now, a subsystem has been defined by a subsystem code—a technical identifier that must be unique within the scope of the owning member. In other words, the subsystem code isn’t usually very descriptive for users outside of the owning organisation, and therefore, additional metadata is needed to describe the subsystem.
When upgrading to version 7.7.0 from an earlier version, the subsystem code is initially used as the default name for each subsystem. The name can be defined on the Security Server by the Security Server administrator or on the Central Server by the Central Server administrator. When updating the name of a subsystem that's registered on multiple Security Servers, it's enough to update it once on one of the Security Servers where it's registered or on the Central Server.
When a subsystem is renamed on the Security Server, an update request is sent to the Central Server using a management service. The request is approved automatically by the Central Server, and the new subsystem name will become visible on Security Servers as soon as they download an updated version of the global configuration from the Central Server. In other words, the new subsystem name is not visible in the Security Server UI immediately after sending the update request. Instead, it will become visible within a couple of minutes.
To enable renaming subsystems in an X-Road ecosystem, the Central Server administrator must refresh the management service WSDL on the management Security Server(s) after upgrading to version 7.7.0. The new management service clientRename must be added to the management Security Server(s).
Putting a Security Server into maintenance mode
Starting from version 7.4.0, it has been possible to temporarily disable a subsystem on the Security Server. However, putting an entire Security Server into maintenance mode previously required disabling all subsystems individually—a process that is inconvenient for Security Servers hosting dozens of subsystems. To address this, version 7.7.0 introduces the ability to put an entire Security Server into maintenance mode with a single action.
When a Security Server is in maintenance mode, it will not accept requests from other Security Servers. An attempt to send a request to a server in maintenance mode will result in an error. This error may include an optional message configured by the administrator of the target Security Server. Suppose the target service is also registered on another Security Server that is not in maintenance mode. In that case, a client Security Server running X-Road version >= 7.7.0 will send the request to one of the available Security Servers. Instead, an older client Security Server cannot pick up an optional target Security Server, and the request will fail.
The Security Server administrator can turn maintenance mode on or off as needed. However, a Security Server that provides management services cannot be placed into maintenance mode. In such cases, the maintenance mode feature is entirely disabled.
When turning maintenance mode on or off on a Security Server, the maintenance mode status changes within a couple of minutes. The Security Server sends a maintenance mode activation/deactivation request to the Central Server through management services, and the request is approved automatically. The Security Server status is updated to the global configuration by the Central Server and once the updated global configuration has reached all the Security Servers, the new maintenance mode status has been fully applied.
To enable putting a Security Server into maintenance mode in an X-Road ecosystem, the Central Server administrator must refresh the management service WSDL on the management Security Server(s) after upgrading to version 7.7.0. The new management services maintenanceModeEnable and maintenanceModeDisable must be added to the management Security Server(s).
Visualise subsystem and service usage metrics in the Security Server UI
Starting from version 7.7.0, viewing different usage metrics in the Security Server UI is possible. The Diagnostics view will provide a new section that visually represents traffic passing through the Security Server. The page supports filtering traffic data by time frame, role (consumer/provider), subsystem code, service code, and message status (success/failure). This means viewing the traffic metrics doesn't require invoking the Operational Monitoring SOAP interface anymore.
Traffic data is available only if the Operational Monitoring add-on is installed on the Security Server. For example, the Security Server Sidecar Docker image's slim variants don't include the add-on, so the feature is not available on them.
Also, the available time frame depends on the configuration of the Operational Monitoring add-on. By default, the add-on retains operational monitoring data for seven days, meaning that older data is unavailable in the usage metrics view. The retention period can be adjusted using the op-monitor.keep-records-for-days property on the Security Server. However, before increasing the value, please consider the associated increase in the need for operational monitoring of the database's disk space.
Other improvements and updates
Besides the already-mentioned features, version 7.7.0 includes many other minor improvements and updates. For example, support for removing HSM tokens using the Security Server UI and REST management API, support for automatically adjusting the memory allocation of the Security Server’s proxy component, support for the proxy component's memory-related warnings via the health check interface, support for reserving X-Road meta service codes and support for Brazilian Portuguese in the Central Server and Security Server UIs.
This time, we also received several contributions from members of the X-Road Community. It's great to see the number of community contributions increasing, and we hope this trend continues. Thank you to all the contributors—your efforts are highly appreciated!
Please review the release notes document to understand fully all the changes in version 7.7.0.
Towards the X-Road 8 "Spaceship"
Version 7.8.0 will support sending email notifications about technical issues on the Security Server. Other changes that will be introduced in version 7.8.0 include, but are not limited to, support for selecting between free and paid timestamping services on the Security Server, support for automatically picking up the supported Certificate Signing Request (CSR) format (pem / der) for the selected CA when generating a CSR for authentication or sign certificate on the Security Server and streamlining the Security Server configuration during the installation. Version 7.8.0 will be released during Q4 in 2025.
At the same time, when developing X-Road 7, NIIS continues to work on the next X-Road major version – X-Road 8 “Spaceship”. More news regarding X-Road 8 will be published regularly. Stay tuned!