How to setup the SAP Web Dispatcher with SSL Termination?

By admin Last updated Jan 20, 2021

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 first scenario.

The SSL Termination causes that the communication between the WDP and the SAP application server happens via HTTP. If you have no concerns about unencrypted traffic passing in your network, then this is a valid approach for your landscape.

If you intend to use SSL Re-encryption, then be aware that the WDP will have more CPU work: you have encryption/decryption operations happening in both sides of the WDP: [browser <-> WDP] AND [WDP <-> app server].

The last scenario is End-to-End SSL: the web dispatcher simply forwards all the content to the application server. The WDP cannot look at the browser request, cannot look for session cookies. The load balancing, in this scenario, can only be accomplished based on the browser’s network address (IP address).

Prerequisites

SAP Web Dispatcher 7.20 or higher
SAPCRYPTOLIB 5.5.5 patch level 24 or higher (in this blog pl 32 was used)

Profile parameters

The standard SSL configuration demands the following three parameters:

ssl/ssl_lib = sapcrypto.dll

ssl/server_pse = SAPSSLS.pse

ssl/client_pse = SAPSSLC.pse

As the WDP 7.20 (and higher) can connect to different systems, the following parameters were set:

wdisp/system_0 = SID=AAA, MSHOST=, MSPORT=8100, SRCSRV=webdispatcher.foo.bar:10000

wdisp/system_1 = SID=BBB, MSHOST=, MSPORT=8171, SRCSRV=webdispatcher.foo.bar:10001

The server ports also must be defined:

icm/server_port_0 = PROT=HTTP,PORT=9999

icm/server_port_1 = PROT=HTTPS,PORT=10000

icm/server_port_2 = PROT=HTTPS,PORT=10001

As the WDP will terminate the SSL communication, the parameter below must be set:

wdisp/ssl_encrypt = 0

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

A result similar to the following should be seen:

Checking SAP Web Dispatcher Configuration

=========================================

maximum number of sockets supported on this host: 8192

Server info will be retrieved from host: :8100 with protocol: http

Checking connection to message server of system AAA…OK

Retrieving server info from message server…OK

Message Server instance list of system AAA

+———————+———————+———+———-+

+———————+———————+———+———-+

| HOST_AAA_00 | | 8000 | 443 |

+———————+———————+———+———-+

Checking ABAP servers with URL “/sap/public/icman/ping”:

Checking ABAP server https://:8000…OK

Checking J2EE servers with URL “/index.html”:

No server group “!J2EE” defined

Server info will be retrieved from host: :8171 with protocol: http

Checking connection to message server of system BBB…OK

Retrieving server info from message server…OK

Message Server instance list of system BBB

+———————+———————+———+———-+

+———————+———————+———+———-+

| HOST_BBB_71 | | 8071 | 443 |

+———————+———————+———+———-+

Checking ABAP servers with URL “/sap/public/icman/ping”:

Checking ABAP server https://

Checking J2EE servers with URL “/index.html”:

No server group “!J2EE” defined

Retrieving group info with HTTP from server :8000…OK

Defined server groups:

+———————+———-+

| group name | #entries |

+———————+———-+

| !DIAG | 3 |

| !DIAGS | 3 |

| !ALL | 3 |

+———————+———-+

Retrieving url info with HTTP from server :8000…OK

Url map info file “/sap/public/icf_info/icr_urlprefix” is OK

Contents of url map file:

+———————+———————+——————–+

| URL | Group | virtual host |

+———————+———————+——————–+

| /nwbc/ | | *:*;|

| /sap/ | | *:*;|

| /srm/ | | *:*;|

+———————+———————+——————–+

Check ended with 0 errors, 0 warnings

The WDP is now ready to work!

Analyzing the scenario and the dev_webdisp trace file

The backend is emitting a warning in the logon screen, since the WDP is terminating the SSL:

In this case, the service in SICF can be set to avoid issuing warnings:

The dev_webdisp has plenty information available. From the test above it is possible to see the moment the request reached the WDP:

“…

[Thr 7540] IcmWorkerThread: worker 4 got the semaphore

[Thr 7540] REQ TRACE BEGIN: 0/207/1

[Thr 7540] REQUEST:

Type: ACCEPT_CONNECTION Index = 24

[Thr 7540] CONNECTION (id=0/207):

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

