Skip to Content
Product Information
Author's profile photo Simon Luser

UPDATES for Principal Propagation in an HTTPS Scenario

You might know this blog post for setting up Principal Propagation in an HTTPS Scenario to ABAP – in my blog post some extended information is going to be collected and new features are explained which try to ease the configuration process. It will be continuously updated.

Things to take care of

Certificate Version and CA Flag for Cloud Connector’s System Certificate

Background

To forward a principal received from the cloud, an mTLS connection from Cloud Connector to the ABAP backend needs to be established. This means both partners need to authenticate and trust each other. Cloud Connector needs to trust the server certificate of the backend in its trust store, while ABAP needs to trust the system certificate (i.e. the client certificate) of the Cloud Connector (transaction STRUST). The trust is established successfully if any certificate of the PKI certificate chain is trusted.
If an SAP Web Dispatcher is in between, mutual trust needs to be established along this chain additionally.

Potential issue

If an own x.509 system certificate is used, make sure when you import it on the backend site (with e.g. STRUST) that it has either Version 1 or Version 3. For Version 3 you need to make sure that the extension Basic Constraints: Critical CA is set!

ICM properties trusted_reverse_proxy and trust_client_with_issuer

Background

The Internet Communication Manager (ICM) needs to trust the system certificate of the Cloud Connector for principal propagation. As described here, those properties need to be set correctly.

Potential issue

There are two valid approaches:

  1. Using icm/trusted_reverse_proxy_<x> parameters, especially if multiple trusted reverse proxies need to be specified
  2. Using (older) icm/HTTPS/trust_client_with_issuer and icm/HTTPS/trust_client_with_subject parameter to specify one trusted reverse proxy

Please make sure to specify only one of these approaches!
If both are set, the new ones will be ignored as also mentioned in Note 2052899.

Connection Check Feature

With Cloud Connector version 2.14 the connection check feature has been extended in order to provide more valuable information, especially for the Principal Propagation use case.

How does it work?

If you have followed the steps for the initial configuration and created a system mapping, you can execute a connection check:Executing%20connection%20check
You will afterwards see if the internal host could be technically reached or not in the ‘Check Result’ column. In this example the host could not be reached. To see further details you can click on the ‘Show Details’ button.Check%20Result
Under ‘Connection Check Details’ you can find additional information why the connection could not be established. Here the connection has been refused, i.e. the target application is currently not listening on the internal port, or the wrong port has been entered. Connection%20refused
If you have corrected the mapping configuration, and in the ‘Check Result’ column it says Reachable a basic TLS connection could have been created successfully. However, for Principal Propagation mTLS is needed. In order to get more information, especially with respect to the client authentication, you can check the details view again. As you can see here, a System Certificate is missing to enable mTLS. The next step would be to import a System Certificate.Client%20Authentication%20Information
With this connection check feature, you are now able to incrementally check where the current configuration is wrong and stuck and get hints on how to resolve the issue.

Which dedicated checks are currently available?

Basic network issues

  • Wrongly entered host name which cannot be resolved
  • Refused connections due to wrong or inactive remote ports

TLS issues –¬†Server Authentication

  • Cloud Connector does not trust the partner’s certificate in its trust store

TLS issues –¬†Client Authentication

  • No System Certificate acting as a client certificate is provided by Cloud Connector
  • Partner does not request Client Authentication during the TLS handshake
  • Partner is not trusting the System Certificate of Cloud Connector

For each of these issues a detailed message, the thrown exception, and a hint on how to resolve the issue are displayed.

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.