Skip to Content

This blog describes how to setup secure outbound connections with client certificates using the keystore monitor (available with 24-June-2017 release (2.29*)) for maintaining the keys and certificates in the cloud integration system. It gives a step by step description what needs to be configured where. Furthermore, test options are described for testing outbound connectivity.

Setup Secure Outbound HTTP Connection using Keystore Monitor

A typical task in an integration project is to connect remote systems to the SAP Cloud Integration Tenant. Before going into detailed configuration of the outbound communication lets first have a short look at the basics.

Basics of Secure System Configuration

The remote system can act either as a sender or a receiver of messages. The setup and the detailed configuration procedure differ according to the communication direction that is being set up: whether a remote system is supposed to send a message to the integration platform or the other way round.

For more detailed information about the different authentication and authorization options refer to the SAP Cloud Platform Integration Documentation, section ‘Connecting a Customer System to Cloud Integration’.

As Secure inbound communication does not need a keystore we focus only on the outbound communication in this blog. Inbound Communication is described in blog ‘How to setup secure HTTP Inbound Communication’.

Secure Outbound Communication

For HTTPS based outbound communication with client certificate authentication, keys and certificates have to be maintained in the receiver system and in the cloud integration tenant keystore.

Configure Connection in Receiver and Cloud Integration Tenant

Download Root Certificate from Receiver System

For HTTPS based communication the receiver system needs to have a private key and its certificate chain, which typically consists of the server certificate and the intermediate certificate. The intermediate certificate is signed by a CA’s root certificate. The integration tenant trusts the backend server if the CA’s root certificate is available in its keystore.

For the configuration as a first step this root certificate needs to be downloaded from receiver system or provided by the receiver system administrator to add it to the cloud integration tenant in the next step.

Configurations in Cloud Integration Tenant

For HTTPS based communication in the cloud integration tenant, the root certificate of the receiver system provided in previous step is needed in the cloud integration tenant’s keystore. Furthermore, for using client certificate authentication, a signed key pair including complete certificate chain is required in the cloud integration tenant’s keystore.

Maintain Keystore in Keystore Explorer

As the first version of the Keystore Monitor is not able to import single certificates or keys the root certificate of the backend and the signed private key including certificate chain have to be maintained in an external keystore maintenance tool, for example the Keystore Explorer.

As all newly provisioned cloud integration tenants already have a private key pair pre-delivered by SAP, which you can use this for your communications. But, if required, you can also create your own private key pairs for the cloud integration tenant as described in detail in SAP Cloud Platform Integration Documentation in chapter ‘Creating X.509 keys’.

To add the root certificate of the receiver systems private key, open an existing keystore in Keystore Explorer or create a new keystore. Easiest is to just create a new one, select JCEKS as type for the new keystore.

Under Tools select Import Trusted Certificate and add the root certificate of the receiver backend. Give it an alias in the customer namespace; you are not allowed to use aliases with prefix sap_, hcicertificate and hcimsgcertificate. More information about the naming conventions can be found in blog ‘How to use Keystore Monitor to maintain your keys and certificates’.

Add additional certificates, if required, and save the keystore with a password as .jks file. Remember the password as this will be needed during import in Keystore Monitor.

Import Keystore in Keystore Monitor

To import the created keystore file open the Keystore Monitor available in the Operations View in Web in section Manage Security. All certificates and private key pairs contained in the tenant keystore are shown, the ones pre-delivered by SAP cannot be changed.

Upload the keystore via Add button on the top of the monitor. Browse the *.jks file and enter the password you gave in previous step. The root certificates contained in the keystore file will be added to the existing entries for owner Tenant Administrator with the aliases used in Keystore Explorer.

More information about maintaining keys and certificates in Keystore Monitor, about migration of existing keystores into the new monitor and about existing naming conventions can be found in blog ‘How to use Keystore Monitor to maintain your keys and certificates’.


To maintain keys and certificates in Keystore Monitor your user needs the Group Role AuthGroup.Admin or Single Roles, and

Download Certificate Chain from Keystore Monitor

For client certificate based authentication at the receiver system the root certificate and the client certificate of the cloud integration tenants private key are needed in the receiver system. For this, export the certificate chain of the private key pair in the Keystore Monitor. This option is available as single line option, select Download from the actions Button in the line of the private Key Pair.

Download for a Key Pair will create a file with the name <alias>.p7b in the download directory. The file contains the whole certificate chain assigned to the private key. The certificate chain file can, for example, be opened with the Certificates Snap-in of Microsoft Management Console (Certmgr.msc), which is usually available on Windows systems.

Open the downloaded <alias>.p7b file with the Certificates Snap-in on your system and open the tab Certificate Path. There, the whole certificate chain can be seen.

The entry on the top is the root certificate. Open the root certificate via double click. This will open the root certificate. In the tab Details export the root certificate into a file via Copy to File. In the Certificate Export Wizard export the root certificate as DER encoded binary X.509 file. Use any arbitrary file name to save the certificate as *.cer file.


The same way you exported the root certificate, also export the client certificate, which is the one at the bottom of the certificate chain.

Both certificates need to be imported into the receiver system in the next step.


To download entries from Keystore Monitor your user needs the Group Role AuthGroup.IntegrationDeveloper or Single Roles and

Import Certificates to Receiver System

For outbound communication using client certificate authentication, in the receiver system the root certificate and the client certificate of the cloud integration tenant’s private key are to be imported into the backend.

For this, import the root certificate retrieved in previous step into the trust store of the receiver system. In addition, you normally need to import the client certificate into a user to certificate mapping in the receiver backend.

With this last step the configuration of the outbound communication using client certificates is completed. To test the connectivity, continue as described below.

Alternative configuration options

Beside the recommended and most used configuration option to have the whole certificate chain including the root CA certificate assigned to the server’s private key available in the server keystore and only the root certificate in the client’s trust store, there are other configuration options possible with which the client can establish a trust relation to the server:

  • If the server keystore contains only the server certificate including intermediate certificate, the client keystore also needs to contain only the root certificate in its keystore.
  • If the server keystore contains only the server certificate without the certificate chain the client keystore needs to contain the intermediate and root certificate.
  • If the server uses a self-signed certificate the client keystore needs to contain this certificate.

Similar options are possible when the server has to trust the client certificate in the client certificate authentication use case.

Connectivity Test

After setting up the connection toward the backend system, the connectivity test feature can be used to test the communication or even to download server certificates.

TLS Connectivity Test

The Connectivity Test is available in Operations View in Web, in section Manage Security Material. Selecting the Connectivity Test tile from Overview Page will open the test tool offering tests for different protocols. To test the HTTPS based outbound communication the TLS option is to be selected.

Enter the address of your cloud backend (Tests to On-Premise backends via cloud Connector cannot be done) as used in the outbound channel and execute the test. The test will give a success message or an error with detailed error information.

If there is an error with the SSL connectivity it is possible to execute the test without the option to Validate Server Certificate. In this case the server certificate is not checked, but can be downloaded via Download Button and added to the keystore in Keystore Monitor as described in the above chapter.

Client Certificate based authentication can be checked via option Authenticate with Client Certificate. It is possible to enter a specific alias contained in the keystore or to leave the field empty, in this case the first alias fitting to the server request will be used.



