Client Certificate Signing for Integration Suite – An iFlow That Does the Heavy Lifting

Public Certificate Authorities are phasing out the Client Authentication EKU from publicly trusted SSL/TLS certificates. For inbound scenarios that use Client Certificate Authentication to connect to Cloud Integration or API Management, that EKU is mandatory; certificates without it get rejected at runtime, typically surfacing as an HTTP 401 Unauthorized error on the sender side.

For the full background on this change and the available remediation options, see the SAP KBA 3711618 . for a step-by-step tutorial on the manual way to do that, follow this blog post Integration Suite – Client Authentication EKU deprecation. This blog offers an easy, user-friendly way to do it, all by simply deploying an iFlow.

We have two versions on offer:

• iFlow v1 — full self-service: if you’d rather avoid the technical details of generating a private key and CSR yourself, this version handles all of that for you, end to end.
• iFlow v2 — sign-only: if you’d prefer not to expose your private key to the CPI or iFlow at all, you van generate your private key and CSR separately (e.g., via OpenSSL or your own..), and use this version purely to get your certificate signed by the SAP Cloud Root CA.

Both iFlows need a Destination service instance and service key to call the signing API. How you get there depends on your environment:

• Cloud Foundry subaccount: subscribe to the Destination service and create a service key directly in that subaccount.
• NEO subaccount: you’ll need a Cloud Foundry subaccount as well, since the Destination service used here runs on Cloud Foundry. Creating one alongside your existing NEO subaccount can be done free of charge, with no additional costs involved.

For the step-by-step subscription and service-key creation process, follow the first part of this blog: 
👉SAP Integration Suite – Client Authentication EKU deprecation

Once you’ve subscribed and created the service key, you’ll be left with a service key JSON that looks like this:

we’ll use the clientid, clientsecret, url (token endpoint), and uri (Destination service API endpoint) values from this JSON when configuring the iFlow in the next section.

I. Full Self-Service – Client Certificate Signing via BTP Destination Service v1
If you’d rather not go through the technical the Client Certificate Signing via BTP Destination Service v1 iFlow takes care of all of it for you. The iflow works on both Cloud Foundry and NEO tenants. Under the hood, it handles:

• Generating a private key
• Generating a CSR
• Converting the CSR to Base64
• Fetching an OAuth2 access token
• Making the CSR signing call to the Destination service
• Retrieving the signed certificate
• Converting the response back from Base64
• Attaching the private key and signed certificate.

All you have to do is:
Step 1 — Import the iFlow into your CPI tenant

Download the iflow v1 ZIP file, and then in your cloud Integration tenant go to Design and then choose your desired package or create one, and click on Edit. And then click on Add, then Integration Flow:

You will get a pop up, chose the Upload Option, and then from your downloads choose the Iflow ZIP file that you just downloaded:

And finally click on Add and Open in Editor:

Step 2 — Configure the iflow
Next, navigate to configure. Fill in the following receiver parameters:

• The authentication server, which is the URL from the service key:

• In the receiver field, open the dropbox, and choose the destination server, and fill it with the URI from the service key:

• Next Navigate to more, and configure the rest of the parameters (desired certificate name and CN, client ID and Secret):

Step 3 — Save the configurations & deploy the iflow
Save the configuration, and deploy the iflow:

Finally, go to Monitor Message Processing and filter by the iFlow name. The completed message has two files attached: private_key.pem (the private key generated for your certificate) and CertNameExample.pem (the signed certificate from the SAP Cloud Root CA). Download both and store them.

II. Sign only – Client Certificate Signing via BTP Destination Service v2
If you’d rather not expose your private key to Cloud Integration and the iFlow, you can generate it yourself, either via OpenSSL or directly from your backend system’s STRUST. In that case, the Client Certificate Signing via BTP Destination Service v2 iFlow is your safe choice. Given your CSR, this iFlow takes care of:

• Converting the CSR to Base64
• Fetching an OAuth2 access token
• Making the CSR signing call to the Destination service
• Retrieving the signed certificate
• Converting the response back from Base64
• Attaching the signed certificate.

Next, navigate to configure. Fill in the following receiver parameters:

• The authentication server, which is the URL from the service key:

• In the receiver field, open the dropbox, and choose the destination server, and fill it with the URI from the service key:

• The private key and the signed certificate are both returned in PEM format.
• The signed certificate you receive is actually a full chain: the leaf (your client certificate), one or more intermediates (depending on your tenant’s region), and the root, all concatenated into a single file. Open it in a text editor and copy each block delimited by —–BEGIN CERTIFICATE—– and —–END CERTIFICATE—– into its own file: the first block is the leaf certificate, the next one(s) are the intermediate(s), and the last is the SAP Cloud Root CA. Save each one in whatever format you prefer (.cer works well if you just want to double-click and inspect it).
• Ensure all Destination service configuration values are entered correctly. Even a single extra character (such as a space or line break) can cause errors.

 Public Certificate Authorities are phasing out the Client Authentication EKU from publicly trusted SSL/TLS certificates. For inbound scenarios that use Client Certificate Authentication to connect to Cloud Integration or API Management, that EKU is mandatory; certificates without it get rejected at runtime, typically surfacing as an HTTP 401 Unauthorized error on the sender side.For the full background on this change and the available remediation options, see the SAP KBA 3711618 . for a step-by-step tutorial on the manual way to do that, follow this blog post Integration Suite – Client Authentication EKU deprecation. This blog offers an easy, user-friendly way to do it, all by simply deploying an iFlow.We have two versions on offer:iFlow v1 — full self-service: if you’d rather avoid the technical details of generating a private key and CSR yourself, this version handles all of that for you, end to end.iFlow v2 — sign-only: if you’d prefer not to expose your private key to the CPI or iFlow at all, you van generate your private key and CSR separately (e.g., via OpenSSL or your own..), and use this version purely to get your certificate signed by the SAP Cloud Root CA.Both iFlows need a Destination service instance and service key to call the signing API. How you get there depends on your environment:Cloud Foundry subaccount: subscribe to the Destination service and create a service key directly in that subaccount.NEO subaccount: you’ll need a Cloud Foundry subaccount as well, since the Destination service used here runs on Cloud Foundry. Creating one alongside your existing NEO subaccount can be done free of charge, with no additional costs involved.For the step-by-step subscription and service-key creation process, follow the first part of this blog: 👉SAP Integration Suite – Client Authentication EKU deprecationOnce you’ve subscribed and created the service key, you’ll be left with a service key JSON that looks like this:  we’ll use the clientid, clientsecret, url (token endpoint), and uri (Destination service API endpoint) values from this JSON when configuring the iFlow in the next section.   I. Full Self-Service – Client Certificate Signing via BTP Destination Service v1If you’d rather not go through the technical the Client Certificate Signing via BTP Destination Service v1 iFlow takes care of all of it for you. The iflow works on both Cloud Foundry and NEO tenants. Under the hood, it handles:Generating a private keyGenerating a CSRConverting the CSR to Base64Fetching an OAuth2 access tokenMaking the CSR signing call to the Destination serviceRetrieving the signed certificateConverting the response back from Base64Attaching the private key and signed certificate.All you have to do is:Step 1 — Import the iFlow into your CPI tenant  Download the iflow v1 ZIP file, and then in your cloud Integration tenant go to Design and then choose your desired package or create one, and click on Edit. And then click on Add, then Integration Flow:   You will get a pop up, chose the Upload Option, and then from your downloads choose the Iflow ZIP file that you just downloaded:And finally click on Add and Open in Editor:Step 2 — Configure the iflowNext, navigate to configure. Fill in the following receiver parameters:The authentication server, which is the URL from the service key:In the receiver field, open the dropbox, and choose the destination server, and fill it with the URI from the service key: Next Navigate to more, and configure the rest of the parameters (desired certificate name and CN, client ID and Secret):Step 3 — Save the configurations & deploy the iflowSave the configuration, and deploy the iflow:Finally, go to Monitor Message Processing and filter by the iFlow name. The completed message has two files attached: private_key.pem (the private key generated for your certificate) and CertNameExample.pem (the signed certificate from the SAP Cloud Root CA). Download both and store them.II. Sign only – Client Certificate Signing via BTP Destination Service v2If you’d rather not expose your private key to Cloud Integration and the iFlow, you can generate it yourself, either via OpenSSL or directly from your backend system’s STRUST. In that case, the Client Certificate Signing via BTP Destination Service v2 iFlow is your safe choice. Given your CSR, this iFlow takes care of:Converting the CSR to Base64Fetching an OAuth2 access tokenMaking the CSR signing call to the Destination serviceRetrieving the signed certificateConverting the response back from Base64Attaching the signed certificate.All you have to do is:Step 1 — Import the iFlow into your CPI tenant   Download the iflow v2 ZIP file, and then in your cloud Integration tenant go to Design and then choose your desired package or create one, and click on Edit. And then click on Add, then Integration Flow:      You will get a pop up, chose the Upload Option, and then from your downloads choose the Iflow ZIP file that you just downloaded:  And finally click on Add and Open in Editor: Step 2 — Configure the iflowNext, navigate to configure. Fill in the following receiver parameters:The authentication server, which is the URL from the service key: In the receiver field, open the dropbox, and choose the destination server, and fill it with the URI from the service key: Next Navigate to More, and configure the rest of the parameters (desired certificate name and CN, client ID and Secret, and CSR to sign): Step 3 — Save the configurations & deploy the iflowNext , Save the configuration, and deploy the iflow: Finally, go to Monitor Message Processing and filter by the iFlow name. The completed message has a file attached: CertNameExample.pem (the signed certificate from the SAP Cloud Root CA). Download and store it. Notes: The private key and the signed certificate are both returned in PEM format.The signed certificate you receive is actually a full chain: the leaf (your client certificate), one or more intermediates (depending on your tenant’s region), and the root, all concatenated into a single file. Open it in a text editor and copy each block delimited by —–BEGIN CERTIFICATE—– and —–END CERTIFICATE—– into its own file: the first block is the leaf certificate, the next one(s) are the intermediate(s), and the last is the SAP Cloud Root CA. Save each one in whatever format you prefer (.cer works well if you just want to double-click and inspect it).Ensure all Destination service configuration values are entered correctly. Even a single extra character (such as a space or line break) can cause errors.  Read More Technology Blog Posts by SAP articles 

#SAPCHANNEL