Skip to Content
Technical Articles
Author's profile photo Abinash Nanda

HANA Cloud Integration (HCI) – Application Edition Learning Series – Part 5

In this blog we will look at the one of the most important aspects of any cloud based solution, Security. We will keep our focus limited to the transport layer security aspects which are relevant for using the pre-packaged content only. Security being a vast topic, we will cover in two posts. On this post we will talk about the client side security and on the next we will talk about server side security.


Client Side Security

Let’s first understand what client side security is, with a very simple example. Let’s take the example of any site which uses SSL.

Note: I am using Google Chrome bowser for this post, but the same is true for any browser.


The point of interest here is the green lock icon as shown above. The lock symbol states that the site using SSL and the green color states that browser has successfully established a secure connection with the site. Here the bowser is acting as a client and the site is the server (SSL provider). Now why does the browser trust the site? This is because browser trusts the root issuer certificate for the given site.

For example for this site the own certificate is the last entry *, which is issued by Google Internet Authority G2 (Intermediate authority), which in turn is signed by GeoTrust Global CA (Root certificate). Every client maintains a list of trusted root certification authority, in case of chrome (browser) this can be seen below


So for client to continue with the SSL handshake a very basic requirement is client must trust the root CA of the server certificate otherwise the SSL handshake will terminate on the client side with an error Peer certificate rejected by chain verifier or unable to find valid certification path to requested target.


Additionally in case of certificate based mutual authentication where client authenticates itself with a certificate, client certificate should be signed a CA which is in trust list of Server (In the next blog post we will look at the server side authentication). During a client authenticated SSL handshake in the negotiation phase Server presents a list of issuer (CA) it trusts and expects client certificate must be signed by one of the issuers from the list.


HCI (Certificate Based authentication)

Now with this basic understanding let’s now shift our focus to HCI. HCI acts as a client when it is sending request to a destination system example SAP Cloud for Customer or SAP Business suite systems (CRM or ERP).


We configure if HCI would use basic authentication or certificate based authentication in the receiver channel as shown below (here below I have used IDOC receiver adapter, but it holds true for all other adapters as well). By default receiver channel use client cert authentication, but in case we want to use basic authentication we need to select the check box Connect using Basic authentication (more on this a bit latter)



Now where we store the issuer certificates for the service provider for which HCI is the client.

On Every HCI tenant we can deploy a keystore artifact and this keystore contains HCI own keypair (key + Public certificate) and the list of trusted issuers. The public certificate from this keypair is used for client authentication. There can only be one key store per tenant and the default name is system.jks


Let’s examine the content of this key store (I am using a free software Portecle, but any other tool can be used as well)


Here we can see there is one own key (alias pioduser) and few trusted issuers. We can add any number of trusted CA’s but there can be only one key per keystore. Let’s assume HCI is consuming a C4C service at endpoint


With the key store as shown above if we try to send a message to this endpoint using HCI then we will get the following error: “unable to find valid certification path to requested target”


This is expected as HCI does not trust the issuer CA for the above service.


As shown above the C4C service is signed by issuer Cybertrust Public SureServer SV CA, which is in turn signed by Baltimore CyberTrust Root. So now we need to add the Baltimore CyberTrust Root cert to the HCI key store and redeploy.


Now if we send another message to the above endpoint using HCI, it should result in a success message.



Basic Authentication

In addition to Client certificate based authentication HCI PI also support basic authentication. For basic authentication we need to simply provide the username and password in the receiver communication channel. But the way we provide it is bit different in HCI

First we need to deploy an artifact type Basic authentication


And then we need to provide it a name and provide the authentication information (credentials) for the destination system


And as a last step provide this credential name in the receiver communication channel



Please keep in mind even if Basic authentication is used on receive channel still HCI needs to trust the endpoint to which it is sending the data, so the issuer CA needs to be maintained in the HCI key store.


That’s it for this post. In the next blog we will look at the Server side authentication. Watch out for this series and happy learning!!!




Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Ginger Gatling
      Ginger Gatling

      Great blog, Thanks, Abinash!!

      Author's profile photo Former Member
      Former Member

      Hi Abinash,

      Thanks for this blog serie this is very helpful!

      I have a quick question on the keystore. We don't seem to be able to retrieve it so we can use the keypair for a certificate based authentication with our on premise system.

      Could you clarify this part? How can we retrieve it or is it something Support will provide?



      Author's profile photo Vinay Avva
      Vinay Avva

      Hi Abinash

      Great Blog. We had issue with the Key store . After deploying the Key Store we solved the issue with the Keystore.

      Now when we are trying to access(download from Brower) the WSDL we are getting <faultcode>soap:Server</faultcode><faultstring>Unsupported Request Method GET</faultstring> , When I have certificate authentication in the iFlow.

      When I changed it to Basic I get <faultcode>soap:Server</faultcode><faultstring>Unauthorized</faultstring>

      Is this some thing to do with our Roles on the tenant. 

      When I try to access the WSDL through SOAP UI  I get

      WSDLException (at /soap:Envelope): faultCode=INVALID_WSDL: Expected element '{}definitions'.

      Please Help me out with this.

      Author's profile photo Ginger Gatling
      Ginger Gatling

      Meghna Shishodiya - do we publish a list of roles needed?   Can you help withthe WSDL question?

      Author's profile photo Vinay Avva
      Vinay Avva

      Hi Ginger,

      It is working now.  It is working now I'm able to view and execute the wsdl. The mistake I did was to have SAP RM as the Sender Message protocol, instead of SOAP 1.x. As soon I changed it it worked perfectly.



      Author's profile photo Former Member
      Former Member

      Hi Abinash,

      Thanks for this wonderful blog.

      Appreciate your efforts in building knowledge around. 🙂

      Best regards,

      Srivatsava J

      Author's profile photo Florian Preuß
      Florian Preuß

      Hi Abinash,

      your blog helps a lot in understanding the SSL topic. But I am facing an issue I am not able to track down.

      We are working with a SAP operated HCI and trying to get the connection to our customers reverse proxy done.

      The error in HCI we see is:

      Error          = Outbound processing in endpoint at failed with message "Could not send Message.", caused by "SunCertPathBuilderException:unable to find valid certification path to requested target"

      The whole discussion can be found in the following discussion.

      Thank you for any help.

      Best Regards


      Author's profile photo Former Member
      Former Member

      Abinash Nanda, you mention you're using Portecle to open the keystore. How did you determine which password to use to do so? If one adds another Root-CA to the keystore, does this mean the HCI instance would accept ssl connections initiated by servers initiated by a server (ERP in our case) with certificates signed by the new CA?

      Kind regards,


      Author's profile photo Abinash Nanda
      Abinash Nanda
      Blog Post Author

      Hi Niklas, You can obtain the key store password from HCI operations team.

      The key store ON HCI is used to maintain a list of Trusted CA's for outbound connection. i.e.HCI sending data to external server. For incoming connections CA list is maintained with HCI Load balancer.

      Best regards, Abinash