Skip to content
Swiss federal authorities

Release notes for the sedex-ClientπŸ”—

These release notes contain a summary of new features, changes and bug fixes for the software releases of the sedex-Client.

sedex-Client 8.0.1 (2026-02-04)πŸ”—

This release does not introduce any new functionality, but updates dependencies/libraries.

  • Internal client improvements: A few dependencies/libraries were updated to their latest version.

sedex-Client 8.0.0 (2025-10-09)πŸ”—

Since 2008, sedex (β€œsecure data exchange”) has been the trusted platform for secure and traceable data exchange among federal, cantonal, and municipal applications in Switzerland. To maintain this high standard of reliability and compliance, sedex is continuously enhanced and aligned with evolving technological and security requirements. With the release of sedex Client 8.0, the platform introduces a number of major improvements that further strengthen security and operational robustness for all connected systems.

Guiding Principles for sedex Client Version 8.0πŸ”—

The major release sedex Client 8.0 introduces several enhancements that can further increase the security of your local installation. To ensure a smooth transition, the configuration of these new features follows two key principles:

Security First – for New InstallationsπŸ”—

New sedex Client installations are configured by default with the latest security features enabled. These default settings strengthen the platform against potential attacks, but depending on your environment, they may require adjustments on your side.

If your operations depend on the behaviour of earlier sedex Client versions, you can manually adapt the configuration – either during installation or afterwards.

Compatibility First – for Upgrades/Migrations of Existing InstallationsπŸ”—

When upgrading an existing sedex Client installation, the current behaviour is preserved.
The new security features are initially disabled, but can be enabled manually if desired.

New features of sedex Client 8.0πŸ”—

Additional Protection for the Keystore File (P12)πŸ”—

The keystore file containing the sedex participant certificate (P12 file) is part of the sedex Client configuration. With version 8.0, this file is now protected in such a way that extracting the private key for external use outside the sedex Client is no longer possible.

Since sedex automatically renews participant certificates when needed, using these certificates outside the sedex context could lead to operational issues. This new protection mechanism is designed to prevent misuse or unintended use of sedex certificates.

This protection applies to all newly generated keystore files and cannot be disabled.
If this behaviour causes problems in your environment, please contact the sedex Service Desk.

Introduction of HTTPS for the sedex Client Monitoring PageπŸ”—

The sedex Client provides a monitoring page for operational and automated observability. Previously, access to this page was only possible via the file system or over HTTP.

Starting with version 8.0, access via HTTPS is now supported.
A dedicated self-signed TLS certificate is automatically created and configured for this HTTPS endpoint.
If desired, this endpoint can also be configured to use a custom TLS certificate provided by the customer.

New installations use HTTPS by default, while HTTP is disabled (but can be re-enabled if needed).
For upgraded installations, HTTP remains enabled; switching to HTTPS is possible through manual configuration.

Deactivation of HTTP for Access to the sedex Client WS-ProxyπŸ”—

Since version 6.0, the sedex Client has supported both HTTP and HTTPS access to its web services. Starting with version 8.0, new installations enforce HTTPS-only communication.
The HTTP port is disabled by default but can be re-enabled if required.

When upgrading an existing installation, the previous dual HTTP/HTTPS behaviour is preserved. Administrators may manually disable HTTP at any time.

New Option to Restrict Network Interfaces and Addresses (Port Binding)πŸ”—

In previous versions, sedex Client services (WS-Proxy, Messaging REST API, and Monitoring Page) were bound by default to all available network interfaces and addresses of the host system.

Version 8.0 introduces the option to restrict bindings to specific interfaces or addresses.
During installation, the setup wizard now suggests restricting bindings to localhost by default.
Administrators can choose to bind the sedex Client to a specific interface or keep the previous behaviour (binding to all available interfaces).

For upgrades, the behaviour remains unchanged: all services stay reachable on all interfaces unless manually restricted.

Deactivation of Anonymous Access for all Web Services provided by sedex Web Service ProxyπŸ”—

In previous versions, by default certain web services offered by the sedex Web Service Proxy were accessible without user authentication (e.g. checkSedex).

For new installations, anonymous access to all web services is disabled by default as of version 8.0. If required, administrators can manually enable anonymous access via configuration properties after installation.

For upgrades, the behaviour remains unchanged: anonymous access remains enabled unless explicitly restricted by the administrator.

For any questions or support regarding the upgrade to version 8.0, please contact the sedex Service Desk.

sedex-Client 7.0.13 (2025-09-02)πŸ”—

