> 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/es/integrar-la-api-de-d1-transit/configurar-autenticacion-mutua-tls.md).

# Configurar autenticación mutua TLS

Todas las APIs expuestas por el servidor D1 Transit requieren autenticación mutua TLS; esto es válido tanto para las llamadas API entrantes como para las salientes desde el servidor D1 Transit.

Como consumidor de las APIs de D1 Transit, se le conoce como un "**emisor**" y, como tal, tiene un **identificador de emisor** asignado dentro de la plataforma D1. Este identificador es importante porque la conectividad TLS se configura individualmente para cada **identificador de emisor**.

Hay dos entornos de D1, preproducción y producción, que están aislados entre sí. Debe establecer la conectividad TLS explícitamente para cada uno de ellos.

### Flujo desde el emisor Transit hacia Thales <a href="#flow-from-transit-issuer-to-thales" id="flow-from-transit-issuer-to-thales"></a>

<figure><img src="/files/e655c0e9c3f17688748937206f11b28012c159d2" alt=""><figcaption></figcaption></figure>

Requisitos generales:

1. Autenticación mutua
2. TLS 1.2+ (se prefiere TLS 1.3)
3. A través de Internet

{% hint style="info" %}
Thales aplica lista blanca de IP
{% endhint %}

4. CA del servidor Thales: firmada por la CA de Amazon
5. Certificado de cliente del emisor Transit: firmado por la CA de Thales

**Certificados de cliente**

Debe solicitar a la CA de Thales que firme su certificado de cliente TLS para poder acceder a las APIs de D1 Transit. Para ello, debe proporcionar una Solicitud de Firma de Certificado (CSR) a su representante de Thales para su firma.

**Requisitos generales:**

1. Algoritmo: claves ECDSA P-256 y hash SHA256.
2. Nombre común (CN): el formato y el valor están impuestos y verificados por Thales. El valor deberá seguir el patrón que se describe a continuación.

**Ejemplo de generación de CSR**

* Genere un nuevo par de claves para su CSR de tipo ECDSA.

Puede crear un par de claves ECDSA P-256 con los siguientes comandos de OpenSSL:

```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=<país>/ST=<estado>/L=<localidad>/O=<organizaciónDelEmisor>/OU=<unidadOrganizativaDelEmisor>/CN=TLSMA-ECDSA\/<issuerId>\/TSH/TRANSIT.<env>"

```

Donde:

* *Nombre de la organización* debe ser el nombre de la organización del emisor.
* *Unidad organizativa* debe ser la unidad organizativa del emisor.
* *CN* significa Nombre común.
* *issuerId* es el id que le proporciona su representante de Thales.
* *env* es el entorno al que va dirigido este certificado. Para el entorno de pruebas: `REL/QA1`, para preproducción: `PPR`, para producción: `PRD`

{% hint style="info" %}
El backend del emisor Transit debe resolver sistemáticamente el nombre de dominio Thales D1 y sus subdominios. La plataforma D1 de Thales no admite IPs estáticas a largo plazo y, por esta razón, el cliente de Thales nunca debe configurar, codificar de forma rígida ni almacenar en caché direcciones IP durante un período superior al Time To Live devuelto por el Servidor de Nombres de Dominio.
{% endhint %}

### Flujo desde Thales hacia el emisor Transit <a href="#flow-from-thales-to-transit-issuer" id="flow-from-thales-to-transit-issuer"></a>

<figure><img src="/files/0935f80af2505b611202b76882296131edb4bf97" alt=""><figcaption></figcaption></figure>

#### Requisitos generales: <a href="#general-requirements-2" id="general-requirements-2"></a>

1. Autenticación mutua
2. TLS 1.2+ (se prefiere TLS 1.3)
3. A través de Internet

{% hint style="info" %}
Thales aplica lista blanca de IP
{% endhint %}

4. Debe confiar en la CA de cliente de Thales para autenticar el certificado de cliente MTLS presentado por la plataforma D1 de Thales (la CA de cliente de Thales se compartirá con usted durante el proceso de incorporación) O debe proporcionar su cadena de CA de cliente durante el proceso de incorporación
5. La plataforma D1 de Thales confiará en su certificado de servidor. Para ello, debe proporcionar la cadena de CA de su servidor durante el proceso de incorporación.


---

# 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/es/integrar-la-api-de-d1-transit/configurar-autenticacion-mutua-tls.md?ask=<question>&goal=<endgoal>
```

`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.
