> 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/transit-digitization/integrate-d1-transit-api/set-up-tls-mutual-authentication.md).
# 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
{% hint style="info" %}
Thales applies IP Whitelisting
{% endhint %}
4. Thales server CA: signed by Amazon CA
5. 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:
```bash
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=/ST=/L=/O=/OU=/CN=TLSMA-ECDSA\/\/TSH/TRANSIT."
```
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`
{% hint style="info" %}
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.
{% endhint %}
### Flow from Thales to Transit Issuer
#### General requirements:
1. Mutual Authentication
2. TLS 1.2+ (TLS 1.3 preferred)
3. Over the internet
{% hint style="info" %}
Thales applies IP whitelisting
{% endhint %}
4. 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
5. Thales D1 platform will trust your server certificate. For this you must provide your server CA chain during the onboarding process.
---
# 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/transit-digitization/integrate-d1-transit-api/set-up-tls-mutual-authentication.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.