cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

User principal certificate from trustworthy issuer is not leading to login session

pieterjanssens
Active Participant
0 Kudos
783


ICM trace on level 3 seems to indicate the principal propagation certificate is accepted:

 

 

 

[Thr 139903707502336] HttpHandleCertificate: Client certificate received: with len=1278, subj="CN=sapcc, EMAIL=pieter@xxx.com", issuer="CN=sapcc, EMAIL=pieter@xxx.com", cipher="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"                
[Thr 139903707502336] HttpCertIsReverseProxyTrustworthy: intermediate is trustworthy (i:s):     
[Thr 139903707502336] "CN=sapcc, EMAIL=pieter@xxx.com:CN=sapcc, EMAIL=pieter@xxx.com"                                                                                                                                                  
[Thr 139903706973952] HttpIsReverseProxyTrustworthy: intermediary is trusted
[Thr 139903706973952] HTTP request [14/15/1] Accept trusted forwarded certificate (received via HTTPS with trusted certificate): subject="CN=pieter@xxx.com", issuer="CN=sapcc, EMAIL=pieter@xxx.com" 
[Thr 139903706973952] HttpModGetDefRules: determined the defactions: COPY_CERTHEADER_TO_MPI STATIC_OPERATIONS (130)
[Thr 139903706973952] HttpModHandler: decode SSLCERT from header
[Thr 139903706973952] HttpModHandler: perform the actions: COPY_CERTHEADER_TO_MPI STATIC_OPERATIONS (130)
...

 

 

 

Then it returns a 401. There is no sign of any user mapping in ICM (level 3) or in SEC_TRACE_ANALYZER (level 3).

  • CERTRULE is setup to map the subject from CN attribute to the email address of the user.
  • login/certificate_mapping_rulebased is set to '1' after which I restarted ICM
  • I'm using /sap/bc/ping to test and it's using the standard login procedure.

Where to look next?

[UPDATE 8/10 15h13 CEST]
SM50 security trace on level 3 is showing new info
I'm now realizing that "login/certificate_mapping_rulebased" is not an icm parameter and so not activated by restarting ICM... restart incoming.

SCR-20241008-nkcd-2.png

 

 

 

-- 
Pieter

Accepted Solutions (1)

Accepted Solutions (1)

pieterjanssens
Active Participant

I'm happy to report - "Server reached." 

Some important lessons learned:

Many thanks for your suggestions@Ulrich_Schmidt1 @philipp_seiler @gregorw which helped me to pursue finding the solution! 

Answers (2)

Answers (2)

Ulrich_Schmidt1
Product and Topic Expert
Product and Topic Expert
0 Kudos

I know there are two certificates involved in the Principal Propagation scenario:

  1. The certificate used during TLS handshake between SCC and SAP backend system. This is called "system certificate" in the SCC. It needs to have "special" permissions in the SAP system, as otherwise the SAP system won't allow the system represented by the certificate to "impersonate" multiple different users via temporary certificates (as in point 2).
  2. Possibly multiple short-lived end-user certificates, which are used for login.

I am not completely sure, but the message

Accept trusted forwarded certificate (received via HTTPS with trusted certificate): subject="CN=pieter@xxx.com", issuer="CN=sapcc, EMAIL=pieter@xxx.com"

is a bit unclear to me. Is this the "system certificate" that is used to establish a trust relationship between SCC and backend, or is this a "user certificate" that is supposed to be used for login? Could it be that the "CN=pieter" certificate is accidentally used for both? I know that a certificate that is defined as "system certificate" cannot at the same time be used as a "user certificate". (I.e. the settings in icm/trusted_reverse_proxy_<x> overrule the CERTRULE settings.) Perhaps this can be a reason, why the certificate is ignored in the CERTRULE mapping?!

Where to look next? It might help to activate the SSL/TLS trace in the SCC and check, which certificates are actually exchanged, both in the handshake as well as in the CLIENT_CERT header field.

pieterjanssens
Active Participant
0 Kudos
I've added the log statements that show the CA certificate (CN=sapcc) to be accepted.
philipp_seiler
Explorer
0 Kudos

Okay, then at least that should be fine. What we also faced in the past and resulted in a 401 with PP was that the request was made to the wrong backend client due to a misconfiguration on BTP side. But I assume you already verified that as well in the ICM trace?

pieterjanssens
Active Participant
0 Kudos
I haven't set it explicitly in the destination, but in the ICM trace I do see the incoming request to contain the correct client in the header 'sap-client'.