Authors: Adam Csallokozi, David Domokos

Driven by an industry-wide change by Certification Authorities (see SAP KBA 3711618 – Client Authentication EKU Deprecation), newly procured publicly trusted SSL/TLS certificates may omit the “Client Authentication” Extended Key Usage (EKU) starting May 2026 as CAs separate server and client roles. For inbound scenarios that use Client Certificate Authentication (two‑way SSL/mTLS) with SAP Integration Suite, Cloud Integration, or API Management, the client certificate must include the Client Authentication EKU; certificates lacking this EKU will not be accepted by the Integration Suite endpoints.

There are multiple ways to implement this requirement. In this article,  we will demonstrate one of the three supported approaches, including the technical steps needed to generate and use the client certificate in your integration scenarios.

Let’s first determine your environment 

Before starting the implementation, first determine which environment applies to your landscape. The steps in this guide differ depending on the environment used for generating and signing the client certificate:

If you are working on Cloud Foundry environment please start with Verify the Destination Service chapter

If you are working on Neo environment please start with the Create Cloud Foundry Subaccount chapter

Create Cloud Foundry Subaccount

ℹ️ Please note that all steps described in this section can be performed free of charge and do not involve any additional costs ℹ️

⚠️ Please be aware to perform the listed actions you need to have a Global Account Admin role or appropriate admin colleague is required⚠️

If you are working on Neo environment, first create a new, Cloud Foundry (CF) Subaccount. This is required to use the Destination service to sign certificate.

1. Create the CF Subaccount

Go to your Global Account and click on ‘Create’ then choose ‘Subaccount’

2. Add required data for the new CF Subaccount

 Please fill the required fields:

Display Name: Choose the desired name for your subaccountRegion: Choose the desired region for your subaccount

the rest of the fields will be filled automatically, after that click on ‘Create’.

3. Enable Cloud Foundry

Once the Subaccount has been created, please open it. Click on “Enable Cloud Foundry” button. In the “Enable Cloud Foundry” popup window, input desired value, then press button “Create”. Once see “Cloud Foundry Environment” section get populated with Cloud Foundry organization data, the Subaccount creation is successfully completed. 

ℹ️If you need more detailed guide to complete this step you can check our Help Page: Create a Subaccount ℹ️

Verify the Destination Service

In case you are running Cloud Integration / Integration Suite with CF environment, then please go to the CF subaccount where Cloud Integration / Integration Suite is subscribed. In case you are running Cloud Integration with NEO environment, then please go to the newly created CF subaccount as mentioned in chapter ‘Create Cloud Foundry Subaccount’.  Then access  menu ‘Entitlements’ and confirm ‘Destination Service’ with service plan ‘lite’ is listed.

1. Create the Destination Service Instance and Service Keys

In BTP Cockpit, go to ‘Instances and Subscriptions’ on the left, then choose the ‘Create’ button in the top right corner

In the pop-up, set Service to Destination Service and Plan to lite. Select the Space where you have administrator permissions, then enter an Instance Name that follows your naming convention. Once the Create button is enabled, click Create.

⚠️When you enable Cloud Foundry (CF) for a new subaccount, only the org is created by default, no spaces are created. As a result, when you create a Destination Service instance, you may see a popup (as shown below) prompting you to create a space first ⚠️

  The instance is now created and visible on the Instances list.

Next, create a service key for the instance. Click the “lite” link to open the details panel on the right, navigate to the Service Keys section, and choose Create.

Finally, click View Credentials to display the generated credentials; you’ll use them in the next chapter.

2. Generate the Private Key and a Certificate Signing Request (CSR)

⚠️Command line (CMD) should be opened directly in the folder where the .KEY and .CSR files should be saved + OpenSSL needs to be installed on the computer ⚠️

To generate the private key and the CSR signed by a newly generated private key use openSSL. Execute the following command:

openssl req -utf8 -nodes -sha256 -newkey rsa:3072 -keyout genExample.key -out genExample.csr

⚠️All CSR attributes (shown below) will be overwritten during generation, so avoid spending too much time configuring them ⚠️

The command generates genExample.key (private key). You won’t need it for the API steps, but keep it for later use (for example, when creating a .PFX). As a last step of this chapter, the generated .CSR file needs to be Base64‑encoded. This can be done (in case of Windows operating system) via Windows Powershell.

Open Windows PowerShell in the folder containing genExample.csr and run the command:

