Skip to Content
Technical Articles

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,

You must be Logged on to comment or reply to a post.
  • 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


    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,

  • Hi


    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>?






  • 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.


    • 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




  • 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

      • 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,


        • 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...