Connectivity

All Thales APIs require mutual TLS (mTLS) authentication. This applies to both inbound and outbound APIs.

TLS setup is the first integration step. Complete it before configuring any Thales services. The Tokenization Service uses a single endpoint per environment for all its APIs.

As an API consumer, you are a customer. You have a customer identifier in the Tokenization Service. TLS connectivity is set up per customer identifier.

TLS connectivity must be established explicitly for each isolated environment:

• Pre-Production

• Production

mTLS connectivity overview between the issuer backend and Thales TSH.

Inbound flow (issuer backend → Thales TSH)

Once established, the TLS connection is used for all APIs. The endpoint depends on the Thales service you are calling.

Your customer client certificate (self-signed) must be endorsed (certificate pinning) in Thales backend. This endorsement is done through the Thales portal.

General requirements:

1. Mutual Authentication

2. TLS 1.2 (or higher)

3. Over the internet (no IP whitelisting)

4. Thales server CA : Digicert SHA2 High Assurance server CA

5. Customer client certificate must be a self-signed certificate with following requirement (see below)

Self-signed certificate requirements:

1. Expiry date 2 years maximum

2. Algorithm: elliptic curve with key size 256-bits or key size 384-bits or RSA 2048 bits algorithm sha256. Elliptic curve is preferred to RSA. Supported curve are prime256v1 and secp384r1.

3. Common Name : format and value is enforced and checked by Thales, the value that you should use (per environment) will be provided to you within the D1 Portal.

The issuer backend must always resolve the TSH domain name and its subdomains using DNS.

Thales TSH does not support long-term static IP addresses. Do not configure, hardcode, or cache TSH IP addresses longer than the DNS time-to-live (TTL).

Outbound flow (Thales TSH → issuer backend)

General requirements:

1. Mutual authentication.

2. TLS 1.2 or later.

3. Your server must listen on port 443 (preferred) or 8443.

4. Over the public internet (no IP whitelisting).

5. You must trust Thales Client CA to authenticate our client certificate. Our Client CA is available for download from our D1 Portal for Issuer.

6. Thales D1 must trust your server certificate, for this you must provide your server CA Chain to be endorse through our D1 Portal for Issuer.

Trust only the Thales client CA, and do not pin the client certificate. Thales client certificates are signed by the Thales client CA. Thales may rotate its client certificate at any time before expiration, without notice.

Certificate exchange is managed through the TSH portal as follows:

Certificate exchange flow in the TSH portal.

Use the credentials provided by the Thales delivery team to access the portal: TSH portal

This table summarizes the assets exchanged through the portal for TLS setup:

ASSET	DESCRIPTION
TSH_TLS_SERVER_CERTIFICATE_CHAIN	Thales TSH server certificate chain. Trust it to establish a TLS connection from the issuer backend to Thales TSH.
TSH_TLS_CLIENT_CERTIFICATE	Thales TSH client certificate. Trust it to accept TLS connections from Thales TSH to the issuer backend.
TSH_INBOUND_HOST	Thales TSH hostname to call. Use it with the API base path.
CUSTOMER_TLS_SERVER_CERTIFICATE_CHAIN	Your server certificate chain. Thales TSH uses it to trust your server certificate and establish a TLS connection to the issuer backend.
ISSUER_HOST	Issuer backend hostname. Thales TSH uses it with the API base path to call the issuer backend.