> 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/es/referencia-de-la-api/seguridad/resumen-de-conectividad.md).
# Resumen de conectividad
Todas las APIs expuestas por Thales requieren **autenticación mutua TLS**, esto es válido tanto para API entrantes como salientes desde Thales.
La configuración de la conectividad TLS es el primer paso de la instalación y debe realizarse antes de la configuración de los servicios de Thales. El Servicio de Tokenización tiene un punto de enlace único para todas las APIs. Esto significa que la configuración de la conectividad TLS se realiza solo una vez para todos los servicios de Thales.
Como consumidor de las APIs, usted es conocido como un "**cliente**" o "**actor**" y como tal usted tiene un **identificador de cliente** dentro del Servicio de Tokenización. Este identificador es importante porque la conectividad TLS se configura de forma individual para cada **identificador de cliente**.
La conectividad TLS debe establecerse explícitamente para cada entorno, cada uno de ellos estando aislado:
* Preproducción
* Producción
Flujo entrante desde su host hacia Thales TSH
| Punto de enlace | Entorno |
| ------------------------------------------------------------------------------------------------- | -------- |
|
| Pre-Prod |
| [https://api.dbp.thalescloud.io](https://api.dbp.thalescloud.io/) | Prod |
Requerirá que la CA de Thales firme su certificado de cliente TLS para poder acceder a la API de TSH. Para ello, deberá proporcionar una Solicitud de Firma de Certificado (CSR) a su representante de Thales para su firma.
#### Requisitos generales:
1. Algoritmo: cifrado RSA con claves de 4096 bits o ECDSA P-256 y hashing SHA256.
2. Nombre común (CN): Thales aplica y verifica el formato y el valor. El valor debe seguir el patrón descrito en el paso 2 del ejemplo abajo.
#### Ejemplo de generación de CSR
Repita el siguiente procedimiento para cada uno de los entornos a los que apunte; preproducción y producción.
1. Genere un nuevo par de claves para su CSR, ya sea RSA o ECDSA.
Puede crear un par de claves RSA 4096 con el siguiente comando de OpenSSL:
```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."
```
Puede crear un par de claves ECDSA P-256 con los siguientes comandos de OpenSSL:
```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."
```
donde:
* *país* significa el país del emisor.
* *estado* significa el estado del emisor.
* *localidad* significa la localidad del emisor.
* *Nombre de la organización* debe ser el nombre de la organización emisora.
* *Unidad organizativa* debe ser la unidad organizativa emisora.
* *CN* significa Nombre Común.
* *tspId* es el id proporcionado por su representante de Thales.
* *env* es el entorno al que va dirigido este certificado. Para preproducción: `PPR`, para producción: `PRD`
* *ECDSA vs RSA* en el CN depende del tipo de clave.
{% hint style="info" %}
El backend del emisor debe resolver sistemáticamente el nombre de dominio de TSH y sus subdominios. Thales TSH no admite IPs estáticas a largo plazo y por esta razón, el cliente de Thales nunca debe configurar, codificar en duro o almacenar en caché direcciones IP de TSH por un período superior al Time To Live devuelto por el servidor de nombres de dominio.
{% endhint %}
Flujo saliente desde Thales TSH hacia su host
Requisitos generales:
1. Autenticación mutua
2. TLS 1.2 (o superior)
3. Su servidor debe ejecutar en el puerto 443 (o 8443, pero se prefiere 443)
4. A través de Internet (sin listas blancas de IP)
5. Debe confiar en la CA de Cliente de Thales para autenticar nuestro certificado de cliente. Nuestra CA de Cliente está disponible para descarga desde nuestro Portal TSH para Emisor y se intercambia manualmente para Comerciante. Si es necesario, Thales puede generar un nuevo par de claves para que lo firme el TSP.
6. Thales TSH debe confiar en el certificado de su servidor; para ello debe proporcionar la cadena de CA de su servidor para ser validada a través de nuestro Portal TSH para Emisor y se intercambia manualmente para Comerciante.
Debe aceptar únicamente nuestra CA de Cliente y no debe "anclar" el certificado de cliente. Nuestros certificados de cliente están firmados por nuestra CA de Cliente. TSH puede rotar su certificado de cliente en cualquier momento antes de su fecha de expiración sin previo aviso.
---
# 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/es/referencia-de-la-api/seguridad/resumen-de-conectividad.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.