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:
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. :wink:
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):
"...
N 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
- SAP note 320991
- SAP note 1257108
- SAP Help page on icm/HTTPS/verify_client
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.
- SAP Managed Tags:
1 Comment