This release does not introduce any new functionality, but updates dependencies/libraries.

  • Internal client improvements: A few dependencies/libraries were updated to their latest version.

sedex-Client 7.0.12 (2025-07-09)πŸ”—

This version includes only minor updates without any major changes, focusing on updating third-party libraries to their latest versions.

  • Web Service Proxy improvement: When attempting to upgrade connections to HTTP/2.0, a specific web service failed to respond. To address this issue, the sedex-Client 7.0.12 disables HTTP/2.0 upgrades, ensuring compatibility and stable communication.

  • Configuration improvement: The mechanism for automatically detecting changes in the configuration file sedex-incoming-message-interface-rules.conf has been made more robust to ensure reliable detection of updates, including on specific cloud platforms such as Azure.

  • Internal client improvements: A few dependencies/libraries were updated to their latest version.

sedex-Client 7.0.11 (2025-03-28)πŸ”—

This version focuses on fixing an issue regarding the Sedex Web Service Proxy connectivity and includes updates to its underlying dependencies. No new features are introduced in this version.

  • Fix: Connectivity Issue with Specific Network Proxies in Sedex Web Service Proxy
    Addresses a bug within the Apache HttpClient library, a dependency of the Sedex Web Service Proxy, which caused connection failures to web services like UPI when using certain network proxies. This issue was presented with the error message 'Chunked transfer encoding not allowed for HTTP/1.0'. It was introduced in sedex Client version 7.0.9 but is now fixed.

  • Internal client improvements: A few dependencies/libraries were updated to their latest version.

sedex-Client 7.0.10 (2025-02-13)πŸ”—

This version includes only minor updates without any major changes, focusing on updating third-party libraries to their latest versions.

  • Internal client improvements: A few dependencies/libraries were updated to their latest version.

sedex-Client 7.0.9 (2024-12-02)πŸ”—

This release does not introduce any new functionality, but updates dependencies/libraries.

  • Internal client improvements: A few dependencies/libraries were updated to their latest version.

sedex-Client 7.0.8 (2024-10-03)πŸ”—

This release does not introduce any new functionality, but updates dependencies/libraries.

  • Internal client improvements: A few dependencies/libraries were updated to their latest version.

sedex-Client 7.0.7 (2024-08-20)πŸ”—

This release does not introduce any new functionality, but updates dependencies/libraries.

  • Internal client improvements: A few dependencies/libraries were updated to their latest version.

sedex-Client 7.0.6 (2024-06-06)πŸ”—

This release does not introduce any new functionality, but addresses an issue in the new self-diagnosis / installation check functionality.

  • Fix: Proxy support in new self-diagnosis / installation check functionality
    The new functionality introduced in the previous version 7.0.5 to perform an automatic installation check at the end of the installation process can lead to an error if the sedex-Client accesses the sedex server indirectly via a proxy server. The error message says:
    Could not connect to sedex url without client certificate https://sedex-service.admin.ch/monitoring/accesstest, error was: <proxy> protocol is not supported.
    Important: The installation and operation of the sedex-Client 7.0.5 itself is not affected by this error. The sedex-Client 7.0.5 can therefore continue to be used normally.

sedex-Client 7.0.5 (2024-06-03)πŸ”—

This release introduces extended self-diagnosis functionality and addresses an issue of the sedex-Client.

  • New Functionality: Self-diagnosis / Installation Check of a sedex-Client Installation
    To ensure that a sedex-Client installation is configured correctly and works successfully, a new function for self-diagnosis and an installation check is now available. This test function can be executed manually by the participant at any time using the new shell script (β€œcheck-installation”) e.g. when encountering problems.

    This stand-alone installation-check script allows checking a sedex-Client installation without having to start the client. In this way, a new installation can be checked at an early stage without unintentionally processing sedex messages.

    Among other things, the following aspects are checked:

    • correctness of the configuration files
    • validity of the certificates
    • reachability of the sedex servers via the network connection

    For more details, refer to the technical sedex-Client documentation: Self Diagnosis / Installation check

  • Fix: Improved robustness of the sedex Messaging REST API on Windows installations
    The envelope of a sedex message offers an XML field to send optional test metadata with a sedex message. Due to a difference in the encoding of special characters on Windows installations, problems could occur when sending messages via the sedex Messaging REST API. This problem has been fixed.

    Note: Since such test data is almost never transmitted in practice, only very few users are affected by this problem. Linux and Docker installations are not affected anyway.

  • Internal client improvements: A few dependencies/libraries were updated to their latest version.

sedex-Client 7.0.4 (2024-02-23)πŸ”—

This release does not introduce any new functionality, but addresses an issue of the sedex-Client.

  • Correcting an error from unclosed file system resources: If sedex messages are received whose payload is larger than 5 megabytes, their payload is temporarily stored in a file in the temp directory of the sedex-Client. On Windows-based file systems, these files can no longer be deleted properly after reception. The files accumulated in this way are only deleted when the sedex-Client is restarted. As a result, the hard disk space used by the client can grow and fill up the hard disk, especially for installations with a small amount of allocated disk space. However, sedex-Clients running on a Linux-based file system are not affected by this. To ensure the operational stability of a sedex-Client 7.0 installation, an update to the new version is recommended (sedex-Client 6.x is not affected)
  • Internal client improvements: A few dependencies/libraries were updated to their latest version.

sedex-Client 7.0.3 (2024-01-16)πŸ”—

This release does not introduce any new functionality, but addresses an issue of the sedex-Client.

  • Correcting an error from unclosed file system resources: As part of the new REST API functionality in the client, the file system is checked every five minutes. This leaves two additional unclosed file system resources each time. If a sedex-Client runs for a long time, these resources can run out (especially under Linux), which means that the sedex-Client no longer works. The accumulated open resources are only closed again when the sedex-Client is restarted. To ensure the operational stability of a sedex-Client 7.0 installation, an immediate update to the new version is recommended (sedex-Client 6.x is not affected).
  • Internal client improvements: A few dependencies/libraries were updated to their latest version.

sedex-Client 7.0.2 (2023-11-18)πŸ”—

This release does not introduce any new functionality, but updates dependencies/libraries.

  • Security improvement: A potential vulnerability has been identified in the Apache open source library "XML Security for Java (xmlsec)" (CVE-2023-44483). This can lead to sensitive information being written into log files when the logging level debug for this library is switched on. The default logging level for this Library is warn, which prevents the problem from occurring.
    Note: Administrator permissions are required to activate the logging level debug. An administrator could access the sensitive information directly anyway, which is why the risk of this potential vulnerability in the context of sedex-Client is rather low.
    The library used in this version of the sedex-Client fixes this problem.
  • Internal client improvements: A few dependencies/libraries were updated to their latest version.

sedex-Client 7.0.1 (2023-10-17)πŸ”—

This release does not introduce any new functionality, but addresses an issue of the sedex-Client.

  • Fix of the Service Wrapper in Windows: If the sedex-Client was installed in a folder with spaces in the path in Windows, it could happen that the sedex-Client could not be registered as a Windows service. This is now fixed. Note: we generally recommend to use paths without spaces.
  • Change in Windows Installer: Due to the significantly increased memory consumption of the JVM 64 bit version (plus 30 percent) we decided to include the 32 bit version again. This optimization is especially beneficial for participants who run a large number of sedex-Clients on a single host.
  • Internal client improvements: A few dependencies/libraries were updated to their latest version.

sedex-Client 7.0.0 (2023-09-01)πŸ”—

