Skip to content

Commit

Permalink
Merge pull request #1910 from nordic-institute/XRDDEV-2530_start-7.5
Browse files Browse the repository at this point in the history 
chore: start 7.5 development
  • Loading branch information
@mloitm
mloitm committed Dec 22, 2023
2 parents 14478f6 + 96fa56d commit 6be1eb0
Show file tree
Hide file tree
Showing 41 changed files with 926 additions and 217 deletions.
23 changes: 22 additions & 1 deletion CHANGELOG.md
View file
Original file line number Diff line number Diff line change
@@ -1,6 +1,8 @@
# Change Log

## 7.4.0 - 2023-11-27
## 7.5.0 - UNRELEASED

## 7.4.0 - 2023-12-21
- XRDDEV-851: As an Architect I want to study alternatives how to make global configuration more flexible so that it is easier to add new configuration items.
- XRDDEV-1520: As an Architect I want to investigate how ACME could be supported in the X-Road ecosystem so that onboarding would be faster
- XRDDEV-331: As an X-Road operator I want to rotate Central Server sign keys without having to send a new configuration anchor to all Security Server administrators so that rotating sign keys could be done regularly.
Expand Down Expand Up @@ -60,7 +62,26 @@
- XRDDEV-2512: Management service API key creation fails silently during Central Server installation/upgrade
- XRDDEV-2519: As a Security Server Administrator i want the configuration signing keys to rotate without manual intervention
- XRDDEV-227: As a Security Server Administrator I want to be able to change my Security Server's address in the global configuration from the UI
- XRDDEV-2520: As an X-Road user I would like to be able to use OpenAPI 3.1 so that I can use the latest version of the specifications
- XRDDEV-2465: As a Security Server Administrator I want the initialization process to provide me with helptext that clarifies what rules are in effect for the pin code so that I know how to set it
- XRDDEV-2528: As a Developer I want to check and fix a potential issue with long strings in the Security Server so that security is improved
- XRDDEV-2521: As a Developer I want to update the Ubuntu packaging so that new installations use ports 8080 and 8443 by default similar to RHEL so that we open up port 80 and 443 to be used for ACME
- XRDDEV-2529: As a Developer I want to check and fix a potential issue with cookies in the Security Server so that security is improved
- XRDDEV-2525: As a Central Server Administrator I want to be able to set up a trusted CA without having a separate certificate for the OCSP responder so that I can use it as I did in the previous version of the Central Server
- XRDDEV-2457: As a Central Server Administrator I want the usability of the filtering input to be improved so that I don't have to double click it
- XRDDEV-445: As a Product Owner I want to use of better certificate hashing algorithms such as SHA-256, so that insecurities of SHA-1 do not cause problems
- XRDDEV-2531: Security server edit token view crashes when refreshing page
- XRDDEV-2545: The UI layout is broken in the Management Service TLS certificate view on the Central Server
- XRDDEV-2526: As a Security Expert I want to verify that the allowed-hostnames parameter works correctly in the Security Server so that security is improved
- XRDDEV-2538: As a Security Server Administrator I want the proxy_ui_api_access.log to be rolled in the same way as all other logs so that it is consitent
- XRDDEV-1203: As a Central Server Administrator I want to be able to export management service TLS certificate using the Central Server UI so that I can verify the TLS connection between management Security Server and management services.
- XRDDEV-2473: As a Security Server Administrator I want to have information on how to configure LDAP role mapping in the user guide so that I can configure it
- XRDDEV-50: As a service provider I want to disable a subsystem temporarily so that I can do maintenance on all the services under the subsystem.
- XRDDEV-2547: Configuration client fails to download global conf over HTTPS and switches to HTTP
- XRDDEV-2548: Federated instance's configuration distribution will remain stuck at v2 after upgrading CS from an older version
- XRDDEV-2546: When upgrading to X-Road 7.4.0 on RHEL8 Java 17 is not set as default automatically.
- XRDDEV-2543: Central Server security officer sees Permission denied in Settings tab
- XRDDEV-2549: After upgrading to version 7.4.0 or doing a clean 7.4.0 install the client information system port on the Security Server is sometimes 443 and other times 8443 with the Estonian meta package.

