Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

ICM 'SSSLERR_SSL_READ' error, with subrc = 110

Former Member
0 Kudos

Hi,

After setting up my HTTP RFC connection, loading third party server certificate, and testing successfully mi connection, I´ve run my code.

When I send my request, everything is fine.

When I try to get the response (client->receive), I get no text error, with subrc code= 110.

ICM trace file says:

*** ERROR during SecudeSSL_Read() from SSL_read()==SSL_ERROR_SSL

session uses PSE file "/usr/sap/GSD/DVEBMGS00/sec/SAPSSLC.pse"

SecudeSSL_Read: SSL_read() failed

secude_error 536872195 (0x20000503) = "handshake failure"

>> Begin of Secude-SSL Errorstack >>

ERROR in ssl3_read_bytes: (536872195/0x20000503) handshake failure

WARNING in ssl3_read_bytes: (536875072/0x20001040) received a fatal SSLv3 handshake failure alert message from the peer

<< End of Secude-SSL Errorstack

SSL NI-sock: local=192.168.79.17:60348 peer=201.175.40.6:443

<<- ERROR: SapSSLRead(sssl_hdl=0x6000000005f35bc0)==SSSLERR_SSL_READ

*** ERROR => IcmReadFromConn(id=5/222): SapSSLRead returned (-58): SSSLERR_SSL_READ

*** ERROR => IcmReadFromConn(id=5/222): read failed (rc = -1)

*** ERROR => IcmHandleNetRead(id=5/222): IcmReadFromConn failed (rc = -1)

Any idea of what does it means?

Thanks in advance.

Federico

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi Frederico,

Try to increase the ICM trace level to the maximum and redo your test.

Decrease back the ICM trace level because it is very verbose...

It may be a cryptology problem but you need more precise messages from the ICM trace.

Regards,

Olivier

11 REPLIES 11

Former Member
0 Kudos

Hi Frederico,

Try to increase the ICM trace level to the maximum and redo your test.

Decrease back the ICM trace level because it is very verbose...

It may be a cryptology problem but you need more precise messages from the ICM trace.

Regards,

Olivier

Former Member
0 Kudos

Thanks for your restless help...

Look, I've got my new trace with the highest possible detail, but sincerely don´t know very well where or what to search for. The text strictly related with my error remains the same as in previous trace level.

What should I look for? I´m afraid it´s too large to paste the whole trace here...

Thanks in advance,

Federico.

0 Kudos

Hi again,

Try to see error messages concerning the SSL handshake.

Yes, Do NOT post the full trace here or only a very small interesting extract.

Here is an example of a successfull HTTPS connexion :


[Thr 19896] <<- SapSSLSessionInit()==SAP_O_K
[Thr 19896]      in: args = "role=2 (SERVER), auth_type=1 (ASK_CLIENT_CERT)"
[Thr 19896]     out: sssl_hdl = 0000000001A6B650
[Thr 19896] NiIBlockMode: set blockmode for hdl 51 TRUE
[Thr 19896]   SSL NI-sock: local=xxx.xxx.xxx.xxx:444  peer=172.26.97.130:1106
[Thr 19896] <<- SapSSLSetNiHdl(sssl_hdl=0000000001A6B650, ni_hdl=51)==SAP_O_K
[Thr 19896] <<- SapSSLSessionStart(sssl_hdl=0000000001A6B650)==SAP_O_K
[Thr 19896]          status = "new SSL session, NO client cert"
[Thr 19896] IcmPlCheckRetVal: Next status: READ_REQUEST(1)
[Thr 19896] IcmReadFromConn(id=0/6775): request new MPI (0/0)
[Thr 19896] MPI<e7>0#3 GetOutbuf -1 187210 65536 (0) -> 000000000CF97280 0
[Thr 19896] <<- SapSSLReadPending(sssl_hdl=0000000001A6B650)==SAP_O_K
[Thr 19896]     out: pendlen = 0
[Thr 19896] <<- SapSSLRead(sssl_hdl=0000000001A6B650)==SAP_O_K
[Thr 19896]          result = "max=65463, received=1096"
[Thr 19896] IcmReadFromConn(id=0/6775): read 1096 bytes(timeout 500)
[Thr 19896] BINDUMP of content denied
[Thr 19896] PlugInHandleNetData(rqid=0/6775/1): role: 1, status: 1
#content-length: 0/0, buf_len: 1096, buf_offset: 0, buf_status: 0
[Thr 19896] HttpParseRequestHeader: content length: 219
[Thr 19896] HttpParseRequestHeader: no transfer-encoding set
[Thr 19896] HttpParseRequestHeader: Version: 1001
[Thr 19896] HttpParseRequestHeader: Keep-Alive: 1
[Thr 19896] <<- SapSSLGetPeerInfo(sssl_hdl=0000000001A6B650)==SAP_O_K
[Thr 19896] HttpRewriteRequestHeader: perform actions: 0
[Thr 19896] PlugInHandleNetData: need more data (0/219)
[Thr 19896] IcmPlCheckRetVal: Next status: READ_REQUEST(1)
[Thr 19896] IcmHandleNetRead(id=0/6775): read_len: 1096, HandleNetData returned: 1
[Thr 19896] <<- SapSSLReadPending(sssl_hdl=0000000001A6B650)==SAP_O_K
[Thr 19896]     out: pendlen = 0
[Thr 19896] IcmHandleNetRead(id=0/6775): pending SSL data: 0, rollout=0
[Thr 19896] <<- SapSSLReadPending(sssl_hdl=0000000001A6B650)==SAP_O_K
[Thr 19896]     out: pendlen = 0
[Thr 19896] <<- SapSSLRead(sssl_hdl=0000000001A6B650)==SAP_O_K

