Skip to main content

Security

For the communication, mTLS is used. For incoming TLS connections the following TLS versions and cipher suites are accepted:

TLS versionCipher Suite
1.3TLS_AES_256_GCM_SHA384

Authentication​

The issuer is authenticated by their client certificate and only has access to their data.

Separate certificates are required for the test and production environments.

Client Certificate Lifecycle Management​

Transition to SIX-Issued Certificates​

Public Certificate Authorities (CAs) will no longer issue certain certificates used for mTLS client authentication. Therefore, certificates for the affected applications and interfaces will in future be provided by SIX BBS AG.

The following transition rules apply:

  • From September 1, 2026 until March 15, 2027, certificates can either be obtained from SIX BBS AG (recommended) or from a public Certificate Authority.
  • Existing certificates issued by a public Certificate Authority before March 15, 2027 can continue to be used until their expiry date.
  • From March 15, 2027, new certificates for the affected applications and interfaces will be issued exclusively by SIX BBS AG.

Client certificates from Public Certificate Authority - Obsolete​

The issuer may obtain the certificates themselves and then forward the entire certificate chain to SIX Client Delivery. The issuer ensures that the certificates are renewed in time and that SIX Client Delivery is informed about the date of a certificate replacement one month in advance.

To guarantee a high level of security, the certificates must meet at least the following requirements:

  • Validity of the user certificates: not expired, still valid for nine months for new registrations
  • Validity of the root certificates: not expired, still valid for five years with new registration
  • Standard: X.509 V3
  • Signature algorithm: RSA-SHA-256 or better, ECDSA-SHA256 or better
  • Key length: min. 2048 Bit
  • Key Usage: Client Authentication

SIX-Issued Client Certificates - Recommended​

From March 15, 2027, access to SIX services, e.g. debiX API, is based on machine-to-machine client authentication using X.509 certificates issued and managed by SIX.

The following section describes how customers can request, obtain and deploy SIX-issued client authentication certificates, including the required inputs and technical prerequisites.

Process Overview​

The certificate ordering process consists of the following steps:

  1. Customer prepares a Certificate Signing Request (CSR)
    • According to SIX requirements
  2. Customer submits the request to the SIX support
  3. SIX validates the request and issues the certificate
    • Non-compliant CSR may require a new submission.
  4. Certificate is delivered to the customer
    • Certificate chain provided in PKCS#7 and PEM (OpenSSL) format
  5. Customer deploys the certificate for the relevant SIX application(s)
    • Once received, the certificate can be used immediately.

Step 1 – Prepare the Certificate Signing Request (CSR) - Requirements​

The customer generates a CSR locally and retains full control over the private key.

CSR requirements

  • Format: PKCS#10, PEM encoded
  • Key type: RSA
  • Key length: 3072 or 4096 bits
  • Requested Common Name (CN): Company Legal Name (mandatory)
  • Subject Alternative Name (SAN): email address (mandatory)
    • MUST include the lifecycle notification email address (only shared mailbox allowed)
  • Subject Alternative Name (SAN) - Optional: DNS Name
    • Should be included
  • Organisation Unit (OU)
    • debiX API (fixed value, mandatory)
    • Optionally, an environment identifier may be appended to the mandatory base value using the format:
      • debiX API - <Environment> (Ex. debiX API – Production)

The private key must remain adequately protected with the customer at all times. The CSR must not contain any confidential or secret data.

Step 2 – Submit the Certificate Request​

The CSR (PKCS#10, PEM) must be submitted to SIX (support.debit@six-group.com).

Please include the following information in your email:

  • Target environment: Test or Production
  • Service: debiX API

The request must be submitted or confirmed by the Main Point of Contact.

All information provided must be consistent and complete to avoid delays.

Step 3 – Validation and Certificate Issuance by SIX​

SIX performs a formal validation of the submitted request.

Validation criteria

  • CSR content must match the submitted request data (CN, SAN, etc.)
  • Contact and service information must correspond to the registered customer data

If inconsistencies are identified, a new CSR may be required.

Upon successful validation, SIX issues the client authentication certificate and registers it internally for the relevant SIX systems.

Step 4 – Certificate Delivery​

The issued certificate will be provided to the customer via email.

The certificate in PEM (Linux/Windows) and DER encoded (Windows) is delivered together with the required certificate chain.

Step 5 – Deployment and Usage​

The customer installs the certificate, including the full trust chain, in their system landscape. The certificate can be used immediately after deployment.

Validity and Renewal​

Participants are responsible for monitoring the validity of their certificates. Certificates remain valid until their defined expiry date. Customers are responsible for requesting a replacement certificate in due time before expiry, following the same process described on this page.

The CSR needs to be sent to support.debit@six-group.com for configuration at least 2 weeks before the current certificate expires.

Key Compromise or Loss​

If a private key associated with a SIX issued client authentication certificate is lost, suspected to be compromised, or otherwise exposed, customers must immediately inform SIX via the designated support contact.

Upon notification, SIX will take the necessary steps to revoke and block the affected certificate to prevent unauthorized access. A new certificate must then be requested following the standard ordering process described on this page.

Customers are responsible for ensuring appropriate key protection measures on their side, including secure storage and access controls for private keys.

Certificate Usage Restrictions​

SIX-issued client authentication certificates are exclusively intended for authentication against SIX services.

The certificates and associated private keys must not be reused for other purposes, services, environments, or third-party systems. Any use outside the agreed SIX service context is not permitted.

This restriction ensures clear trust boundaries, reduces security risks, and supports reliable certificate lifecycle management.

Price​

Free until 2028.

Support and Contact​

For questions regarding certificate requests, validation, or deployment, please contact SIX Support (support.debit@six-group.com).

OpenSSL on Linux distributions / Microsoft Windows​

  1. A quick note on “umlaut”: use “ae” instead of “ä”, “ue” instead of “ü”, etc. in

    • Subject Common Name (CN)
    • Organizational Unit (OU)
    • Organization (O)

    Remark: Country (C) codes shall adhere to ISO 3166 two letter code (alpha-2) standard. Example Switzerland: C=CH.

    If generating a certificate signing request (CSR) using OpenSSL, escape spaces and special characters in parts of the subject distinguished name attribute. Example: SUBJECT_COMMON_NAME=Donau\ Sandbank\ AG

    Now, declaring the variables

    KEY_LENGTH=3072
    PKCS_DIR=/opt/myApp/certs
    KEY_NAME=client_auth_key_donau-sandbank
    FQDN=myServer.donau-sandbank.ch
    SUBJECT_COMMON_NAME=Donau\ Sandbank\ AG
    OU=debiX\ API
    O=Donau\ Sandbank\ AG
    C=CH
    NOTIFICATION_EMAIL=cryptoservices@donau-sandbank.ch

  2. Option A): no private key protection (except file system permissions)

    #This command generates an only file-system protected RSA key.
    #Comment, if not using a secure random number generator.
    openssl genrsa -rand /dev/random -out $PKCS_DIR/$KEY_NAME.key $KEY_LENGTH

    ##or without secure random number generator; uncomment
    #openssl genrsa -out $PKCS_DIR/$KEY_NAME.key 3072

    Option B): protected private key, encrypts generated key using a 3des key derived from user PIN

    #This command generates a PIN protected private key, where
    #the user has to enter and confirm the PEM pass phrase.
    #Comment, if not using a secure random number generator
    openssl genrsa -rand /dev/random -out $PKCS_DIR/$KEY_NAME.key -des3 $KEY_LENGTH

    ##or without secure random number generator; uncomment
    #openssl genrsa -des3 -out $PKCS_DIR/$KEY_NAME.key $KEY_LENGTH

  3. Generating the CSR

    #This command generates a PKCS#10 message using the constants and outputs the CSR to $PKCS_DIR/$FQDN.csr

    openssl req -new -key $PKCS_DIR/$KEY_NAME.key \
    -out $PKCS_DIR/$FQDN.csr \
    -subj "/C=$C/O=$O/OU=$OU/CN=$SUBJECT_COMMON_NAME" \
    -addext "subjectAltName=DNS:$FQDN,email:$NOTIFICATION_EMAIL"

  4. Verify the subject distinguished name in the CSR

    #This command verifies subject distinguished name in the CSR
    openssl req -in $PKCS_DIR/$FQDN.csr -subject -noout

  5. Verify the SAN extensions in the CSR

    #This command verifies the subject alternative name extension in the CSR
    openssl req -in $PKCS_DIR/$FQDN.csr -text -noout | grep -A1 "Subject Alternative Name"

  6. Display the CSR for later submission to the appropriate SIX Service Desk

    #This command displays the CSR in base64 format, which can be copied into any text editor and later submitted to SIX CA for signing.

    cat $PKCS_DIR/$FQDN.csr

