Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

How to Guide - Troubleshooting Principal Propagation - ICM Traces

former_member250012
Explorer
‎2017 Jun 26 12:04 PM
18,380

How to Guide


Troubleshooting Principal Propagation


ICM Traces on the ABAP stack


 

 

Introduction


This How to Guide comes as a follow up to the one explaining how to implement Principal Propagation in an HTTPS scenario.

The intend of this document is first to explain how to configure and how to use the ICM traces but also to highlight the output of ICM (Internet Communication Manager) traces while breaking the working configuration allowing Principal Propagation to occur in an HTTPS scenario.

Prerequisites


The starting point of this How to Guide is built on the outcome of the How to Guide dedicated to the implementation of Principal Propagation in an HTTPS scenario.  The following diagram illustrates the architecture of our lab environment.  To get more details on this please check the documents mentioned previously.


What kind of information can be seen from the ICM Traces?


Logs collected on ICM level can only reveal details of the communication directly happening with the SAP Frontend Server.  In the context at hand, that’s the details related to the communication between the SAP Cloud Connector and the SAP Frontend Server.

We should thus find information about the SSL handshake between those two components and see the details of the short-lived certificated built by the SAP Cloud Connector.

Configuring the ICM Trace level



  1. Go to transaction SMICM

  2. Go to “Goto” menu > Trace Level > Set


  3. Enter the value 3 to get a maximum of information.

  4. Click on the change button to save the modifications.


Cleaning the ICM Traces



  1. Go to transaction SMICM

  2. Go to “Goto” menu > Trace File > Reset

  3. Confirm in pressing Yes


Viewing the ICM Traces


The traces can of course be viewed from inside SAP Logon but that not the most convenient especially when the traces get lengthy…  I would rather recommend to open it using a different editor such as Notepad++ or Baretail…

  1. Go to transaction SMICM

  2. Go to “Goto” menu > Trace File > Save Locally

  3. Give it a name and press Save

  4. Press Allow (and check the Remember My Decision)

  5. Press the Ok button


 

Example of ICM Traces in the context of Principal Propagation


It’s of course not possible to cover all the scenarios that could lead to error.  Here are nevertheless some typical problems that could happened and their impact on the ICM traces.

Displaying all the logs of each scenario here doesn’t make much sense but I have extracted the most important pieces of information that can be seen from these traces.

Output of a working configuration


The interesting part starts with this line, indicating that a client is establishing a new session with the SAP Frontend Server.
[Thr 7684] CCL[SSL]: Srv-0000000C: Client requested for new session

The following lines indicates which are the trusted CA from the SAP Frontend side and their verification in the context of the SSL handshake.
[Thr 7684] CCL[SSL]: Srv-0000000C: Sending own certificate [ssl3_output_cert_chain]

[Thr 7684] CCL[SSL]: Srv-0000000C: Own TLS certificate

[Thr 7684]  Subject                      :CN=*.wdf.sap.corp, OU=TDI, O=SAP, C=DE

[Thr 7684]  Issuer                       :CN=SAPNetCA_G2, O=SAP, L=Walldorf, C=DE

[Thr 7684]  Serial number                :0x01125e

[Thr 7684]  [ssl3_output_cert_chain]

[Thr 7684] CCL[SSL]: Srv-0000000C: CA certificate

[Thr 7684]  Subject                      :CN=SAPNetCA_G2, O=SAP, L=Walldorf, C=DE

[Thr 7684]  Issuer                       :CN=SAP Global Root CA, O=SAP AG, L=Walldorf, C=DE

[Thr 7684]  Serial number                :0x610e063700000000000c

[Thr 7684]  [ssl3_output_cert_chain]

[Thr 7684] CCL[SSL]: Srv-0000000C: Requesting for client authentication. [ssl3_send_certificate_request]

[Thr 7684] CCL[SSL]: Srv-0000000C: Offering 2 certificate type(s) for client authentication:

[Thr 7684]     rsa_sign(1)

[Thr 7684]     ecdsa_sign(64)

[Thr 7684]  [ssl3_get_req_cert_type]

[Thr 7684] CCL[SSL]: Srv-0000000C: Offering 2 trusted CA(s) for client authentication:

[Thr 7684]     CA  <0>: CN=private.root.ca, OU=TechEd2017, O=SAP, C=DE

[Thr 7684]     CA  <1>: CN=SAP Global Root CA, O=SAP AG, L=Walldorf, C=DE



Here are the certificates received from the client and their validation, still for the SSL handshake.



[Thr 7684] CCL[SSL]: Srv-0000000C: Received client certificate chain. [ssl3_decode_client_certificate]

[Thr 7684] CCL[SSL]: Srv-0000000C: Client certificate details

[Thr 7684]  Subject                      :CN=vmw6281.wdf.sap.corp, OU=TechEd2017, O=SAP, C=DE

[Thr 7684]  Issuer                       :CN=private.root.ca, OU=TechEd2017, O=SAP, C=DE

[Thr 7684]  Serial number                :0x03

[Thr 7684]  [ssl3_decode_client_certificate]

[Thr 7684] CCL[VERIFY]: Srv-0000000C: Verification result of SSL client certificate (successful)

[Thr 7684]  Verification result header

[Thr 7684]   Verified certificate

[Thr 7684]    Subject                      :CN=vmw6281.wdf.sap.corp, OU=TechEd2017, O=SAP, C=DE

[Thr 7684]    Issuer                       :CN=private.root.ca, OU=TechEd2017, O=SAP, C=DE

[Thr 7684]    Serial number                :0x03

[Thr 7684]    -----BEGIN CERTIFICATE-----



[…]



[Thr 7684]    -----END CERTIFICATE-----

[Thr 7684]   Used signer certificate

[Thr 7684]    Subject                      :CN=private.root.ca, OU=TechEd2017, O=SAP, C=DE

[Thr 7684]    Issuer                       :CN=private.root.ca, OU=TechEd2017, O=SAP, C=DE

[Thr 7684]    Serial number                :0x01

[Thr 7684]    -----BEGIN CERTIFICATE-----



[…]



[Thr 7684]    -----END CERTIFICATE-----

[Thr 7684]  Certificate verification result

[Thr 7684]   Certificate

[Thr 7684]    Subject                      :CN=vmw6281.wdf.sap.corp, OU=TechEd2017, O=SAP, C=DE

[Thr 7684]   Verification result

[Thr 7684]    Status                      :Successful

[Thr 7684]    SignerStatus                :Successful

[Thr 7684]    SignerVerificationResult

[Thr 7684]     Element #1

[Thr 7684]      Status                      :Successful

[Thr 7684]      Validity                    :Successful

[Thr 7684]      BasicConstraints            :Successful

[Thr 7684]      KeyUsage                    :Successful

[Thr 7684]      ObjectStatus                :Successful

[Thr 7684]      SignerCert

[Thr 7684]       Certificate

[Thr 7684]        Subject                      :CN=private.root.ca, OU=TechEd2017, O=SAP, C=DE

[Thr 7684]       Verification result

[Thr 7684]        Status                      :Successful

[Thr 7684]        DirectlyTrusted             :Successful

[Thr 7684]  Trust in PSE:

[Thr 7684]   Token URI                      : tokpse:D:\usr\sap\TDI\D00\sec\SAPSSLS.pse

[Thr 7684]   Trusted certificate            : CN=*.wdf.sap.corp, OU=TDI, O=SAP, C=DE

[Thr 7684]   Trusted certificate            : CN=SAP Global Root CA, O=SAP AG, L=Walldorf, C=DE

[Thr 7684]   Trusted certificate            : CN=private.root.ca, OU=TechEd2017, O=SAP, C=DE

And probably the most important part, the certificate presented to the SAP Frontend Server by the SAP Cloud Connector.
[Thr 7684] Forwarded Client certificate: subject="CN=I063866", issuer="CN=localca.cc.wdf.sap.corp, OU=TechEd2017, O=SAP, C=DE"



[…]



[Thr 7684] HTTP request [3/787/1] Accept trusted forwarded certificate (received via HTTPS with trusted certificate): subject="CN=I063866", issuer="CN=localca.cc.wdf.sap.corp, OU=TechEd2017, O=SAP, C=DE"

