Skip to Content

By now, you already know how to setup the SM50 logon trace and how to configure the system to use X.509 client certificates.

Now it is time to go a bit deeper in the logon trace (and some other resources) and see what happens to have the SSO working.

Test: web browser side

Using IE or any other web browser, access a service in the ECC, e.g. the WEBGUI service (SAPGUI for HTML). The URL is:

https://<FQDN>/sap/bc/gui/sap/its/webgui

The port number is hidden (443 is the default HTTPS port).

The expected result is the WEBGUI loaded:

X.509.jpg

The question is: what happened behind the scenes? Using Fiddler I can see the SSL connection being established:

“…

HTTP/1.0 200 Connection Established

Secure Protocol: Tls12

Cipher: Aes128 128bits

Hash Algorithm: Sha256 ?bits

Key Exchange: RsaKeyX 4096bits

== Client Certificate ==========

[Subject]

  CN=…

[Issuer]

  CN=…

[Serial Number]

  6…

[Not Before]

  …

[Not After]

  …

[Thumbprint]

  …

== Server Certificate ==========

[Subject]

  CN=…

[Issuer]

  CN=…

[Serial Number]

  0…

[Not Before]

  …

[Not After]

  …

[Thumbprint]

  2…

…”

So, the client certificate was sent to the ECC system. Where can I see the certificate? What happened then?

Test: ECC side, part 1: ICM trace


The ICM is the actual web server of the SAP system. It will receive the HTTP/HTTPS requests and, according to the configuration, pass the information to the appropriate handler.

In the ICM trace file, I can find the certificate information. Note that I set, prior of calling the WEBGUI service, the ICM trace level to 3, so I have a lot of information! I also set icm/trace_secured_data=1, so the HTML code is recorded in the trace file.

In the ICM trace file, I could find the following information:

“…

[Thr 3852] IcmWorkerThread: worker 8 got the semaphore

[Thr 3852] DoW moY dd hh:mm:ss yyyy

[Thr 3852] REQ TRACE BEGIN: 4/2944/1

[Thr 3852] REQUEST:

    Type: ACCEPT_CONNECTION    Index = 3891

[Thr 3852] CONNECTION (id=4/2944):

    used: 1, type: default, role: Server(1), stateful: 0

    NI_HDL: 115, protocol: HTTPS(2)

    local host:  xx.yyy.zzz.aa:443 ()

    remote host: xx.bbb.ccc.ddd:53128 ()

    status: NOP

    connect time: dd.mm.yyyy hh:mm:ss

    MPI request:        <0>      MPI response:        <0>     MPI next: <0>

    request_buf_size:   0 response_buf_size:   0

    request_buf_used:   0 response_buf_used:   0

    request_buf_offset: 0        response_buf_offset: 0

…”

This is the moment that the ICM received the request, so thread 3852 will process my connection.

The ICM is acting as a server and, having auth_type=1 (ICM parameter: icm/HTTPS/verify_client=1), the client certificate is requested.

“…

[Thr 3852] ->> SapSSLSessionInit(&sssl_hdl=0000000020162400, role=2 (SERVER), auth_type=1 (ASK_CLIENT_CERT))

[Thr 3852] <<- SapSSLSessionInit()==SAP_O_K

[Thr 3852]      in: args = “role=2 (SERVER), auth_type=1 (ASK_CLIENT_CERT)”

[Thr 3852]     out: sssl_hdl = 000000000554DC50

[Thr 3852] ->> SapSSLSetNiHdl(sssl_hdl=000000000554DC50, ni_hdl=115)

[Thr 3852]   SSL NI-hdl 115: local=xx.yyy.zzz.aa:443  peer=xx.bbb.ccc.ddd:53128

[Thr 3852] <<- SapSSLSetNiHdl(sssl_hdl=000000000554DC50, ni_hdl=115)==SAP_O_K

[Thr 3852] ->> SapSSLSessionStart(sssl_hdl=000000000554DC50)

…”

The SSL handshake happens, where server and client check their respective cipher suites, and decided for one:

“…

[Thr 3852]   Server-configured Ciphersuites: “TLS_RSA_WITH_AES128_GCM_SHA256:TLS_RSA_WITH_AES256_GCM_SHA384:TLS_RSA_WITH_AES128_CBC_

[Thr 3852]   Client-offered Ciphersuites: “TLS_ECDHE_RSA_WITH_AES256_CBC_SHA384:TLS_RSA_WITH_AES256_GCM_SHA384:TLS_RSA_WITH_AES128_G

[Thr 3852]   Client Certificate available (FCPath-Len= 0)

[Thr 3852]   New session (TLSv1.2, TLS_RSA_WITH_AES128_GCM_SHA256)

[Thr 3852]   HexDump of new SSL session ID { &buf= 000000002040B73C, buf_len= 32 }

…”

The client certificate is received:

“…

[Thr 3852] Base64-Dump of peer certificate (len=1052 bytes)

[Thr 3852]

