Skip to Content

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.

/wp-content/uploads/2014/07/5_1_490554.png

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 *.google.com, 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

/wp-content/uploads/2014/07/5_2_490599.png

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)

/wp-content/uploads/2014/07/5_3_490600.png


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

/wp-content/uploads/2014/07/5_4_490598.png

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)


/wp-content/uploads/2014/07/5_5_490604.png

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 https://vf4-cust234.dev.sapbydesign.com/sap/bc/srt/scs/sap/materialreplicationinitiatedby


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”

/wp-content/uploads/2014/07/5_11_490605.png

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

/wp-content/uploads/2014/07/5_6_490606.png

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.

/wp-content/uploads/2014/07/5_7_490610.png

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

/wp-content/uploads/2014/07/5_12_490611.png


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

/wp-content/uploads/2014/07/5_8_490612.png

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

/wp-content/uploads/2014/07/5_9_490613.png

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

/wp-content/uploads/2014/07/5_10_490614.png


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!!!




To report this post you need to login first.

9 Comments

You must be Logged on to comment or reply to a post.

  1. Jean-Baptiste Steiner

    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?

    Thanks,

    JB.

    (0) 
  2. 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 ‘{http://schemas.xmlsoap.org/wsdl/}definitions’.

    Please Help me out with this.

    (0) 
      1. 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.

        regards,

        Vinay

        (0) 
  3. Florian Preuss

    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 https://customer.reverseproxy.com:443/sap/bc/srt/idoc?sap-client=310 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.

    http://scn.sap.com/thread/3730723


    Thank you for any help.


    Best Regards

    Florian

    (0) 
  4. Niklas Fischer

    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,

    Niklas

    (0) 
    1. Abinash Nanda 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

      (0) 

Leave a Reply