Currently, all of the support requests and feature requests for both our NIIS members and the X-Road community go through the X-Road Service Desk in JIRA. This limits the interaction opportunities and also visibility of common issues for the community. To improve the situation, the following changes have been implemented:
All support requests from the community go to X-Road GitHub repository issues.
All feature requests from the community go to X-Road GitHub repository discussions.
All support and feature requests from the NIIS members and partners continue going through the X-Road Service Desk.
The changes provide a few benefits over the previous model:
More community involvement on the open-source side with regards to feature requests, as it’s possible to have a public discussion there where everyone can chime in. It’s also possible to gague interest in the feature by taking a look at the interaction with the posts.
More visibility for the community into common issues users come across and how to solve them.
Gathering troubleshooting information into a public place to create a naturally growing knowledge base.
Publicly available information on known-issues for releases.
The NIIS members and partners still have a private line.
3
Publish global configuration over HTTPS
There are three alternative approaches how publishing global configuration over HTTPS could be implemented:
Alternative 1
Publish global configuration over HTTPS using a TLS certificate issued by a trusted CA.
The CA must be trusted by the Security Server's Java installation.
Each Central Server and Configuration Proxy node needs their own TLS certificate (=one TLS certificates per node).
The same TLS certificate is used for both internal and external configuration.
Internal and external configuration can be served from the same port.
The TLS key is generated automatically during installation/upgrade, but the TLS certificate must be applied and configured manually by the X-Road Operator.
The TLS key and certificate must be rotated manually.
For test and development purposes the TLS certificate validation can be disabled on the Security Server.
Federation is supported since certificates issued by trusted CAs are used.
Implementation complexity: low.
Alternative 2
Publish global configuration over HTTPS using TLS certificates issued by the global configuration sign keys.
The Security Server trusts the TSL certificates since the global configuration sign key is present in the configuration anchor.
Each Central Server and Configuration Proxy node needs their own TLS certificates (=two TLS certificates per Central Server node, one TLS certificate per each published configuration per Configuration Proxy node).
Internal and external configuration have different TLS certificates which means that they must be published in different ports, e.g. internal configuration on port 443, external configuration on port 4443.
On the Central Server, the TLS key and certificate generation, configuration and rotation (when global configuration sign keys are rotated) are automated.
Federation is supported since the Security Server already trusts the external sign key of federated instances.
Implementation complexity: medium.
Alternative 3 (prerequisite: the configuration anchor is signed)
Publish global configuration over HTTPS using a TLS certificate issued by the configuration anchor sign key.
The Security Server trusts the TSL certificate since the configuration anchor sign key is included in the configuration anchor.
Each Central Server and Configuration Proxy node needs their own TLS certificate (=one TLS certificates per node).
The same TLS certificate is used for both internal and external configuration.
Internal and external configuration can be served from the same port.
The TLS key and certificate generation, configuration and rotation (when configuration anchor sign key is rotated) are automated on the Central Server and Configuration Proxy.
A new web service endpoint to query configuration anchor sign certificates is needed on the Central Server and Configuration Proxy.
The endpoint is used by the Security Server to query configuration anchor sign certificates - both local and federated instances.
The endpoint URL must be configured on the Security Server manually during the initialization or automatically using country-specific meta packages.
Supporting federation is possible, but the implementation is complicated.
Implementation complexity: high.
The X-Road Technical Committee has decided that publishing global configuration over HTTPS will be implemented using alternative 1.
4
Open topics
X-Road Catalog has been published in a new GitHub repository owned by NIIS. However, installation packages (binary) are not available in NIIS Artifactory yet. The X-Road Catalog backlog is available in JIRA.
The Security Server security assessment will be conducted by a third party in Q4 / 2023.
X-Road Community Event takes place online on Friday 22nd September. Registration is now open!
Next meetings
Meeting 16, October 19 2023, 15:00-16:00 (EEST, UTC +3)
Meeting 17, November 15 2023, 15:00-16:00 (EEST, UTC +2)
Meeting 18, December 13 2023, 15:00-16:00 (EEST, UTC +2)
Meeting 19, January 17 2024, 15:00-16:00 (EEST, UTC +2)
Meeting 20, February 14 2024, 15:00-16:00 (EEST, UTC +2)