Set up TLS mutual authentication

All APIs exposed by D1 Transit server require TLS mutual authentication, this is valid for incoming as well as for outgoing API calls from D1 Transit server.

As a consumer of D1 Transit APIs, you are known as an "issuer" and as such you have an issuer identifier assigned within D1 platform. This identifier is important because the TLS connectivity is setup individually for each issuer identifier.

There are two D1 environments, pre-production and production, which are isolated from each other. You need to establish TLS connectivity explicitly for each one of them.

Flow from Transit Issuer to Thales

General requirements:

1. Mutual Authentication
2. TLS 1.2+ (TLS 1.3 is preferred)
3. Over the internet

Thales applies IP Whitelisting

1. Thales server CA: signed by Amazon CA
2. Transit issuer client certificate: signed by the Thales CA

Client Certificates

You have to request the Thales CA to sign your TLS client certificate in order to access the D1 Transit APIs. To do so, you have to provide a Certificate Signing Request (CSR) to your Thales representative for signature.

General requirements:

1. Algorithm: ECDSA P-256 keys and SHA256 hashing.
2. Common Name (CN): format and value are enforced and checked by Thales. The value shall follow the pattern described below.

Example CSR Generation

• Generate a new key pair for your CSR ECDSA type.

You can create an ECDSA P-256 key pair with the following OpenSSL commands:

openssl ecparam -name prime256v1 -genkey -noout -out d1-mtls-client-cert.key
openssl req -new \
-key d1-mtls-client-cert.key \
-out d1-mtls-client-cert.csr \
-subj "/C=<country>/ST=<state>/L=<locality>/O=<Issuer Organization>/OU=<Issuer Organization Unit>/CN=TLSMA-ECDSA\/<issuerId>\/TSH/TRANSIT.<env>"

Where:

• Organization Name must be the issuer organization name.
• Organizational Unit must be the issuer organization unit.
• CN means Common Name.
• issuerId is the id provided to you by your Thales representative.
• env is the environment targeted by this certificate. For test environment: REL/QA1, for pre-production: PPR, for production: PRD

The Transit issuer backend must systematically resolves Thales D1 domain name and its subdomains. Thales D1 platform doesn't support long term static IPs and for this reason, Thales customer must never configure, hardcode, or cache IP addresses for a period higher than the Time To Live returned by the Domain Name Server.

Flow from Thales to Transit Issuer

General requirements:

1. Mutual Authentication
2. TLS 1.2+ (TLS 1.3 preferred)
3. Over the internet

Thales applies IP whitelisting

1. You must either trust the Thales Client CA to authenticate the MTLS client certificate presented by Thales D1 platform (The Thales Client CA will be shared with you during the onboarding process) OR you must provide your client CA chain during the onboarding process
2. Thales D1 platform will trust your server certificate. For this you must provide your server CA chain during the onboarding process.