Skip to Content
Technical Articles
Author's profile photo Dominik Bigl

Principal Propagation in an HTTPS Scenario – Some Hints From My Journey

If you want to setup Principal Propagation you will definitely need the following links and How-To guides. You will find nearly everything to configure your SCP and ABAP backend to use Principal Propagation!


But when setting up Principal Propagation in different environments, I faced some other issues. Here are some more hints from my journey:


Always use parameter icm/trusted_reverse_proxy_<x>, if available! icm/HTTPS/trust_client_with_subject and icm/HTTPS/trust_client_with_issuer didn’t work for me!

Browser Cache

Always completely close your browser to check a changed configuration! Also use incognito mode and sometimes even clear the whole browser cache – especially if you have several accounts, sub accounts and user.

SSSLERR_SSL_ACCEPT – received a fatal TLS certificate unknown alert message from the peer

In the ICM Trace file you see something like this:

<<- ERROR: SapSSLSessionStart(sssl_hdl=000000000790FBA0)==SSSLERR_SSL_ACCEPT
*** ERROR => IcmConnInitServerSSL: SapSSLSessionStart returned (-56): SSSLERR_SSL_ACCEPT [icxxconn.c 1737]
SSL_get_state()==0x1180 "TLS read client certificate A"
*** ERROR during SecuSSL_SessionStart() from SSL_accept()==SSL_ERROR_SSL
session uses PSE file ".....SAPSSLS.pse"
SecuSSL_SessionStart: SSL_accept() failed (536875078/0x20001046)
=> "received a fatal TLS certificate unknown alert message from the peer"


And in the cloud connector log ljs_trace.log you find this:

at ... 28 more Caused by: Algorithm constraints check failed on signature algorithm: MD5withRSA 
at ... 31 more| #SccEndpointValidator has thrown exception for HTTPS://xxx.yyy.zzz:8443: Certificates do not conform to algorithm constraints Certificates do not conform to algorithm constraints 


Please check Note 1848999 – Central Note for CommonCryptoLib 8 (SAPCRYPTOLIB) and patch your Kernel and CryptoLib. Then exchange/recreate the certificates of your ABAP system (Tx STRUST).

While waiting for the Kernel patch you can change the JRE security settings used for the cloud connector (NOT RECOMMENDED – just for testing on development systems!):

Open the file …/jre/lib/security/ and check the parameters


Remove the algorithm mentioned in the log, e.g.: 

Algorithm constraints check failed on signature algorithm: MD5withRSA 


Restart your cloud connector.

Unable to generate authorization token for user XXX on system YYY.

Check the cloud connector log file ljs_trace.log
Unable to generate authorization token java.lang.IllegalStateException: The variable 'login_name' needed for object CN is not available in context.


Some attribute used in the Subject Pattern for the short-lived certificate is not available.

Change the pattern is the cloud connector configuration


Or change the configuration of your Trusted Identity Provider in the Cloud Cockpit:



Will be updated after my next funny hours with this cool stuff ;)!


Have fun,

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Phil Cooley
      Phil Cooley

      Thanks for sharing Domi Bigl - nice idea - as there can be a large number of reasons why Principal Propagation does not work. Particularly interested in this ICM parameter


      as I have not used this previously but still managed to get PP working. Any idea what the normal values should be and what this actually does?

      Thanks again!

      Phil Cooley

      Author's profile photo Domi Bigl
      Domi Bigl
      Blog Post Author

      Hi Phil Cooley

      Thank you!

      icm/trusted_reverse_proxy_<x> was introduced with Note 2025899 to support multiple trusted proxies. It's also described in by Michael Van Cutsem





      Author's profile photo Phil Cooley
      Phil Cooley

      OK, thanks Domi Bigl - will check both of those references out. I have read Michael's blog a few times but have just noticed the additional reference on May 2018. Read the blog before then :-).


      Author's profile photo Markus Tolksdorf
      Markus Tolksdorf


      Hi Domi,

      as soon as one entry for icm/trusted_reverse_proxy_<x> is present, both icm/HTTPS/trust_client_with_subject and icm/HTTPS/trust_client_with_issuer will be ignored. That might have been a reason why you could not make it work with the latter two. From content perspective, you would have added the very same values.

      Best regards,

      Author's profile photo Florence Mae Guzon
      Florence Mae Guzon



      I am wondering about this parameter icm/trusted_reverse_proxy_<x>. I have tried it but after that my connection from Cloud to On-premise is not reacheable. So I had to remove it again.

      Should we remove the parameters icm/HTTPS/trust_client_with_subject and icm/HTTPS/trust_client_with_issuer, if we will use icm/trusted_reverse_proxy_<x>?






      Author's profile photo Yogendra Ahuja
      Yogendra Ahuja

      Hi Domi Bigl

      i am getting the same error  for

      SSSLERR_SSL_ACCEPT – received a fatal TLS certificate unknown alert message from the peer

      please suggest the solution you had to resolve this issue, from the provided note i did not get the exact solution.


      Author's profile photo Dominik Bigl
      Dominik Bigl
      Blog Post Author

      Hi Yogendra Ahuja


      For productive use it's strongly recommended to patch the CryptoLib and Kernel as described in the note!

      My temporary - NOT RECOMMENDED - solution was to remove the unsupported signature algorithm (found in ljs_trace.log) from the Java configuration file




      Author's profile photo Jonas Meyer
      Jonas Meyer

      Hi Dominik

      I was wondering about the possibilites of your last step "assertion attributes mapping" in Cloud Foundry SCP subaccounts? There is no form like in NEO subaccounts to configure the mapping.


      All I have is the mail attribute mapping in IAS, but when I do Principal Propagation to my ERP backend, I get:

      The variable 'mail' needed for object CN is not available in context

      We've done PP many times with mostly NEO accounts and it always worked, Cloud Connector config was never changed.

      Thank you and KR

      Author's profile photo Florian Preuß
      Florian Preuß

      Hi Dominik,

      having the same issue and got stuck setting up PP between CF and ERP backend. Any help would be highly appreciated.

      Best Regards,

      Author's profile photo Bruno Amaral
      Bruno Amaral

      I am having the same issue. "The variable 'mail' needed for object CN is not available in context".

      Did you find the solution?


      Best Regards,


      Author's profile photo Jonas Meyer
      Jonas Meyer

      Still fighting with CF subaccounts! IDP delivers all assertion attributes needed by the application and backend for principal propagation.

      Found this note

      "Cloud Foundry:

      In the CF environment, the user's JWT is forwarded to the Cloud Connector. Currently, it is only possible to configure one of the attributes present in the root path of the JWT.

      The UAA automatically maps the following attributes from the SAML assertion to the JWT when the user authenticates on CF:

      first_name -> given_name
      last_name -> family_name
      mail -> email
      NameID -> user_name

      Only the attributes on the right hand side can be configured as Subject Pattern.


      1. Choose another attribute for CN which exists in the SAML/JWT token instead of the current one.
      2. (not valid for CF) If you want to keep the current mapping of attributes, they need to be set in the Trusted Identity Provider configuration. For this please contact with your IDP admin


      Love it. 🙂

      I wonder if this is still true, because it would mean a real mess with existing Principal propagation scenarios for multiple customers...

      Author's profile photo Jonas Meyer
      Jonas Meyer

      Another update, I'm getting closer:

      "When using a subaccount in the Cloud Foundry environment: As of version 2.12.5, the Cloud Connector also offers direct access to custom variables injected in the JWT (JSON Web token) by SAP BTP Authorization & Trust Management that were taken over from a SAML assertion."

      We have SCC version So obviously there's an upgrade needed first. I can also imagine that app developers also need to get active afterwards for "custom variables injected in the JWT"...

      Author's profile photo Jonas Meyer
      Jonas Meyer

      Hi all, if anyone's still interested - that's how I solved it for multiple customers:

      If you are freshly implementing Principal Propagation with CF only:

      • Send claim user_name from IdP
      • Define user_name as CN in Cloud Connector

      If you add CF subaccounts to existing Principal Propagation with NEO:

      • Send claim user_name from IdP
      • Define user_name as CN in Cloud Connector
        • This replaces any other CN option used by NEO scenarios before (e.g. login_name), so:
        • Existing scenarios are invalidated and need a refresh by creating new sample certificate and importing it to CERTRULE (replace existing rule)

      Helpful sources:

      Principal Propagation with Cloud Foundry: