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

[pieterjanssens]

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.

-- 
Pieter

[gregorw]

How is the logon sequence configured for the ICF node? For a quick test I tend to create an alias for /sap/bc/ping e.g. /sap/bc/ping_x509 and put the certificate on top.

[pieterjanssens]

I'm using /sap/bc/ping to test and it's using the standard login procedure.

[philipp_seiler]

Have you verified that only ONE user with the email address exists in the client? As there is no search function for the mail address in SU01 you have to use the SE16 for table ADR6 to search for the mail address in SMTP_ADDR (but it's case sensitive, so maybe try to search for lower and upper case variants of the mail address) and then with ADDRNUMBER/PERSNUMBER combination you can find out which user the mail address is assigned in table USR21. In case there is more than one user in the client with this mail address you'll receive a 401.

[pieterjanssens]

@philipp_seiler Yes, by validating that the CERTRULE sample is mapped correctly to a user. If there would be multiple users with the same email address, then the mapping would result in an error.

[philipp_seiler]

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]

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