2.

Connecting a Customer System to SAP HCI

Getting Started:

You can set up the technical connection between a tenant and different kinds of remote systems (in
many cases located in the customer landscape).

The process of connecting a remote system to the integration platform (SAP HCI) – also referred to
as onboarding process - depends on the chosen security option. This task requires the cooperation of
experts at SAP and at customer's side.

Throughout this documentation we assume the following basic setup of technical components and
communication paths: A remote system (which is not specified) is being connected to one of the
tenants that are assigned to the customer. 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.

Throughout this documentation, the terms inbound and outbound reflect the perspective of the
integration platform.

 Inbound refers to message processing from a remote system (in many cases, located in the
customer landscape) to the integration platform (which is based on SAP HANA Cloud
Platform). Here, the integration platform is the server.
 Outbound refers to message processing from the integration platform to a remote system
(where the integration platform is the client).

Introduction

You can connect various kinds of remote systems to the cloud-based integration platform using
protocols such as HTTP/S, SSH and SMTP/S. Each communication protocol comes with certain options
to protect the message exchange (security options).

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 1
 2. Connecting a Customer System to SAP HCI

Kind of Systems to Connect to SAP HCI

To give you an idea of which kinds of remote systems can be connected to the integration platform,
here are some typical examples (this is not a complete list):

 On-premise systems, for example, SAP systems based on SAP NetWeaver

 SFTP servers
 Cloud applications, for example, SAP SuccessFactors or SAP Cloud for Customer
 Other systems such as e-mail servers or SOAP clients

Depending on the kind of system to connect, a certain communication protocol is to be considered, as

will be explained below.

To support dedicated kinds of systems (through dedicated communication protocols), the integration
platform provides certain adapters. An adapter allows you to configure the details of the technical
communication channel between the remote system and the integration platform.

Supported Protocols

First task when setting up an integration scenario is to set up a secure transport channel between the
remote system and SAP HCI. The following protocols can be used: Hypertext Transfer Protocol Secure
(HTTPS), SSH File Transfer Protocol (SFTP) and Simple Mail Transfer Protocol (SMTP), respectively
SMTP secured with transport layer security (SMTPS).

Note: That HTTPS is based on the Transport Layer Security (TLS) protocol.

The following table provides more information on the different aspects to consider for each protocol.

Table 1: Protocols

Protocol Call Direction On Premise On Premise Further Aspects to

(Mandatory) (Recommended) Consider

