TLS Certificates
All connections between the bLink API platform, Service Users (SUs), and Service Providers (SPs) are encrypted using Transport Layer Security (TLS) 1.2 or higher and strong cipher suites. bLink verifies all requests from SUs against their certified use cases, and only admissible requests are forwarded to the SP. As a result of the certification process, SUs get authorized for the certified use cases.
In the bLink ecosystem, connections are mutually authenticated through mutual TLS, whereas the SUs register their full chain certificate with SIX to get access to the platform. The platform maps the certificate to a client_id, which is later used to match access tokens to the unique identifier.
- The bLink API authenticates the SUs using X.509 certificates
- FIs authenticate the bLink API using X.509 certificates
Exceptions to the mutual TLS requirement will only be granted in the closed financial network SSFN. Encryption of network traffic is enforced in any case.
Participants have two options to obtain a client certificate for bLink:
- A certificate from one of the accepted public Certificate Authorities listed below
- A certificate issued by SIX, see Client Certificates Issued by SIX
Certificates for API Access
SIX requires client certificates to provide access to bLink, and this applies both for production and test system with the simulator applications. Individual certificates are required to access the environments and must have different designations.
To guarantee a high level of security, certificates not issued by SIX must meet the following conditions:
- Validity: Not expired. The certificate lifetime should be approximately one year
- Version: V3
- Signature Algorithms: sha224RSA, sha256RSA, sha384RSA, sha512RSA
- Supported Key Type: RSA
- Key Length: 3072 bits or longer
- Key Usage: Digital Signature
- Extended Key Usage: Client Authentication
- Issuer: Trusted Certificate Authority (CA) (listed below)
- Type: Organization Validation certificate (OV) or Extended Validation certificate (EV)
- Common Name (CN): Reference to the authorized participant
- Once a valid certificate is available, the main contact in charge at your company must send the full chain certificate to SIX via bLink Support Portal.
- All certificates from the following issuers that meet our conditions can be used for the platform. Companies that want to use certificates from other third-party providers should contact SIX.
Certificate Authorities (CA) and cipher suites to access the platform
The following Certificate Authorities are accepted by SIX for the test environments and for production. Certificate requirements are currently subject to frequent change across the industry. The status column shows how stable each hierarchy is expected to be. If you intend to use a Certificate Authority that is not listed or one whose status is not confirmed, contact SIX before ordering.
| CA | Root CA | Issuing CA | Status |
|---|---|---|---|
| SIX | TBD: SIX Root CA name | TBD: SIX Issuing CA name | Confirmed - Long-Term |
| DigiCert | X9 Financial PKI - RSA 4096 Root | X9 Financial PKI - RSA 4096 ICA X9 Financial PKI - RSA 4096 ICA EU | Confirmed - Long-Term |
| SwissSign | SwissSign RSA TLS Root CA 2022 - 1 | SwissSign RSA TLS EV ICA 2022 - 1 SwissSign RSA TLS OV ICA 2022 - 1 | Confirmed - New certificates until Q1/2027 |
| Cipher Suites | |
|---|---|
| #TLS 1.3 | TLS_AES_256_GCM_SHA384 TLS_AES_128_GCM_SHA256 TLS_AES_128_CCM_SHA256 |
| #TLS 1.2 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_DHE_RSA_WITH_AES_256_CCM_8 TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |
Client certificates issued by SIX
SIX issues client authentication certificates for participants on request, for the test environments as well as for production. The participant prepares a Certificate Signing Request (CSR), submits it through the bLink Support Portal, and SIX validates the request, issues the certificate and whitelists it.
Certificates issued by SIX may only be used for authentication against SIX services.
The full requirements and a step by step guide are described in Client Certificates Issued by SIX.
General Requirements
The following general requirements apply to the TLS certificates used for API access.
Validity of Certificates
Participants are responsible for monitoring the validity of the certificates. Renewed certificates must be sent to bLink for configuration at least two weeks before the existing certificate expires. The same lead time applies to certificates issued by SIX.
Deactivation of whitelisted certificates
Once the certificate is whitelisted for a specific environment, it remains valid for up to three months without any operations. Afterwards it will automatically be deactivated. To avoid deactivation of certificates, it is recommended to perform a periodical directory or healthcheck calls.
Key compromise or loss
Participants are responsible for protecting their private keys, including secure storage and access control. If a private key is lost, suspected to be compromised or otherwise exposed, inform SIX immediately through the bLink Support Portal so that the affected certificate can be blocked. A replacement certificate must then be requested and whitelisted before access is restored.