Quick Guide on using Certificates for Integrating C4C and ECC using HCI

In this document I share my learning about using Certificates in the Integration between C4C and ECC using HCI. It’s mainly an assimilation of information from the Integration Guides – but purely focused on using Certificates. It should be similar for CRM as well

Quick Reference for Certificates Configuration – between C4C and ECC
using HCI

Basically, the Client should trust the Server and the Server should trust the Client for a mutual SSL handshake to happen. To have this trust, both the client and server should provide their certificate/identification to the other. ECC/HCI/C4C behave as a client or server depending upon the direction of flow of information and based on who they are communicating with – Eg: both C4C and ECC communicate with HCI either in an Inbound direction or Outbound direction

A.   For Inbound communication from ECC to C4C via HCI:

There are 2 parts to the trust:

1. Between ECC and HCI and
2. Between HCI and C4C

Between ECC and HCI: ECC is the Client (The side initiating the request is deemed as Client, hence ECC is the Client) and HCI is the Server accepting the request. Hence there should be mutual trust between the two. Then, HCI becomes the Client and C4C the Server, and mutual trust should exist between the two

1. ECC is Client, HCI is server:
   1. HCI should trust ECC as a client ->

• ECC’s own Client Certificate has to be an approved one. This should not be a Self- Signed certificate(like shown below), instead should be a signed one by a valid/approved CA. A certificate request can be created from the STRUST and sent to the CA for signing. Later, the Signed response can be imported back here

• HCI should have this Signed ECC Client Certificate in its iFlows: Once a valid Signed Certificate has been obtained for the Client in ECC, in HCI, in the iFlows – eg.Material replication, using certificate based authentication, this ECC Client Cert needs to be uploaded to the iFlow – Export this SSL Client Certificate from STRUST and import to the iFlow in HCI

b.      ECC should trust HCI as a Server: HCI is the server for ECC, and the HCI Server Root Certificate has to be imported to STRUST in ECC.           HCI Worker node URL has the certificate chain which should be imported in STRUST – SSL Client. The Root of the certificate chain is sufficient for this – in case you get errors, you can import the Intermediate as well as shown below

  2.      Between HCI and C4C, HCI becomes the client and C4C is the server

1. C4C as a Server should trust the HCI client cert
   • In the HCI provisioning mail, the HCI Client Certificate details are provided – or raise a ticket. This then needs to be uploaded to C4C in the communication arrangement for Inbound communications, and
   • the CA for the HCI cert should be in the trust list of C4C

     b. HCI should trust the C4C Server Cert – Nothing needs to be done for this, as this is already taken care of within HCI.

B. For Outbound communications from C4C to HCI:

There are 2 parts to the trust:

1. Between C4C to HCI and
2. Between HCI to ECC

1. Between C4C to HCI : C4C is the client and HCI is the server (C4C is the one initiating the request, hence is deemed as the Client)

1. The CA for the HCI server cert should be in the trust list of C4C
2. C4C client certificate should be imported to the iFlows in HCI in the sender channel – You need to export the x.509 certificate from C4C Communication arrangements and import it to the iFlows in HCI

           c. HCI server should be trusted by C4C client. Nothing needs to be done for this

2. HCI is the Client and ECC is the server

1. ECC- In the Server SSL, the HCI client certificate has to be imported in STRUST

          The HCI client certificate is present inside the key store of HCI. You need to request operations team to provide you the corresponding public certificate, from which you can get the issuer certificate (raise a ticket for this). This then needs to be present in the Server PSE of ECC.

2 things:

1. Actual HCI Client certificate that comes with the provisioning Mail – You can use this to do the User->Certificate mapping explained later

2. The Certificate Chain of HCI as a client -> Request for this in LOD-HCI, and once obtained, import it to the STRUST list of the PSE Server (This may or may not be required, but for me it worked with having this complete information)

Additionally the issuer certificate of HCI should be stored in the system which is facing the internet.

– For example if HCI can directly connect to backend system then the root certificate of HCI should be placed in the Server PSE of the backend system.

– If there is a reverse proxy which receives the request from HCI then the root certificate of HCI should be placed in the trust store of the proxy server.

For simplicity reasons, this blog does not talk about the Reverse Proxy  Scenario in between HCI and ECC.

Upload to STRUST Server SSL

b.    ECC should have a signed Server Root certificate, which should be trusted by HCI in its keystore. Do ensure that this is not a self-signed certificate as it would not work

A Certified Root Server Certificate one has to be obtained by the customer and uploaded here

Mapping the Integration User to the Certificate

When using Certificate based Authentication, the user needs to be mapped to the certificate – so that this certificate can be used to authenticate the
user. The certificate that you need to map can be found in the HCI provisioning mail as an attachment

Create Service Account for Connectivity from HCI to ERP

1. From transaction SU01, create a service account with the type C or B and assign the custom roles :

SAP_SD_COD_INTEGRATION

SAP_SD_COD_INTEGRATION_EXT

In the following example, the CODINTG user is mapped to the HCI client certificate. To map HCI Client Certificate with Service Account, follow the
steps below.

6. Select the file that contains the public certificate and click Open.