--- article_id: KB0394858 article_type: Support Note component_ids: - BNS-ARI-PUR - BNS-ARI-SC - BNS-ARI-SIPM - BNS-ARI-SS component_descriptions: - Achats - Contrats stratégiques - Sourcing stratégique - Supplier Information and Performance Management products: - SAP Ariba Procurement, cloud edition - SAP Ariba Sourcing, cloud edition language: fr created: 2015-05-21 updated: 2022-04-02 source: Knowledge Base url: https://support.ariba.com/item/view/KB0394858_fr connect_url: https://support.ariba.com/item/view/KB0394858_fr?min=1 sap_for_me_url: https://me.sap.com/notes/KB0394858/fr --- # Conseils pour corriger les échecs d'authentification du certificat avec les outils d'intégration (ITK) ## Résolution **Problème** Il arrive que l'outil de transfert de données (DTT) Integration Toolkit (ITK) échoue lors de l'utilisation de l'authentification basée sur un certificat avec des erreurs autour de SSL ou des échecs de négociation. Cette solution est destinée aux instances ITK autonomes installées sur un serveur et non sur SAP NetWeaver PI. **Cause** Le problème est généralement dû à des chaînes de certificats incomplètes ou à l'utilisation de certificats incorrects dans le keystore du client. Lors de la correction des erreurs, vérifiez les points suivants : - Assurez-vous que le client utilise des certificats de clé publique/intermédiaires/racines émis par une autorité de certification approuvée par Ariba. Les certificats auto-signés ne peuvent pas être utilisés avec l'ITK et l'authentification basée sur un certificat. - Assurez-vous que le client a activé le point de terminaison dans l'application Ariba comme méthode d'authentification de **Certificat.** (En amont) : **Gérer > Administration > Gestionnaire d'intégration > Sécurité des outils d'intégration** (En aval) : **Gérer > Administration du système > Gestionnaire d'intégration > Sécurité des outils d'intégration** - Dans le fichier d'options (.bat/.sh), assurez-vous que le paramètre urlPrefix est correctement défini sur [https://xxxxx/Sourcing/filedownload](https://xxxxx/Sourcing/filedownload) ou [https://xxxxx/Buyer/fileual-name](https://xxxxx/Buyer/fileupload), où xxxxx est l'un des sites répertoriés dans la section Informations supplémentaires et doit être utilisé le cas échéant. Par exemple : 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) - Dans le fichier d'options (.bat/.sh), assurez-vous que les paramètres suivants sont définis et non commentés : clientKeystore clientKeystorePassword clientKeyPassword - Assurez-vous que le keystore indiqué dans le paramètre clientKeystore contient la clé privée et les certificats publics du client utilisés pour la communication SSL avec Ariba (clé publique, intermédiaire, certificats racine). - Si la publication HTTPS échoue, le client peut activer les paramètres suivants dans le fichier toolslib.bat/.sh du répertoire bin ITK pour imprimer les informations de débogage concernant le bonjour client/serveur et les informations de handshake : a) Accédez à \/bin b) Modifier le fichier toolslib.bat/.sh c) Définissez les arguments suivants et sauvegardez : **Windows**: set \_command="%JAVA\_HOME%\\bin\\java" **-Djavax.net.debug=ssl:handshake:verbose -Dhttps.protocoles=TLSv1.1,TLSv1.2 -Djdk.tls.client.protocoles="TLSv1.1,TLSv1.2"** -jar "%CLASSESDIR%\\aribafiletransfere.jar" **Linux/Unix**: \_command="$JAVA\_HOME/bin/java **-Djavax.net.debug=\\"ssl:handshake:verbose\\" -Dhttps.protocoles=\\"TLSv1.1,TLSv1.2\\" -Djdk.tls.client.protocoles=\\"TLSv1.1,TLSv1.2\\"** -jar\\ \\"$CLASESSil.SilR"$CLASESSilR" - La prochaine fois que l'ITK s'exécutera et tentera de l'envoyer à Ariba, le journal affichera les informations de certificat/établissement de liaison SSL. Vérifiez l' objet, l' émetteur et les dates de validité pour le(s) certificat(s) trouvé(s) pour le keystore du client. Ces informations doivent être imprimées après l'entrée dans le journal ITK à HTTPS après l'URL Ariba. Vérifiez que le(s) certificat(s) trouvé(s) correspond(nt) aux informations de certificat client attendues dans le keystore. a) Un certificat valide doit être trouvé dans le keystore du client. Exemple : \*\*\*\*Exécution de l'outil de transfert de fichiers le mercredi 11 nov. 13:22:54 PDT 2020\*\*\*\* publication sur https://certs1.ariba.com/Buyer/filedownload?realm=abcCompany \*\*\* Clé trouvée pour : \ b) Le \*\*\* ClientHello, TLSv1 sera initié c) Le \*\*\* ServerHello, TLSv1 sera lancé et la clé publique Ariba (chaîne de certificats) sera envoyée au client d) Un certificat de confiance doit être trouvé e) Le \*\*\* ClientKeyExchange, RSA PreMasterSecret, TLSv1 sera lancé lorsque le client enverra l'échange de clés signé avec la clé publique Ariba f) Ariba décrypte le PreMasterSecret. Il s'agit du point où, en cas d'échec, l'utilisateur peut voir une erreur comme suit. Si c'est le cas, le problème peut résider avec les certificats dans le keystore : javax.net.ssl.SSLHandshakeException : Alerte fatale reçue : handshake\_error **Informations supplémentaires** Les domaines valides sont répertoriés ci-dessous, - 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