certreq.exe on Microsoft Windows using a configuration file​

  1. Download the request.inf file to the instance (see Example). For the purpose of this manual, we assume the path %systemdrive%\temp\certdir\

    request.inf.txt

  2. Open the file %systemdrive%\temp\certdir\request.inf.txt in a text editor such as notepad.exe

  3. Edit the request.inf file sections / parameters (see below). The file will later be used to configure the Certificate Signing Request (CSR).

    A quick note on “umlaut”: use “ae” instead of “ä”, “ue” instead of “ü”, etc. in

    • Subject Common Name (CN)
    • Organizational Unit (OU)
    • Organization (O)

    Sections

    • [NewRequest]

      Subject = "CN=Donau Sandbank AG, OU=debiX API, O=Donau Sandbank AG, C=CH"

    • [Extensions]

      2.5.29.17="{text}"
      • _continue_ = "dns=myserver.donau-sandbank.de&"
      • _continue_ = "email=myTeamMailBoxOrMailingList@donau-sandbank.de&"

  4. Save the modified request.inf (in the process, removing the .txt file-extension) file in UNICODE encoding (UTF-16 LE).

  5. Generate a PKCS#10 Certificate Signing Request (CSR) based on the parameters defined in the request.inf file.

    The corresponding private key is created and stored in the Windows certificate store of the system where the command is executed.

    REM This command generates a PKCS#10 message using the request.inf file as input and generates the CSR as output to %systemdrive%\temp\certdir\myserver.donau-sandbank.de.csr

    certreq -new %systemdrive%\temp\certdir\request.inf %systemdrive%\temp\certdir\myserver.donau-sandbank.de.csr

  6. Display the CSR for later submission to the appropriate SIX Service Desk

    REM This command displays the CSR in base64 format, which can be copied into any text editor and later submitted to SIX CA for signing.
    type %systemdrive%\temp\certdir\myserver.donau-sandbank.de.csr

Certificate Enrolment wizard on Microsoft Windows (certlm.msc / certmgr.msc)​

  1. On the system for which the certificate signing request (CSR) shall be created, use certlm.msc /certmgr.msc and start it with administrative privileges.

  2. Navigate to Certificates - Local Computer > Personal > Certificates.

    Open the context menu and start the custom certificate request wizard by selecting:

    • All Tasks
    • Advanced Operations
    • Create Custom Request

  3. In the wizard, select Proceed without enrollment policy, then click Next.

  4. Select CNG Key in the Template options and PKCS #10 as the request format and continue with Next.

  5. Expand Details and open Properties to define the certificate request attributes before creating the request file.

  6. On the General tab, enter a meaningful friendly name and description. Use values that allow the certificate request to be clearly identified later.

  7. A quick note on “umlaut”: use “ae” instead of “ä”, “ue” instead of “ü”, etc. in Subject Common Name (CN)

    On the Subject tab, add the required

    • common name (CN) using your company’s registered name
    • Subject Alternative Name (SAN) DNS name matching the FQDN of your instance

  8. A quick note on “umlaut”: use “ae” instead of “ä”, “ue” instead of “ü”, etc. in Organizational Unit (OU)

    Still on the Subject tab, add the

    • Organizational Unit (OU)
    • Subject Alternative Name (SAN) Email

    Remark: The latter will be used for lifecycle notification messages

  9. A quick note on “umlaut”: use “ae” instead of “ä”, “ue” instead of “ü”, etc. in Organization (O)

    Still on the Subject tab, add the

    • Organization (O)

  10. Finally, on the Subject tab, add the

    • Country (C)

    Remark: Country (C) codes shall adhere to ISO 3166 two letter code (alpha-2) standard. Example Switzerland: C=CH.

  11. On the Extensions tab, configure the required key usages

    • Digital signature
    • Mark the extension critical

  12. On the Extensions tab, scroll down to configure the Enhanced Key Usage

    • Client Authentication

  13. On the Private Key tab, configure the cryptographic provider, key length, and export settings.

    • Key size:4096
    • Hash Algorithm: sha256

    Confirm the request information by pressing OK

    Remark: To adhere to key management best practices, it is recommended that the private key is NOT exportable. When this is the case, the CSR needs to be generated on the machine that it's going to use the certificate.

  14. Confirm the configured request properties by pressing Next

  15. Save the CSR-file to a local directory selecting the

    • File format: Base64

    Conclude the Certificate Enrollment wizard by pressing FINISH

  16. Copy the file or obtain its base64 encoded content from C:\Certificates\myHost01.sandbank.com-csr.pem using a text editor such as notepad.exe.