[Thr 3852] —–BEGIN CERTIFICATE—–

[Thr 3852] MIIEGDCC 4 g w B g K T c gG   B   FA v  s  Q D

[Thr 3852] l  7/   i n   R   q g    Qu   Y o   8=

[Thr 3852] —–END CERTIFICATE—–

[Thr 3852]<<- SapSSLSessionStart(sssl_hdl=000000000554DC50)==SAP_O_K

[Thr 3852]  in/out: status = “new SSL session,TLSv1.2,TLS_RSA_WITH_AES128_GCM_SHA256, received client cert”

[Thr 3852]   Subject DN = “CN=…”

[Thr 3852]   Issuer  DN = “CN=CA Cert…”

…”

The URL requested was:

“…

[Thr 3852] Address   Offset IcmReadFromConn received

[Thr 3852] ————————————————————————

[Thr 3852] 0000000020714358  000000  47455420 2f736170 2f62632f 6775692f |GET /sap/bc/gui/|

[Thr 3852] 0000000020714368  000016  7361702f 6974732f 77656267 75692048 |sap/its/webgui H|

[Thr 3852] 0000000020714398  000064  5454502f 312e310d 0a416363 6570743a |TTP/1.1..Accept:|

[Thr 3852] 00000000207143A8  000080  20746578 742f6874 6d6c2c20 6170706c | text/html, appl|

[Thr 3852] 0000000020714568  000528  0a0d0a                              |…             |

[Thr 3852] ————————————————————————

[Thr 3852] HttpPlugInHandleNetData(rqid=4/2944/1): role: Server(1), status: 1

[Thr 3852]    content-length: 0/0, buf_len: 531, buf_offset: 0, buf_status: 0

[Thr 3852]   GET /sap/bc/gui/sap/its/webgui HTTP/1.1

[Thr 3852]   accept: text/html, application/xhtml+xml, */*

[Thr 3852]   user-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; Touch; rv:11.0) like Gecko

[Thr 3852]   accept-encoding: gzip, deflate, peerdist

…”

Additional information from the peer:

“…

[Thr 3852] Connection Info: role=Server, local=FQDN:443, peer=xx.bbb.ccc.ddd, protocol=HTTPS

[Thr 3852] ->> SapSSLGetPeerInfo(sssl_hdl=000000000554DC50, &cert=000000003F55E6B8, &cert_len=000000003F55E6B0,

[Thr 3852]     &subject_dn=000000003F55E6C8, &issuer_dn=000000003F55E6C0, &cipher=000000003F55E6D0)

[Thr 3852] <<- SapSSLGetPeerInfo(sssl_hdl=000000000554DC50)==SAP_O_K

[Thr 3852]     out: subject  = “CN=…”

[Thr 3852]     out: issuer   = “CN=CA Cert…”

[Thr 3852]     out: cert_len = 1052

[Thr 3852]     out: cipher   = “TLS_RSA_WITH_AES128_GCM_SHA256”

[Thr 3852] Client certificate info: subject=“CN=…”, issuer=“CN=CA Cert…”

[Thr 3852] HttpModGetDefRules: Client certificate received: with len=1052, subj=”CN=…”, issuer=”CN=CA Cert…”

[Thr 3852] HttpModGetDefRules: determined the defactions: COPY_CERT_TO_MPI ADD_CERT_TO_HEADER COMPAT_HANDLING  (21)

[Thr 3852] ->> SapSSLGetPeerInfo(sssl_hdl=000000000554DC50, &cert=000000003F545610, &cert_len=000000003F5455D8,

[Thr 3852]     &subject_dn=000000003F5456A8, &issuer_dn=000000003F5456B0, &cipher=000000003F5456A0)

[Thr 3852] <<- SapSSLGetPeerInfo(sssl_hdl=000000000554DC50)==SAP_O_K

[Thr 3852]     out: subject  = “CN=…”

[Thr 3852]     out: issuer   = “CN=CA Cert…”

[Thr 3852]     out: cert_len = 1052

[Thr 3852]     out: cipher   = “TLS_RSA_WITH_AES128_GCM_SHA256”

…”

Now the certificate will be copied to the header:

“…

[Thr 3852] HttpModHandler: add cert to headers: cert_array_len=1, cipher_id_len=2, cipher_size=128

[Thr 3852] cipher_suite: 009c[

[Thr 3852] HttpModHandler: perform the actions: COPY_CERT_TO_MPI ADD_CERT_TO_HEADER COMPAT_HANDLING (21)

[Thr 3852] MPI<139>4#4 GetOutbuf -1 214260 65536 (0) -> 00000000207042D0 104857600 MPI_OK

[Thr 3852] HttpModHandler: serialize new http header

[Thr 3852] ICT: IctHttpCloseMessage( 0000000020408020 ) -> u=0 rc=0

[Thr 3852] HttpModHandler: copy cert to buffer (len=1052)

[Thr 3852] Address   Offset ssl client cert:

[Thr 3852] ————————————————————————

[Thr 3852] 00000000203F9EF0  000000  30820418 30820381 a0030201 02020a65 |0…0……….e|

[Thr 3852] 00000000203FA300  001040  f85d0ba0 7c5633a6 1a1399bf          |.]..|V3…..    |

[Thr 3852] ————————————————————————

[Thr 3852] ICT: IctIHttpOpenMessage: 000000000564CC20 typ=1

[Thr 3852] Address   Offset request header rewritten (1 block):

[Thr 3852] ————————————————————————

[Thr 3852] 0000000020714774  000000  47455420 2f736170 2f62632f 6775692f |GET /sap/bc/gui/|

[Thr 3852] 0000000020714984  000528  0a73736c 5f636c69 656e745f 63657274 |.ssl_client_cert|

[Thr 3852] 0000000020714994  000544  3a204d49 49454744 43434134 47674177 |: MIIEGDCCA4GgAw|

[Thr 3852] 0000000020714F04  001936  75676646 597a7068 6f546d62 383d0d0a |ugfFYzphoTmb8=..|

[Thr 3852] 0000000020714F14  001952  73736c5f 63697068 65725f75 73656b65 |ssl_cipher_useke|

[Thr 3852] 0000000020714F24  001968  7973697a 653a2031 32380d0a 73736c5f |ysize: 128..ssl_|

[Thr 3852] 0000000020714F34  001984  63697068 65725f73 75697465 3a203030 |cipher_suite: 00|

[Thr 3852] 0000000020714F44  002000 39630d0a 0d0a |9c….          |

[Thr 3852] ————————————————————————

[Thr 3852] MPI<139>4#5 DiscardOutbuf 2 0 0 214260 0 0 -> 00000000207042B0 MPI_OK

[Thr 3852] HTTP request (rewritten) [4/2944/1]:

[Thr 3852]   GET /sap/bc/gui/sap/its/webgui HTTP/1.1

[Thr 3852]   accept: text/html, application/xhtml+xml, */*

[Thr 3852]   user-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; Touch; rv:11.0) like Gecko

[Thr 3852]   accept-encoding: gzip, deflate, peerdist

[Thr 3852]   ssl_client_cert: MIIEGDCCA4GgAw…

[Thr 3852]   ssl_cipher_usekeysize: 128

[Thr 3852]   ssl_cipher_suite: 009c

…”

Finally, the application server will be called to handle the URI:

“…

[Thr 3852] HttpSAPR3Handler: Call SAP AppServer for URI: /

…”

So now a work process will start handling the request, calling the ITS handler that will process the WEBGUI service request… but this is a matter for another blog in another community. 😉

Test: ECC side, part 2: SM50 logon trace

The entries for my logon were recorded in dev_w2:

“…

—————————————————

trc file: “dev_w2”, trc level: 2, release: “742”

—————————————————

*

*  ACTIVE TRACE LEVEL           2

ACTIVE TRACE COMPONENTS      all, N

*

…”

The logon trace shows that my logon was based on X.509 client certificate, asking to create a logon ticket:

“…

N DoY MoY dd hh:mm:ss yyyy

N  dy_signi_ext: X.509 client certificate logon with ticket request

N  dy_signi_ext: logon ticket creation disabled (system setting)

…”

The logon ticket creation is disabled (as I have login/create_sso2_ticket=3, i.e. only assertion tickets are created).

The certificate details are then displayed:

“…

N  CertGetInfo: Subject-Name >CN=…<

N  CertGetInfo: Issuer-Name >CN=CA Cert…<

N  CertGetInfo: Validity >Validity  –  NotBefore: DoY moY dd hh:mm:ss yyy (…Z)

N                NotAfter:   DoY MoY dd hh:mm:ss yyyy (…Z)

N  <

…”

The system looks for the mapping information (One certificate to one SAP user ID):

“…

lookup USREXTID for certificate mapping information

N  GetUsrExtId: search for <DN, “CN=…”> in client ccc for user “”

N  GetUsrExtId: found matching user >UserID< in client ccc

N  CheckX509CertIssuer: check skipped

N  GetUsrExtId: 1 matching USREXTID entries found

…”

Since there is a valid entry, then the authentication takes place:

“…

N  DyISigni: client=ccc, user=UserID     , lang=E, access=H, auth=X

N  usrexist: effective authentification method: X.509 client certificate

N  Get_RefUser(ccc,UserID) =>

N  password logon is generally enabled (default)

N  productive password is still valid (expiration period=0 / days gone=1)

N  password change not required (expiration period=0 / days gone=717)

N  usrexist: update logon timestamp (M)

N  save user time zone = >BRAZIL< for user >ccc> / >UserID     > into spa

N  dy_UserLocalTimeInit ()

N  DyISignR: return code=0 (see note 320991)

…”

The return code equal 0 was expected – as the WEBGUI screen was displayed!

Additional information

If you have a particular scenario that you would like to discuss, then use the comments and I will improve the blog to address your case.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply