> For the complete documentation index, see [llms.txt](https://docs.payments.thalescloud.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.payments.thalescloud.io/xpay-enablement/api-reference/security/connectivity-overview.md).
# Connectivity overview
All APIs exposed by Thales require to go **TLS mutual authentication**, this is valid for incoming as well as for outgoing API from Thales.
TLS connectivity setup is the first step of the setup and it needs to be performed before the configuration of the Thales services. The Tokenization Service has a unqiue endpoint for all APIs. It means that TLS connectivity setup is done only once for all Thales services.
As a consumer of the APIs, you are known as a "**customer**" or "**actor**" and as such you have a **customer identifier** within Tokenization Service. This identifier is important because the TLS connectivity is setup individually for each **customer identifier**.
TLS connectivity must be establish explicitely for each environment, each of them being isolated :
* Pre-production
* Production
Incoming Flow from your host to Thales TSH
| Endpoint | Environment |
| ------------------------------------------------------------------------------------------------- | ----------- |
|
| Pre-Prod |
| [https://api.dbp.thalescloud.io](https://api.dbp.thalescloud.io/) | Prod |
You will require the Thales CA to sign your TLS client certificate in order to access the TSH API. To do this, you will have to provide a Certificate Signing Request (CSR) to your Thales representative for signature.
#### General requirements:
1. Algorithm: RSA encryption with 4096-bit or ECDSA P-256 keys and SHA256 hashing.
2. Common Name (CN): format and value are enforced and checked by Thales. The value should follow the pattern described in step 2 of the example below.
#### Example CSR Generation
Repeat the following procedure for each one of the environments you target; pre-production and production.
1. Generate a new key pair for your CSR either RSA or ECDSA.
You can create a RSA 4096 key pair with the following OpenSSL command:
```shellscript
openssl req -new -newkey rsa:4096 -nodes -keyout private_rsa.key -out issuer_pp.csr -subj "/C=/ST=/L=/O=/OU=/CN=TLSMA-RSA\/\/TSH\/TSP."
```
You can create an ECDSA P-256 key pair with the following OpenSSL commands:
```shellscript
openssl ecparam -name prime256v1 -genkey -noout -out tsh-mtls-client-cert.key
openssl req -new -key tsh-mtls-client-cert.key -out tsh-mtls-client-cert.csr -subj "/C=/ST=/L=/O=/OU=/CN=TLSMA-ECDSA\/\/TSH.\/TSP."
```
where:
* *country* means issuer country.
* *state* means issuer state.
* *locality* means issuer localitity.
* *Organization Name* must be the issuer organization name.
* *Organizational Unit* must be the issuer organization unit.
* *CN* means Common Name.
* *tspId* is the id provided to you by your Thales representative.
* *env* is the environment targeted by this certificate. For pre-production: `PPR`, for production: `PRD`
* *ECDSA vs RSA* in CN depends on key type.
{% hint style="info" %}
The issuer backend must systematically resolves the TSH domain name and its subdomains. Thales TSH doesn’t support long term static IPs and for this reason, Thales customer must never configure, hardcode, or cache TSH IP addresses for a period higher than the Time To Live returned by the Domain Name Server.
{% endhint %}
Outgoing Flow from Thales TSH to your host
General requirements:
1. Mutual Authentication
2. TLS 1.2 (or higher)
3. Your server must run on port 443 (or 8443, but 443 is preferred)
4. Over the 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 TSH Portal for Issuer and manually exchanged for Merchant. If required, Thales can generate a new key pair to be signed by the TSP.
6. Thales TSH must trust your server certificate, for this you must provide your server CA Chain to be endorse through our TSH Portal for Issuer and manually exchanged for Merchant.
You must endorse only our Client CA, and you must not "pin" the client certificate. Our client certificate are signed by our Client CA. TSH may rotate its client certificate any time before their expiry date without notice to you.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.payments.thalescloud.io/xpay-enablement/api-reference/security/connectivity-overview.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.