Skip to Content
Technical Articles

Cloud Integration – How to Setup Secure HTTP Inbound Connection with Client Certificates

This blog describes how to setup secure inbound communication using client certificates, it describes the different configuration options available and gives a step by step description what needs to be configured where.

Setup Secure HTTP Inbound Connection with Client Certificates

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 inbound 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 Integration Documentation, section ‘Connecting a Customer System to Cloud Integration’.

This blog focuses on inbound communication. Outbound communication configuration is described in blogHow to Setup Secure Outbound HTTP Connection using Keystore Monitor’.

Secure Inbound Communication

For HTTPS based communication towards Cloud Integration Tenant no keystore in the Integration tenant needs to be maintained. Sender system and Load Balancer need to get the certificates and keys configured as described below. In Integration Tenant only certificates for Client Certificate based authorization are to be maintained, either in Certificate-to-User Mapping or directly in the integration flow.


Configurations in Sender System

For secure inbound communication via HTTPS the sender system must trust the Load Balancer, for this it must have the root certificate of the load balancer in its trust store.

The easiest way to get the Load Balance root certificate would be to use the Connectivity Test in the cloud integration tenant. The Connectivity Test is available in Operations View in Web, in section Manage Security Material. Selecting the Connectivity Tests tile from Overview page opens the test tool offering tests for different protocols. To connect to a cloud integration tenant via the load balancer to get the root certificate select the TLS option. Enter the URL of your runtime node (the URL you want to call from your sender backend) in the Host field. The host name of the runtime node has the format: <tenant>-iflmap.<data center>

Execute the connectivity test. If there is in error you may have to uncheck the option ‘Validate Server Certificate‘. The response screen provides the list of certificates from the load balancer because the SSL/TLS connection is terminated by the load balancer. You can use the Download option to download the certificates. A file is created in your local download directory containing all the certificates. From the *zip file select the *.cer file of the root certificate and import this into the trust store of the sender system.

Furthermore, if you want to use Client Certificate authentication, the sender system keystore needs to contain a key pair signed by one of the CAs supported by the load balancer.

Note, that only root certificates are being imported into the Keystore of the SAP Load Balancer ! Therefore you as a customer must always assign the whole certificate chain to the certificate to enable the connected component to evaluate the chain of trust.

More information on the supported CAs: Load Balancer Root Certificates Supported by SAP.


Configurations in Cloud Integration Tenant

For secure inbound communication using Client Certificates, in the cloud integration tenant only the certificates needed for the Client Certificate based authorization check need to be configured. In general, there are two configuration options available:

  • Role based Authorization
  • Maintain Certificates directly in the integration flow

Note: SAP does not recommend to use Basic authentication because of security aspects, details can be found in documentation chapter ‘Basic Authentication’.

Role Based Authorization

The recommended configuration is to use User Role as authorization option in the integration flow sender channel and import the client certificates in the Certificate-to-User Mapping monitor.

Configure Sender Channel

You configure the authorization option in the sender channel in the integration flow. For the adapters supporting client certificate based authorization you find the authorization configuration option in the Connection tab. If User Role is selected an additional entry field for the role to be checked is shown.

The default role provided by SAP is ESBMessaging.send, this role can be used if no additional, integration flow specific authorization checks are needed. In case only specific certificates/users shall be allowed to send messages to this integration flow you can enter your own role in this field and create the role in the Cloud Platform Role Management as described further down in the blog.

With the May-13-2018 update user roles created in the Cloud Platform Role Management are offered as help function using the Select button for the User Role field.


To configure and deploy Integrations flows in WebUI your user needs the Group Role AuthGroup.IntegrationDeveloper or Single Roles WebToolingWorkspace.Read,
WebTooling.IntegrationFlowConfigure, GenerationAndBuild.generationandbuildcontent and

Configure Client Certificate in Certificate-to-User Mapping Monitor

The client certificates, that will be used to send messages to the integration flow, have to be configured in the Certificate-to-User Mapping Monitor. The monitor is available in the Operations View in section Manage Security.

In the monitor a user name is assigned to the client certificate. To setup the client certificate based communication upload the client certificate via the Add Button at the top of the monitor and assign a user name. The user name does not need to exist in the SAP Identity Provider as SAP Community Network (SCN) user.

Note that with the 12-May-2019 update expired client certificates are highlighted in red for easy spotting in the monitor.

To get alerted before a client certificate expires follow blog post Automated Notification for Client Certificates Reaching Expiry.


To configure Certificate-to-User Mappings your user needs the Group Role AuthGroup.Admin or Single Roles, NodeManager.deploysecuritycontent and

Assign Role to User in Authorization Management

The user created in the Certificate-to-User Mapping has to be assigned to the user role configured in the sender channel to allow sending messages to the integration flow. This is to be done in SAP Cloud Platform Cockpit.

Under Subscriptions select the application for the worker node, the one with the suffix iflmap or hcioem (depending on profile). In section Roles you can create your own roles. The only SAP delivered role on the worker node is ESBMessaging.send. You add additional roles using the New Role option at the top of the monitor. Afterwards assign the new role to the user set in the User-to-Certificate mapping.

You can also create groups for users and assign the groups to the custom role.


To configure roles in SAP Cloud Platform Cockpit you need to be administrative member of the subscriber account.

Configure Certificates directly in Integration Flow

The second option is to configure the certificates for the authorization check directly in the integration flow. But this option is not recommended because changes to the certificate will always cause short downtimes as the integration flow needs to be restarted.

Configure Sender Channel

In the sender channel in the integration flow authorization can be configured for the adapters supporting client certificate based authorization. The authorization configuration option is available in the Connection tab of the channel. If Client Certificate is selected a table is shown, where you can add the client certificates. Via Add Button add a new row to the table, in the row you can open the upload dialog for a certificate. Via Upload from File System you can browse the certificate file and add it to the channel.

You can add several certificate to the integration flow sender channel. But be aware that each update in the integration flow needs a redeployment of the integration flow and so is always causing a short downtime. This means, also during certificate renewal of the client certificate you must redeploy the integration flow, causing a short downtime. Exactly because of this disadvantage SAP recommends to use the Role Based Authorization option with user to certificate mapping.


To configure Integrations flows your user needs the Group Role AuthGroup.IntegrationDeveloper or Single Roles WebToolingWorkspace.Read, WebTooling.IntegrationFlowConfigure,  GenerationAndBuild.generationandbuildcontent and NodeManager.deploycontent.


Analyze Problems

If the configuration is not correct, you encounter errors either during SSL handshake or during authorization check.

To analyze such problems, you need to check the detailed error messages in the sender system. In addition, you can check if the request reaches the Cloud Integration tenant at all and if there are errors in the trace file of the runtime node.

HTTP Access Log

To find out if the request reaches the Cloud Integration tenant at all, first check in the HTTP Access Log if you can find the request there. You can access this log from the Monitoring Dashboard. In the section Access Logs select the System Log Files tile. You get a list of log files with the most recent files at the top. There are one or more HTTP Access Log files with nearly the same time stamp, one for each runtime node started in your tenant. Because you don’t know at which runtime node the request arrives you need to check all of those files.

For each inbound call reaching the Cloud Integration runtime node one line is written into the HTTP Access Log containing the IP address of the calling system, the certificate or user contained in the request, the date, the path and the HTTP return code. The line in the log file has the following format:

<IP Address> – <certificate or user> [<Date>] GET <path> HTTP/1.1 <return code>

Important for the analysis is to check the return code and the certificate or user entry. If a certificate is passed along with the request, the entry should have either the certificate mentioned like this:

<IP Address> – <CN of subjectDN>@<CN of Issuer DN> [<Date>] GET <path> HTTP/1.1 <return code>

Or, if for this certificate a user is created in the Certificate-to-User Mapping, the entry contains not the certificate but the user name maintained in the Certificate-to-User Mapping. The entry should look like this if you try to use Role-based Authorization using client certificate.

<IP Address> – <user> [<Date>] GET <path> HTTP/1.1 <return code>

If the request reaches the Cloud Integration tenant without a certificate, neither the certificate nor the user is shown:

<IP Address> – [<Date>] GET <path> HTTP/1.1 <return code>

In this case, either the sender does not send the client certificate or the Load Balancer does not accept it, so it is not forwarded. In this case you should check:

  • if the client certificate is sent by the sender system (check logs/traces of the sender system)
  • if you really use a signed client certificate, self-signed certificates are not supported by the Load Balancer
  • if the root certificate of the CA that signed the client certificate is really supported by the Load Balancer. The supported CAs are listed here Load Balancer Root Certificates Supported by SAP.
  • if the whole certificate chain is sent by the sender system.
  • if you have configured a custom domain/SSL host check that the trusted CAs are uploaded to your custom domain and that the authentication profile is configured as described here Managing Client Certificate Authentication for Custom Domains.

LJS Trace

If the certificate is received, but there is an error during authorization check, you should consult the LJS Trace (also known as CP Default Trace) for more details about the error.

You can access the LJS Trace from the Monitoring Dashboard. In the section Access Logs select the System Log Files tile. In addition to the HTTP Access Logs there are one or more CP Default Trace files with nearly the same time stamp, one for each runtime node started in your tenant

Check the name of the HTTP Access Log file, where you found the request (see above), to get the ID of the runtime node. The name of the file has the following format: http_access_<Node ID>_<date>.log. The Node ID is the ID of the runtime node, that received the request. Search for the corresponding CP Default Trace with the same node ID, file name format: ljs_trace_<Node ID>_<date>.log.

In this file search for the error and check the details. It could be that the user mapped fron the certificate does not have the role assigned which is configured in the integration flow sender channel.

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

    in my Iflows (C4C Integration), I can choose between "Client Certificate" and "User Role" Certification, but I'm not able to specify any Role, that is allowed to use the iflow.

    Also in my case the Authorization setting is located inside the System and not inside the connection tab of the channel.


    Any Idea, how I specify the allowed User Roles in my case?

    Best Regards



      This was the case in older versions of the adapter. To get the most recent settings, re-configure the channel (and the sender participant). In future there will be a migration option to the new version.



  • hi Mandy

    Thanks fo this blog , after I enabled the client certificate  with HTTP Adapter , How can I simulate the GET/POST request with POST Man?






      in postman you can select the method to use for the request. Please check out the documentation for postman.



  • Hi!

    Is there any possibility to use self signed or internal CA signed certificates for inbound connection (for testing only)?

    Do I understand correctly that the new self service keystore management can be used only for outbound communication (to import target system cert/root CA)?

    Thanks a lot!




      The loadbalancer only supports the CAs listed in the linked page. Self-signed certificates are not supported.

      You are correct, the Keystore Management can be used to maintain the keys and certificates for the outbound communication.



  • Dear Mandy,

    To try this feature out, i acquired a client certificate from Sectigo which uses the USERTrust RSA Certification Authority. This Root CA is trusted by the SAP Loadbalancer as listed here.

    I have setup the iflow both with setting “Client certificate” and “User role”, however, it seems that my certificate is not passed to the flow at all. I believe that all is in place though, so i have a hard time figuring out why this is not working.

    I used both POSTMAN and SOAP UI and see that the certificates are being transmitted in the handshake messages in Wireshark


    The HTTP log however shows no certificate or user.

    Kind regards,





      Hello Jeroen,

      if neither certificate nor user is shown on the HTTP access log this means that the load balancer does not forward the certificate. Usual root causes are:

      • certificate not signed by a supported CA
      • sender system does not send the whole certificate chain: as mentioned above the whole chain needs to be send as in the load balancer only the root CAs are available.

      If this does not help to solve your problem I suggest to create a BCP ticket on BC-NEO-IT-NW and ask why the certificate is not passed by the Load Balancer. The colleagues could create a trace and provide further details.

      Best regards,




  • Thanks Mandy for the information. I do have 1 question.

    We have a sender system and the common name is a mandatory field when generated the CSR.

    However, we don't know what the common name should be.

    Is this CN checked in SAP CPI or is only the root CA certificate checked (and can the common name be whatever value)?

    • Hello,

      the CN name in CPI can be any value, only trailing spaces are not allowed.

      In runtime in inbound communication only the root CA is checked for the SSL communication, if client certificate based authentication is used, the whole client certificate is checked (including CN, serial number etc.) against the client certificate maintained in the certificate-user mapping.

      Hope this clarifies your question.

      Best regards,


      • Hi,

        thanks for the reply. It is indeed clear.
        In that case the CN is only relevant (as validation method) for the CA that should sign the certificate.

  • Hello Mandy,

    Thank you for this information.  It is excellent.

    I am trying to test basic authentication using postman, before switching over to client certificate authentication.  I have uploaded the load balancer root certificate into postman.  I have also created the user in the security material in CPI with the credentials as well as assigned the user role ESBMessaging.send to my user.

    I am getting the 401 unauthorized error in postman.

    I checked the access log in CPI and neither the user or the certificate is shown in the log. ( – – [01/Oct/2019:00:23:32 +0000] POST /http/Sales_Order HTTP/1.1 401 5 518 –

    I am struggling to figure this one out.  I would appreciate any help you can provide.

    Thank you,


    • Hello Rhonda,

      if neither user nor certificate can be found in the HTTP access log this means that you do neither use a client certificate accepted by the load balance, nor user/password.

      Before trying with client certificate you should try to connect with basic authentication and get this working. Use user and password in the postman and check in http access log. Then the user should appear. This user needs to get the ESBMessaging.send role assigned. User Credentials do not need to be deployed for this user, this is only used for outbound connections.

      Best regards,


    • Hello Rhonda,

      Do you connect with postman to the CPI?

      How did you set up certificates in postman?

      Where can I get the certificate file?


      Thank you,


  • Hello Mandy,

    Thank you for the quick response.  Yes, my issue is with basic authentication, not client certificate authentication.  Please re-read my message if you don’t mind.

    I am trying to test using a service user (not my S-user id) to help my sending system understand how to test my iFlow. (BTW, using my S-user id, works just fine.)

    Does basic authentication require a S-user id or P-user id that is set up as a CPI member or is there a way to use a service user?  I was trying with a different user id that only had the role ESBMessaging.send and set up in the security material.  

    I really appreciate your help.

    Thank you,


    • Hi Rhonda,

      now you confuse me. The screen shots attached use the client certificate.

      If your S-user is working fine basic authentication is working. The user you created in the user to certificate mapping cannot be used as user to connect to CPI. Also a user for which you deploy a credentials in CPI cannot be used for basic inbound authentication, this credentials are only for outbound calls from Cloud Integration to a receiver system. For inbound authentication you can use either a real user existing in the IDP (for example your S-user) or a client certificate that can be mapped to any username.

      So, you need to check why your client certificate is not accepted.

      Either it is not signed by an accepted CA (see link in the blog for allowed CAs) or you do not send the whole certificate chain with the request.

      Best regards,


      • Hello Mandy,

        I apologize for the confusion.  Thank you so much for the information.  You have cleared things up for me.

        Thank you again for your help.


  • Hi Mandy Krimmel ,

    I have an additional question regarding the type of certificate.

    We have requested a client certificate with Digicert which unfortunately did not get signed by Digicert Global Root CA so we couldn't use it.

    Could you elaborate on what type of certificate we should request? Are we talking about a standard SSL certificate?

    thank you in advance,


    • Hello,

      for the HTTPS connection we are talking about SSL certificates, yes. For authentication with client certificates we talk about Client Certificates.

      Best regards,


      • Thanks Mandy!

        So I understand that in case we are having an inbound HTTPS connection from salesforce we should request to have a ssl certificate.

        kind regards,


  • HI Mandy,

    I am trying Client Certificate Authorization in SOAP sender channel. Could you please let me know which tenant certificates are to be shared with third party. I would really appreciate your help on this.

    Best Regards,

    Akshay Shrivastav

    • Hi,

      as stated in the blog the sender system needs to root certificate of the Load Balancer, this can be retrieved as explained using the connectivity test.

      This is the only thing required from CPI to be stored in the sender system. But what you require from the sender system admin is the client certificate which will be used for login. This you need to upload into the certificate to user mapping in CPI.

      But this is all explained in the blog, not sure what is missing from your point of view?



  • Dear Mandy,

    Thanks for your excellent blog. I am trying replicate BP from S4 to C4C via CPI. CPI Connectivity test is OK.

    Run DRFOUT but return error info. I dont know why. Could you help me? Thanks very much!

    Best Regards,


    Run SRT_LOG

    I check iFlow S4 certificate

    I only find out http_access_log file without ljs log file in CPI Monitor System Logs

    SMICM log

    • Hello,

      as you see in the http access log the certificate is reaching the CPI tenant, but still the certificate is shown and not the user to whom the certificate should be mapped. You need to check your user to certificate mapping configuration. Looks like the certificate sent with the request is not the one uploaded to the certificate to user mapping monitor.

      The certificate really need to be exactly the one used for sending the request, otherwise the user cannot be found and the user roles cannot be check which will end in an HTTP 443 error as in your request.

      The CPI connectivity test has nothing to do with this configuration as this for outbound connectivity, not for inbound calls.

      As said, please make sure the correct certificate is used for sending the call.

      Best regards,


      • Dear Mandy,

        Appreciate your quick reply. I checked all steps. Could you tell me which step is wrong?

        Thanks very much!

        Best regards,


        S4 client certificate is from STRUST client SSL Client. It is uploaded into CPI keystore.

        Maybe it is because the S4 certificate is not signed?

        CPI security material


        • Hi,

          see in the blog above:

          Furthermore, if you want to use Client Certificate authentication, the sender system keystore needs to contain a key pair signed by one of the CAs supported by the load balancer.

          So, a self signed certificate will for sure not be accepted by our Load Balancer.

          Please read the blog carefully and follow all necessary steps!

          Best regards,



  • Hi Mandy,

    Thanks for posting the process involved to achieve Client Certificate-based authentication. It was really helpful.

    Please excuse my understanding as I am very much a beginner to CPI. 

    I was unable to follow on the creation of a new role and assigning it to the iFlow(SAP S/4 -> SCPI). Seems like the UI has gone through some change. I followed the below steps, could you please correct me if I am wrong?

    1. I created a new User and new Group in SAP Cloud Platform Cockpit under the Authorization tab and assigned 'AuthGroup.Administrator' role with Sub-account as 'hcisvc' and application as 'provision'.
    2. From SAP STRUST I downloaded SSL Client Standard Certificate and assigned this to the user which I created above in the Client-To-Certificate Mapping. This certificate cannot be self-signed and should be signed by one of the CAs supported by Load Balancer. Please correct me.
    3. I assigned the role 'AuthGroup.Administrator' in the iFlow. Here, I am confused as I didn't have any option in the Authorization to create a role as you have in the blog. Please let me know if I am doing it the right way.
    4. I created an SM59 RFC Destination for HTTPs and provided the endpoint of the iFlow and selected option to use SSL Client Standard Certificate and not to logon with any user.
    5. After creating an RFC Destination, the connection test should not ask to enter HCI User-ID and Password. But, for me, it asks. I don't know where I have gone wrong.

    It would be of great help if you could make me understand the right process.

    Best regards,

    • Hello Kiran,

      please follow the blog carefully:

      • the UI to assign the role is still available (I just checked)
      • you need to select the application for the worker node (iflmap) not for provision
      • and you need to assign role ESBMessaging.send, not Administrator. Administrator role does not have authorization to send messages.

      It is important that you really follow the steps described carefully.



  • Hello Mandy,

    we're are not able to find the Certificate-to-User Mapping Monitor.

    Configure Client Certificate in Certificate-to-User Mapping Monitor

    The client certificates, that will be used to send messages to the integration flow, have to be configured in the Certificate-to-User Mapping Monitor. The monitor is available in the Operations View in section Manage Security.

    Are the any changes in the Operations View?

    The SAP Load Balancer is that anything we can reach? Is there a monitor or app for that?

    Thanks Thomas

    • Hello,

      according to the screenshot you are working on Cloud Foundry? There the configuration of client certificate based authentication is completely different, please refer to the blog

      Best regards,


  • Hello Mandy,

    Thank you so much.

    In the guided procedure "SAP Finance Applications Integration with ELSTER Finance Tax Integration for Germany (UStVA)

    SAP Cloud Platform Integration Configuration

    4.1 Set up HTTPS Connection to CPI System

    To setup a secure HTTPS connection between the application system (HR/Finance) and the Cloud Integration tenant, add the load balancer root certificate to the HR/Finance trust store. Further details are available in blog How to setup secure http inbound connection with client certificates. certificates/

    we followed the link.

    I never knew that there are the NEO and CF docu.

    I'll try that.




    • I have informed the colleagues responsible for the guided procedure to update it and add the CF link as well. Thank you for pointing out!

      Best regards,


  • Hello Mandy,

    I want to configure access (incoming) without a username and password, but through a certificate.
    1. Can I create my own certificate? (for example with @"keystore explorer")?
    2. Which file should be uploaded to Integration Flow and which one to the client (Postman)?

    This is my settings:


    In postman:


    My files from "Manage Keystore"


    It is difficult for me to understand which file I need to create and which file to upload to Integration Flow and which to postman.




    • Hi Andrey,

      the client certificate needed to call to CPI could be created in an external tool (e.g. Keystore Explorer) but need to be signed by a CA supported by the load balancer (as described in the blog).

      The private key pair (p12) needs to be available in the sender (system or application), the public key (cer) needs to be uploaded to the user to certificate mapping or integration flow.




      • Hello Mandy,

        Thanks for the answer.

        I reread the text again and I understand that I am confused in the names.

        I can't figure out where to start creating certificates. I already have downloaded certificates from sap.

        Sorry for the large screenshots.

        I see that the СPI asks for a (*.cer | *.ctr )- file and a postman crt-file.

        How do I start creating these files?




        • Hello Andrey,

          the CPI keystore does have nothing to do for the inbound authentication. The private key pair available there cannot be used as you cannot download private content. Private content is not allowed to be downloaded for security reasons, the private key is expected to stay in the system where is was created.

          If you need a client certificate to connect to CPI you can create it in keystore explorer and get it signed by an allowed CA.



  • I am getting an error while calling SOAP inbound from S4Hana on premise.

    my iflow is working when calling from soapUI.


    soap UI

    in S4 Hana on premise, i used se80 and soamanager to build consumer proxy and logical port to create the soap request.

    my iflow is using user role only, no client certificate as i am using CPI trial.


    soap adapter config

    but while trying to test the soap request from se80, i am getting the following error:


    soap request error


    Please suggest what am i missing? i have imported S4 certificates into CPI and CPI certificates into S4 also.