TLS Certificates
All connections between the bLink API platform, Third-Party Providers (TPPs), and Financial Institutions (FIs) are encrypted using Transport Layer Security (TLS) 1.2 or higher and strong cipher suites. bLink verifies all requests from TPPs against their certified use cases, and only admissible requests are forwarded to the FI. As a result of the certification process, TPPs get authorized for the certified use cases.
In the bLink ecosystem, connections are mutually authenticated through mutual TLS, whereas the TPPs 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 TPPs 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 networks, FinanceIP or 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: Client authentication
- Issuer: Trusted Certificate Authority (CA) (some examples listed below)
- Type: Single Domain OV or Single Domain EV (No wildcard or multi-domain)
- 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.
Examples of 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 Assured ID Root G3 DigiCert Global Root G3 DigiCert Trusted Root G4 | DigiCert Global CA G2 RapidSSL TLS RSA CA G1 RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1 DigiCert TLS RSA SHA256 2020 CA1 GeoTrust TLS DV RSA Mixed SHA256 2020 CA-1 |
| SwissSign | SwissSign Silver CA SwissSign Gold CA - G2 SwissSign Platinum CA - G2 | SwissSign EV Gold CA 2014 |
| 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:
- Wildcard certificates are not allowed.
- 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 | R3 |
| Let's Encrypt | ISRG Root X2 | R3 |
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.