--- 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 - Sourcing estratégico - Supplier Information & Performance Management products: - SAP Ariba Procurement, cloud edition - SAP Ariba Sourcing, cloud edition language: pt-br created: 2015-05-21 updated: 2022-04-02 source: Knowledge Base url: https://support.ariba.com/item/view/KB0394858_pt-br connect_url: https://support.ariba.com/item/view/KB0394858_pt-br?min=1 sap_for_me_url: https://me.sap.com/notes/KB0394858/pb --- # Dicas para solucionar falhas de autenticação de certificado com o kit de ferramentas de integração (ITK) ## Resolução **Problema** Existem momentos em que a ferramenta de transferência de dados (TDT) do kit de ferramentas de integração (ITK) pode falhar ao usar a autenticação baseada em certificado com erros em torno de SSL ou falhas de handshake. Esta solução destina-se a instâncias ITK independentes instaladas em um servidor, não instaladas no SAP NetWeaver PI. **Causa** O problema é normalmente devido a cadeias de certificados incompletas ou certificados incorretos sendo usados na keystore do cliente. Ao solucionar problemas, verifique o seguinte: - Certifique-se de que o cliente está usando certificados de chave pública/intermediária/raiz emitidos por uma autoridade certificadora confiável pela Ariba. Os certificados autoassinados não podem ser usados com o ITK e a autenticação baseada em certificado. - Certifique-se de que o cliente ativou o ponto de extremidade no aplicativo Ariba para ser um método de autenticação de **Certificado,** (Upstream): **Gerenciar > Administração > Gerenciador de integração > Segurança do kit de ferramentas de integração** (Downstream): **Gerenciar > Administração principal > Gerenciador de integração > Segurança do kit de ferramentas de integração** - No arquivo de opções (.bat/.sh), certifique-se de que o parâmetro urlPrefix esteja definido corretamente como [https://xxxxx/Sourcing/filedownload](https://xxxxx/Sourcing/filedownload) ou [https://xxxxx/Buyer/fileupload](https://xxxxx/Buyer/fileupload), em que xxxxx seria um dos sites listados na seção Informações adicionais e deve ser usado conforme apropriado. Por exemplo: defina 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) - No arquivo de opções (.bat/.sh), certifique-se de que os seguintes parâmetros estão definidos e não comentados: clientKeystore clientKeystorePassword Senha da chave do cliente - Certifique-se de que o keystore especificado no parâmetro clientKeystore contém a chave privada do cliente e os certificados públicos que estão sendo usados para a comunicação SSL com Ariba (chave pública, intermediária, certificados-raiz). - Se a publicação HTTPS estiver falhando, o cliente pode habilitar os seguintes parâmetros no arquivo toolslib.bat/.sh no diretório ITK bin para imprimir informações de depuração sobre as informações de cliente/servidor hello e handshake: a) Vá para \/bin b) Edite o arquivo toolslib.bat/.sh c) Defina os seguintes argumentos e salve: **Windows**: set \_command="%JAVA\_HOME%\\bin\\java" **-Djavax.net.debug=ssl:handshake:verbose -Dhttps.protocolos=TLSv1.1,TLSv1.2 -Djdk.tls.client.protocolos="TLSv1.1,TLSv1.2"** -jar "%CLASSESDIR%\\aribafiletransfer.jar" %args " **Linux/Unix**: \_command="$JAVA\_HOME/bin/java **-Djavax.net.debug=\\"ssl:handshake:verbose\\" -Dhttps.protocolos=\\"TLSv1.1,TLSv1.2\\" -Djdk.tls.client.protocolos=\\"TLSv1.1,TLSv1.2\\"** -jar \\"$CLASSESDIeDIariR" - Na próxima vez que o ITK for executado e tentar publicar na Ariba, o registro mostrará as informações de handshake/certificado SSL. Verifique o Assunto, Emissor, Datas de validade para o(s) certificado(s) encontrado(s) para o keystore do cliente. Essas informações devem ser impressas após a entrada no registro ITK para HTTPS postar no URL da Ariba. Verifique se os certificados encontrados correspondem às mesmas informações de certificado do client que esperam que estejam no keystore. a) Um certificado válido deve ser encontrado na keystore do cliente. Exemplo: \*\*\*\*Executando ferramenta de transferência de arquivos na qua Nov 11 13:22:54 PDT 2020\*\*\*\* lançamento em https://certs1.ariba.com/Buyer/filedownload?realm=abcCompany \*\*\* chave encontrada para: \ b) O \*\*\* ClientHello, TLSv1 será iniciado c) O \*\*\* ServerHello, TLSv1 será iniciado e a chave pública da Ariba (cadeia de certificados) será enviada ao cliente d) Um certificado confiável deve ser encontrado e) O \*\*\* ClientKeyExchange, RSA PreMasterSecret, TLSv1 será iniciado onde o cliente envia a troca de chaves assinada com a chave pública da Ariba f) A Ariba descriptografa o PreMasterSecret. Este é o ponto em que, se ocorrer uma falha, o usuário poderá ver um erro como o seguinte. Em caso afirmativo, o problema pode estar com os certificados na keystore: javax.net.ssl.SSLHandshakeExceção: alerta fatal recebido: handshake\_failure **Informações adicionais** Os realms válidos estão listados abaixo, - 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