[Convert]::ToBase64String([IO.File]::ReadAllBytes(“genExample.csr”))

as a result the Base64 encoded value of the .CSR file will be displayed in the PowerShell window:

Please copy that value and save it because it will be needed in a later step, you can save it as simple text file in the same folder as the previously created files.

3. Generate the OAuth Token for Destination Service

In this step the OAuth token will be generated that is needed for the certificate creation. To retrieve that OAuth token, either follow the API documentation, or download our predefined REST API collection from here. This collection will be used for the rest if the steps in the 4th and 5th chapters.

Open the “DestinationServiceTokenGeneration” request and populate its variables with the actual values from the credentials you created in the last step of Chapter 1 (Create the Destination Service Instance and Service Keys).

Collection VariableActual Value from Credentialshost (in the URL section)url (https://XXXX.authentication.eu12.hana.ondemand.com)clientID (in the Body section)clientid (sb-clone9ae33f841f774443XXXXXXXXXXXXX)clientSecret (in the Body section)clientsecret (1c8d712b-b4ed-42ff-bb17-c2c8db2e166b$ROCeUoa1GXXXXXXXXXXXXX)

After you send the request with your actual values, the response body will include the OAuth token:

4. Generate the Certificate via Destination Service REST API

From the collection, open the request ‘DestinationServiceCertificateGenerator’

Collection VariableActual Value from Credentialshost (in the URL section)uri (https://destination-configuration.cfapps.XXXXXXX.ondemand.com)Name (in payload of the body)Desired name of the created certificate (TestCert)CN_value (in payload of the body)Common Name, represents the primary, specific domain name (MyDomain)Base64_Encoded_CSR (in payload of the body)Paste the Base64 encoded value of .CSR that is created as a last step in the chapter ‘2. Generate the Private Key and a Certificate Signing Request (CSR)’BearerToken (in Authorization Header)Value of the token that is generated in the previous step (eyJ0eXAiOiJKV1QiLCJqaWQiOiJoKys5MWZsblpnVXXXXXXXXXXXXXXXXXX)

In the response of the API call the HTTP 201 – Created should be appear as response code:

5. Retrieve the Newly Generated Certificate

From the collection, open the request ‘FetchNewCertificate’ and a last step retrieve the created certificate chain.

Collection VariableActual Value from Credentialshost (in the URL section)uri (https://destination-configuration.cfapps.XXXXXXX.ondemand.com)name (in the URL section)In the previous step created name of the certificate (TestCert)BearerToken (in Authorization Header)Value of the token that is generated in the previous step (eyJ0eXAiOiJKV1QiLCJqaWQiOiJoKys5MWZsblpnVXXXXXXXXXXXXXXXXXX)

The API should return HTTP 200 OK, and the payload contains the newly created certificate chain, this can be found in the ‘Content’ field:

Save this value in a text file (base64.txt), because it is needed to Base64-decode the value to get the certificate chain. To perform the Base64 decoding open Windows PowerShell in the folder containing the recently saved file and run the command:

$base64 = Get-Content base64.txt -Raw
[IO.File]::WriteAllBytes(“certChain.txt”, [Convert]::FromBase64String($base64))

This command will:

read the Base64 string from base64.txtConvert it to bytesWrite the bytes to certChain.txt in the folder where the PowerShell was opened

Once the command completes, verify that the created file contains content like:

You can then save it as a .PEM file and generate a .PFX for client certificate based authentication, by referring to the blog “Client Certificate Authentication in SAP Cloud Integration: Configuration and Best Practices,” section 1.1/A, “Generating the Client Certificate (.PFX file) – Using OpenSSL.”

ℹ️BTP Connectivity Service on CN data centers signs the keypair using [CDC Cloud Root CA] ℹ️

Create and Load the Client Certificate into S/4HANA (STRUST)

This section explains how to create and load a client certificate in S/4HANA using transaction STRUST. If you’re connecting from S/4HANA, you can generate the CSR directly in STRUST – no OpenSSL needed. After generating the CSR, use the Destination Service API to sign it and obtain the client certificate, then import the signed certificate back into the client PSE in STRUST for client certificate–based authentication.

Create an SSL client PSE in S/4HANA; for exact steps refer to 2. Configuration Steps in the Backend 

Right‑click the PSE and choose Create. (Make sure you are in Change mode.)

Generate new Client Certificate and sign the certificate: STRUST -> Edit -> Create certificate request.

In the popup, select Use PSE algorithm as the Signature algorithm, and press Continue.

Save the signing request, which should have the following format:
—–BEGIN CERTIFICATE REQUEST—–
<CSR>
—–END CERTIFICATE REQUEST—–

Encode the CSR in Base64 (the Destination Service API expects a Base64 string without the PEM headers/footers).

In the DestinationServiceCertificateGeneration request, copy the encoded CSR in the body in the parameter “CSR”.

After the certificate is signed by the Destination Service API, Base64‑decode it, then in STRUST choose Edit -> Import certificate response. Import the full certificate chain (from the decoded file).

Import the Client Certificate into SAP BTP

Cloud Integration running in NEO environment:

In Neo, inbound client-certificate authentication is configured by uploading the caller’s public certificate and mapping it to a platform user. This is done in the Certificate-to-User Mapping monitor in the Operations view.

Open your Cloud Integration tenant and switch to Operations.Go to Manage Security > Certificate-to-User Mapping.Click Add and upload the client’s public certificate file (.cer). Upload only the leaf certificate of the client, not the chain.Assign a user name to this certificate. Use the technical platform user that should run the iFlow.Save the mapping.

Cloud Integration in the Cloud Foundry environment:

To make the client certificate available to your Integration flows, create an external-certificate service key:

Go to the SAP BTP cockpit, open your subaccount, and navigate to Instances and SubscriptionsSelect your desired ‘Process Integration Runtime’ with plan ‘integration-flow’ service instanceChoose Create under Service KeysEnter a name for the service keySet Key Type to External Certificate and paste the PEM-encoded client certificate (only the first/leaf certificate, not the chain) into the External Certificate fieldSelect Create

For more detailed steps, refer to the KBA 3297437  – Client Cert Authentication for Inbound calls to CPI tenants on CF.

Conclusion

The upcoming EKU deprecation underscores the need to proactively adjust certificate management practices in SAP Integration Suite landscapes. By implementing the recommended steps, organizations can maintain secure, compliant client certificate authentication for inbound scenarios. Preparing early helps prevent disruptions and ensures integrations continue to run smoothly as industry standards evolve.

​    Authors: Adam Csallokozi, David DomokosDriven by an industry-wide change by Certification Authorities (see SAP KBA 3711618 – Client Authentication EKU Deprecation), newly procured publicly trusted SSL/TLS certificates may omit the “Client Authentication” Extended Key Usage (EKU) starting May 2026 as CAs separate server and client roles. For inbound scenarios that use Client Certificate Authentication (two‑way SSL/mTLS) with SAP Integration Suite, Cloud Integration, or API Management, the client certificate must include the Client Authentication EKU; certificates lacking this EKU will not be accepted by the Integration Suite endpoints.There are multiple ways to implement this requirement. In this article,  we will demonstrate one of the three supported approaches, including the technical steps needed to generate and use the client certificate in your integration scenarios.Let’s first determine your environment Before starting the implementation, first determine which environment applies to your landscape. The steps in this guide differ depending on the environment used for generating and signing the client certificate:If you are working on Cloud Foundry environment please start with Verify the Destination Service chapterIf you are working on Neo environment please start with the Create Cloud Foundry Subaccount chapter Create Cloud Foundry Subaccountℹ️ Please note that all steps described in this section can be performed free of charge and do not involve any additional costs ℹ️⚠️ Please be aware to perform the listed actions you need to have a Global Account Admin role or appropriate admin colleague is required⚠️If you are working on Neo environment, first create a new, Cloud Foundry (CF) Subaccount. This is required to use the Destination service to sign certificate.1. Create the CF SubaccountGo to your Global Account and click on ‘Create’ then choose ‘Subaccount’2. Add required data for the new CF Subaccount Please fill the required fields:Display Name: Choose the desired name for your subaccountRegion: Choose the desired region for your subaccountthe rest of the fields will be filled automatically, after that click on ‘Create’.3. Enable Cloud Foundry Once the Subaccount has been created, please open it. Click on “Enable Cloud Foundry” button. In the “Enable Cloud Foundry” popup window, input desired value, then press button “Create”. Once see “Cloud Foundry Environment” section get populated with Cloud Foundry organization data, the Subaccount creation is successfully completed. ℹ️If you need more detailed guide to complete this step you can check our Help Page: Create a Subaccount ℹ️Verify the Destination ServiceIn case you are running Cloud Integration / Integration Suite with CF environment, then please go to the CF subaccount where Cloud Integration / Integration Suite is subscribed. In case you are running Cloud Integration with NEO environment, then please go to the newly created CF subaccount as mentioned in chapter ‘Create Cloud Foundry Subaccount’.  Then access  menu ‘Entitlements’ and confirm ‘Destination Service’ with service plan ‘lite’ is listed. 1. Create the Destination Service Instance and Service KeysIn BTP Cockpit, go to ‘Instances and Subscriptions’ on the left, then choose the ‘Create’ button in the top right cornerIn the pop-up, set Service to Destination Service and Plan to lite. Select the Space where you have administrator permissions, then enter an Instance Name that follows your naming convention. Once the Create button is enabled, click Create.⚠️When you enable Cloud Foundry (CF) for a new subaccount, only the org is created by default, no spaces are created. As a result, when you create a Destination Service instance, you may see a popup (as shown below) prompting you to create a space first ⚠️  The instance is now created and visible on the Instances list.Next, create a service key for the instance. Click the “lite” link to open the details panel on the right, navigate to the Service Keys section, and choose Create. In the pop-up, enter a name for the Service Key, then click Create.You should now see the newly created service key listed:Finally, click View Credentials to display the generated credentials; you’ll use them in the next chapter. 2. Generate the Private Key and a Certificate Signing Request (CSR)⚠️Command line (CMD) should be opened directly in the folder where the .KEY and .CSR files should be saved + OpenSSL needs to be installed on the computer ⚠️To generate the private key and the CSR signed by a newly generated private key use openSSL. Execute the following command:openssl req -utf8 -nodes -sha256 -newkey rsa:3072 -keyout genExample.key -out genExample.csr⚠️All CSR attributes (shown below) will be overwritten during generation, so avoid spending too much time configuring them ⚠️The command generates genExample.key (private key). You won’t need it for the API steps, but keep it for later use (for example, when creating a .PFX). As a last step of this chapter, the generated .CSR file needs to be Base64‑encoded. This can be done (in case of Windows operating system) via Windows Powershell.Open Windows PowerShell in the folder containing genExample.csr and run the command:[Convert]::ToBase64String([IO.File]::ReadAllBytes(“genExample.csr”))as a result the Base64 encoded value of the .CSR file will be displayed in the PowerShell window:Please copy that value and save it because it will be needed in a later step, you can save it as simple text file in the same folder as the previously created files.3. Generate the OAuth Token for Destination ServiceIn this step the OAuth token will be generated that is needed for the certificate creation. To retrieve that OAuth token, either follow the API documentation, or download our predefined REST API collection from here. This collection will be used for the rest if the steps in the 4th and 5th chapters.Open the “DestinationServiceTokenGeneration” request and populate its variables with the actual values from the credentials you created in the last step of Chapter 1 (Create the Destination Service Instance and Service Keys).Collection VariableActual Value from Credentialshost (in the URL section)url (https://XXXX.authentication.eu12.hana.ondemand.com)clientID (in the Body section)clientid (sb-clone9ae33f841f774443XXXXXXXXXXXXX)clientSecret (in the Body section)clientsecret (1c8d712b-b4ed-42ff-bb17-c2c8db2e166b$ROCeUoa1GXXXXXXXXXXXXX)After you send the request with your actual values, the response body will include the OAuth token: 4. Generate the Certificate via Destination Service REST APIFrom the collection, open the request ‘DestinationServiceCertificateGenerator’Collection VariableActual Value from Credentialshost (in the URL section)uri (https://destination-configuration.cfapps.XXXXXXX.ondemand.com)Name (in payload of the body)Desired name of the created certificate (TestCert)CN_value (in payload of the body)Common Name, represents the primary, specific domain name (MyDomain)Base64_Encoded_CSR (in payload of the body)Paste the Base64 encoded value of .CSR that is created as a last step in the chapter ‘2. Generate the Private Key and a Certificate Signing Request (CSR)’BearerToken (in Authorization Header)Value of the token that is generated in the previous step (eyJ0eXAiOiJKV1QiLCJqaWQiOiJoKys5MWZsblpnVXXXXXXXXXXXXXXXXXX)In the response of the API call the HTTP 201 – Created should be appear as response code: 5. Retrieve the Newly Generated CertificateFrom the collection, open the request ‘FetchNewCertificate’ and a last step retrieve the created certificate chain.Collection VariableActual Value from Credentialshost (in the URL section)uri (https://destination-configuration.cfapps.XXXXXXX.ondemand.com)name (in the URL section)In the previous step created name of the certificate (TestCert)BearerToken (in Authorization Header)Value of the token that is generated in the previous step (eyJ0eXAiOiJKV1QiLCJqaWQiOiJoKys5MWZsblpnVXXXXXXXXXXXXXXXXXX)The API should return HTTP 200 OK, and the payload contains the newly created certificate chain, this can be found in the ‘Content’ field:Save this value in a text file (base64.txt), because it is needed to Base64-decode the value to get the certificate chain. To perform the Base64 decoding open Windows PowerShell in the folder containing the recently saved file and run the command:$base64 = Get-Content base64.txt -Raw
[IO.File]::WriteAllBytes(“certChain.txt”, [Convert]::FromBase64String($base64))This command will:read the Base64 string from base64.txtConvert it to bytesWrite the bytes to certChain.txt in the folder where the PowerShell was openedOnce the command completes, verify that the created file contains content like:You can then save it as a .PEM file and generate a .PFX for client certificate based authentication, by referring to the blog “Client Certificate Authentication in SAP Cloud Integration: Configuration and Best Practices,” section 1.1/A, “Generating the Client Certificate (.PFX file) – Using OpenSSL.”ℹ️BTP Connectivity Service on CN data centers signs the keypair using [CDC Cloud Root CA] ℹ️Create and Load the Client Certificate into S/4HANA (STRUST)This section explains how to create and load a client certificate in S/4HANA using transaction STRUST. If you’re connecting from S/4HANA, you can generate the CSR directly in STRUST – no OpenSSL needed. After generating the CSR, use the Destination Service API to sign it and obtain the client certificate, then import the signed certificate back into the client PSE in STRUST for client certificate–based authentication. Create an SSL client PSE in S/4HANA; for exact steps refer to 2. Configuration Steps in the Backend Right‑click the PSE and choose Create. (Make sure you are in Change mode.)Generate new Client Certificate and sign the certificate: STRUST -> Edit -> Create certificate request.In the popup, select Use PSE algorithm as the Signature algorithm, and press Continue.Save the signing request, which should have the following format:—–BEGIN CERTIFICATE REQUEST—–<CSR>—–END CERTIFICATE REQUEST—–Encode the CSR in Base64 (the Destination Service API expects a Base64 string without the PEM headers/footers).In the DestinationServiceCertificateGeneration request, copy the encoded CSR in the body in the parameter “CSR”.After the certificate is signed by the Destination Service API, Base64‑decode it, then in STRUST choose Edit -> Import certificate response. Import the full certificate chain (from the decoded file).Import the Client Certificate into SAP BTPCloud Integration running in NEO environment:In Neo, inbound client-certificate authentication is configured by uploading the caller’s public certificate and mapping it to a platform user. This is done in the Certificate-to-User Mapping monitor in the Operations view.Open your Cloud Integration tenant and switch to Operations.Go to Manage Security > Certificate-to-User Mapping.Click Add and upload the client’s public certificate file (.cer). Upload only the leaf certificate of the client, not the chain.Assign a user name to this certificate. Use the technical platform user that should run the iFlow.Save the mapping.Cloud Integration in the Cloud Foundry environment:To make the client certificate available to your Integration flows, create an external-certificate service key:Go to the SAP BTP cockpit, open your subaccount, and navigate to Instances and SubscriptionsSelect your desired ‘Process Integration Runtime’ with plan ‘integration-flow’ service instanceChoose Create under Service KeysEnter a name for the service keySet Key Type to External Certificate and paste the PEM-encoded client certificate (only the first/leaf certificate, not the chain) into the External Certificate fieldSelect CreateFor more detailed steps, refer to the KBA 3297437  – Client Cert Authentication for Inbound calls to CPI tenants on CF.ConclusionThe upcoming EKU deprecation underscores the need to proactively adjust certificate management practices in SAP Integration Suite landscapes. By implementing the recommended steps, organizations can maintain secure, compliant client certificate authentication for inbound scenarios. Preparing early helps prevent disruptions and ensures integrations continue to run smoothly as industry standards evolve.    Read More Technology Blog Posts by SAP articles 

#SAP

#SAPTechnologyblog