--- article_id: KB0394858 article_type: Support Note component_ids: - BNS-ARI-PUR - BNS-ARI-SC - BNS-ARI-SIPM - BNS-ARI-SS component_descriptions: - Supplier Information & Performance Management - Закупуване - Стратегически договори - Стратегическо ресурсно осигуряване products: - SAP Ariba Procurement, cloud edition - SAP Ariba Sourcing, cloud edition language: bg created: 2015-05-21 updated: 2022-04-02 source: Knowledge Base url: https://support.ariba.com/item/view/KB0394858_bg connect_url: https://support.ariba.com/item/view/KB0394858_bg?min=1 sap_for_me_url: https://me.sap.com/notes/KB0394858/bg --- # Съвети за отстраняване на неизправности при проверка на автентичност на сертификат с набор инструменти за интеграция (ITK) ## Разрешение **Проблем** Има моменти, в които Integration Toolkit (ITK) Data Transfer Tool (DTT) може да се провали при използване на удостоверяване, базирано на сертификат, с грешки около SSL или неуспешно ръкостискане. Това решение е предназначено за самостоятелни инстанции на ITK, инсталирани на сървър, които не са инсталирани на SAP NetWeaver PI. **Причина** Проблемът обикновено се дължи на непълни вериги сертификати или неправилни сертификати, които се използват в хранилището за ключове на клиента. При отстраняване на неизправности, моля, проверете следното: - Уверете се, че клиентът използва публични/междинни/основни сертификати, издадени от сертифициращ орган, доверен от Ariba. Самоподписаните сертификати не може да се използват с удостоверяване на база на ITK и сертификат. - Уверете се, че клиентът е активирал метода за удостоверяване на сертификат за крайната точка в приложението Ariba**,** (Upstream): **Управление > Администрация > Мениджър на интеграция > Сигурност на набор инструменти за интеграция** (Downstream): **Управление > Основна администрация > Мениджър на интеграция > Сигурност на набор инструменти за интеграция** - Във файла с опции (.bat/.sh) се уверете, че за параметъра urlPrefix е зададено правилно [https://xxxxx/Sourcing/filedownload](https://xxxxx/Sourcing/filedownload) или [https://xxxxx/Buyer/fileupload](https://xxxxx/Buyer/fileupload), където xxxxx ще бъде един от сайтовете, изброени в раздела Допълнителна информация и трябва да се използва според случая. Например: задаване на 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) - Във файла с опции (.bat/.sh) се уверете, че следните параметри са зададени и некоментирани: clientKeystore clientKeystorePassword clientKeyPassword - Уверете се, че хранилището за ключове, посочено в параметъра clientKeystore, съдържа личния ключ на клиента и публичните сертификати, използвани за SSL комуникацията с Ariba (публичен ключ, междинен, основен сертификат). - Ако HTTPS публикацията е неуспешна, клиентът може да активира следните параметри в файла toolslib.bat/.sh в директорията на ITK bin, за да отпечата информация за дебъгиране по отношение на информация за клиент/сървър и информация за ръкостискане: a) Отиди до \/място б) Редактиране на файла toolslib.bat/.sh в) Задайте следните аргументи и запазете: **Windows**: set \_command="%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 "%CLASSSDIR%\\aribilethansferjar. **Linux/Unix**: \_command="$JAVA\_HOME/bin/java **-Djavax.net.debug=\\"ssl:handshake:verbose\\" -Dhttps.protocols=\\"TLSv1.1,TLSv1.2" -Djdk.tls.client.protocols=\\"TLSv1.TLSv1.2" -jar \\"$CLASSSDIR/aribilet\_resfilet\_residetfer1"** -jar \\ - Следващият път, когато ITK се изпълнява и прави опит за осчетоводяване в Ariba, журналът ще показва информацията за SSL ръкостискането/сертификата. Проверете темата, издателя, датите на валидност за сертификата(ите), намерени за хранилището на ключове на клиента. Тази информация трябва да се отпечата след записа в ITK журнала към HTTPS осчетоводяване в URL адреса на Ariba. Проверете дали намерените сертификати съответстват на информацията за клиентския сертификат, която очакват да бъдат в хранилището за ключове. а) Трябва да се намери валиден сертификат от хранилището на ключове на клиента. Пример: \*\*\*\*Изпълнение на инструмент за пренос на файлове в Wed Nov 11 13:22:54 PDT 2020\*\*\*\* осчетоводяване в https://certs1.ariba.com/Buyer/filedownload?област=abcCompany \*\*\* намерен ключ за : \ б) Ще бъде инициирано \*\*\* ClientHello, TLSv1 в) Ще бъде иницииран \*\*\* ServerHello, TLSv1 и публичният ключ на Ariba (верига сертификати) ще бъде изпратен на клиента г) Трябва да се намери доверен сертификат д) ClientKeyExchange, RSA PreMasterSecret, TLSv1 ще се инициира, когато клиентът изпрати обмена на ключове, подписан с публичния ключ на Ariba. е) Ariba декриптира PreMasterSecret. Това е точката, в която ако възникне грешка, потребителят може да види грешка като следната. Ако е така, проблемът може да лежи със сертификатите в хранилището за ключове: javax.net.ssl.SSLHandshakeException: Получено фатално предупреждение: handshake\_failure **Допълнителна информация** Валидните области са изброени по-долу, - 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