## 7.3.2 - 2023-08-07
- XRDDEV-2447: The securityServerType property value is stored in the operational monitoring database using capital letters.
Expand Down
7 changes: 0 additions & 7 deletions ansible/roles/xroad-base/tasks/rhel.yml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -33,13 +33,6 @@
state: present
when: ansible_distribution_major_version == "7"

- name: Install Java 17 (RHEL 8 only)
become: yes
yum:
name: "jre-17-openjdk-headless"
state: present
when: ansible_distribution_major_version == "8"

- name: X-Road repo key
rpm_key:
state: present
Expand Down
78 changes: 32 additions & 46 deletions doc/Manuals/ig-ss_x-road_v6_security_server_installation_guide_for_rhel.md
View file

Large diffs are not rendered by default.

24 changes: 19 additions & 5 deletions doc/Manuals/ug-cs_x-road_6_central_server_user_guide.md
View file
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# X-Road: Central Server User Guide <!-- omit in toc -->

Version: 2.38
Version: 2.40
Doc. ID: UG-CS

## Version history <!-- omit in toc -->
Expand Down Expand Up @@ -64,6 +64,8 @@ Doc. ID: UG-CS
| 09.12.2023 | 2.36 | Management service TLS certificate | Eneli Reimets |
| 12.12.2023 | 2.37 | Add a reference to LDAP configuration in Security Server guide | Ričardas Bučiūnas |
| 12.12.2023 | 2.38 | Client subsystem disabling and enabling management requests | Madis Loitmaa |
| 15.12.2023 | 2.39 | Publishing global configuration over HTTPS | Eneli Reimets |
| 20.12.2023 | 2.40 | Automatic configuration signing key rotation | Andres Rosenthal |
## Table of Contents <!-- omit in toc -->