NI_HDL: 103, protocol: HTTPS(2)

local host: :10000 ()

remote host: :50098 ()

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

…”

Next it is possible to check the SSL handshake between the client and the server (WDP):

“…

[Thr 7540] ->> SapSSLSessionInit(&sssl_hdl=000000000296C6E0, role=2 (SERVER), auth_type=1 (ASK_CLIENT_CERT))

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

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

[Thr 7540] out: sssl_hdl = 0000000000566A80

[Thr 7540] ->> SapSSLSetNiHdl(sssl_hdl=0000000000566A80, ni_hdl=103)

[Thr 7540] NiIBlockMode: set blockmode for hdl 103 TRUE

[Thr 7540] SSL NI-sock: local=:10000 peer=:50098

[Thr 7540] <<- SapSSLSetNiHdl(sssl_hdl=0000000000566A80, ni_hdl=103)==SAP_O_K

[Thr 7540] ->> SapSSLSessionStart(sssl_hdl=0000000000566A80)

[Thr 7540] Server-configured Ciphersuites: “TLS_RSA_WITH_AES128_CBC_SHA:TLS_RSA_WITH_AES256_CBC_SHA:SSL_RSA_WITH_RC4_128_SHA:SSL_RSA_WITH_RC4_128_MD5:SSL_RSA_WITH_3DES_EDE_CBC_SHA:SSL_RSA_WITH_DES_CBC_SHA:SSL_RSA_EXPORT_WITH_DES40_CBC_SHA:SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5:SSL_RSA_EXPORT_WITH_RC4_40_MD5”

[Thr 7540] Client-offered Ciphersuites: “TLS_RSA_WITH_AES128_CBC_SHA:TLS_RSA_WITH_AES256_CBC_SHA:SSL_RSA_WITH_RC4_128_SHA:SSL_RSA_WITH_3DES_EDE_CBC_SHA:SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA:SSL_RSA_WITH_RC4_128_MD5”

[Thr 7540] No Client Certificate

[Thr 7540] New session (TLSv1.0)

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

[Thr 7540] 00000: 3e a1 0f 16 d4 da 2c d8 0e df 81 df f7 fd e1 8e >…..,. ……..

[Thr 7540] 00010: 1b d9 31 11 77 32 33 9b 23 66 90 fc 36 97 e3 ed ..1.w23. #f..6…

[Thr 7540] <<- SapSSLSessionStart(sssl_hdl=0000000000566A80)==SAP_O_K

[Thr 7540] status = “new SSL session, NO client cert”

…”

The request is then read from the connection:

“…

[Thr 7540] IcmReadFromConn(id=0/207): read 631 bytes, 1 readops (timeout 0)

[Thr 7540] Address Offset IcmReadFromConn received

[Thr 7540] ————————————————————————

[Thr 7540] 0000000003F16058 000000 47455420 2f736170 2f62632f 6775692f |GET /sap/bc/gui/|

[Thr 7540] 0000000003F16068 000016 7361702f 6974732f 77656267 75692048 |sap/its/webgui H|

[Thr 7540] 0000000003F16078 000032 5454502f 312e310d 0a416363 6570743a |TTP/1.1..Accept:|

[Thr 7540] 0000000003F16088 000048 20617070 6c696361 74696f6e 2f782d6d | application/x-m|

…”

The WDP will reach the web application server ABAP via HTTP:

“…

[Thr 7540] HttpPortTableMatchPort: Port 0, webdispatcher.foo.bar:10000 (:10000) matches request

