afirizarry_uw Absent Member.
Absent Member.
1054 views

SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol

Installed our first OES2018 server in to our tree. Seeing these errors in ndstrace filtered on LDAP:
TLS accept failure 1 on connection 0x14cfc000, setting err = -5875. Error stack:
error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol

Error appears over and over and am not having any luck in tracking this down. Other servers in the tree are OES2015, OEs2 and OES11. Error -5875 seems fairly generic.
How do we track down connection 0x14cfc000?
Labels (1)
Tags (2)
0 Likes
3 Replies
afirizarry_uw Absent Member.
Absent Member.

Re: SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol

Additional information. I had a secondary IP address on this server. I did a tcpdump (/usr/sbin/tcpdump -n -s 0 -i any -v -w /tmp/tcp636.cap port 636) and all the resulting traffic in the trace refereed to that secondary IP address. I deleted the secondary IP and restarted NDS and the errors in NDS trace went away. Problem is that we need the secondary IP address on the server for production.
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol

> Installed our first OES2018 server in to our tree. Seeing these errors
> in ndstrace filtered on LDAP:
> TLS accept failure 1 on connection 0x14cfc000, setting err = -5875.
> Error stack:
> error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown
> protocol


If you are filtering on LDAP then before you see the errors you should see
the connection information. It is supposed to be a default by now, but if
not you may need to enable more screen/tracing options from the LDAP
Server object associated with this server, or even faster/easier/better,
by using 'ldapconfig' from the command line like this:


ldapconfig set 'LDAP Screen Level=all'


Once you find the client making the connection you may find out more. If
you use tcpdump to write to a file you can analyze more of the actual
TLS/SSL handshake, and that can be very useful. It may be that you have
an old client out there, pointing to that old/former IP address, which is
too old to handle newer TLS/SSL protocols or ciphersuites, in which case
it may complain, but without seeing the LAN/wire trace itself it is
impossible to know for sure from what you have provided.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Knowledge Partner
Knowledge Partner

Re: SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol

afirizarry_uw;2490760 wrote:
Additional information. I had a secondary IP address on this server. I did a tcpdump (/usr/sbin/tcpdump -n -s 0 -i any -v -w /tmp/tcp636.cap port 636) and all the resulting traffic in the trace refereed to that secondary IP address. I deleted the secondary IP and restarted NDS and the errors in NDS trace went away. Problem is that we need the secondary IP address on the server for production.


Sounds like one or more of the OES services is confused. You might have better luck asking about this in the OES support forums.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.