How to setup the SAP Web Dispatcher with End-to-End SSL?

[cris_hansen]

There are three different scenarios involving the SAP Web Dispatcher (WDP) and HTTPS access: SSL Termination (in the WDP), SSL Re-encryption and End-to-End SSL. This blog will present the third and last scenario.

Prerequisites

• SAP Web Dispatcher 7.20 or higher


• SAPCRYPTOLIB 5.5.5 patch level 24 or higher (in this blog pl 32 is used)

Profile parameters

The standard SSL configuration demands the following two parameters:

ssl/ssl_lib     = <path>\sapcrypto.dll

ssl/server_pse  = <path>\SAPSSLS.pse

As the WDP 7.20 or higher can connect to different systems, the following parameter was set:

wdisp/system_0 = SID=AAA, MSHOST=<FQDN1>, MSSPORT=44400, SRCSRV=webdispatcher.foo.bar:10000

The WDP will reach the message server from the backend through the HTTPS port 44400.

The server ports also must be defined:

icm/server_port_0 = PROT=ROUTER,PORT=10000

icm/server_port_1 = PROT=HTTPS,PORT=0

As the metadata exchange should be done via HTTPS, then the parameter below is set:

wdisp/server_info_protocol = https

At last, but not least, for testing purposes, the HTML dump into the trace will be enabled, along with a trace level 3. Important: the trace files will be HUGE! The parameters below should be set only for a quick test or for error analysis. The default trace level (i.e. 1) must be used in productive systems (and for security matters, the HTML dump should not be active).

icm/trace_secured_data = 1

rdisp/TRACE = 3

Checking the configuration

As soon as the profile file is saved, one can test the configuration by running:

sapwebdisp pf=sapwebdisp.pfl -checkconfig

No error message is expected (the result of the -checkconfig is the same as shown here)

The WDP is now ready to work!

Analyzing the scenario and the dev_webdisp trace file

One issue with this scenario is that the Web Application Server (WAS) will do the SSL handshake. The certificate sent to the web browser will have the CN from the WAS and not from the WDP! The web browser will see this and issue a warning:

In this scenario, the WDP serves as a router to the request. The entry found in the dev_webdisp shows:

"...

[Thr 6424] IcmWorkerThread: worker 3 got the semaphore

[Thr 6424] REQ TRACE BEGIN: 2/15/2

[Thr 6424] REQUEST:

    Type: READ_REQUEST    Index = 10995

[Thr 6424] CONNECTION (id=2/15):

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

    NI_HDL: 169, protocol: ROUTER(16)

    local host:  <WDP IP>:10000 ()

    remote host: <Client IP>:54828 ()

    status: READ_REQUEST

    connect time: xx.zz.yyyy aa:bb:cc

    backend host: <FQDN WAS>:443, nihdl: 177, ssl: 0, desc: 0000000002BB0790

    MPI request:        <6>      MPI response:        <7>  

request_buf_size:   0        response_buf_size:   0    

    request_buf_used:   0 response_buf_used:   0    

request_buf_offset: 0 response_buf_offset: 0    

..."

The actual communication can be found in the dev_icm trace file from the WAS (in this case, the trace level was already set to 3).

The connection from WDP to WAS:

"...

[Thr 3428] IcmWorkerThread: worker 20 got the semaphore

[Thr 3428] REQ TRACE BEGIN: 0/1552/1

[Thr 3428] REQUEST:

    Type: ACCEPT_CONNECTION    Index = 3156

[Thr 3428] CONNECTION (id=0/1552):

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

    NI_HDL: 250, protocol: HTTPS(2)

    local host:  <WAS IP>:443 ()

    remote host: <WDP IP>:56517 ()

    status: NOP

    connect time: xx.zz.yyyy aa:bb:cc

    MPI request:        <0>      MPI response:        <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

..."

The SSL handshake between the client and the server (WAS):

"...

[Thr 3428] ->> SapSSLSessionInit(&sssl_hdl=0000000002A0BE60, role=2 (SERVER), auth_type=1 (ASK_CLIENT_CERT))

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

[Thr 3428]      in: args = "role=2 (SERVER), auth_type=1 (ASK_CLIENT_CERT)"

[Thr 3428]     out: sssl_hdl = 0000000002D1D130

[Thr 3428] ->> SapSSLSetNiHdl(sssl_hdl=0000000002D1D130, ni_hdl=250)

