---
article_id: KB0394858
article_type: Support Note
component_ids:
  - BNS-ARI-PUR
  - BNS-ARI-SC
  - BNS-ARI-SIPM
  - BNS-ARI-SS
component_descriptions:
  - Achiziții
  - Contracte strategice
  - Sourcing strategic
  - Supplier Information & Performance Management
products:
  - SAP Ariba Procurement, cloud edition
  - SAP Ariba Sourcing, cloud edition
language: ro
created: 2015-05-21
updated: 2022-04-02
source: Knowledge Base
url: https://support.ariba.com/item/view/KB0394858_ro
connect_url: https://support.ariba.com/item/view/KB0394858_ro?min=1
sap_for_me_url: https://me.sap.com/notes/KB0394858/ro
---

# Recomandări pentru depanarea erorilor de autentificare a certificatului cu trusa de instrumente de integrare (ITK)

## Rezolvare

**Problemă**

Există momente în care Instrumentul de transfer de date (TDT) al trusei de unelte de integrare (ITK) poate eșua atunci când se utilizează autentificarea bazată pe certificat cu erori în jurul SSL sau a erorilor de strângere de mână. Această soluție este destinată instanțelor ITK autonome instalate pe un server, care nu sunt instalate pe SAP NetWeaver PI.

**Cauză**

Problema se datorează, de obicei, lanțurilor de certificate incomplete sau utilizării de certificate incorecte pe keystore-ul clientului.

La depanare, verificați următoarele:

- Asigurați-vă că clientul utilizează certificate de cheie publică/intermediare/rădăcină care sunt emise de o autoritate de certificare de încredere Ariba. Certificatele autosemnate nu pot fi utilizate cu ITK și cu autentificarea bazată pe certificat.
- Asigurați-vă că clientul a activat punctul final din aplicația Ariba ca metodă de autentificare a **certificatului,**

  (Upstream): **Gestionare > Administrare > Manager de integrare > Securitate trusă de unelte de integrare**  
  (Downstream): **Gestionare > Administrare de bază > Manager de integrare > Securitate trusă de unelte de integrare**
- În fișierul de opțiuni (.bat/.sh), asigurați-vă că parametrul urlPrefix este setat corect la [https://xxxxx/Sourcing/filedodownload](https://xxxxx/Sourcing/filedownload) sau [https://xxxxx/Buyer/fileuLoad](https://xxxxx/Buyer/fileupload), unde xxxxx ar fi unul dintre site-urile listate în secțiunea Informații suplimentare și trebuie utilizat după caz. De exemplu: setare 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)
- În fișierul de opțiuni (.bat/.sh), asigurați-vă că următorii parametri sunt setați și nu sunt comentați:  
  clientKeystore  
  clientKeystorePassword  
  clientKeyPassword
- Asigurați-vă că keystore-ul specificat în parametrul clientKeystore conține cheia privată a clientului și certificatele publice utilizate pentru comunicarea SSL cu Ariba (cheie publică, certificate intermediare, rădăcină).
- Dacă postarea HTTPS eșuează, clientul poate activa următorii parametri în fișierul toolslib.bat/.sh din directorul coșului ITK pentru a tipări informațiile de depanare privind salutul clientului/serverului și informațiile de strângere de mână:

  a) Salt la \<ITK\_install\_root>/bin  
  b) Editați fișierul toolslib.bat/.sh  
  c) Stabiliți următoarele argumente și salvați:

  **Windows**: set \_order="%JAVA\_HOME%\\bin\\java" **-Djavax.net.debug=ssl:handshake:verbose -Dhttps.protocols=TLSv1.1,TLSv1.2 -Djdk.tls.client.protocols="TLSv1.1,TLSv1.2" -jar "%CLASSESDIR%\\aribafilejar%"TLSv1.TLSv1.2"** -jar "%CLASSESDIR%\\aribafilejar%

  **Linux/Unix**: \_order="$JAVA\_HOME/bin/java **-Djavax.net.debug=\\"ssl:handshake:verbose\\" -Dhttps.protocols=\\"TLSv1.1,TLSv1.2\\" -Djdk.argt.client.protocols=\\"TLSv1.1,TLSv1.2\\" -jar $R"$CLSASaris.client.protocols=\\"TLSv1.1.TLSv1.2\\" -jar $\\"$CLSASaris.CLSASjar**"\\
- Data viitoare când ITK execută și încearcă să publice în Ariba, jurnalul va afișa informațiile despre handshake-ul/certificatul SSL.

  Verificați Subiect, Emitent, Termene de valabilitate pentru certificatele găsite pentru keystore-ul clientului. Aceste informații trebuie tipărite după intrarea din jurnalul ITK la publicarea HTTPS în URL-ul Ariba. Verificați dacă certificatele găsite corespund cu aceleași informații de certificat de client pe care le așteaptă să fie în keystore.

  a) Trebuie găsit un certificat valabil de la keystore al clientului.  
  Exemplu:  
  \*\*\*\*Running File Transfer Tool at Wed Nov 11 13:22:54 PDT 2020\*\*\*\*  
  înregistrare la https://certs1.ariba.com/Buyer/filedownload?domeniu=abcCompany  
  \*\*\*  
  cheie găsită pentru : \<clients\_keystore>

  b) Va fi inițiat \*\*\* ClientHello, TLSv1  
  c) Va fi inițiat \*\*\* ServerHello, TLSv1 și cheia publică Ariba (lanțul de certificate) va fi trimisă clientului  
  d) Trebuie găsit un certificat avizat  
  e) \*\*\* ClientKeyExchange, RSA PreMasterSecret, TLSv1 vor fi inițiate acolo unde clientul trimite schimbul de chei semnat cu cheia publică Ariba  
  f) Ariba decriptează PreMasterSecret. Acesta este punctul în care, dacă apare o eroare, utilizatorul poate vedea o eroare precum următoarea. Dacă da, problema poate apărea în certificatele din keystore: javax.net.ssl.SSLHandshakeExcepție: Primită alertă fatală: handshake\_fail

**Informații suplimentare**

Domeniile valide sunt enumerate mai jos,

- 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