<!-- toc -->
Expand Down Expand Up @@ -105,6 +107,7 @@ Doc. ID: UG-CS
- [5.6 Uploading a Trusted Anchor](#56-uploading-a-trusted-anchor)
- [5.7 Viewing the Contents of a Trusted Anchor](#57-viewing-the-contents-of-a-trusted-anchor)
- [5.8 Deleting a Trusted Anchor](#58-deleting-a-trusted-anchor)
- [5.9 Publishing global configuration over HTTPS](#59-publishing-global-configuration-over-https)
- [6. The Management Requests System](#6-the-management-requests-system)
- [6.1 Registration Requests](#61-registration-requests)
- [6.1.1 State Model for Registration Requests](#611-state-model-for-registration-requests)
Expand Down Expand Up @@ -502,7 +505,7 @@ To download a configuration anchor, follow these steps.
Access rights: Security Officer
Normally, the configuration anchors are generated (and in an HA setup, distributed to every node) automatically by the system upon changes in the data included in the anchor (one or more Central Server addresses, signing keys). The re-creation of an anchor is necessary only for recovering from error situations.
Normally, the configuration anchors are generated (and in an HA setup, distributed to every node) automatically by the system upon changes in the data included in the anchor (one or more Central Server addresses, signing keys). The re-creation of an anchor is necessary mostly for recovering from error situations.
To re-create an anchor, follow these steps.
Expand All @@ -524,14 +527,15 @@ Note that in an HA setup, each node has its own set of configuration signing key
The steps of key change are as follows:
- First, a new key is generated (on each node in HA setups) and the configuration anchor containing the public key part(s) of the key(s) is distributed to X-Road participants. Until all participants have received the public key(s), the old (i.e. current) key(s) is/are used for signing configuration.
- Then, after all participants have received and uploaded the new public key(s), the old key(s) is/are removed and the new key(s) is/are used to sign configuration.
- Then, after all participants have received & applied the new public key(s), the old key(s) is/are removed and the new key(s) is/are used to sign configuration.
To perform a regular key change, follow these steps.
1. Generate, but do not activate a new configuration signing key (see 5.4.1) (in an HA setup, for each node). The system uses the old (active) key(s) to sign the configuration. Upon the generation of a new key, the system generates a new anchor for the corresponding configuration sources.
2. Download the anchor (see 5.2) containing the public key part(s) of the new signing key(s) and distribute the anchor along with the anchor file hash value either to the Security Server administrators (in case of internal configuration anchor) or to the federation partners (in case of external configuration anchor).
2. If there are pre 7.4.0 Security Servers within the ecosystem (including federations) then download the anchor (see 5.2) containing the public key part(s) of the new signing key(s) and distribute the anchor along with the anchor file hash value either to these Security Servers' administrators (in case of internal configuration anchor) or to the federation partners (in case of external configuration anchor).
> **NOTE**: Starting from version 7.4.0 new configuration signing keys are automatically distributed to Security Servers within the global configuration. Distribution will take place within two global configuration refresh cycles.
3. Activate the new signing key(s) (see 5.4.2).
The new signing key(s) should only be activated after all the affected server administrators have received and uploaded the distributed anchor. The Central Servers use the active key to sign configuration. If a server administrator has not uploaded the configuration anchor containing the public key part of the new key before the new key is activated, the verification of the downloaded configuration in the Security Servers will fail and the services exchange with the X-Road participants described in the configuration will be discontinued.
The new signing key(s) should only be activated after all the affected Security Servers have received & applied the new public key (either through automatic configuration signing key rotation or uploading the distributed anchor manually). The Central Servers use the active key to sign configuration. If a server administrator has not applied the new public key before the key is activated, the verification of the downloaded configuration in the Security Servers will fail and the services exchange with the X-Road participants described in the configuration will be discontinued.
4. Delete the old signing key (in an HA setup, delete the old keys on all the nodes) (see 5.4.3). Upon the deletion of a key, the system generates a new configuration anchor.
5. Download the generated anchor (it does not contain the public key part(s) of the old signing key(s)) and distribute the anchor along with the anchor file hash value either to the Security Server administrators (in case of internal configuration anchor) or to the federation partners (in case of external configuration anchor).

Expand Down Expand Up @@ -613,6 +617,16 @@ To delete an anchor file, follow these steps.
2. In the anchor section, click Delete.
3. Confirm the deletion by clicking Yes.
## 5.9 Publishing global configuration over HTTPS
Starting from version 7.4.0, the Central Server supports publishing global configuration over HTTP and HTTPS. Instead, before version 7.4.0, only HTTP was supported.
Starting from version 7.4.0, a new private key and a self-signed TLS certificate are created automatically when installing a new Central Server or upgrading an existing installation from an older version. After the installation or upgrade, the Central Server Administrator must manually apply for a TLS certificate from a trusted Certificate Authority (CA) and then configure the certificate. The CA must be trusted by the Security Server's Java installation. More information about configuring the TLS certificate on the Central Server is available in the Central Server Installation Guide [CSI](#13-references).

Applying for a TLS certificate issued by a trusted CA is required, because the Security Server does not trust the new automatically generated self-signed certificate by default. The Security Server supports disabling certificate verification, but disabling it in production environments is not recommended. More information is available in the `[configuration-client]` section of the System Parameters User Guide [UG-SYSPAR](#13-references).

When upgrading from a version < 7.4.0 to a version >= 7.4.0, the configuration anchor must be re-generated and imported to all the Security Servers to enable downloading global configuration over HTTPS.

# 6. The Management Requests System
## 6.1 Registration Requests

Expand Down
5 changes: 3 additions & 2 deletions doc/Manuals/ug-sec_x_road_security_hardening.md
View file
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# X-Road: Security hardening guidelines <!-- omit in toc -->

Version: 0.3
Version: 0.4
Doc. ID: UG-SEC

## Version history <!-- omit in toc -->
Expand All @@ -10,6 +10,7 @@ Doc. ID: UG-SEC
| 02.06.2023 | 0.1 | Initial version | Ričardas Bučiūnas |
| 24.08.2023 | 0.2 | Minimum supported client Security Server version | Eneli Reimets |
| 14.11.2023 | 0.3 | Publish global configuration over HTTPS | Eneli Reimets |
| 15.12.2023 | 0.4 | Minor updates | Eneli Reimets |

## Table of Contents <!-- omit in toc -->
<!-- toc -->
Expand Down Expand Up @@ -186,7 +187,7 @@ For example, setting the value `server-min-supported-client-version = 7.3.1` mea

## 5. Publish global configuration over HTTPS

Starting from X-Road version 7.4, it is possible to 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.
Starting from X-Road version 7.4, it is possible to 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. See the Central Server User Guide [UG-CS](#Ref_UG-CS) for details.

### 5.1 Central Server TLS configuration

Expand Down
Loading

0 comments on commit 6be1eb0

Please sign in to comment.