Technical Articles
Cloud Integration on CF – How to Setup Secure HTTP Inbound Connection with Client Certificates
This blog describes how to setup secure inbound communication using client certificates when using SAP Cloud Integration in the Cloud Foundry environment. It describes the different configuration options available and gives a step by step description what needs to be configured where. Additional focus of the blog is using custom roles for inbound authorization.
Setup Secure HTTP Inbound Connection with Client Certificates and Custom Roles in Cloud Foundry
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 let’s 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 around.
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 in the Cloud Foundry environment. Inbound communication in Neo environment is described in blog ‘How to Setup Secure HTTP Inbound Connection with Client Certificates’. Outbound communication configuration for Neo and Cloud Foundry is described in blog ‘How to Setup Secure Outbound HTTP Connection using Keystore Monitor’.
Secure Inbound Communication
For HTTPS based communication towards a Cloud Integration tenant no keystore needs to be maintained in the Integration tenant. Sender system and load balancer need to get the certificates and keys configured as described below. This setup can be used with basic authentication with user and password.
For client certificate-based authentication and authorization in the Cloud Integration tenant in Cloud Foundry the private key pair provisioned with the tenant (alias sap_cloudintegrationcertificate) needs to be available in the keystore and the client certificate used for the inbound call needs to be maintained in the service key. In case the deprecated option to configure the client certificate directly in the integration flow is used, the client certificate is required additionally in the service instance. This is different to the configuration in the Neo environment.
Configurations in Sender System
Add Root Certificate from Load Balancer
For secure inbound communication via HTTPS the sender system must trust the load balancer. Therefore the root certificate of the load balancer needs to be part of its trust store.
The easiest way to get the load balancer root certificate is to use the Connectivity Test on the Cloud Integration tenant. The Connectivity Test is available in the Operations View in Web, in section Manage Security. Selecting the Connectivity Tests tile from the 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>.cfapps.<data center>.hana.ondemand.com. You can find this URL by selecting a tile under Manage Integration Content in the Operations view and selecting the integration flow which should be called.
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 certificates.zip 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.
Create Client Certificate
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.
Download the client certificate as PEM-encoded X.509 certificate, this is required later when the service key is created.
Configurations on Cloud Integration Tenant in CF
For secure inbound communication using client certificates, on the Cloud Integration tenant the provisioned private key pair with the alias sap_cloudintegrationcertificate is required in the keystore of the Cloud Integration tenant. Furthermore the client certificate needed for the client certificate-based authorization check needs to be configured. In general, there are two configuration options available:
- Role based authorization
- Maintaining certificates directly in the integration flow (not recommended)
Note: SAP does not recommend to use basic authentication because of security aspects, details can be found in documentation chapter ‘Basic Authentication’.
1. Option: 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 during service key creation.
Get JSON File for Role in the User Role Monitor
First you need to decide if you want to use the SAP pre-delivered role ESBMessaging.send or use a user-defined role for calling the integration flow.
Use Role ESBMessaging.send
The easiest option for role-based authorization is to use the SAP pre-delivered role ESBMessaging.send. Differently to the Neo environment, where the user roles are configured in the cloud platform cockpit, in the Cloud Foundry environment a monitor exists in the Cloud Integration monitoring to maintain user roles. Open the User Role monitor in section Manage Security in the Monitoring section in the Cloud Integration tenant.
Select the pre-delivered role ESBMessaging.send and choose Download JSON.
The format of the downloaded JSON file looks like this:
{"roles":["ESBMessaging.send"]}
You need this JSON snipped later in the creation of the service instance.
Use User-defined Role
If you want to secure the integration flow by a user-defined role you need to create a new role. In the Cloud Foundry environment a monitor exists in the Cloud Integration monitoring to maintain user roles. Open the User Role monitor in section Manage Security in the Monitoring section in the Cloud Integration tenant.
Create a new role by selecting the Add option.
In the creation dialog enter the role name and a description.
Select the newly created role and choose Download JSON.
The format of the downloaded JSON file looks like this:
{"roles":["Role1"]}
You need this JSON snipped later in the creation of the service instance.
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. See above how to create the custom user role in the User Roles monitor in the Cloud Integration monitoring page in section Manage Security.
Authorization
To configure and deploy Integrations flows in WebUI your user needs the role AuthGroup_IntegrationDeveloper.
Check for Key Pair ‘sap_cloudintegrationcertificate’ in Keystore Monitor
As already stated, in the Cloud Foundry environment the SAP key pair provisioned on the tenant is required in the tenants keystore in order to use client certificate-based inbound authentication and authorization. Check in the Keystore monitor in section Manage Security that the key pair with alias sap_cloudintegrationcertificate is available and that the key is not expired.
Note that in Trial accounts no SAP key pair is provisioned. Because of this client certificate-based inbound authentication and authorization cannot be used. You can only use basic authentication.
Configure Client Certificate-Based Authentication and User Role in the Service Instance in SAP Cloud Platform Cockpit
In order to use client certificate-based inbound authentication, this authentication option has to be activated in the service instance in SAP Cloud Platform Cockpit. When creating the service instance to be used for client certificated-based authentication in the SAP Cloud Platform Cockpit, you need to specify client_credentials as grant type. Furthermore, specify the user role you defined in the integration flow in your sender channel.
The easiest way to configure this is to use the downloaded JSON snipped for the user role and extend it with the grant type client_credentials and the redirect-uris like shown here. Note that the grant type needs to be client_credentials even if you want to configure client certificates.
{
"roles": ["ESBMessaging.send"],
"grant-types":[ "client_credentials"],
"redirect-uris":[],
}
More details on creating service instances in Cloud Foundry can be found in the SAP online documentation at Creating Service Instance and Service Key for Inbound Authentication.
Configure Client Certificate in the Service Key in SAP Cloud Platform Cockpit
The client certificates that will be used to send messages to the integration flow, have to be configured in the service key in the SAP Cloud Platform Cockpit.
After the service instance is available, a service key for the instance needs to be created. In the Create Service Key dialog select the Form based key creation. To upload the external client certificate for the sender system select ‘External Certificate’ as Key Type, provide a Name and in the External Certificate field add the client certificate in the following PEM-encoded format:
-----BEGIN CERTIFICATE-----MIIHyDCCBrCgAwIB[...]CAq8Tn7kSFDmVnrXe6v8hcQ==-----END CERTIFICATE-----
Note that the client certificate is a PEM-encoded X.509 certificate.
Note that you can create multiple service keys for one service instance with different client certificates. But a client certificate can be assigned to one service instance only once.
More details on defining service keys in the Cloud Foundry environment can be found in the SAP online documentation at Creating Service Instance and Service Key for Inbound Authentication.
In future a view in the Cloud Integration monitoring section will make this configuration more user-friendly.
2. Option: 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. Furthermore, in the Cloud Foundry environment the client certificate has to be added to the service key additionally.
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. Select Add to 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 certificates 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 User Role Authorization option with user to certificate mapping.
Authorization
To configure Integrations flows your user needs the role AuthGroup_IntegrationDeveloper.
Check for Key Pair ‘sap_cloudintegrationcertificate’ in Keystore Monitor
As already stated, in the Cloud Foundry environment the SAP key pair provisioned in the tenant is required in the keystore in order to use client certificate-based inbound authentication. Check in the Keystore monitor that it is available and that the key is not expired.
Note that in Trial accounts no SAP key pair is provisioned. Because of this client certificate-based inbound authentication cannot be used. You can only use basic authentication with clientid and clientsecret generated in the service key.
.
Configure Client Certificate Based Authentication in the Service Instance in SAP Cloud Platform Cockpit
If you like to use client certificate-based inbound authentication, you have to activate this option in the service instance in SAP Cloud Platform Cockpit. When creating the service instance to be used for client certificated-based authentication in the SAP Cloud Platform Cockpit, you need to specify client_credentials as grant type.
Note that the grant type needs to be client_credentials even if you want to configure client certificates.
{
"grant-types":[ "client_credentials"],
"redirect-uris":[],
}
More details on creating service instances in Cloud Foundry can be found in the SAP online documentation at Creating Service Instance and Service Key for Inbound Authentication.
Configure Client Certificate in the Service Key in SAP Cloud Platform Cockpit
Configure the client certificate that will be used to send messages to the integration flow in the service key in the SAP Cloud Platform Cockpit.
After the service instance is available, a service key for the instance needs to be created. In the Create Service Key dialog select the Form based key creation. To upload the external client certificate for the sender system select ‘External Certificate’ as Key Type, provide a Name and in the External Certificate field add the client certificate in the following PEM-encoded format:
-----BEGIN CERTIFICATE-----MIIHyDCCBrCgAwIB[...]CAq8Tn7kSFDmVnrXe6v8hcQ==-----END CERTIFICATE-----
Note that the client certificate is a PEM-encoded X.509 certificate.
Note that you can create multiple service keys for one service instance with different client certificates. But a client certificate can be assigned to one service instance only once.
More details on defining service keys in the Cloud Foundry environment can be found in the SAP online documentation at Creating Service Instance and Service Key for Inbound Authentication.
How to setup OAuth client credential grant for API clients is described in Setup Inbound OAuth Client Credential Grant Authentication for API Clients.
Hi Mandy, a very nice, detailed blog that I am finding useful even at the end of 2020! I was wondering if you could clarify a few details, considering CF will now be the only CP-CPI option available from 2021...
"roles": ["ESBMessaging.send"],
"grant-types": ["client_x509"]
}, and then provision a service key with the client certificate's Base64 content?
Thank you very much, and wish you a Happy New 2021!
Regards
Satish Bhagwat
Hello,
I hope this clarifies?
BR
Mandy
Hi Mandy,
thanks for clarification (and thanks Satish Bhagwat for rightfully pointing this out). I must admit it doesn't particularly shed a trustworthy light onto your service. I mean It's allright that you use the same security artifacts for internal communication with the CF framework / runtime but since you are in complete ownership of the stack and the provisioning procedure including you (as SAP) prohibiting the deletion of SAP owned security artifacts like "sap_cloudintegrationcertificate" (for a good reason, of course) this then would mainly mean you don't trust your own provisioning procedure to always have that "sap_cloudintegrationcertificate" readily available?
Or are there other situations where this could get lost or deleted?
Forgive me, for maybe being particularly salty but doing a current migration from Neo to CF I feel you are really more selling (forcing upon the client) a PaaS instead of a SaaS when it comes to Cloud Integration.
Cheers
Jens
Hello Jens,
thank you for your feedback. We are already planning to improve this, but this needs some time.
Best regards
Mandy
Hi Mandy, I appreciate your response. The issue I have been facing is as follows: Please see the question posted on the forum (URL link = https://answers.sap.com/questions/13219259/error-while-attempting-salesforce-to-cpi-integrati.html).
In a subscribed (NOT Trial) CF CPI setup, attempting to have a client certificate-based authentication and authorization from a Salesforce client to CPI.
This interface works properly with a basic auth; however, ran into problem when attempting to make it work using client certificate authentication.
Salesforce log shows the following error:
USER_DEBUG [67]|DEBUG|RESPONSE_STRING<InvalidClientException><error>invalid_client</error><error_description>Either client certificate is not configured in any service key of a Process Integration Runtime service instance or client-certificate authentication was not enabled for your tenant (key-pair with alias 'sap_cloudintegrationcertificate' does not exist in the keystore or was not mapped to the UAA instance): sb-it-rt-xxxxxxxxxxxxxxxx!b46, client certificate MIIDjzCCAnegAwIBAgINVPYo.
This error is the reason I was asking about the clarification on the key-pair with alias 'sap_cloudintegrationcertificate'.
I was able to confirm that the CA cert of the deployed integration flow as well as the CA cert of the key-pair with alias 'sap_cloudintegrationcertificate' do exist in the CA certificate entries under the Trusted Keystore of Salesforce.
It appears that the interface call from Salesforce gets stopped at the Load Balancer and never reaches the CPI tenant, since no incoming call details show up in CPI Monitor.
For now, I used the keypair of a S-user Passport in Salesforce. Am I correct that this should suffice as a CA-certified keypair, since the CA of SAP Passport is trusted by the Load balancer?
I then set up the service instance of the type "Process Integration Runtime" and the service key with the client cert details corresponding to the public key of the S-user passport keypair. I have successfully implemented outbound IDocs from on-prem ECC to CPI using cert-based auth approach, which also requires the service key detail to be done right in SAP Cloud Platform; so I think the service key part was done correctly.
Can you share your perspective if you notice anything that needs to be corrected? I would very much appreciate that!
Best regards
Satish Bhagwat
Hello Satish,
if the sap_cloudintegrationcertificate key pair is available in the keystore of your tenant and you have maintained the client certificate in the service key in a CPI runtime service instance configuring X.509 authentication ("grant-types": ["client_x509"]) this should work.
The error indicates that there is something wrongly configured in the service instance and/or service key.
I would suggest you re-check this configuration. If you do not find the problem I would suggest you open a ticket on LOD-HCI-PI-RT.
Best regards
Mandy
Hi Mandy, I am responding to let you know that I was able to fix the issue, and was also able to recreate the error. Your informative blog as well as your subsequent helpful comments to my questions were instrumental in finding the resolution and recreation of the error. I very much appreciate that!
I was receiving the error that I reported earlier, because I had used the same S-user Passport keypair in different client applications (Salesforce, SAP CRM, etc.) for testing purpose. Not realizing that the public key contents were identical, I had created multiple service keys in different service instances for the same public certificate Base 64 content. When I removed multiple service keys having identical Base64 content and left only one service key in place, the interface started working properly.
This is the observed SAP Cloud Platform behavior -
When a service key was attempted to be created within a service instance with the same service key parameters (i.e., Base64 certificate data placed in JSON as the value of the variable "X.509"), the SAP CP logic properly stopped that attempt with an error to generate a service key.
However, multiple service keys could be generated from the same Base64 content if the keys were created in different service instances. For example, I was able to create service keys with identical Base64 content in instances “ClientCertificateAuth”, “rolenx509” and “x509only” (Service key names were same in one case and different in another; but Base64 content was identical every time.).
When there are multiple service keys with the same Base64 content, AND AFTER a lag time of exactly 1 hour, then I was able to see the error that I reported earlier. If a connection test was attempted within this 1 hour, I still received a HTTP 200 OK response. So there appears to be a lifespan of 60 minutes, similar to the OAuth2 bearer token lifetime of 4,199 seconds (appx 70 minutes).
The error was exactly the same error that I had reported earlier.
error = "invalid_client", error_description="Either client certificate is not configured in any service key of a Process Integration Runtime service instance or client-certificate authentication was not enabled for your tenant (key-pair with alias 'sap_cloudintegrationcertificate' does not exist in the keystore or was not mapped to the UAA instance): sb-it-rt-xxxxxxxnonprodcpi!b46, client certificate MIIDjzCC<Rest of the Base64 stuff>cF5sKGPn, message: 400 Bad Request"
thank you for the detailed analysis. We will check if we can improve the UIs to not allow same certificate in different service instances.
Best regards
Mandy
Is it supported to have multiple certificates within one key, e.g. for certificate rollover so something like this
https://help.sap.com/viewer/368c481cd6954bdfa5d0435479fd4eaf/Cloud/en-US/7a9b282981784f399615b2fda3cda062.html doesn't say anything about this. I currently assume I need two service keys.
Correct?
Many thanks and kind regards
Jens
Yes, you need to separate service keys. It is not possible to have bother certificates in one service key.
Best regards
Mandy
Hi Mandy,
So with respect to load balancing this means we would have to generate a key pair, and have it signed by one of the approved certificate authorities to do testing in a non-productive tenant? E.g. AS2 testing where we would want to unit test different flows (camel framework) related to error handling, logging, etc.? I have a local Mendelson client for sending test messages, but it is delivered with certificates purely for testing and one has the option to create other self-signed certificates. Trying to get more clarification because I am a many year veteran of SAP PI/PO but have never used CPI until the last few days.
Also, if we do not have a process integration runtime service created in the BTP is that a problem? I have seen some references to it in other blogs and help articles, but I do not see it in our setup.
Regards,
Ryan
Hello Ryan,
there are different authentication options available, not only the client certificate based authentication described in the blog, for all options please refer to the official Cloud Integration documentation:
Setting Up Inbound HTTP Connections (Integration Flow Processing), Cloud Foundry Environment - SAP Help Portal
Best regards
Mandy
Hi Mandy,
Thank you for the response. I did find some content on how to setup the basic authentication for testing. I cannot get Mendelson to connect properly for an AS2 test, but I was able to simulate a test with the HTTP adapter. It gives some complaint about protocol, I think related to certificates, but no log is generated so I cannot figure out what is missing on that one.
Regards,
Ryan
Hello,
concerning AS2 and usage of mendelson you may refer to this blog: B2B Capabilities in SAP Cloud Integration – Part 1 | SAP Blogs
If this does not help I would suggest you open a ticket, this is hard to analyze via the blog comments.
Best regards
Mandy
Hi Mandy,
Yes, I had been referring to that blog to see what was different between this and PO/PI, but it is not working. I'm opening an incident right now because it seems to be tied to the keys for the SSL connection.
Regards,
Ryan
Hi Mandy,
Maybe you could point me in the right direction on this one? I'm looking at some older blogs, but not sure if they are specific to only the Neo environment. I'm trying to figure out how we identify a partner id in the Partner Directory by certificate - I have tried the following blog: https://blogs.sap.com/2017/08/24/cloud-integration-partner-directory-sender-partner-connecting-with-client-certificate-authentication/ and I get this error:
It is not clear how the partner mapping is maintained so we can access the necessary string value pairs. When I use the OData API to view partners I get nothing despite having sent messages previously. I also tried explicitly creating a partner to see what the API would do and it mentions they are created implicitly. Implicit creation does not make the link clear especially when I do not see any entries and I cannot find any help or blogs on the topic that are recent.
Regards,
Ryan
In CF there is no such entity as Certificate-User Mapping. In general the PD as such works same in Neo and CF, you can store key/value pairs for specific partners.
I would point you to the following design guidelines for the partner directory usage:
Use the Partner Directory Appropriately - SAP Help Portal
Hope this helps you to figure the problem out.
best regards
Mandy
Hi Mandy,
Thank you, as that at least got me started. It may be helpful for the official help documentation to point out that the AuthorizedUsers should match the clientId from the service keys that are generated. Without explicitly mentioning this it wastes a lot of time unit testing, tracing, logging, etc. to determine that the connection between the arbitrary partner that we create is linked to the information in the service key in another system.
Regards,
Ryan
Hi Mandy,
There is a requirement to enable both basic authentication to authorize the HTTP Client to call the Integration Flow Endpoint using grant type as client_credentials and certificate based authentication using grant type as client_x509 but both grant types cannot be combined for the service instance. So, how can this requirement be implemented.
Best Regards,
Sarbtej
Hello Sarbtej,
this is currently not planned, but we will evaluate and if possible to add it ad new requirement.
Best regards
Mandy
Hi Mandy,
we can create two Process Integration Runtime instance, one with grant type as client credentials and other with grant type as client_x509 and this will allow both basic and client certificate authentication for an Integration Flow?
Best Regards,
Sarbtej
Hello,
ok, looks like I misunderstood your first question, you do not want both to be checked and only then allow execution (dual authentication)? This is what is not possible.
But to allow both options in parallel, meaning user can come with either basic auth or credential is already possible. Simply use the role based option in the integration fflow. then this flow can be accessed by both options, with a certificate assigned in user-certificate mapping, and also with a user/password if he has the correc role assigned.
BR
Mandy
Hi Mandy,
My requirement is in CF CPI to enable basic and client certificate authentication for an Integration Flow but in CF there is no option of user to certificate mapping.
Best Regards,
Sarbtej
In CF you can enable this via a service instance for OAuth/Basic and a second service instance for client certificate based authentication.
Then both is possible in parallel.
BR
Mandy
I am using CPI Trial account.
configured sender SOAP adapter with User Role and ESBMessaging.
When i invoke this in soapUI. it works with Basic authentication.
soap ui
then, i tried to invoke it from an S4 on premise system.
i created Service consumer with CPI wsdl in se80 and created a logical port. i was able to read wsdl and logical port generated successfully.
when i am testing the service consumer in se80. it's not working with the credentials.
error in se80
what am i missing here? please help.
i have imported certificates of CPI in strust. also imported certificates of S4 in CPI keystore.
Hello,
this is really hard to evaluate using your comments in the blog.
Some thoughts:
Best regards
Mandy
Thanks for your response.
Issue got resolved.
As I am using CPI trial account, i had to export the 'WSDL without policies' from the endpoint details page.
And in the soamanager in S4 system, I had to use the wsdl file instead of URL access.
Hi Mandy,
For cloud integration content deployed on PO (CPI RUNTIME) , does all the above steps hold true ?
Also all the certificates like loadbalancer certificate generated from CPI valid on PO ?
Hello;
no, in case of PO runtime the security setup needs to be done in the Netweaver as per the Netweaver documentation.
For additional details please check 2195773 - Cloud Integration Content in SAP Process Orchestration 7.50 - Known Constraints - SAP ONE Support Launchpad
Best regards
Mandy
Hi Mandy,
Thanks for the reply , really appreciate it .
I had seen that note but i thought that it says that if you are using client certificate option on sender adapters as opposed to user role option (which SAP recommends now) then its an issue and we need to use SAP web dispatcher as component for terminating SSL.
I thought if we configured the sender adapters with user role , then we have both the options below available, considering we have options to download and upload all the security artifacts.
Hello
the note says:
<<Client Certificate Authorization on sender channels requires the usage of a SAP Web Dispatcher as component for terminating SSL and forwarding HTTP header ssl_client_cert.
It is recommended to use User Role Authorization instead. Client certificates can be mapped to allowed users via NetWeaver Administrator Identity Management.>>
This means if you use user role you can use Client Certificates as well mapping them to users in the NetWeaver Identity Management.
Best regards
Mandy
Hi, Mandy.
Thank you for this detailed article. I'm trying to implement option 1 in our tenant but I am encountering an issue when creating the service key.
I can create the service instance correctly with the grant-types and roles populated:
But when creating the service key within the instance, the grant-types and roles are not assigned:
Am I missing anything here? Thank you!
Regards,
Mae
Hello,
there was a change done. The configuration details were removed from the service keys. Instead you can check the configuration of the service instance by selecting the instance and choose “Show parameters” from the menu on the right top in the cockpit UI.
Best regards
Mandy
Hi, Mandy.
Thank you for sharing! This helps a lot as we were wondering if this was the cause of our connection issue.
Regards,
Mae
I too have a connection issue C4C (DEV) --> CI --> x and raised the same question to SAP support. Funnily enough my current problem from C4C DEV persists, while I needed to exchange another client certificate in PRD MKT (PRD) --> CI --> x without a problem
Any clues how you resolved your issue?
Thanks Mandy. Your post has been a saviour, I was trying to create Service Key and wondering why it was not including role details.
Hi Mandy,
Currently we are stuck with Go-Live. As per your suggestion we performed all the activities and deployed the Artifact with AS2 adapter connection. When customer tries to send test data connection is getting failed.
Thanks and Regards,
Raja
rajasegaran.bhuvaneswari@goodbabyint.com
+49 -15145292961
I request you to open a ticket on LOD-HCI-PI-RT-B2B so that the experts can have a look.
Thank you,
Mandy
Hi Mandy,
Thanks a lot for this exhaustive guide . I am currently setting this up at our client to call an endpoint created in the Integration Suite.
Just to know, is it supposed to work if I trigger a connection to the endpoint via Postman by mimicking the sender system ? I placed the Root of the client certificate chain in Postman and triggered a GET towards the CPI endpoint but got an unauthorized error. The call did not arrive at the CPI so I am guessing it got terminated at the load balancer.
As per https://blogs.sap.com/2020/02/24/client-certificate-based-authentication-in-sap-cpi/ , it would work but this blog is anyways for Neo and a different authentication mechanism.
Thanks & Regards,
Satyaki
Hello Satyaki,
yes, it should work sending the request via Postman. Authorization error probably means that something in the role assignment is not correct. Are you using x.509 client cert to connect? Maybe you first try with basic auth using client ID and client secret from the service key?
Best regards
Mandy
Hi Mandy,
thanks for your reply.
The connection from Postman works if I use Oauth2.0 with the basic auth using client ID and client secret from the service key.
I am going to try the Option 2 ( from ur blog) for configuring x.509 certificate for connection ( although it is not recommended but just to test if the certificates work as option 2 is simpler to implement and we are in development phase). In the Service key json file , will it work if I just put the Root certificate ( GlobalSign) of the sender or do I have to paste the entire certificate chain of the sender ?
Also for testing this from Postman, I have to just upload the Root certificate of the sender and select 'No Auth' as Authorization, right ?
Thanks & Regards,
Satyaki
Hi,
When you say root certificate, are you referring to the Key Pair (p12 or pkcs format) certificate? I can test this through postman when I use the Private Key Pair - note you will need to specify the hostname and the password for the Private Key pair in the settings>certificates area in Postman.
Kind regards,
David
Hi,
in the service key you need to upload the real client certificate, not only the root certificate.
Also in the postman you need the whole client certificate, not only the root certificate.
Best regards
Mandy
Hi Mandy/David,
Thanks a lot for your replies.
The certificate authentication now works for me in CF.
Best Regards,
Satyaki
Hi,
Please refer to this question, it's regarding inbound certificate based authentication in CPI in CloudFoundry:
SAP CPI : Inbound Client Certificate Authentication, Cloud Foundry Environment | SAP Community
Thanks
Hello,
in the service key only the client certificate needs to be uploaded, not the whole chain. This client certificate needs to be signed by a approved CA, then the load balancer will accept it. If this does not work, I would suggest to open a ticket so that the experts can have a detailed look.
Best regards
Mandy
Thank you Mandy.
Hello Mandy,
Your blog is very benefit to a lot of us. Thank you for creating such blog and providing answer to the many questions. Please keep up with the great job.
I have a question with relevant about using the Private Key from SAP Customer Data Cloud for JWT Authentication usage, I'm currently referring to this SAP Help Portal page -> https://help.sap.com/viewer/b6a1e8b75222421a8faf0269e8fbd0dc/2108/en-US/3fac5bcd1f7e4b369080976232efe799.html and using this OOTB iFlow as my reference https://api.sap.com/integrationflow/Receive_B2C_Customer_Updates_in_SAP_Customer_Data_Cloud
With specific to the Steps 3 -> Using the private key from SAP Customer Data Cloud, generate an X.509 public key and key pair.
I used the Private Key from CDC, to generate an X.509 public key, since there is no guide mentioned, do we generate a self-sign certificate or we need to generate a CSR using the CDC private key and send it to sign by an approved CA? This step is not very clear...
Below are the steps I did, unfortunately, the JWT authentication is still doesn't work.
This is the OpenSSL command I used to create the X.509 public key.
-> openssl req -new -x509 -key Private_Key_cdc.key -out publickey_cdc.cer
After that I use application KeyStore Explorer, to create a JKS KeyStore by using the CDC Private Key and the generated X.509 certificate as Key Pair Type PKCS #8. Then upload it to our CI Keystore for the JWT usage.
I assume the OOTB iFlow JWT authentication should work accordingly. Do you know what steps we could have been missing here?
Look forward to hearing from your advice.
Regards,
Aiivenn
Hello
sorry, but I have no experience with SAP Customer Data Cloud. With this question you would have to request help from this experts.
Best regards,
Mandy
Thank you, Mandy.
Do you happen to know anyone/blog that I can refer at?
Regards,
Aiivenn
I suggest you search in the SAP community for the blogs in the context of SAP Customer Data Cloud.
Best regards
Mandy
Hi Mandy
I Have a subbaccount BTP configured for Basic authentication ( S-USER id and password ) , so i have my SAP ERP WEB services ( in soamanager ) that are configured to contact SAP BTP Tenant with "User ID and Password " in the "Authentication Setting ; now I want to switch to X.509 SSL Client Certificate instead of User ID/Password. I already download the keypayr sap_cloudintegrationcertificate and import this chain in a directory of STRUST; next I have changed in the soamanager Web service the autentication in X.509 SSL Client Certificate selecting STRUST directory that contain the certificate sap_cloudintegrationcertificate CHAIN, but the connection test fail. I think it fail because i Have yo chenge the authetication also in BTP ... but Exaclty Where ? there is a central point to do this or there are many points ?
Thank you in advance and Best regard.
In Cloud Integration in general with the default setting all authentication options are possible.
In integration Flow when using Role Based Authentication you can connect with user and password as well as with the certificate. This depends how you have configured your service instance.
If the client certificate is uploaded there as described in this blog then you should be able to connect with client certificate.
Best regards
Mandy
Sorry Mandy
I have downloaded sap_cloudintegrationcertificate CHAIN from the BTP from the keystore tenant : this is not the client certificate for the authentication ? Do I need more ? The client certificate in not provided by SAP BTP ?
Where i have to go to see how instance ( already configured in the past ) have been configured to support client certificate authentication ?
The system is already configured.
Hello,
if you want to connect from ERP to CPI you have to get the client certificate from ERP and upload it to the service instance. As this is the certificate you want to use for connecting. This is the inbound connection case described in this blog.
The sap_cloudintegrationcertificate from the tenant can be used to connect to a backend from CPI -> outbound connection. Please do not mix this up.
Best regards
Mandy
sorry But how can i Generate this client certificate from My erp ?
For example: I use ssl client certificate authentication from BW to autenticate to C4C, but the client certificate is completely released FROM the C4C sistem ... I trasform IT in pse file and import in strust dedicate directory
System A connect to System B
System B must give the key to Sistem A for access.
IF system A is ERP and System B is HCI platform , in my mynd HCI platform must give ERP the key to access.
How can be done this technically ? Is there a specific Procedure step by step ?
thank yoy
Hello,
The system that acts as a client (sender) is expected to provide the client certificate, not the receiver. In your scenario CPI is the receiver.
I'm not an expert in how to generate certificate in the backend. I would suggest you contact the administrator of the backend system. He should be able to support you with this.
Best regards
Mandy
Can I use the same sender client cert to authenticate the same sender in two different CPI tenants?
Example:
We have a sandbox CPI tenant and a dev CPI tenant but only one sender system with a trusted CA signed client cert.
Thanks
yes, this is possible.
Thank you.
Hello Mandy,
I am currently trying to set up the integration between S4HANA and SAP C4C with Client Certificate Based Authentication .
I currently only have a self-signed certificate in the S4HANA system. I read in the SAP help that it wont work with that.
When creating the service key in CF, can I also set to "Certificate" instead of "External Certificate" and use the generated certificate in S4HANA in STRUST as a client certificate?
Or do i need to get a signed certificate by one of the supported CA´s ?
Thank you for your help
Many greetings
Simon
Hello Simon,
yes, you can use the SAP generated key pair, see also here: Creating Service Instance and Service Key for Inbound Authentication - SAP Help Portal | SAP Help Portal
Best regards
Mandy
Hello Mandy,
I added it to the STRUST list of my self-signed PSE.
Unfortunately the connection doesn't work.
My assumption was that I have to replace the PSE with the generated certificate.
What am I doing wrong ?
Many greetings
Simon
HI Simon
I'm no expert in how to configure STRUST, but you need to add the whole key pair as SSL client .
Maybe this blog (point 2) helps as an example: How to Setup Direct connection from your On Prem to SAP Logistics Business Network Freight Collaboration Option | SAP Blogs
Best would be to get this done by the admin of the system.
Best regards
Mandy
In order to configure an end-end scenario including the configuration on the backend (ECC/S4HANA) please refer my blog post at https://www.synergetrix.com/post/configuring-https-inbound-connection-in-cloud-integration-using-client-certificate-authentication
Thanks
Saurabh Kumbhare
Hi Mandy,
We are calling CPI ( cloud foundry) from our application and our client certificate is signed by an intermediate CA viz. 'GlobalSign RSA OV SSL CA 2018' which in turn is signed by Root CA ' GlobalSign'.
I have created the Service Key with key type as 'External Certificate' and maintained the client certificate there :
I have also followed the steps to configure the service instance to use 'ESBMessaging.send' as role and grant type as 'client_credentials'. Our CPI channel also is set to use authorization as 'user role' = ESBMessaging.send.
However, on triggering a call to CPI , we receive an error in our a
Hi Mandy,
We have an application whose client certificate is signed by an intermediate CA ' GlobalSign RSA OV SSL CA 2018' which in turn is signed by the Root CA 'Globalsign'.
I have created a service instance in our subaccount with grant-types as 'client_credentials' and roles as 'ESBMessaging.send'. Then, I created the service key within it where I have set key type as 'External certificate' and placed our client certificate.
Our CPI channel is also configured to use authorization as 'User role' = ESBMessaging.send. However, on trying to call the Integration Suite endpoint URL from our application, we receive an error as below :
'403 Forbidden: [Failed to establish Mutual-Auth (mTLS) based secure connection with Remote/Backend service'
It's an issue with SSL handshake for sure and I am trying to gather more logs. Do you see any issue already with our client certificate ? Also, is it possible to ask from SAP the SSL logs from the load balancer to see if they are rejecting our client certificate ?
Thanks a lot in advance.
Best Regards,
Satyaki
also, fyi the root certificate of the SAP load balancer is also added in our trust store . I obtained the load balancer certificate from our IS tenant using the procedure described here.
Hello,
in general the setup looks good. I would suggest to open a ticket on LOD-HCI-PI-CON-SOAP so that the experts could have a look.
Best reagrds
Mandy
Hi Mandy,
I have generated a CPI instance service key with a validity of 365 days. After that, I uploaded it to the destination service on BTP and configured a new destination with the same to communicate from BTP to CPI, which is working fine.
Since its validity is just 365 days after the validity is expired, do we have to generate a new service key and update the destination manually, or is there any automatic way of enabling certificate rotation?
Best Regards,
Rishabh
Hello,
you have to create a new service key with new certificate, there is no automatic way of rotation.
Best regards
Mandy
Hi Mandy,
Thank your for sharing wonderful blog!
I have created iflow with inbound HTTP adapter, I have shared endpoint URL and client certificate along client id and client secrets.
1.Vendor trying to send message from Postman it working and reaching to CPI
2.They tried to hit CPI URL from their browser it is reaching to CPI
When they are trying to send message from their application getting below error in their application.
Could you please advice where it is blocking exactly.
vendor Logs:
CPI Logs:
Regards,
sunil
Hello,
is the vendor trying to connect with client ID and secret or with the certificate? They could first try with with client ID and secret using basic auth to see if this works at all. Then they could use the client cert. It is really hard to try to analize this via blog comments, would be much better if you could create a ticket on LOD-HCI-PI-CON-SOAP so that the experts could check this.
Best regards
Mandy
Hello Mandy,
I believe that I have followed your blog but when performing a connection test in our ECC system, I'm receiving a 401 error.
Setting SM59 to use certs isn't working. Based upon what I've read, I'm wondering if it is due to our ECC certs being self-signed.
I've tried setting SM59 up with a user/pw for a S-user id with MessagingSend that we use with NEO integration. This is also receiving the 401 error. The user seems to be setup correctly in BTP/Integration but I'm wondering if I'm missing some authorizations as if I use my personal S-user, I am able to connect successfully. My S-user is setup as an Admin in BTP.
I'm unable to setup SM59 with the Service key client id/secret as the generated Client id appears to be 67characters and I'm only able to enter 33 characters.
Do you have any suggestions?
Thank you!
Hello,
concerning client cert authentication, as written in the blog the certificate needs to be signed by one of the accepted CAs, self-signed certificates are not allowed.
Maybe an option would be to use SAP generated certificates (certificate type - SAP certificate): Client Certificate Authentication for Integration Flow Processing | SAP Help Portal
Set Up Inbound OAuth Client Credentials Grant Authentication for API Clients with SAP-Generated Certificate | Tutorials for SAP Developers
If you want to use your S-User please follow this description: Basic Authentication of IdP User for Integration Flow Processing | SAP Help Portal
Best regards
Mandy
Hello Mandy,
I have one additional question -
Should I be creating a Service Instance for each partner? I was creating multiple service keys under one Service Instance, but I have noticed that the user id is the same for each service key.
If so, is there a limit on the number of Service Instances that I can create under one subaccount?
Thank you!
Hello,
yes, if the communication is expected from multiple partners you should create multiple service instances, on this level you could also grant different authorizations.
There is no fix limit on the number of service instances per tenant.
Best regards
mandy
Thank you for this clarification! If this is spelled out somewhere in the documentation, I must have missed it.
Hi Mandy,
How we will test iflow endpoint with key type External Certificate in Postman. We are moving from Certificate to user mapping of Neo to the method you explained here in cloud foundry. Wanted to understand how we can test this in postman. In Postman certificates section, we don't have pfx, key all these details. So how to test?
Thanks and Regards
Zameer Ahamad.
Hello,
you need to add the client certificate you want to use to connect to the integration flow (the one you uploaded as external certificate in the service key) into postman. Refer to Working with certificates | Postman Learning Center for more information.
BR
Mandy