This information matches perfectly the configuration made on the cloud connector since the test performed using Web IDE uses the corporate identity certificate existing in the machine.  This certificate is initially issued by another CA as it can be seen here under:



Here is the configuration that dictates how the short-lived certificate should be built.  Nothing beside the Common Name is defined.





Later in the trace we can also see the following lines confirming the access to the requested data:
[Thr 7988] HTTP response (raw) [3/787/1]:

[Thr 7988]   HTTP/1.1 200 OK

 

Output of an incomplete configuration – STRUST


For this test, we have removed from the STURST configuration the private root ca from the list of certificates under Server SSL Standard.  This means that the SAP Frontend Server doesn’t have the mean to verify the certificate that are given to it…



In the logs, the SSL handshake did not happen properly. The most important entry of the traces is the following:
[Thr 4324] HttpModIsReverseProxyTrustworthy: client did not sent any cert ->intermediate not trustworthy

[Thr 4324] HttpModGetDefRules: intermediary is NOT trusted -> remove SSL header fields

[Thr 4324] HTTP request [2/890/1] Reject untrusted forwarded certificate (received via HTTPS without certificate): subject="CN=I063866", issuer="CN=localca.cc.wdf.sap.corp, OU=TechEd2017, O=SAP, C=DE"

We can also see the following entries in the logs explaining why we get a prompt for credentials to access the SAP Frontend Server:
[Thr 4324] HTTP response (raw) [2/890/1]:

[Thr 4324]   HTTP/1.1 401 Unauthorized

Output of an incomplete configuration – CERTRULE


In this context, we haven’t configured the mapping of the user.  It is thus impossible of the SAP System to translate the user that comes in into a local user…



In the ICM Trace, while the SSL handshake worked fine we can see the following message in the logs:
[Thr 6136] HTTP response (raw) [3/1346/1]:

[Thr 6136]   HTTP/1.1 401 Unauthorized

While we had a 200 with the correct configuration.  This means that the SAP Frontend server just refused to grant access to the requested content unless you provide other credentials…

Output of an incomplete configuration - RZ10


While for all the previous test we make the configuration pretty loose in RZ10 we tried to make it a bit stricter before introducing an error in it…

For the previous tests the parameter “icm/HTTPS/trust_client_with_issuer” was set to “*”.  Before running into this scenario, we set the value to “CN=private.root.ca, OU=TechEd2017, O=SAP, C=DE” which is the correct configuration.



Now we will modify this configuration to “CN=localca.cc.wdf.sap.corp, OU=TechEd2017, O=SAP, C=DE” which could seem to be fine as well and see the outcome.

No surprise, once again we get the prompt for credentials meaning that we couldn’t access the backend resources.  This is confirmed by the HTTP 401 that we get:
[Thr 5036] HTTP response (raw) [1/12/1]:

[Thr 5036]   HTTP/1.1 401 Unauthorized

But more important we can also see the following lines:
[Thr 5036] HttpModGetDefRules: Client certificate received: with len=1061, subj="CN=vmw6281.wdf.sap.corp, OU=TechEd2017, O=SAP, C=DE", issuer="CN=private.root.ca, OU=TechEd2017, O=SAP, C=DE", cipher="TLS_RSA_WITH_AES128_GCM_SHA256"

[Thr 5036] HttpModIsReverseProxyTrustworthy: intermediate cert issuer "CN=private.root.ca, OU=TechEd2017, O=SAP, C=DE" does not match trusted issuer "CN=localca.cc.wdf.sap.corp, OU=TechEd2017, O=SAP, C=DE"

[Thr 5036] HttpModGetDefRules: intermediary is NOT trusted -> remove SSL header fields

[Thr 5036] HTTP request [1/12/1] Reject untrusted forwarded certificate (received via HTTPS with untrusted certificate): subject="CN=I063866", issuer="CN=localca.cc.wdf.sap.corp, OU=TechEd2017, O=SAP, C=DE"

The message highlight clearly that there is a mismatch between two issuers.  We already know the solution to this specific problem…

 

 
4 Comments
Labels in this area
Popular Blog Posts