Skip to content
Swiss federal authorities

sedex Participant Certificates (X.509)🔗

Overview🔗

sedex Participant Certificate

The sedex platform uses dedicated sedex participant certificates (X.509) for strong authentication of its participants.
These certificates are automatically issued by the Swiss Government PKI (SwissGov-PKI) and stored within the sedex-Client as part of its configuration.

Danger

While it may appear convenient to extract and reuse these certificates, this is strictly prohibited.

sedex participant certificates may only be used for configuring a sedex-Client instance. The sedex system manages and renews these certificates automatically — meaning that a certificate can be replaced with a new one at any time.

To ensure the integrity and security of participant credentials:

  • The private key associated with a participant certificate must remain within the sedex-Client.
  • Extracting keystore files (.p12) or private keys from the sedex-Client configuration is not permitted.
  • Newly issued certificates (starting with sedex-Client version 8.0) are protected against extraction by an internal safeguard mechanism.
    This protection cannot be disabled and is intended to prevent misuse or unauthorized access. If this mechanism causes compatibility issues in your environment, please contact the sedex Support Team.

Certificate Configuration File🔗

Participant certificates and sedex server truststores are defined in a dedicated configuration file:

<sedex_home>/conf/sedex-certificate-configuration.xml

Note

The sedex-Client automatically ensures that this configuration file is set up correctly.
Manual changes are not recommended and typically not required.

Example Structure🔗

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<certificateConfiguration
    xmlns="http://www.sedex.ch/xmlns/certificateConfiguration/1/0">
    <privateCertificate>
        <location>** path to private certificate of participant **</location>
        <password>** password to private certificate **</password>
    </privateCertificate>
    <transportCertificate>
        <location>${sedex.home}/conf/certificates/sedex-transport-encryption.cer</location>
    </transportCertificate>
    <webserviceTruststore>
        <location>${sedex.home}/conf/certificates/sedex-server-truststore.jks</location>
        <password>trustme</password>
        <truststoretype>JKS</truststoretype>
    </webserviceTruststore>
</certificateConfiguration>

The field <location> must point to the valid PKCS#12 keystore file (.p12) containing the participant’s private key.
The field <password> must specify the corresponding password for this keystore.

Multiple Certificates and Renewal🔗

Normally, a participant has only one valid keystore entry at a given time.
However, during an automatic renewal, a new certificate is added and the previous one is marked as renewed.
Renewed certificates remain for 60 days before being deleted automatically.

Example with Multiple Certificates🔗

[...]
<privateCertificate>
    <location>** path to key store 1 **</location>
    <password>** password to key store 1 **</password>
</privateCertificate>
<privateCertificate>
    <location>** path to disabled key store 2 **</location>
    <password>** password to key store 2 **</password>
    <renewed>2019-12-04+01:00</renewed>
</privateCertificate>
[...]

Initial Certificate Requests🔗

Clients without an existing participant certificate can request a new one.
In this case, the configuration contains an <initialCertificateRequest> element instead of <privateCertificate>.

[...]
<initialCertificateRequest>
    <requestId>SETUP_REQUEST_ID(CRID)</requestId>
    <oneTimePassword>SETUP_ONE_TIME_PASSWORD(OTP)</oneTimePassword>
</initialCertificateRequest>
[...]

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<certificateConfiguration
    xmlns="http://www.sedex.ch/xmlns/certificateConfiguration/1/0">
    <initialCertificateRequest>
        <requestId>05-35-f4-85-ed</requestId>
        <oneTimePassword>LGCA-AIXL-QCOL-YVZH</oneTimePassword>
    </initialCertificateRequest>
    <transportCertificate>
        <location>${sedex.home}/conf/certificates/sedex-transport-encryption.cer</location>
    </transportCertificate>
    <webserviceTruststore>
        <location>${sedex.home}/conf/certificates/sedex-server-truststore.jks</location>
        <password>trustme</password>
        <truststoretype>JKS</truststoretype>
    </webserviceTruststore>
</certificateConfiguration>

Note

The input parameters (CRID, OTP) must be requested from your responsible sedex domain administrator or from FSO’s sedex Customer Support.
They will be provided via two separate communication channels for security reasons.

Additional Elements🔗

Depending on the certificate’s lifecycle, the sedex-Client may add additional metadata elements.

<restriction>🔗

Added and managed automatically during the certificate renewal process.

[...]
<privateCertificate>
    <location>( path to key store )</location>
    <password>( password to key store )</password>
    <restriction>READONLY</restriction>
</privateCertificate>
[...]

Possible values:

Restriction Type Effect
READONLY The certificate can only be used for receiving messages, not sending.
DISABLED The certificate is completely inactive.

<optionalInfo>🔗

Contains informational attributes for documentation purposes.

<privateCertificate>
    <location>( path to key store )</location>
    <password>( password to key store )</password>
    <optionalInfo>
        <issuer>CN=vAdminCA-CD-T01,OU=Certification[...]</issuer>
        <serial>4545</serial>
        <expirydate>2012-06-19T13:34:50.000+02:00</expirydate>
    </optionalInfo>
</privateCertificate>

Tip

Always include the files sedex-certificate-configuration.xml and all current keystore files (.p12) in your regular backup process to ensure recoverability.