To report this post you need to login first.


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

  1. Former Member

    For a not too technical guy this is hard to read, especially the term receiver system etc is unclear to me – whether the receiver system refers to SAP ERP, AEAT or to the HCI tenant. I would prefer to read a step by step instruction specifically naming the receiver system.

    What confuses me in addition is the use of some terms like certificate, root certificate and certificate chain.

    Again, maybe I am not the intended audience but I couldn’t do the keystore maintenance with this, sorry.



    1. Mandy Krimmel Post author



      thank you for your feedback. But I think for someone knowing cloud integration and doing system integration using cloud integration the terms certificate, root certificate and certificate chain should be familiar. It is not the goal of this blog to explain such basic terms.

      Receiver system can be any external system called from cloud integration, this is also a very known term in cloud integration, where you configure the Receiver system in the integration flow.



  2. Former Member

    Hi Mandy,

    I’ve done the steps follow your posting, but I have the following information when perform the connection test for ‘TLS’. The scenario is from a HCI (Demo) to one of internal SAP system (with port 44311).

    The error message show as following: ” connect timed out (local port 57753 to address (, remote port 44311 to address “.

    Could you kindly advise the potential cause for this error and how to resolve it? Thanks!

    Best regards,

    Radar Lei

    1. Mandy Krimmel Post author



      this error looks like some port needs to be opened. Please open a BCP ticket on component LOD-HCI-PI-OPS with the detailed information configured in your outbound channel.

      Best regards,


  3. Former Member

    HI Mandy,

    My receiver system is SuccessFactors and I want to build a client certificate based connection between HCI to SuccessFactors.

    I have SuccessFactors certificates, could you please explain me step by step how to build a connection between both the system.


    Thanks & regards,






    1. Mandy Krimmel Post author



      I would expect this is described step by step in the specific success factors scenario setup guide. In general the steps mentioned above are necessary, except that the certificates for the HTTPS connection to the SuccessFactors System should already be available in the CPI Keystore and do not need to be imported.

      Best regards,


  4. Gabor Szigeti

    Hi Mandy,

    Thank you for the great post, I find it really helpful.

    Two questions:
    – In our tenant keystore there are no Key Pair entries from Owner=SAP with a small lock icon. I assumed those entries are pre-delivered and also locked. Note that our tenant is ~2 years old. In your other post I read about the migration of old keystores following v2.29, currently we are on build 2.34.6 but the SAP owned entries are not there.

    – On Test Connectivity I select “Authenticate with Client Certificate”, enter the host name, port, and the alias (validate server certificate is also checked): the conection test is successful (“successfully reached host…”), the server certificates are also displayed, still it says “Client Certificate Used: NO” without any errors. What can be the problem? Is the selected Alias wrong or target host must explicitly require client certificate authentication?

    Thanks for your help in advance,



    1. Mandy Krimmel Post author


      Hello Gabor,

      do you have key pairs that fit to the SAP naming convention, hcicertificate or sap_? Normally these key pairs are then maintained by SAP. There is one exception; if you deployed the keystore on your own on the tenant without asking Cloud Operations, you are responsible for these keys.

      Do you have SAP owned certificates in the keystore? This would mean the migration took already place.

      Concerning the connectivity test: if the server does not require client certificate it will not be be used. The target host should require client certificate authentication.



  5. Jens Schwendemann
    Thanks Mandy for the detailed and very(!) helpful blog. Obviously I stilly got coupple of questions 🙂 I am planning to integrated two backend On-Prem systems (SAP ERP and SAP BW) via CPI to C4C.
    1. In your paragraph “Maintain Keystore in Keystore Explorer” you mentioned that one could use the pre-delivered private key pair. I suppose you mean the one under alias “hcicertificate”?
    2. However, if I use that in C4C, only one technical user (there’s a 1:1 relationship between communciation system and technical user of that system in C4C) will be found, when connecting via that certificate from CPI to C4C. Would I then need another private key pair as mentioned in the “Maintain Keystore in Keystore Explorer” paragraph?
    3. If so, would that private key pair really needed to be signed with an CA which is allowed by SAP? That then would be a list which C4C (or it’s pre-settled load balancers) would issue, not the one found here, right?
    4. Or would it be wise for my initial problem to just skip all this and use the method of creating and downloading a PKCS#12 file from C4C and import that to CPI?
    Many thanks and kind regards
    1. Mandy Krimmel Post author


      Hi Jens,

      let me try to answer.

      1. yes
      2. If the receiver backend expects a unique certificate/user for each sender system that sends messages via CPI, then yes, you would need an additional key pair. But this you should confirm with the C4C colleagues, as this depends on the requirements of the receiver backend.
      3. yes, it should be signed by a CA, that is allowed by C4C
      4. This is up to you, you can also import private keys to CPI via the keystore monitor via import keystore option. In future, you will be able to directly import key pairs.

      Best regards,



Leave a Reply