Skip to Content
Technical Articles

Understanding the role of Ignore Client Certificate flag while invoking API/ODATA services on SAP S/4HANA On-Premise system using SAP Intelligent RPA

As an SAP Intelligent RPA Bot developer, while invoking API/ODATA services using ctx.ajax method, you might have come across the Client Certificate Authentication issues for the SAP S/4 HANA On-Premise Systems.

This blog post helps you to understand the role of the Ignore Client Certificate flag used while invoking API/ODATA service. This flag sets certain conditions to verify the client.

Before diving into the technical details, let’s first understand the different types of client verification configuration in the SAP S/4HANA On-Premise systems. While invoking an API call, a server can have different methods of verifying the client. In the case of SAP S/4HANA On-Premise systems, you can set the method of verifying the client using the “icm/HTTPS/verify_client” parameter.

Parameter Name Value Description Bot Run
icm/HTTPS/verify_client 0 No certification is required, and the server does not ask for one. Always Supported
icm/HTTPS/verify_client 1 The server asks the client to produce a certificate. If the client does not send a certificate, authentication is carried out by another method, for example, basic (default setting). Supported if value IGNORE_CLIENT_CERT set to ‘True’
icm/HTTPS/verify_client 2 The client must transfer a valid certificate to the server, otherwise, access is denied. Not Applicable
Note: Currently the SAP Intelligent RPA process bot does not have any mechanism to provide client certificate when the icm/HTTPS/verify_client is set to ‘2’.

 

If icm/HTTPS/verify_client is set to ‘1’ and the API is invoked without adding the flag ignoreClientCertificate as ‘true’ in the ctx.ajax call parameter, the status after the call will be ‘0’. This means, either client is unauthorized or an error occurred while verifying the client.

How does the flag ignoreCientcertificate works?

SAP Intelligent RPA has two implementations for invoking an API:

  1. With ignoreClientCertificate set as ‘false’ – Uses ActiveXObject call to invoke the API. This implementation is added to the Javascript SDK.
  2. With ignoreClientCertificate set as ‘true’ – Uses WinHttp call to invoke the API. This implementation is added to the C++ component of the SDK.

 

 

If the server requests the certificate but does not require it, the application can specify this option to indicate that it does not have a certificate. The server can choose another authentication scheme or allow anonymous access to the server.

The application provides the WINHTTP_NO_CLIENT_CERT_CONTEXT macro in the lpBuffer parameter of WinHttpSetOption.

In the C++ implementation, the same mechanism is used to inform the server that the client doesn’t have any client certificate and to proceed with basic authentication to verify the client.

If the server requires a client certificate, it may send a 403 HTTP status code in response.

Note: The ignoreClientCertificate flag does not bypass any security checks. The flag only uses the implementation in which the server is configured to decide the requirement of client certificate authentication.

 

Let’s look at the sample GET and POST calls using ignoreClientCertificate flag:

Ajax GET Call

ctx.ajax.call({
      url: url,
      method: 'GET',
      contentType: "application/json",
      headers: headers,
      ignoreClientCertificate: true,
      success: function(res, status, xhr) {
             var xCSRF = xhr.headers["x-csrf-token"];
             var cookies = xhr.headers["Set-Cookie"]; 

      },
      error: function(xhr, status, statusText) {
            ctx.log('error') 
});

Ajax POST Call

var headers = {};
headers["Authorization"] = "Basic " + ctx.base64.encode('USER' + ':' + ‘PASS’);
headers["Accept"] = "application/json";
headers["x-csrf-token"] = xCSRF;
headers["Cookie"] = cookies;             //Setting cookie is mandatory in this scenario

ctx.ajax.call({
      url: url,
      method: 'POST',
      contentType: "application/json",
      data: ctx.json.stringify(data),
      headers: headers,
      ignoreClientCertificate: true,
      success: function(res, status, xhr) {
            ctx.log('success') 
      },
      error: function(xhr, status, statusText) {
            ctx.log('error') 
      }
});

 

Note: Setting the cookie in the request header is mandatory if you are using the flag ignoreClientCertificate as true. 

 

You might have noticed that even after using ignoreClientCertificate as ‘true’ for SAP S/4HANA On-Premise systems, the API doesn’t work and send a response status code as ‘12175’ and status message as ‘A security error occurred’. This means that the SAP S/4HANA On-Premise system does not have a valid SSL certificate installed which is signed by a valid certifying authority. Hence, the SAP Intelligent RPA cannot verify the server and sets the response as ERROR_WINHTTP_SECURE_FAILURE. 

Hope this blog post will help you solve the most common certificate issues while running a bot on SAP S/4HANA On-Premise Systems.

Please feel free to post your comments. Also, if you have come across any other issues related to client certificate authentication, do share your questions and concerns.

 

More Information about the SAP S/4HANA template bots, check out the following links:

SAP Best Practices Explorer: SAP Best Practices for SAP Intelligent Robotic Process Automation Integration with SAP S/4HANA

SAP Intelligent RPA store:  here

Release Note: 2788986 – Release Strategy for SAP Intelligent Robotic Process Automation Store for SAP S/4HANA

Stay tuned to know more about the SAP S/4HANA template bots.

/
2 Comments
You must be Logged on to comment or reply to a post.
  • Thanks for sharing Amit Sharma

    I have seen community questions where the suggestions were given to implement the same ajax call using curl to work around this issue. This blog gives the real root cause but also clarifies that using Curl is not the solution. Right?

    Thanks

    SR

    • Hello Srinivas,

      Yes, this blog gives the root cause, and curl was a workaround which we were using initially. Instead of curl, we can use the ajax call with ignoreClientcertificate flag as mentioned in the blog.