HTTP, HTTPS Inbound HTTP/S sender HTTP/S proxy Firewall to set up and
system (for example, configure
SAP ERP Central
Component

HTTP, HTTPS Outbound HTTP/S receiver Web Firewall to set up and

system (for example, Dispatcher OR SAP configure
SAP ERP Central Cloud Connector

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 2
 2. Connecting a Customer System to SAP HCI

Table 1: Protocols

Protocol Call Direction On Premise On Premise Further Aspects to

(Mandatory) (Recommended) Consider

Component

SSH Outbound SFTP server (to store Tooling for ssh key Virus scanner on
files) management inbound directory

SMTP, SMTPS Outbound Mail server SMTPS (SMTP over Virus scanner on
SSL/TLS) support of inbound mail boxes
mail server

For each protocol, different authentication options are supported - ways how the connected systems
prove their trustworthiness against each other during connection setup. Connection setup is
performed differently, depending on whether inbound communication (when a remote system as a
sender calls SAP HCI) or outbound communication (when SAP HCI calls a remote system which, in
turn, is then considered as the receiver) is configured. The detailed procedure also depends on the
chosen protocol and authentication option.

Adapters

The following figure illustrates some options for kinds of systems to connect to SAP HCI. Both
communication directions are considered: systems sending messages to SAP HCI and systems that
receive messages from SAP HCI. The figure also shows which communication protocols and the SAP
HCI adapters that are to be configured in order to enable SAP HCI to connect to the respective kind of
system. Note that the figure only shows some typical use cases and is not complete.

The following table lists the available adapters:

 Ariba sender or receiver adapter

Connect a tenant to the Ariba network (this allows SAP and non-SAP cloud applications to
send and receive business-specific documents in cXML format to and from the Ariba network).

 Facebook receiver adapter

Access and extract information from Facebook based on certain criteria such as keywords or
user data.

 HTTP receiver adapter

Connect to a receiver system using the HTTP protocol.

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 3
 2. Connecting a Customer System to SAP HCI
 HTTPS sender adapter

Connect to a sender system using the HTTPS protocol.

 IDoc sender or receiver adapter

Exchange IDoc messages with another system.

 LDAP receiver adapter

Connect to LDAP directory service

 Mail sender adapter

Receiver e-mails from an e-mail server.

 Mail receiver adapter

Send e-mails to an e-mail server.

 OData sender and receiver adapter

Connect to systems exposing OData services (OData service providers).

OData stands for the Open Data Protocol.

 ODC receiver adapter

Connect to SAP Gateway OData Channel

 SFTP sender adapter

Connect to a remote system using the SSH File Transfer protocol (also referred to as Secure
File Transfer protocol) to read (poll) files from the system.

 SFTP receiver adapter

Connect to a remote system using the SSH File Transfer protocol to write files to the system.

 SOAP /SOAP 1.x sender and receiver adapter

Exchange messages with another system that supports SOAP 1.1 or SOAP 1.2.

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 4
 2. Connecting a Customer System to SAP HCI
 SOAP / SOAP RM sender and receiver adapter

Exchange messages with another system based on the SOAP communication protocol and
SAP RM as the message protocol.

 SuccessFactors sender and receiver adapter

Connect to a SuccessFactors system using the SOAP, OData, and REST message protocol.

 Twitter receiver adapter

Access Twitter and either read or post tweets.

As well as the transport-level security options, you can also secure the communication at message
level. This protects the content of the exchanged messages by means of digital encryption and
signatures. Various security standards are available to do this: PKCS#7, XML Digital Signature,
OpenPGP, and WS-Security.

Detailed Steps Setting Up the Tenant Client Keystore

A tenant client keystore is required for each tenant that sends messages to a receiver system (server).
It is the storage location for the tenant client certificate. Additionally, the required server root
certificates from the connected external systems have to be imported into the tenant client keystore.

You have installed the KeyStore Explorer.

For the procedure described in this documentation, it is assumed that you are using the KeyStore
Explorer. You can download this tool from http://keystore-explorer.sourceforge.net/ .

1. Open the KeyStore Explorer and choose New.

2. For type of keystore select JCEKS.

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 5
 2. Connecting a Customer System to SAP HCI

JCEKS provides a stronger encryption than JKS.

3. Choose Tools Generate Key Pair .

4. As Algorithm select RSA or DSA, and for Key Size select 2048.
5. Choose OK.
6. For Version select Version 3, and for Signature Algorithm select SHA-256 with RSA.
Choose a Validity Period as required for your scenario.
7. Next to the Name field, click Edit Name.
8. In the next dialog, enter the name parts.

The information you need to enter depends on who is the owner of the tenant for which the
keystore and the contained client certificate are being generated.

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 6
 2. Connecting a Customer System to SAP HCI
Enter the relevant information to identify your tenant as the owner of the certificate.

o Password
o Common Name (CN)

Enter a meaningful common name of your choice.

o Organizational Unit (OU)

Enter a short name for your (the customer's) organizational unit.

o Organization Name (O)

Enter a short name for your (the customer's) organization.

o Locality Name (L)

Enter the name of your (the customer's) location.

o State Name (ST)

Enter the name of your (the customer's) state.

o Country (C)

Enter the name of your (the customer's) country.

You do not need to make an entry for the Email (E) field.

9. Choose OK.
10. Enter a key alias.

When creating SSH keys (for SFTP), enter one the following kay aliases.

Option Description

id_rsa When you have selected RSA as Algorithm.

id_dsa When you have selected DSA as Algorithm.

11. Choose OK.

12. Enter (and repeat) the keystore password.

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 7
 2. Connecting a Customer System to SAP HCI
You need a password to protect the private key.

Note: There is the option to specify different passwords to protect a private key and to
protect the keystore as a whole.To set up a tenant client keystore, it is mandatory that identical
passwords are used.

Note: When you specify the password, follow the password rules as described in a separate
topic.

13. The key pair has been generated successfully.

14. When you save the keystore for the first time, you have to specify the keystore password.
15. Use the same password as for the protection of the private key.
16. When you save the keystore, enter .jks as the file extension.

The client certificate created initially is self-signed (owner and issuer are identical) and therefore needs
to be signed by a certification authority (CA). To initiate this step, create a certificate signing request
(CSR). The CA sends back the signed certificate, and you can then update your keystore accordingly.

When you import an existing key pair into the keystore, and you have the choice among different files
with different Key Pair Type, we recommend to choose the option PKCS #12 (in case one key pair file
corresponding to this format is available). This format contains the certificate in addition to the private
key. If you choose one of the other Key Pair Types, the certificate has to be specified separately.

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 8
 2. Connecting a Customer System to SAP HCI

Creating X.509 Keys

You need X.509 keys to configure communication with certificate-based authentication over HTTPS and
if you want to configure digital encryption and signing of messages with security standards PKCS#7
and XML Digital Signature.

Generating a Key Pair

You have installed the KeyStore Explorer.

For the procedure described in this documentation, it is assumed that you are using the KeyStore
Explorer. You can download this tool from http://keystore-explorer.sourceforge.net/ .

1. Open the KeyStore Explorer and open a keystore or create a new one.

When creating a keystore, for type of keystore select JCEKS.

JCEKS provides a stronger encryption than JKS.

2. Choose Tools Generate Key Pair .

3. As Algorithm select RSA and for Key Size select 2048.
4. Choose OK.
5. For Version select Version 3, and for Signature Algorithm select SHA-256 with RSA.
Choose a Validity Period as required for your scenario.

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 9
 2. Connecting a Customer System to SAP HCI

6. Next to the Name field, click Edit Name.

7. In the next dialog, enter the name parts.

The information you need to enter depends on who is the owner of the tenant for which the
keystore and the contained client certificate are being generated.

Enter the relevant information to identify your tenant as the owner of the certificate.

o Password
o Common Name (CN)

Enter a meaningful common name of your choice.

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 10
 2. Connecting a Customer System to SAP HCI
Caution: Do not use *.hana.ondemand.com as the Common Name (CN).

Note: Note the following with regard to the usage of wildcards in the CN entries (for
example *.mycompany.com):

For inbound certificate-based client authentication (where the CA-signed certificate needs
to be imported into the customer’s back-end systems), wildcards in the CN field are allowed.

For outbound certificate-based client authentication (where you have to import the CA-
signed certificate into the tenant keystore), wildcards in the CN field are not allowed.

Note that the terms inbound and outbound always refer to the integration platform/tenant.

o Organizational Unit (OU)

Enter a short name for your (the customer's) organizational unit.

o Organization Name (O)

Enter a short name for your (the customer's) organization.

o Locality Name (L)

Enter the name of your (the customer's) location.

o State Name (ST)

Enter the name of your (the customer's) state.

o Country (C)

Enter the name of your (the customer's) country.

You do not need to make an entry for the Email (E) field.

8. Choose OK.
9. Enter a key alias.

When creating SSH keys (for SFTP), enter one the following key aliases.

Option Description

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 11
 2. Connecting a Customer System to SAP HCI

Option Description

id_rsa When you have selected RSA as Algorithm.

id_dsa When you have selected DSA as Algorithm.

10. Choose OK.

11. Enter (and repeat) the keystore password.

You need a password to protect the private key.

Note: There is the option to specify different passwords to protect a private key and to
protect the keystore as a whole.

To set up a tenant client keystore, it is mandatory that identical passwords are used.

Note: When you specify the password, follow the password rules as described in a separate
topic.

12. The key pair has been generated successfully.

13. When you save the keystore for the first time, you have to specify the keystore password.

Use the same password as for the protection of the private key.

14. When you save the keystore, enter .jks as the file extension.

The client certificate created initially is self-signed (owner and issuer are identical) and therefore needs
to be signed by a certification authority (CA). To initiate this step, create a certificate signing request
(CSR). The CA sends back the signed certificate, and you can then update your keystore accordingly.

When you import an existing key pair into the keystore, and you have the choice among different files
with different Key Pair Type, we recommend to choose the option PKCS #12 (in case one key pair file
corresponding to this format is available). This format contains the certificate in addition to the private
key. If you choose one of the other Key Pair Types, the certificate has to be specified separately.

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 12
 2. Connecting a Customer System to SAP HCI

Basic Authentication

Basic authentication allows a the tenant to authenticate itself against the receiver through credentials (user
name and password).

How it Works

The following figure shows the setup of components required for this authentication option.

Basic authentication for HTTPS-based outbound calls works the following way:

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 13
 2. Connecting a Customer System to SAP HCI
1. The tenant (client) sends a message to the customer back-end system.

The HTTP header of the message contains user credentials (name and password).

To protect the user credentials during the communication step, the connection is secured using SSL.

2. The customer back-end authenticates itself as server against the tenant using a certificate (the
customer back-end identifies itself as trusted server).

To support this, the keystore of the customer back-end system must contain a server certificate signed
by a certification authority. To be more precise, the keystore must contain the complete certificate
chain. On the other side of the communication, the keystore of the connected tenant must contain the
customer back-end server root certificate.

3. The tenant is authenticated by the customer back-end by evaluating the credentials against the
user stored in a related data base connected to the customer back-end.

Required Security Material

Table 1: Certificates for Outbound Message Processing

Keystore Security Element Description

Keystore (tenant-specific) Receiver server root certificate This certificate is required to identify the
root CA that is at the top of the
certificate chain that ultimately
guarantees the trustability of the
receiver server certificate.

Receiver keystore Receiver server certificate (signed by This certificate is required to identify the
CA with which the tenant has a trust receiver (to which the tenant connects
relationship) as the client) as a trusted server.

User credentials artefact User and password With these credentials the tenant
authenticates itself as client at the
receiver system.

Client Certificate Authentication

The following figure shows the setup of components required for this authentication option.

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 14
 2. Connecting a Customer System to SAP HCI

How it Works

The tenant authenticates itself against the receiver based on a certificate.

This authentication option works the following way:

1. The tenant sends a message to the receiver.

2. The receiver authenticates itself (as trusted server) against the tenant when the connection is being
set up.

In this case, the receiver acts as server and the authentication is based on certificates.

3. Authentication of the tenant: The identity of the tenant is checked by the receiver by evaluating the
client certificate chain of the tenant.

As prerequisite for this authentication process, the client root certificate of the tenant has to be
imported into the receiver keystore (prior to the connection set up).

As CA who provides the root certificate, Cyber trust Public Sure Server SV CA is used.

Steps 2 and 3 are referred to as mutual SSL handshake.

4. Authorization check: The permissions of the client (tenant) are checked in a subsequent step by the
receiver.

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 15
 2. Connecting a Customer System to SAP HCI

Setting up Message-Level Security Use Cases

On top of the secure transport channel (that is based either on HTTPS or SFTP), you can additionally protect
the message exchange by digital encrypting and signing the message.

To do that, you can use different security standards.

Inbound: Message-Level Security With PKCS#7, XML DigitalSignature

On top of a secure transport channel (for example, based on HTTPS), you have the option to implement
message-level security capabilities. That way, you can protect the message by applying digital signing or
encryption. Asymmetric key technology is used in the following way to implement these features:

Table 1: Keys for Message-Level Security

Key Type Usage

Private key Used by a sender to sign a message

Used by a receiver to decrypt a message (that has been encrypted by a sender)

Public key Used by a receiver to verify a message (signed by a sender)

Used by a sender to encrypt a message

In the inbound case, the tenant acts as receiver that either decrypts or verifies a message.

To implement message-level security for the standards PKCS#7, WS-Security, and XML Digital Signature, you
use X.509 certificates (the same type of certificates as used for HTTPS-based transport-level security).
However, note that different keys are usually used for message-level security and SSL transport-level security.
XML Digital Signature supports only the use cases of signing/verifying messages.

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 16
 2. Connecting a Customer System to SAP HCI

Configuring the Sender

Configure the sender keystore in the following way:

 Generate a key pair (and get it signed by a CA).

 Import the tenant public key into the sender keystore.

Provide SAP with the public key (is used to verify messages sent to the tenant).

Configuring the Integration Flow Steps for Message-Level Security

Depending on the desired option, configure the security-related integration flow steps.

 Configure the Verifyer (PKCS7 or XML Signature Verifyer) step.

Specify the Public Key Aliases in order to select the relevant keys from the tenant keystore.

 Configure the Decryptor (PKCS7) step.

Make sure that you specify the Public Key Aliases for all expected senders (only if you have
specified Enveloped or Signed and Enveloped Data or Signed and Enveloped
Data for Signatures in PKCS7 Message).

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 17
 2. Connecting a Customer System to SAP HCI
These are the public key aliases corresponding to the private keys (of the expected senders) that are
used to sign the payload. The public key aliases specified in this step restrict the list of expected
senders and, in this way, act as an authorization check.

In general, an alias is a reference to an entry in a keystore. A keystore can contain multiple public keys. You
can use a public key alias to refer to and select a specific public key from a keystore.

Inbound: Message-Level Security with OpenPGP

On top of a secure transport channel (for example, based on HTTPS), you have the option to implement
message-level security capabilities. That way, you can protect the message by applying digital signing or
encryption. Asymmetric key technology is used in the following way to implement these features:

Table 1: Keys for Message-Level Security

Key Type Usage

Private key Used by a sender to sign a message

Used by a receiver to decrypt a message (that has been encrypted by a sender)

Public key Used by a receiver to verify a message (signed by a sender)

Used by a sender to encrypt a message

In the inbound case, the tenant acts as receiver that either decrypts or verifies a message.

To implement message-level security for OpenPGP, you use PGP keys.

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 18
 2. Connecting a Customer System to SAP HCI

Configuring the Sender

1. Generate and configure the PGP keys and the storage locations (PGP secret and public keyrings) for
the sender system.
2. Import the related public keys from the tenant into the public PGP keyring of the sender and finish the
configuration of the sender system.

Provide SAP with the public key (is used to verify messages sent to the tenant).

Configuring the Integration Flow Steps for Message-Level Security

Configure the security-related integration flow steps.

Configure the Decryptor (PGP) and Verifyer (PGP) step.

When signatures are expected, make sure that you specify the Signer User ID of Key(s) from Public
Keyring for all expected senders.

Based on the signer user ID of key(s) parts, the public key (for message verification) is looked up in the PGP
public keyring. The signer user ID of key(s) key parts specified in this step restrict the list of expected senders
and, in this way, act as an authorization check

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 19
 2. Connecting a Customer System to SAP HCI

Outbound: Message-Level Security With PKCS#7, XML DigitalSignature

On top of a secure transport channel (for example, based on HTTPS), you have the option to implement
message-level security capabilities. That way, you can protect the message by applying digital signing or
encryption. Asymmetric key technology is used in the following way to implement these features:

Table 1: Keys for Message-Level Security

Key Type Usage

Private key Used by a sender to sign a message

Used by a receiver to decrypt a message (that has been encrypted by a sender)

Public key Used by a receiver to verify a message (signed by a sender)

Used by a sender to encrypt a message

In the outbound case, the tenant acts as sender that either encrypts or signs a message.

To implement message-level security for standards PKCS#7, WS-Security, and XML Digital Signature, you use
X.509 certificates (the same type of certificates as used for HTTPS-based transport-level security). However,
note that different keys are usually used for message-level security and SSL transport-level security. XML
Digital Signature supports only use cases for signing and verifying messages.

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 20
 2. Connecting a Customer System to SAP HCI

Configuring the Receiver

Configure the receiver keystore in the following way:

 Generate a key pair (and get it signed by a CA).

 Import the tenant public key into the receiver keystore.

Provide SAP with the public key (is used to encrypt messages sent to the receiver).

Configuring the Integration Flow Steps for Message-Level Security

Depending on the desired option, configure the security-related integration flow steps.

 Configure the Verifyer (PKCS7 or XML Signature Verifyer) step.

Specify the Public Key Aliases in order to select the relevant keys from the tenant keystore.

 Configure the Decryptor (PKCS7) step.

Make sure that you specify the Public Key Aliases for all expected senders (only if you have
specified Enveloped or Signed and Enveloped Data or Signed and Enveloped
Data for Signatures in PKCS7 Message).

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 21
 2. Connecting a Customer System to SAP HCI
These are the public key aliases corresponding to the private keys (of the expected senders) that are
used to sign the payload. The public key aliases specified in this step restrict the list of expected
senders and, in this way, act as an authorization check.

In general, an alias is a reference to an entry in a keystore. A keystore can contain multiple public keys. You
can use a public key alias to refer to and select a specific public key from a keystore.

Outbound: Message-Level Security with OpenPGP

On top of a secure transport channel (for example, based on HTTPS), you have the option to implement
message-level security capabilities. That way, you can protect the message by applying digital signing or
encryption. Asymmetric key technology is used in the following way to implement these features:

Table 1: Keys for Message-Level Security

Key Type Usage

Private key Used by a sender to sign a message

Used by a receiver to decrypt a message (that has been encrypted by a sender)

Public key Used by a receiver to verify a message (signed by a sender)

Used by a sender to encrypt a message

In the outbound case, the tenant acts as sender that either encrypts or signs a message.

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 22
 2. Connecting a Customer System to SAP HCI
To implement message-level security for OpenPGP, you use PGP keys.

Configuring the Receiver

1. Generate the PGP keys and the storage locations (PGP secret and public keyrings) for the receiver
system.
2. Import the related public keys from the tenant into the public PGP keyring of the receiver and finish the
configuration of the receiver system.

Provide SAP with the public key ( used to encrypt messages sent to the receiver).

Configuring the Integration Flow Steps for Message-Level Security

Depending on the desired option, configure the security-related integration flow steps.

 Configure the Encryptor (PGP) step.

Specify the User ID of Key(s) from Public Keyring in order to select the relevant public receiver keys
from the PGP public keyring.

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 23
 2. Connecting a Customer System to SAP HCI

Specific Use CasesTechnical Landscape for On Premise-On Demand

Integration

As one example for certificate-based connectivity, customer intends to connect a customer-based SAP on-
premise system (based on SAP Application Server ABAP with SAP HCI.

The following figure illustrates the required keystores and security artifacts for the mentioned landscape.

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 24
 2. Connecting a Customer System to SAP HCI

Note We use the following abbreviations in this documentation:

 AS for SAP Application Server

 WD for SAP Web Dispatcher
 HCI for SAP HANA Cloud Integration

In the proposed system landscape, SAP Web Dispatcher is used in the on premise customer landscape to
receive incoming calls from SAP HCI. SAP Web Dispatcher (as reverse proxy) is the entry point for HTTPS
requests into the customer system landscape.

Communication SAP HCI to SAP Application Server

In the proposed landscape, two SSL connections have to be implemented on the way in between HCI and
AS, because SAP Web Dispatcher - interconnected in between - terminates all SSL calls from SAP HCI.
Therefore, the folowing traust relationships have to be implemented:

 Trust relationship between SAP Web Dispatcher and SAP HCI.

As this connection spans the Internet, it is strongly recommended to use certificates that are signed by
a certification authority (CA) that both parties (SAP Web Dispatcher and SAP HCI) trust.

 Trust relationship between SAP Web Dispatcher and AS.

As this connection resides within the customer landscape, it might be an option to use self-signed
certificates for this connection.
Ankaiah Yerraboina (M.Tech)
+91-7993388825 Page 25
 2. Connecting a Customer System to SAP HCI
Note: For reasons of simplicity, within this guide we assume that self-signed certificates are used
for this connection.

The following table summarizes the required certificates and the related keystores.

Table 1: Keystores

Keystore Certificate/Key Description

HCI client keystore HCI client certificate (private and public Required to authenticate SAP HCI as
key) sender of messages.

This security artifact has to be

generated at SAP side and contains the
public and private key of SAP HCI.

The certificate has to be signed by a

certification authority (CA) that both
SAP (HCI) and the customer (WD) trust.

WD server root certificate (of the CA that Required to authenticate WD as receiver

has signed the server certificate) od messages.

This certificate identifies the CA that

has signed the WD server certificate.

WD server keystore HCI client root certificate Required to identify SAP HCI as trusted
communication partner.

(SSL server PSE)

This certificate identifies the CA that
has signed the HCI client certificate.

WD server certificate Required to authenticate WD as trusted

communication partner to receive calls.

This certificate is signed by the CA to

which both WD and HCI have
established a trust relationship.

WD client keystore WD client certificate (private and public Required to authenticate WD as sender
key) of messages.

(SSL client PSE)

This security artifact has to be
generated at customer side and
contains the public and private key of

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 26
 2. Connecting a Customer System to SAP HCI

Table 1: Keystores

Keystore Certificate/Key Description

the WD.

As the related communication path

resides within the customer landscape,
it might be sufficient to use a self-signed
certificate.

Note Customers can extend the use

case in a way that also this certificate
is signed by a CA. This is not covered
in this guide.

AS server keystore WD client certificate (public key) Required to authenticate WD as sender

of messages.

(SSL server PSE)

This public key has to be imported it
into the AS server keystore.

Communication SAP Application Server to SAP HCI

In the proposed landscape, the SSL connection is not terminiated on the way in between AS and SAP HCI
(transparent proxy). Therefore, a trust relationship has to be set up between AS and SAP HCI.

As this connection spans the Internet, it is strongly recommended to use certificates that are signed by a
certification authority (CA) that both parties (AS and HCI) trust.

The following table summarizes the required certificates and the related keystores.

Table 2: Keystores

Keystore Certificate/Key Description

AS client keystore AS client certificate (private and public Required to authenticate AS as sender of
key) messages.

This security artifact has to be

generated at customer side and
contains the public and private key of

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 27
 2. Connecting a Customer System to SAP HCI

Table 2: Keystores

Keystore Certificate/Key Description

AS.

The certificate has to be signed by a

certification authority (CA) that both
SAP (HCI) and the customer (AS) trust.

HCI server root certificate Required to authenticate SAP HCI as

trusted receiver of messages.

This certificate identifies the CA that

has signed the HCI server certificate.

HCI server keystore AS client root certificate Required to authenticate AS as sender of

messages.

This certificate identifies the CA that

has signed the AS client certificate.

This artifact has to be provided by the

customer for SAP during the connection
setup process, and the expert at SAP
side has to import it into the HCI server
keystore.

HCI server certificate Required to authenticate HCI as trusted

communication partner to receive calls.

This certificate is signed by the CA to

which both AS and HCI have
established a trust relationship.

You can find more information on this landscape in the Technical Connectivity Guide for SAP Cloud for Travel:
at https://service.sap.com/ondemand under SAP Cloud for Travel and Expense.

Terms of Use | Copyright/Trademark | Privacy | Legal Disclosure | Disclaimer

Ankaiah Yerraboina (M.Tech)

+91-7993388825 Page 28