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.
The list of Certificate Authorities whose certificates are accepted by bLink API is presented in the following subsection.
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.
In order to guarantee a high level of security, the certificates must meet the following conditions:
- Validity: Not expired
- Version: V3
- Signature algorithm: sha224RSA, sha256RSA, sha384RSA, sha512RSA
- Key length: At least RSA (2,048 bits)
- 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) for production and cipher suites to access the platform
| CA | Root CA | Issuing CA (already authorized by us and from an authorized issuer) |
|---|---|---|
| DigiCert | DigiCert Assured ID Root G2 DigiCert Global Root G2 DigiCert TLS RSA4096 Root G5 | DigiCert Assured ID Client CA G2 DigiCert EV RSA CA G2 DigiCert G2 TLS EU RSA4096 SHA384 2022 CA1 DigiCert Global G2 TLS RSA SHA256 2020 CA1 GeoTrust G5 TLS RSA4096 SHA384 2022 CA1 GeoTrust TLS RSA CA G1 RapidSSL TLS RSA CA G1 |
| QuoVadis | QuoVadis Root CA 1 G3 QuoVadis Root CA 2 G3 | DigiCert QV TLS ICA G1 QuoVadis Qualified Web ICA G2 QuoVadis Swiss Advanced CA G4 |
| SwissSign | SwissSign Gold CA - G2 SwissSign RSA TLS Root CA 2022 - 1 | SwissSign RSA TLS EV ICA 2022 - 1 SwissSign RSA TLS OV ICA 2022 - 1 |
| 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 |
Additional certificates accepted for the testing environment
Let's Encrypt is a certificate authority that provides x.509 certificates for TLS encryption free. The certificates can be issued with the participants server by using the linked certbot or other ACME clients.
When using Let's Encrypt, the following must be considered:
- Certificate renewal should be automated in order to prevent adjustments of the participants configurations.
| CA | Root CA | Issuing CA (already authorized by us and from an authorized issuer) |
|---|---|---|
| Let's Encrypt | ISRG Root X1 ISRG Root X2 | R10 or R11 |
General Requirements
Validity of Certificates
Participants are responsible for monitoring the validity of the certificates. Renewed certificates must be sent to bLink for configuration before the existing certificate expires.
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.