[Thr 3428] NiIBlockMode: set blockmode for hdl 250 TRUE

[Thr 3428]   SSL NI-sock: local=<WAS IP>:443  peer=<WDP IP>:56517

[Thr 3428] <<- SapSSLSetNiHdl(sssl_hdl=0000000002D1D130, ni_hdl=250)==SAP_O_K

[Thr 3428] ->> SapSSLSessionStart(sssl_hdl=0000000002D1D130)

[Thr 3428] Server-configured Ciphersuites: "TLS_RSA_WITH_AES128_CBC_SHA:TLS_RSA_WITH_AES256_CBC_SHA:SSL_RSA_WITH_RC4_128_SHA:SSL_R

[Thr 3428] Client-offered Ciphersuites: "TLS_RSA_WITH_AES128_CBC_SHA:TLS_RSA_WITH_AES256_CBC_SHA:SSL_RSA_WITH_RC4_128_SHA:SSL_RSA_

[Thr 3428]   No Client Certificate

[Thr 3428]   Cached session resumed (TLSv1.0)

[Thr 3428]   HexDump of native SSL session ID { &buf= 0000000002C9D224, buf_len= 32 }

[Thr 3428] 00000: c6 7e ec f1 55 cb 9e 4c  d4 3d 34 08 78 ba 67 c3   .~..U..L .=4.x.g.

[Thr 3428]    00010: 01 36 ee 05 23 ea 98 5f  d8 fc 10 ac f2 29 49 4f   .6..#.._ .....)IO

[Thr 3428] <<- SapSSLSessionStart(sssl_hdl=0000000002D1D130)==SAP_O_K

[Thr 3428]          status = "resumed SSL session, NO client cert"

..."

The request is then read from the connection:

"...

[Thr 3428] IcmReadFromConn(id=0/1552): read 318 bytes, 1 readops (timeout 0)

[Thr 3428] Address Offset  IcmReadFromConn received

[Thr 3428]

[Thr 3428] 0000000007FF56D8 000000  47455420 2f736170 2f62632f 6775692f  GET /sap/bc/gui/

[Thr 3428] 0000000007FF56E8 000016  7361702f 6974732f 77656267 75692048  sap/its/webgui H

[Thr 3428] 0000000007FF56F8 000032  5454502f 312e310d 0a416363 6570743a  TTP/1.1..Accept:

...

[Thr 3428] 0000000007FF57D8 000256  0a486f73 743a2077 65626469 73706174  .Host: webdispat

[Thr 3428] 0000000007FF57E8  000272 63686572 2e666f6f 2e626172 3a313030 cher.foo.bar:100

[Thr 3428] 0000000007FF57F8 000288  30300d0a 436f6e6e 65637469 6f6e3a20  00..Connection:

[Thr 3428] 0000000007FF5808 000304  4b656570 2d416c69 76650d0a 0d0a      Keep-Alive....

..."

A few seconds later the WAS sends the response to the client:

"...

[Thr 3428] Address Offset  IcmWriteToConn:

[Thr 3428]

[Thr 3428] 0000000007FF56D8 000000  48545450 2f312e31 20323030 204f4b0d  HTTP/1.1 200 OK.

[Thr 3428] 0000000007FF56E8  000016 0a636f6e 74656e74 2d747970 653a2074 .content-type: t

[Thr 3428] 0000000007FF56F8 000032  6578742f 68746d6c 3b206368 61727365  ext/html; charse

..."

Finally, the thread is free to wait a new request:

"...

[Thr 3428] CONNECTION (id=1/1553):

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

    NI_HDL: 308, protocol: HTTPS(2)

    local host:  <WAS IP>:443 ()

    remote host: <WDP IP>:56518 ()

    status: READ_REQUEST

    connect time: xx.zz.yyyy aa:bb:cc

    MPI request:        <107a>   MPI response:        <107b>

request_buf_size:   0        response_buf_size:   0

request_buf_used:   0        response_buf_used:   0

request_buf_offset: 0 response_buf_offset: 0

[Thr 3428] REQ TRACE END: 1/1553/5

[Thr 3428] IcmWorkerThread: Thread 20: Waiting for event

..."

If the parameter "icm/trace_secured_data = 1" is not set, it is not possible to see the HTML content. The following log entry appears:

"…

BINDUMP of content denied

…"

So, the three usual SSL scenarios involving the web dispatcher are now available.

For more on the SAP Web Dispatcher, please access this Wiki page.