limited 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. 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. The TLS key is generated automatically during installation/upgrade, but the TLS certificate must be applied and configured manually by the X-Road Operator. 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. 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. 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. 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. |