2024 Oct 07 9:37 PM - edited 2024 Oct 08 2:16 PM
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).
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
Request clarification before answering.
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I know there are two certificates involved in the Principal Propagation scenario:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
41 | |
15 | |
10 | |
9 | |
6 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.