[Thr 7540] ICR: IcrFindTargetSystem(0000000002A78020, ‘/sap/bc/gui/sap/its/webgui’ -> 0

[Thr 7540] HttpGetRouteTargetSystem: SID=’AAA’

[Thr 7540] ICT: IctLookupPathTable() -> 0

[Thr 7540] HTR: found stack ABAP for URL /sap/bc/gui/sap/its/webgui

[Thr 7540] HTR: routing destination type = ICF/ABAP .

[Thr 7540] HTR: No esid found in request

[Thr 7540] HTR: HtrIExtractSessionID -> ” 0

[Thr 7540] HTR: stateless request (no valid session ID found) or initial request for stored session id

[Thr 7540] ICR: IcrIGetMinLoadServer: server ‘HOST_AAA_00’1 delta=400 load=0/8800valid=1 resp=1 capacity=10

[Thr 7540] ICR: IcrIFindMatchingPort for prot=0 stack=1 vhost=-1

[Thr 7540] ICR: IcrIFindMatchingPort: compare with 0 0 8000 10

[Thr 7540] ICR: IcrIFindMatchingPort: found matching port: prot=0 vhost=0 port=8000 f=10

[Thr 7540] ICR: IcrIGetMinLoadServer: near-zero load #0: HOST_AAA_00

[Thr 7540] ICR: IcrAttachToServer: next destination server ‘HOST_AAA_00’1 10 1 0 port:8000/0/0

…”

A few seconds later the WDP sends the request to the application server:

“…

[Thr 7540] local host: :50099

[Thr 7540] remote host: :8000

[Thr 7540] HTR: forwarding buffer to server (631)

[Thr 7540] Address Offset Send to AppServer via net:

[Thr 7540] ————————————————————————

[Thr 7540] 0000000003F16058 000000 47455420 2f736170 2f62632f 6775692f |GET /sap/bc/gui/|

[Thr 7540] 0000000003F16068 000016 7361702f 6974732f 77656267 75692048 |sap/its/webgui H|

[Thr 7540] 0000000003F16078 000032 5454502f 312e310d 0a616363 6570743a |TTP/1.1..accept:|

[Thr 7540] 0000000003F16088 000048 20617070 6c696361 74696f6e 2f782d6d | application/x-m|

…”

A response is received from the application server:

“…

[Thr 7540] Address Offset IcmReadFromPartner received

[Thr 7540] ————————————————————————

[Thr 7540] 0000000003F16058 000000 48545450 2f312e31 20323030 204f4b0d |HTTP/1.1 200 OK.|

[Thr 7540] 0000000003F16068 000016 0a636f6e 74656e74 2d747970 653a2074 |.content-type: t|

[Thr 7540] 0000000003F16078 000032 6578742f 68746d6c 3b206368 61727365 |ext/html; charse|

…”

The response is then encrypted and sent to the web browser:

“…

[Thr 7540] IcmPlCheckRetVal: Next status: READ_REQUEST(1)

[Thr 7540] IcmHandleNetWrite(id=0/207): HandleServData returned: 1

[Thr 7540] Address Offset IcmWriteToConn:

[Thr 7540] ————————————————————————

[Thr 7540] 0000000003F16058 000000 48545450 2f312e31 20323030 204f4b0d |HTTP/1.1 200 OK.|

[Thr 7540] 0000000003F16068 000016 0a636f6e 74656e74 2d747970 653a2074 |.content-type: t|

[Thr 7540] 0000000003F16078 000032 6578742f 68746d6c 3b206368 61727365 |ext/html; charse|

[Thr 7540] 0000000003F16088 000048 743d7574 662d380d 0a636f6e 74656e74 |t=utf-8..content|

…”

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

“…

[Thr 7540] IcmWriteToConn(id=0/207): wrote data to partner (len = 5502)

[Thr 7540] IcmNetBufFree: free netbuf: 0000000000619C30 out of 1 used

[Thr 7540] MPI<5>0#4 DiscardOutbuf 0 0 0 1a5fa0 0 0 -> 0000000003F15FF0 MPI_OK

[Thr 7540] NiWakeupExec: send wakeup signal to 59458->64998 (sock 33016)

[Thr 7540] IcmConnRollOut: connection (id=0/207) rolled out: reason:1 role:1 timeout:60

[Thr 7540] CONNECTION (id=0/207):

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

NI_HDL: 103, protocol: HTTPS(2)

local host: :10000 ()

remote host: :50098 ()

status: READ_REQUEST

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

MPI request: <4> MPI response: <5>

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 7540] IcmWorkerThread: SSL Session rolled out

[Thr 7540] REQ TRACE END: 0/207/1

[Thr 7540] IcmWorkerThread: Thread 4: 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

…”

Stay tuned for my next blog about SSL Re-encryption in the SAP Web Dispatcher!

Would you like to access Full Article?

If you are already a member in this website, Please Click here to loginIf you are not yet a member, Please Click here to Sign up

if you have any questions don’t hesitate to contact us from the Button bellow

New NetWeaver Information at SAP.com

Very Helpfull

User Rating: Be the first one !