Regards,

Olivier

Former Member
0 Kudos

Hi Olivier,

I don´t see any further information related to the error in the trace.

I´ll just show you some lines may be you see anything interesting:

NiIBlockMode: set blockmode for hdl 9 TRUE

*** ERROR during SecudeSSL_Read() from SSL_read()==SSL_ERROR_SSL

session uses PSE file "/usr/sap/GSD/DVEBMGS00/sec/SAPSSLC.pse"

SecudeSSL_Read: SSL_read() failed --

secude_error 536872195 (0x20000503) = "handshake failure"

>> -

-


Begin of Secude-SSL Errorstack -

-


>>

ERROR in ssl3_read_bytes: (536872195/0x20000503) handshake failure

WARNING in ssl3_read_bytes: (536875072/0x20001040) received a fatal SSLv3 handshake failure alert message from the peer

<< -

-


End of Secude-SSL Errorstack -

-


<<- ERROR: SapSSLRead(sssl_hdl=0x60000000009273e0)==SSSLERR_SSL_READ

->> SapSSLErrorName(rc=-58)

<<- SapSSLErrorName()==SSSLERR_SSL_READ

*** ERROR => IcmReadFromConn(id=3/1455): SapSSLRead returned (-58): SSSLERR_SSL_READ

*** ERROR => IcmReadFromConn(id=3/1455): read failed (rc = -1)

*** ERROR => IcmHandleNetRead(id=3/1455): IcmReadFromConn failed (rc = -1)

Finally, there´s no doubt about that the destination server is the one who sends the alert, and finish communication, right? I mean, it´s not SAP who interrupts the session.

Hope you could help me.

Thanks a lot.

Federico

Former Member
0 Kudos

Additionally, the server-side guys, told me the log in the server says all the time:

[Fri Jun 12 14:42:08 2009] [error] Re-negotiation handshake failed: Not accepted by client!?

Regards,

Federico.

0 Kudos

Hi Frederico,

The diagnosis is difficult because I've never had such an error...

It may be a compatibility problem between the Server and SAP Netweaver.

Check the HTTPS protocol release : SSL v2, SSL v3, TLS 1.0, TLS 1.1, TLS 1.2 ?

It seems that SAP Netweaver uses SSL v3. IS the distant server compatible with SSL v3 ?

Regards,

Olivier

0 Kudos

Hi,

Check also your release of the SAP Cryptolib.

I'm using Release 5.5.5C patch level 24 which, I think, is the newest one.

Olivier

Former Member
0 Kudos

Hi, Olivier, it´s good to hear from you again.

We´ve already installed the last SAP Cryptolib version.

Also, I´ve sent my whole ICM trace file to SAP, and they told me:

u201CThis error message does not directly tell anything - it only shows

that the peer (in this case: the server) is unhappy with the certificate being sent.

You'll need to doublecheck on the server side to find out what

actually goes wrong. My guess is, that no certificate or the wrong

certificate is received.

This mean that the server sends a list of the trusted certificates

and the client finds out, that he won't be trusted anyway. So, the

requirement is to add either the client's certificate, or (recommended)

the CA certificate that was used to issue the client certificate, to the server's certificate list. Please restart ICM as well.

(u2026) if the HTTP external server side is not from SAP, you'll

have to double check the certificate settings.u201D

The server-side guys tell that everything regarding technical setting seems to be fine, that SAP SRM certificates are added as a trustworthy client, but the error persists.

Any idea?

Thanks in advance,

Federico.

0 Kudos

Hi Frederico,

I suppose that you are working on test systems.

I suggest that you ask the server-sideguys to deactivate client certificate authentication on their servers.

That would be a test to detect if the problem is here as SAP seems to think...

Regards,

Olivier

Former Member
0 Kudos

Hi,

No, they can´t deactivate the SSL (or they don´t want to).

We´re still dealing with certificates, where the problem appears to be.

Any news (if solved) will be posted form the community benefit.

Thanks for all your help, Olivier.

Regards,

Federico

Former Member
0 Kudos

We finally never solve the problem, the error persists in the server-side.

Anyway, an Apache parameter was set to ignore certificate errors, and that´s how we could go on.

Thanks everyone, hope this could help someone else.

Regards,

Federico.