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 blog ‘How 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>.hana.ondemand.com:
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.
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.
Authorization
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
NodeManager.deploycontent.
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.
Authorization
To configure Certificate-to-User Mappings your user needs the Group Role AuthGroup.Admin or Single Roles IntegrationOperationServer.read, NodeManager.deploysecuritycontent and
NodeManager.read.
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.
Authorization
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.
Authorization
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.
Hi Mandy Krimmel,
Thank you for the great explanation of the possibilities and the recommended approach 🙂
Best Regards,
Venu
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
Tobias
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.
BR,
Mandy
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?
Thanks
Cai
Hi,
in postman you can select the method to use for the request. Please check out the documentation for postman.
BR,
Mandy
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!
Viktor
Hello,
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.
BR,
Mandy
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,
Jeroen
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:
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,
Mandy
Thanks Mandy for the detailed blog. Really helpful.
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,
Mandy
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.
10.174.109.13 (73.153.28.37) – – [01/Oct/2019:00:23:32 +0000] POST /http/Sales_Order HTTP/1.1 401 5 518 XXXXXXX-iflmap.hcisbp.us3.hana.ondemand.com:443 –
I am struggling to figure this one out. I would appreciate any help you can provide.
Thank you,
Rhonda
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,
Mandy
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,
Andrey
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,
Rhonda
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,
Mandy
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.
Rhonda
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,
Maarten
Hello,
for the HTTPS connection we are talking about SSL certificates, yes. For authentication with client certificates we talk about Client Certificates.
Best regards,
Mandy
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,
Maarten
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?
Regards,
Mandy
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,
Dou
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,
Mandy
Dear Mandy,
Appreciate your quick reply. I checked all steps. Could you tell me which step is wrong?
Thanks very much!
Best regards,
Dou
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
Mapping
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,
Mandy
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?
It would be of great help if you could make me understand the right process.
Best regards,
Kiran
Hello Kiran,
please follow the blog carefully:
It is important that you really follow the steps described carefully.
BR,
Mandythe
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 https://blogs.sap.com/2019/08/14/cloud-integration-on-cf-how-to-setup-secure-http-inbound-connection-with-client-certificates/.
Best regards,
Mandy
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. https://blogs.sap.com/2017/06/05/cloud-integration-how-to-setup-secure-http-inbound-connection-with-client- certificates/
we followed the link.
I never knew that there are the NEO and CF docu.
I'll try that.
Thanks
Thomas
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,
Mandy
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.
Thanks
Andrey
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.
BR
mandy
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?
Thanks
Andrey
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.
BR
Mandy
hi andry,
May I know whether you have the solution on this. recently I also need to call CPI api via client certificate. I have tried to follow the blog,
Can you guide me which steps am I missing?
Hi Derek.
I found the only way to connect to the SPI from Postman with certificates. I used "Single Sign-On with SAP Passports".
This is how you can get a pair of keys on the side of the postman for free! Only the public key is loaded on the SPI side.
But this method does not suit me, because it is tied to a real s-user. The correct solution to this problem is to buy a pair of keys in trusted centers from SAP.
Hi Andrey,
I have created the SAP Passport with .pfx file and then I import it to my browser and export it to get the certificate.
photo
Hi Derek.
In postman you have to download a pair of keys, use the menu "settings" -> "certificates"
And understand, postman does not transfer this pair of keys. He encrypts the message with her help, and CPI decrypts with the public key
Hi Andrey,
Is that mean I have to upload my sap passport cert to postman first and then down it ? it is my first time to do it, do you have the step for me. if you don't mind could I setup a call with you via MS team?
thanks
derek
Hi Derek.
Let's start with what files do you have?
And where are they from?
hi Andrey
I have Sxxxxxxx.pfx file which downloads from SAP passport. Then I have imported to chrome and export Sxxxxxx.cer.
Then I have imported that cert into https setting as below screen. May I know what I need to do next? Do I need do anything at keystore?
Hi Derek
*.cer file uploaded to iFlow - that's right.
Try uploading the *.pfx file to postman.
Set the connection type in Auth page, in postman as "Inherit..." (I don't remember here. You need to pick up)
Try to send data.
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.
see my answer in the other blog.
Hi Mandy,
Thank you for your incredible blog!!
I am trying to establish inbound connectivity with soap adapter with a third party non SAP system. I have imported sender's certificate chain in user to certificate mapping and the sender system have installed the root certificate of the
Load balance in their application as mentioned in the blog.
The sender has confirmed that, they have the same certificate chain in their keystore which they have shared with CPI.
The root certificate of the sender is also signed by CA supported by load balancer.
but still getting the below error in HTTP access logs.
Error in words- XX.XX.XXX.XX (XX.XXX.X.XXX) - - [18/Jul/2022:13:01:39 +0000] POST /cxf/GetArtifactId HTTP/1.1 401 5 53 <tenant>-iflmap.hcisbt.<data center>.hana.ondemand.com:443
Please suggest where am I going wrong.
Thanks,
Chinmay
Hello,
I would suggest to have a look into the ljs trace, sometimes additional details are logged there based on what we get from load balancer. In the http trace it looks like the certificate is not passed to the cloud integration tenant at all.
Again check that the sending system really passes the correct client certificate.
Best regards
Mandy
Hi Mandy,
We were unsuccessful with our efforts to establish the client certificate based authentication.
We have now directly imported the client's root certificate in our SOAP adapter configuration and our CPI tenant's intermediate is presents in client's keystore.
CPI is receiving the below error in LJS trace log-
2022 10 07 08:06:55#+00#ERROR#com.sap.esb.security.cloud.authentication.CloudAuthenticationFilter##anonymous#https-jsse-nio-8041-exec-12###ae17f860e#na#na#na#na#client certificate received at load balancer: Qz1DSCwgU1Q9QmVybiwgTD1CZXJuLCBPPVNjaHdlaXplcmlzY2hlIEJ1bmRlc2JhaG5lbiBTQkIsIENOPXp2cy1iMmItd3Muc2JiLmNo|
2022 10 07 08:06:55#+00#ERROR#com.sap.esb.security.cloud.authentication.CloudAuthenticationFilter##anonymous#https-jsse-nio-8041-exec-12###ae17f860e#na#na#na#na#client certificate status from load balancer: Invalid Certificate Presented, OpenSSL verify result code: 20|
Please suggest what am I missing?
Thank You!
Regards,
Chinmay P.
Did you also import the public of your client certificate into Keystore?
Hi Vijay,
No, we have not imported public key in the Keystore, Is it required for the second method of configuring the certificate directly in the iflow?
Regards,
Chinmay P.
'
I would try that for sure. However, I did not understand why the original method as proposed in the blog did not work for you. That should be straight forward step as well. However CPI might need the whole public certificate chain rather than just the root.
Hi Vijay,
We have tried first method as well, got a same issue and in second method, have imported whole certificate chain but issue persist.
May be something is wrong at load balancer's end, not sure.
Please guide further.
Regards,
Chinmay P.
Hello,
I would suggest you create a ticket so that the experts could have a look. Its really hard to do such analysis via blog comments.
Normally the process is straight forward. But the sending system really needs to send the whole chain as also written in the blog because in the load balancer only the root CAs are imported.
Best regards
Mandy