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