REST channel error - HTTP/1.0 500 Internal Server Error

[former_member637026]

Hi Experts,

>Our scenario is SAP(Proxy)>PI>Third party external system(REST API). We are on PO 7.4. The flow is a synchronous flow.

>We have created a REST receiver channel with POST as the http operation to fetch the response. We are sending an xml message with some data as the request to get the response back from the API. Both input and output message structures are xml for the REST API.

>The API is an application on SSL. The API is https://**************

>We have imported the public certificate of the third party system in PI TrustedCA's. But PI public certificate is not imported in the third party server. For REST receiver channel, all configuration looks good but we are getting the below error when the "use client certificates" is not checked in channel:

MP: exception caught with cause com.sap.aii.adapter.rest.ejb.common.exception.HttpCallException: HTTP POST call to https://************************************ was not successful. HTTP/1.0 500 Internal Server Error

>We then imported the public certificate of the third party system in PI SSL keystore. But PI public certificate is not imported in the third party server. The "use client certificates" is checked in channel and pointed to the SSL keystore, we are getting the below error:

com.sap.aii.adapter.rest.ejb.security.SSLException: SSL enabled call failed. Cannot create secure socket excess private key

We are using the header parameters in the "Use HTTP Headers" tab in REST channel. We are able to hit the API successfully from SOAP UI(using the same cert we have imported in PI) and getting the response back. The same set of working header parameters we have configured in the REST channel as well.

Could someone please help me why we are getting this error? Are we missing something?

Thanks in advance, Surya

[JaySchwendemann]

One second, you are asking that over and over again?

[former_member815869]

I am getting same com.sap.aii.adapter.rest.ejb.common.exception.HttpCallException: HTTP POST call to https:<REST API> was not successful. HTTP/1.0 500 Internal Server Error error.

Did you find solution for this?

[former_member637026]

Hi Jens,

Thank you for your inputs. You can ignore the ICM_SSL* view n all, we were trying all those configurations to check if REST API connection works that way.

Below is the current config in PI:

>As per the 3rd party system, their public cert should be sufficient for authentication. They have confirmed that from PI no need of using any username and password. They also said there is no need of importing PI public cert on their server. According to them other clients are able to connect just using 3rd party public cert so even PI should be able to connect.

>We have imported their public cert in PI TrustedCA’s already.

>From SOAP UI we are able to hit the REST API successfully and get the response back properly.

In SOAP UI we are using the same cert and some HTTP header parameters. The same request/response xml structures and HTTP header parameters are configured in PI as well.

>Below is the PI config screen shots:

>We are currently on PO 7.4

>In PI we are getting this error:

com.sap.aii.adapter.rest.ejb.common.exception.HttpCallException: HTTP POST call to https:<REST API> was not successful. HTTP/1.0 500 Internal Server Error

>Below is the network level log for calls from PI,due to this error the call is not reaching 3rd party.:

https:<REST API> -> Authorization failed, Neither Client Certificate nor SAML Assertion present

Kindly help me with you inputs/suggestions.

Thanks, Surya

[JaySchwendemann]

Ok, I think you are mixing up different concepts here. To get your ducks in a row, please answer / follow along this:

1. Ask / determine how you would authenticate against the 3rd party server. If it is an API that is publically available it's most certainly not via client certificate but via basic auth or OAuth
2. Assuming it is basic auth
   - you will need to import the servers public key (the server's certificate in lay man's terms) into your PI's "TrustedCAs" keystore view. NOT! into the ICM_SSL* view
   - the 3rd party server will not need to have your PI's public key imported in it's system. You are client. You have to trust the server in this configuration, not the other way around
   - the "SSL enabled call failed. Cannot create..." error message is just a red herring. Concentrate on the former HTTP 500 error which means you are authenticated to the 3rd party server and it's more of a "wrong data, wrong endpoint" kind of error (5xx status codes)
3. If it is really client certificate based auth (mutual auth)
   - You need to have a private key (most of the times not the PI server own private key within ICM_SSL* view but a private key in a separate (to be created) keystore view
   - This private key is either created via CSR from within that view or imported into it
   - The 3rd party server then must import that certificate's public key

[former_member637026]

Hi Jens,

I wasn't able to comment on your inputs so added all info as the answer.

Thanks, Surya

[JaySchwendemann]

Commenting to the answer https://answers.sap.com/answers/13131884/view.html below:

They have confirmed that from PI no need of using any username and password. They also said there is no need of importing PI public cert on their server [...] From SOAP UI we are able to hit the REST API successfully and get the response back properly

So there's no authentication at all? That is kind of strange. Do you when you hit the Service using SoapUI go through any pre-configuration steps like getting OAuth token?

Are you in a different network segment / using a different outgoing IP Adress when making the call from your soapUI in contrast to when making the call from the server?

--> Please ask the service provider about authentication and authorization. Please ask them if network restrictions apply (with HTTP 500 that does not seem likely though)

 In SOAP UI we are using the same cert and some HTTP header parameters. The same request/response xml structures and HTTP header parameters are configured in PI as well

--> Make use of a "man in the middle" like fiddler or use an "HTTP examination endpoint" like r_herrmann described here https://blogs.sap.com/2020/04/10/how-to-sniff-sap-cpi-and-sap-po-request/. Then you might see if PI sends the header like you would expect

Authorization failed, Neither Client Certificate nor SAML Assertion present

--> You might want to look into SAML Bearer Assertion Flow within Rest Receiver adapter then. Please first check with service provider if that is really what they want for authentication.

[former_member637026]

Hi Jens,

Thank you for your inputs. PFB:

So there's no authentication at all? That is kind of strange. Do you when you hit the Service using SoapUI go through any pre-configuration steps like getting OAuth token?

I apologize, want to correct info I provided – it is actually not third party, the REST server is also residing inside company network (on premise).

As per the target system, only cert should be sufficient for authentication.

In SOAP UI as well NO pre-configuration like OAuth is done. It’s just the client cert we used along with HTTP headers.

Are you in a different network segment / using a different outgoing IP Adress when making the call from your soapUI in contrast to when making the call from the server?

SOAP UI is in my machine, which is in the same company network. No different IP is used.

Telnet to REST server from PI OS level is done, connection works. Ping from my machine to REST server also works.

https:<REST API> -> Authorization failed, Neither Client Certificate nor SAML Assertion present

Target team checked on logs of traffic from PI, they say the call coming from PI is not having any cert with it and hence it is not getting authenticated.

In PI we have already imported cert in TrustedCA’s, not sure why call going out from PI doesn’t have any cert. PI XPI logs says:

Make use of a "man in the middle" like fiddler or use an "HTTP examination endpoint"

I am checking on this, not sure if we r allowed to download this app in company network.

Thanks, Surya

[JaySchwendemann]

Ok, this is quite a different scenario from the one initially described. However, it seems some things are clearing up. I'm in a hurry, so this is only a quick one:

• Seems you are really having to do mutual authentication then
• You would then need a client certificate (as already described, generate an csr and let it be signed by the service provider or, as it is internal, by an internal PKI or have an well-known-CA trusted certificate). Ask the service provider team what they prefer
• That client certificates goes to a separate key store
• reference that keystore in the receiver channel
• check use-client-certificates in receiver channel
• try again while having an xpi inspectore trace running

Cheers

[former_member637026]

Hi Jen,

W opened a SAP incident for this issue.

The connection was erroring out due to mismatch in TLS versions. SAP PO 7.4 supports only TLS 1.0 whereas the system we were trying to connect supports only TLS 1.2

So SAP suggested that we can not have this integration unless we upgrade to SAP PO 7.5 which supports TLS 1.2

Thanks for all your inputs, Surya