--- article_id: KB0394858 article_type: Support Note component_ids: - BNS-ARI-PUR - BNS-ARI-SC - BNS-ARI-SIPM - BNS-ARI-SS component_descriptions: - Einkauf - Strategische Beschaffung - Strategische Verträge - Supplier Information and Performance Management products: - SAP Ariba Procurement, cloud edition - SAP Ariba Sourcing, cloud edition language: de created: 2015-05-21 updated: 2022-04-02 source: Knowledge Base url: https://support.ariba.com/item/view/KB0394858_de connect_url: https://support.ariba.com/item/view/KB0394858_de?min=1 sap_for_me_url: https://me.sap.com/notes/KB0394858/de --- # Tipps zur Fehlerbehebung bei Zertifikatsauthentifizierungsfehlern mit dem Integrations-Toolkit (ITK) ## Lösung **Problem** Es gibt Zeiten, in denen das Integration Toolkit (ITK) Data Transfer Tool (DTT) fehlschlagen kann, wenn die zertifikatsbasierte Authentifizierung mit Fehlern bezüglich SSL oder Handshake-Fehlern verwendet wird. Diese Lösung ist für eigenständige ITK-Instanzen gedacht, die auf einem Server installiert sind, nicht auf SAP NetWeaver PI. **Ursache** Das Problem wird in der Regel dadurch verursacht, dass unvollständige Zertifikatsketten oder falsche Zertifikate im Keystore des Kunden verwendet werden. Prüfen Sie bei der Fehlerbehebung Folgendes: - Stellen Sie sicher, dass der Kunde Public-Key-/Intermediate-/Root-Zertifikate verwendet, die von einer von Ariba vertrauenswürdigen Zertifizierungsstelle ausgestellt wurden. Selbstsignierte Zertifikate können nicht mit der ITK- und zertifikatsbasierten Authentifizierung verwendet werden. - Stellen Sie sicher, dass der Kunde den Endpunkt in der Ariba-Anwendung als Authentifizierungsmethode Zertifikat aktiviert hat**.** (Upstream): **Verwalten > Administration > Integrations-Manager > Integrations-Toolkit-Sicherheit** (Downstream): **Verwalten > Ariba Administrator > Integrations-Manager > Integrations-Toolkit-Sicherheit** - Stellen Sie in der Optionsdatei (.bat/.sh) sicher, dass der Parameter urlPrefix korrekt auf [https://xxxxx/Sourcing/filedownload](https://xxxxx/Sourcing/filedownload) oder [https://xxxxx/Buyer/fileupload](https://xxxxx/Buyer/fileupload) gesetzt ist, wobei xxxxx eine der im Abschnitt Zusätzliche Informationen aufgeführten Sites wäre und entsprechend verwendet werden muss. Beispiel: 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) - Stellen Sie in der Optionsdatei (.bat/.sh) sicher, dass die folgenden Parameter gesetzt und nicht kommentiert sind: clientKeystore clientKeystorePassword clientKeyPassword - Stellen Sie sicher, dass der im Parameter clientKeystore angegebene Keystore den privaten Schlüssel und die öffentlichen Zertifikate des Kunden enthält, die für die SSL-Kommunikation mit Ariba verwendet werden (öffentlicher Schlüssel, Zwischenzertifikat, Stammzertifikat). - Wenn der HTTPS-Post fehlschlägt, kann der Kunde die folgenden Parameter in der Datei toolslib.bat/.sh im ITK-bin-Verzeichnis aktivieren, um Debug-Informationen bezüglich der Client-/Server-Hallo und Handshake-Informationen zu drucken: a) Navigieren Sie zu \/bin. b) Bearbeiten Sie die Datei toolslib.bat/.sh. c) Legen Sie die folgenden Argumente fest, und sichern Sie: **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 "%CLASSESDIR%\\afaribiletransfer.jar" **Linux/Unix**: \_command="$JAVA\_HOME/bin/java **-Djavax.net.debug=\\"ssl:handshake:verbose\\" -Dhttps.protocols=\\"TLSv1.1,TLSv1.2\\" -Djdk.tls.client.protocols=\\"TLSv1.1,TLSvfer1.2\\" -jar \\"$CLASils.client.protocols=\\"TLSv1.1,.jfer1.2\\" -jar \\"$CLASils.SEilcols**" - Wenn das ITK das nächste Mal ausgeführt wird und versucht, an Ariba zu senden, zeigt das Protokoll die SSL-Handshake-/Zertifikatsinformationen an. Prüfen Sie Inhaber, Aussteller und Gültigkeitsdaten für die Zertifikate, die für den Keystore des Kunden gefunden wurden. Diese Informationen sollten nach dem Eintrag im ITK-Protokoll zum HTTPS-Post an die Ariba-URL gedruckt werden. Prüfen Sie, ob die gefundenen Zertifikate mit denselben Client-Zertifikatsinformationen übereinstimmen, die sie im Keystore erwarten. a) Im Keystore des Clients sollte ein gültiges Zertifikat gefunden werden. Beispiel: \*\*\*\*Ausführen des Dateiübertragungstools am Mittwoch, 11. Nov. 13:22:54 PDT 2020\*\*\*\* Buchung auf https://certs1.ariba.com/Buyer/filedownload?realm=abcCompany \*\*\* Schlüssel gefunden für : \ b) Der \*\*\* ClientHello, TLSv1 wird initiiert. c) Der \*\*\* ServerHello, TLSv1 wird initiiert, und der öffentliche Ariba-Schlüssel (Zertifikatskette) wird an den Client gesendet. d) Es sollte ein vertrauenswürdiges Zertifikat gefunden werden. e) Der \*\*\* ClientKeyExchange, RSA PreMasterSecret, TLSv1 wird initiiert, wenn der Client den mit dem öffentlichen Ariba-Schlüssel signierten Schlüsselaustausch sendet. f) Ariba entschlüsselt das PreMasterSecret. Dies ist der Punkt, an dem der Benutzer beim Auftreten eines Fehlers einen Fehler wie den folgenden sehen kann. Wenn dies der Fall ist, kann das Problem bei den Zertifikaten im Keystore liegen: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake\_failure **Zusätzliche Informationen** Die gültigen Bereiche sind unten aufgeführt. - 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