CODEWITHSUNDEEP
perlssllwp
vani
vani

Reputation: 1

SSL23_GET_SERVER_HELLO:unknown protocol while running perl script

@Steffen: I will check on script part. I just noticed that wget command to service now url not able to establish SSL connection

[root@XXXX rpms]# wget https://testuser:testpwd.service-now.com/u_incident_interface.do --2018-06-10 13:00:07-- https://srv_SOAPimporterNagios:password@rwe.service-now.com/u_incident_interface.do Resolving rwestproxy-neurathdc.rwe.com... 10.88.253.20 Connecting to rwestproxy-neurathdc.rwe.com|10.88.253.20|:8080... connected. Unable to establish SSL connection. [root@XXXX rpms]#

Can you advice on SSL connection issue?

Upvotes: 0

Views: 15576

Answers (1)

Steffen Ullrich
Steffen Ullrich

Reputation: 123320

TL;DR: Server is responding with plain traffic instead of the expected TLS. Cause of this might be wrong expectations on the client, misconfiguration or old buggy software.

SSL connect attempt failed error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

Errors like unknown protocol or also SSL_ERROR_RX_RECORD_TOO_LONG or wrong version number usually happen if the other device does not properly talk SSL at all. This means the client is initiating the TLS handshake with the ClientHello and the server is responding with something which does not resemble SSL/TLS at all. Still the client will try to interpret the non-TLS answer as TLS and thus will complain about some strange TLS version or some corrupted TLS record.

This happens typically if one is trying to talk to plain HTTP server with HTTPS. It might be because the server was never configured for HTTPS in the first place and one is wrongly assuming that changing the URL from http:// to https:// will magically make the server HTTPS ready. It might also be that that one is accessing the wrong port at the server, i.e. the plain HTTP port and not the HTTPS port. And there are also cases where due to a misconfiguration of the server only speaks plain HTTP while the config looks like it should speak HTTPS - like in this question. Or it might be because of a wrong proxy configuration, i.e. assuming that a proxy will be accessed by HTTPS wheres it is accessed by plain HTTP even for HTTPS URL like in this question.

It can also happen if the server needs some initial plain data before switching to TLS. This is for example when using a proxy to connect to the final target. In case of a HTTP proxy the client needs to send a plain HTTP CONNECT request first, read the plain HTTP response from the server and check for success and only then can start with the TLS handshake. This situation can happen for example if you are using an older version of LWP since between 6.00 and 6.06 proxy support for HTTPS was broken.

Upvotes: 6

Related Questions