This blog post tries to provide you with a step-by-step steps on how to configure client certificate based authentication from your SAP Netweaver system towards SAP BTP sometimes referred to as Inbound Connection in Cloud Integration using Client Certificate based Authentication.

I know there are many Blog Posts available and couple of SAP KBAs available as well. But I came across a unique situation in our landscape and that’s the reason, I wanted to share that information / experience with all of you.

First of all, lets clear the basics first

In this case, client is my backend SAP Netweaver ABAP On-Premise system and Server is my SAP BTP Platform. That means, we have to send a certificate to the server.

 

Before I went ahead with client certificate based authentication, I made sure that Testing the connection with Basic Authentication was successful from my backend Netweaver ABAP System by creating a simple RFC of Type ‘G’ – HTTP Connection to External Server.

 

What was so special about our case ?

All of our applications are accessible only via Intranet and they are not exposed to the Internet and not to mention like any other enterprise organizations our landscape is connected to hundreds of other internal systems either directly or via different middleware’s like SAP PO, BizTalk, IBM MQ etc.

Most of those integrations use certificate based authentication as well and we have our inhouse CAs to sign our internal certificates.

Now, when I initially started my configuration I was apprehensive about this because I had created the RFC Connection ( G Type ) and tried to connect to the SAP BTP Tenant and it was always asking for User credentials.

 

To troubleshoot this further, I then increased the ICM Trace level to 3 of that specific Application Instance and tried to figure out what was going wrong and guess what this is what I noticed

 

[Thr 3232] CCL[SSL]: Cli-0001D1E1: Cannot perform client authentication: Have no certificate fitting to CA names received from server [ssl3_send_client_certificate]
[Thr 3232] Wed Dec 14 11:07:05:502 2022
[Thr 3232] CCL[SSL]: Cli-0001D1E1: Sending message with empty certificate list [ssl3_send_client_certificate]
[Thr 3232] CCL[SSL]: Cli-0001D1E1: Sending empty Certificate message. [tls1_empty_cert_list]

 

Then I found out this interesting piece of information

 

your sender system’s client certificate need to be signed by a CA which is trusted by our load balancer (listed in note 2801396) so that this certificate can be used to communicate with CPI.

 

That means I have to make sure that I am sending a SAP Approved CA signed client certificate so that this certificate can be used to communicate with CPI / BTP.

 

Now I had this question in my mind – as I had mentioned previously

If I see the own certificate of my SAP ECC NW System , that is an Internal CA signed certificate and that certificate is used with all the other inter connected systems within our organization. Now if I get a new external certificate then all my existing connections are going to fail? Do I have to exchange that certificate will all my interconnected system owners? How others will react because other internal application owners may not agree to have an external signed certificate for internal applications.

With all these questions in my mind, then I thought that there must be a way by which I should not need to change the current client certificate.

I then created a dedicated PSE for this purpose only and created a CSR , got it signed by our company approved external CAs ( BTW fortunately that was SAP approved CA as well ), uploaded it to backend system via transaction STRUST. But did not make it default one. So all default connections did not get affected, and I was able to use this new certificate / PSE only for CPI / BTP connection. In this way our internal connections still use the default internal certificate, and outgoing CPI / BTP connection use the newly signed certificate, no conflict happened.

I am sure all of you know how to achieve this one but still as a guide below SAP KBA can be handy for creating a brand new PSE.

2148372 – How to create an own SSL Client PSE Identity

Once the PSE has been created , you have to create the certificate response i.e. CSR which then needs to be sent to the CA for getting it signed.

SAPBTP%20Dedicated%20PSE

Screenshot taken from ECC : SAPBTP Dedicated PSE

Once you have the CSR signed, go back to the STRUST Transaction code again and select that dedicated PSE which was created earlier and import that certificate response ( The full chain).

Once the signed certificate is given back to you , in our case they had provided us the chains separately – Root, Intermediate & the main certificate.

I opened them up in a notepad and pasted the contents of all three and then in STRUST while importing pasted the whole content. After that Add it to the Certificate List and save it.

Once this is done, lets go back to the SAP BTP Tenant and in order for Cloud Integration to support client certificate authentication, we need to create an instance and a generate a service key for the certificate.

Back to the SAP BTP Cockpit, Click on Instances and Subscription and Click on Create

 

Create%20new%20Instance

Screenshot taken from SAPBTP: Create new Instance

Give a name to your instance as shown below for example clientcertificate and make sure the Service is “Process Integration Runtime”

Click on Next and Create a service instance with Grant-types set to Client Credentials.

Service%20Instance%20Parameter

Screenshot taken from SAPBTP : Service Instance Parameter

 

Refer to 3171264 – New Configuration Steps to Configure Client Certificate Authentication (integration-flow Plan)

If everything goes well, a new service instance will be created – this may takes some time.

 

After that we have to create a service key as below and we need to provide the X509 client certificate to the service key.

Click on the three dots beside the instance which was created earlier and select Create Service Key

 

Screenshot taken from SAPBTP : Service Instance Parameter

 

Under the External Certificate field ( Highlighted in RED), we need to copy the content of the X.509 certificate of the newly signed certificate.

 

Enter the certificate that was provided to you by external CA.

Enter the PEM-encoded X.509 certificate.

PEM stands for Privacy Enhanced Mail and is a common format for X.509 certificates. It contains base64-encoded text content with the string —–BEGIN CERTIFICATE—– at the beginning and the string —–END CERTIFICATE—– at the end of the character sequence.

Example:

—–BEGIN CERTIFICATE—–MIIHyDCCBrCgAwIB[…]CAq8Tn7kSFDmVnrXe6v8hcQ==—–END CERTIFICATE—–

Don’t enter the whole certificate chain but enter the main server certificate.

Keep rest of the settings as they are –

Validity in days : 365

Key Size : 2048

 

Now come back to the backend Netweaver system and create a new RFC ( G Type) as below

 

RFC

Screenshot taken from ECC : RFC Configuration

RFC%20Settings

Screenshot taken from ECC : RFC Configuration

 

Make sure you have selected the correct dedicated PSE for the SSL Certificate Option which was created earlier.

 

Now the moment of truth – Hit the “Connection Test” button and that should be it. It should work, If it doesn’t then back to basics – increase the ICM Trace and see what is going wrong.

 

Two things you might want to keep in mind

  • You may would like to restart ICM once from transaction code SMICM before you want to test the RFC.
  • Signing of certificate by external CAs will involve cost.

There is already a whitepaper in the following WiKi which I had refered:

Sara Sampaio

Sara Sampaio

Author Since: March 10, 2022

0 0 votes
Article Rating
Subscribe
Notify of
0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x