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!

https://launchpad.support.sap.com/#/notes/2462533
https://launchpad.support.sap.com/#/notes/2052899
https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US/a8bb87a72d094e0d981d2b1f67df7bc3.html
https://blogs.sap.com/2017/06/22/how-to-guide-principal-propagation-in-an-https-scenario/
https://blogs.sap.com/?s=principal+propagation

 

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

icm/trusted_reverse_proxy_<x>

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 sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(SSLContextImpl.java:1226) 
at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:1192) 
at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:1106) 
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1626) ... 28 more Caused by: java.security.cert.CertPathValidatorException: Algorithm constraints check failed on signature algorithm: MD5withRSA 
at sun.security.provider.certpath.AlgorithmChecker.check(AlgorithmChecker.java:295) 
at sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(SSLContextImpl.java:1222) ... 31 more| 
+0100#INFO#com.sap.scc.rt#Thread-13# #SccEndpointValidator has thrown exception for HTTPS://xxx.yyy.zzz:8443: java.security.cert.CertificateException: Certificates do not conform to algorithm constraints javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates do not conform to algorithm constraints 
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) 
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)

 

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/java.security and check the parameters

jdk.certpath.disabledAlgorithms
jdk.tls.disabledAlgorithms

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

+0100#ERROR#com.sap.core.connectivity.protocol.http.handlers.HttpAuthenticationHandler#tunnel-client-4-2#0xd2740796#
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,
Domi

8 Comments
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

    icm/trusted_reverse_proxy_<x>

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

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

     

    Regards,

    Florence

     

     

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

    thanks

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

      regards

      Domi

       

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