The sedex-Client 7.0 introduces significant new functionalities while being largely backward compatible with older sedex-Clients. Before migrating an existing sedex-Client 6.x installation to version 7.0, you should study the following release notes thoroughly and make the neces-sary preparations.

  • New Functionality: The sedex Messaging REST API Since 2008, business applications connected to sedex have been sending and receiving sedex messages via a simple file-based interface in the file-system (via the "outbox", "inbox" and "receipts" folders). However, especially on cloud and container platforms, the exchange of files via a shared file system is not always easy to realize. The need for an alternative, networkbased interface is therefore constantly increasing. The new "sedex Messaging REST API" is the answer to the increasing need to exchange sedex messages over https. The "sedex Messaging REST API" is a new machine-to-machine interface provided by the sedex-Client, which allows the business applications of a sedex participant to send and receive sedex messages directly over the usual https protocol. Note: After migrating an existing installation to version 7.0, the Messaging REST API is disabled by default. Consult the documentation to learn how to configure and enable the Messaging REST API.

    The new Messaging REST API comes with additional features

    • Dispatching incoming messages to logical participants: Via the messaging REST API, a business application can now access its own virtual inbox on the sedex-Client. This should eliminate the need for participants to do their own dispatching to different logical sedex-IDs, which is required for the file-based inbox, in many cases.
    • Encrypted caching of messages in the file system: Messages sent or received by the business application via the messaging REST API are automatically stored in encrypted form in the file system of the sedex-Client. This local encryption is applied by default but can be switched off via a specific configuration parameter if required.

    • Compatibility with previous sedex-Clients: The new sedex messaging REST API is largely implemented locally in the sedex Web Service Proxy as part of the sedex-Client. Currently, the WS proxy acts as a translator between the file system and the REST API, i.e. message sending still runs indirectly via classic sedex messages in the file system. This has the advantage that it is transparent for participants which interface is used to send or receive a sedex message. Both interfaces can be used and the new REST API is thus perfectly integrated into the existing sedex world.

    • New Configuration file: In a newly introduced configuration file, specific rules can be used to define in a fine-grained way which messaging interface should be used to deliver an incoming sedex message to the business application. This new configuration file has the name sedex-incoming-message-interface-rules.conf and can be found in the usual configuration folder of the sedex-client. The new configuration file includes a detailed explanation of the specific rules with examples. Thus, it should be self-explanatory.
      Note: As long as all messages are delivered to the business application exclusively via file-system or exclusively via REST-API, specific rules are not necessary at all. Specific rules are only necessary if certain messages are to be received via the file system and certain messages via the REST API.
    • Improvement: New features in the WS-Proxy User Configuration file Passwords may now also contain special characters. To increase the complexity of passwords, the following special characters are now also supported in a password: !"#$%&'()*+,-./:;<=>?@[]^_`{}|~
    • Automatic validation messages in the WS-Proxy User Configuration file. If errors are detected in this configuration file after changes, they are automatically added as comments directly in the file. Depending on the editor used, the file must be reloaded to see any errors.
    • Improvement: TLS 1.3 support. The WS-Proxy now also supports TLS version 1.3, although the TLS 1.2 version remains supported
    • Improvement: Clean up temporary Tomcat folder. The Tomcat server embedded in the WS-Proxy can create temporary folders in the file system at runtime. Such folders are now automatically deleted by the sedex-Client when shutting down if they are empty.
    • Change: New columns in Send and Receive logs. The sedex-Client keeps a sepa-rate functional log, which lists all received and sent sedex messages with their most important metadata. These logs are now supplemented by additional columns showing which messaging interface was used by a business application for sending or receiving (file-system or REST-API). If these business logs are processed automatically, the tools that do this must be adapted to the new extended log format.
    • Change: Extension of the offered monitoring parameters. The sedex-Client offers a page listing various parameters for monitoring purposes via the file system and via an HTTP port. The list of exposed parameters has been extended with additional entries, so that the new messaging REST API can also be included in your operational moni-toring.
    • Change: Client runs on Java 17 (or later). The sedex-Client is based on the Spring Boot Framework. With version 7.0 of the sedex-Client, the previous Spring Boot 2 is replaced by the new Spring Boot 3. This means that the sedex-Client no longer runs with older Java versions, but requires at least a Java Runtime Environment 17 or later. If an existing sedex-Client 6.x installation uses a self-provided Java Runtime Environment, a new one of version 17 or later must be provided before migrating the sedex-Client. Note: This is not required if you use the Windows Installer (which automatically installs a Java runtime environment) or if you use the Docker Client (which includes a suitable Java runtime environment in the container image).
    • Change: Slightly increased resource consumption in the range between 0 and 15 percent. Due to the new Spring Framework 3 and the extended client functionality, a sedex-Client may require slightly more resources (CPU, RAM). In most cases this additional consumption should be marginal and not noticeable. However, especially in situations where a larger number of sedex-Clients are running simultaneously on one host, the additional consumption may add up to require operational adjustments (more CPU, more RAM).
    • Change: New default RMI port. The three processes controller, adapter, WS-Proxy of the sedex-Client communicate with each other via an RMI server. The sedex-Clients from version 7.0.x cannot use an RMI server of an older client and therefore need a separate RMI server. The new RMI server now uses port 11799 by default. (Older sedex-Clients 6.x use port 11899 by default). Of course, the RMI port to be used can be reconfigured in the sedex-client-configuration.properties file if necessary. Please consult the sedex-Client manual for details.
    • Fix: The updated logstash library included in client 6.0.10 (to log directly to logstash) was no longer compatible with the version of the logback framework used for logging. This is now fixed and logstash is supported again.
    • Fix: The Windows Powershell startup script now supports environments where more than one JRE is listed in the path variable.
    • Improvement: Internal client improvements. Several dependencies/libraries have been updated and a few minor internal improvements to the client have been made. These internal improvements have no impact on the functionality.

Older Releases (6.x)πŸ”—

Release-notes for older versions are available here: Release notes for sedex-Client 6.x.