During the first half of 2024, the focus on X-Road development shifted towards X-Road 8 “Spaceship”, and we've put much effort into X-Road 8-related development activities. Nevertheless, X-Road 7 hasn't been forgotten either, and we've worked on various improvements included in X-Road 7.5.0, released at the beginning of July. Let’s see what the highlights of the new version are! The full release notes are available here.
Support for automated authentication and sign certificate management
Until now, managing the Security Server authentication and sign certificates has been an entirely manual process. The Security Server administrator must create a new key pair, generate certificate signing requests (CSRs), send the CSRs to a Certificate Authority (CA) for signing, import and configure the issued certificates. Depending on the X-Road ecosystem and the CA, completing the whole process may take several days.
Starting from version 7.5.0, the Security Server authentication and sign certificate management can be automated using the Automatic Certificate Management Environment (ACME) protocol. At this point, the automation covers the most time-consuming part of the process – sending the CSR to the CA for signing, issuing the certificate and importing it to the Security Server. In other words, the Security Server administrator still needs to create a new key pair manually, provide the information included in the CSR, start the ACME process and activate the imported certificate. However, the whole process is now completed in minutes instead of days.
Using ACME on the Security Server requires at least one available CA that supports the ACME protocol. The X-Road Operator defines the CAs supporting ACME on the Central Server. In addition, depending on the CA, using ACME may require additional configuration on the Security Server, e.g., using ACME requires authentication, and the authentication credentials must be added to the Security Server’s configuration. The configuration is member-specific. The Security Server documentation provides more detailed information about the required configuration. Please note that the configuration may vary between CAs and X-Road ecosystems. Therefore, always consult your own X-Road Operator in ACME-related questions.
The ACME HTTP challenge communication port is one configuration detail shared between different CAs and X-Road ecosystems. According to the ACME protocol, the ACME server communicates with the Security Server using port 80 when verifying the ownership of the domain included in the certificate using the HTTP challenge. Therefore, the Security Server must allow incoming connections to port 80 from the ACME server. Similarly, outgoing connections from the Security Server to the ACME server must also be allowed. All the required firewall configurations can be found in the Security Server installation guide.
In version 7.4.0, the default client information system inbound communication ports on Ubuntu-based security servers were changed from 80 to 8080 and 443 to 8443. Instead, the port must be manually changed before using ACME on older Ubuntu-based Security Servers, where port 80 is still used as a client information system inbound communication port.
Version 7.5.0 doesn’t yet support automatic renewal of authentication and sign certificates using ACME, but this support will be added in version 7.6.0. In version 7.5.0, the renewal must be initiated manually by the Security Server administrator, but starting from version 7.6.0, the Security Server will try to renew the certificates automatically before their expiration date.
Support for Ubuntu 24.04 LTS
Starting from version 7.5.0, the Central Server, Security Server, and Configuration Proxy support the latest Ubuntu 24.04 LTS version. The support includes installation packages and instructions for fresh installation and migration from Ubuntu 22.04 LTS. In addition to version 24.04 LTS, versions 22.04 LTS and 20.04 LTS are also supported. However, Ubuntu 20.04 LTS is only supported to provide an easier upgrade path to Ubuntu 24.04 LTS. It’s strongly recommended that production environments use Ubuntu 22.04 LTS or Ubuntu 24.04 LTS.
Support for Red Hat Enterprise Linux 9 (RHEL9)
Starting from version 7.5.0, the Security Server supports the latest RHEL9 version. The support includes installation packages and instructions for fresh installation and migration from RHEL7 and RHEL8. In addition to RHEL9, RHEL8 and RHEL7 are also supported. However, RHEL7 is only supported to provide an easier upgrade path to RHEL9. It’s strongly recommended that production environments use RHEL8 or RHEL9.
Adding/removing Central Server cluster nodes
The Central Server cluster node connection details are included in the configuration anchor imported to the Security Server. Using the information in the anchor, the Security Server can connect to the nodes. Suppose cluster nodes are added/removed. In that case, a new configuration anchor must be generated on the Central Server, distributed to all the Security Server administrators through an external channel (e.g., email), and imported to each Security Server. Only after that are the changes applied by each Security Server.
Starting from version 7.5.0, the Central Server cluster node connection details are included in the global configuration. Thanks to this, adding/removing cluster nodes is possible without importing a new version of the configuration anchor to each Security Server. Instead, the Security Server gets the updated configuration information from the global configuration directly and applies it immediately.
However, the changed cluster node details are not updated to the configuration anchor on the Security Server. Instead, the information is only present in the global configuration. Suppose the Security Server's local copy of the global configuration expires. In that case, the Security Server returns using the connection details from the local configuration anchor – potentially the one uploaded to the Security Server when it was originally initialised. Therefore, if the Security Server's local copy of the global configuration is expired, importing a new version of the configuration anchor is required if the current connection details don't include any Central Server node from the local configuration anchor (=the address of every Central Server node has changed since the Security Server was initialised).
The same logic applies to rotating global configuration sign keys included in the global configuration since version 7.4.0. The new sign keys are not updated to the configuration anchor stored on the Security Server. Instead, they're only present in the global configuration.
Security Server Sidecar instructions for Microsoft Azure
The Kubernetes Security Server Sidecar User Guide and Kubernetes Security Server Sidecar Security User Guide have been updated to provide instructions on running the Security Server Sidecar using Azure Kubernetes Service (AKS). The user guides now cover AKS and Amazon Elastic Kubernetes Service (Amazon EKS).
Other improvements and updates
Besides the already-mentioned features, version 7.5.0 includes many other minor improvements and updates. For example, improve warning messages when adding new OpenAPI services to the Security Server, improve dialogue navigation in the Central Server UI, allow defining additional options for PostgreSQL CLI tools used in the Security Server and Central Server processes, bump the Security Server sidecar Docker images to Ubuntu 24.04, and many more. To fully understand all the changes, please review the release notes document.
What’s next?
Version 7.6.0 will support the automatic renewal of authentication and sign certificates using ACME. Other changes that will be introduced in version 7.6.0 include, but are not limited to, support for defining a full name for subsystems, support for getting operational metrics on a REST service endpoint level (not just on a service level), support for Elliptic Curve (EC) cryptography. Version 7.6.0 will be released during Q4 in 2024.
At the same time, when developing X-Road 7, NIIS continues to work on the next X-Road major version – X-Road 8 “Spaceship”. Updates regarding X-Road 8 development are published regularly. Stay tuned!