--- article_id: KB0394858 article_type: Support Note component_ids: - BNS-ARI-PUR - BNS-ARI-SC - BNS-ARI-SIPM - BNS-ARI-SS component_descriptions: - Compras - Contratos estratégicos - Gestión de la información y el rendimiento de los proveedores - Sourcing estratégico products: - SAP Ariba Procurement, cloud edition - SAP Ariba Sourcing, cloud edition language: es created: 2015-05-21 updated: 2022-04-02 source: Knowledge Base url: https://support.ariba.com/item/view/KB0394858_es connect_url: https://support.ariba.com/item/view/KB0394858_es?min=1 sap_for_me_url: https://me.sap.com/notes/KB0394858/es --- # Consejos para solucionar errores de autenticación de certificados con el kit de herramientas de integración (ITK) ## Resolución **Problema** Hay ocasiones en las que la herramienta de transferencia de datos (TDT) del kit de herramientas de integración (ITK) puede fallar al utilizar la autenticación basada en certificados con errores relacionados con SSL o fallos de establecimiento de comunicación. Esta solución está pensada para instancias ITK independientes instaladas en un servidor, no instaladas en SAP NetWeaver PI. **Causa** El problema suele deberse a que se utilizan cadenas de certificados incompletas o certificados incorrectos en el almacén de claves del cliente. Cuando se resuelva el problema, verifique lo siguiente: - Asegúrese de que el cliente utiliza certificados de clave pública/intermedios/raíz emitidos por una autoridad de certificación de confianza para Ariba. Los certificados autofirmados no se pueden utilizar con ITK y la autenticación basada en certificados. - Asegurarse de que el cliente haya activado el extremo en la aplicación Ariba para que sea un método de autenticación Certificado**,** (Upstream): **Gestionar > Administración > Administrador de integración > Seguridad del kit de herramientas de integración** (Downstream): **Gestionar > Administración central > Gestor de integración > Seguridad del kit de herramientas de integración** - En el archivo de opciones (.bat/.sh), asegúrese de que el parámetro urlPrefix esté establecido correctamente en [https://xxxxx/Sourcing/filedownload](https://xxxxx/Sourcing/filedownload) o [https://xxxxx/Buyer/fileupload](https://xxxxx/Buyer/fileupload), donde xxxxx sería uno de los sitios enumerados en la sección Información adicional y debe utilizarse según corresponda. Por ejemplo: set urlPrefix=[https://s1-integration.ariba.com/Sourcing/filedownload](https://s1-integration.ariba.com/Sourcing/filedownload) orr set urlPrefix=[https://s1-integration.ariba.com/Buyer/fileupload](https://s1-integration.ariba.com/Sourcing/filedownload) - En el archivo de opciones (.bat/.sh), asegúrese de que los siguientes parámetros están establecidos y no han sido comentados: clientKeystore clientKeystorePassword clientKeyPassword - Asegúrese de que el almacén de claves especificado en el parámetro clientKeystore contiene la clave privada del cliente y los certificados públicos que se utilizan para la comunicación SSL con Ariba (clave pública, intermedio, certificados raíz). - Si la publicación HTTPS falla, el cliente puede habilitar los siguientes parámetros en el archivo toolslib.bat/.sh en el directorio bin ITK para imprimir información de depuración relacionada con el cliente/servidor hola e información de establecimiento de comunicación: a) Vaya a \/bin b) Editar el archivo toolslib.bat/.sh c) Establezca los siguientes argumentos y guarde: **Windows**: set \_command="%JAVA\_HOME%\\bin\\java" **-Djavax.net.debug=ssl:handshake:verbose -Dhttps.orders=TLSv1.1,TLSv1.2 -Djdk.tls.client.celo="TLSv1.1,TLSv1.2" -jar "%CLASjar SESDIR%\\aribargetransferetransfere1.2"** -jar "%CLASjar SESDIR%\\aribargetransferetransferetransfers **Linux/Unix**: \_command="$JAVA\_HOME/bin/java **-Djavax.net.debug=\\"ssl:handshake:verbose\\" -Dhttps.celo=\\"TLSv1.1,TLSv1.2\\" -Djdk.tls.client.celo=\\"TLSv1.1,TLSv1.2\\" -ES.\\"$CLarix""TLSv1.1,TLSv1.2\\"** -ES\\"$CLaris" - La próxima vez que ITK se ejecute e intente publicar en Ariba, el registro mostrará la información del certificado/establecimiento de comunicación SSL. Verifique el Asunto, Emisor, Fechas de validez para los certificados encontrados para el keystore del cliente. Esta información debe imprimirse después de la entrada en el registro ITK en HTTPS posterior a la URL de Ariba. Compruebe que los certificados encontrados coincidan con la misma información de certificado de cliente que esperan estar en el almacén de claves. a) Se debe encontrar un certificado válido en el almacén de claves del cliente. Ejemplo: \*\*\*\*Ejecutando herramienta de transferencia de archivos en Wed Nov 11 13:22:54 PDT 2020\*\*\*\* contabilizando en https://certs1.ariba.com/Buyer/filedownload?realm=abcCompany \*\*\* ha encontrado una clave para: \ b) Se iniciará \*\*\* ClientHello, TLSv1 c) Se iniciará el \*\*\* ServerHello, TLSv1 y la clave pública de Ariba (cadena de certificados) se enviará al cliente d) Se debe encontrar un certificado de confianza e) El \*\*\* ClientKeyExchange, RSA PreMasterSecret, TLSv1 se iniciará cuando el cliente envíe el intercambio de claves firmado con la clave pública de Ariba f) Ariba descifra el PreMasterSecret. Este es el punto en el que si se produce un fallo, el usuario puede ver un error como el siguiente. Si es así, el problema puede estar en los certificados del almacén de claves: javax.net.ssl.SSLHandshakeException: Alerta fatal recibida: handshake\_fail **Información adicional** Los territorios válidos se enumeran a continuación, - service-2-eu.ariba.com - service-2-ru.ariba.com - s1-integration.ariba.com - certs1-integration.ariba.com - s3-integration.ariba.com - certs3-integration.ariba.com - s1-integration-eu.ariba.com - certs1-integration-eu.ariba.com - s1-integration-ru.ariba.com - certs1-integration-ru.ariba.com - service-2.ariba.com - certservice-2.ariba.com