Ssl handshake issue

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: i check at /var/log/nginx/ .error

It produced this output: SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: server:

i get this error and website is not loaded with code

My web server is (include version): nginx

The operating system my web server runs on is (include version): debian

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):certbot 0.31.0

Is some actual person failing to connect to your site? If so, what operating system and browser are they using? Include the version numbers.

Because badly behaved bots may cause those errors too and nothing you can do about that. I see your site successfully from many clients. As one example, see your SSL Labs report which gives you an A+


Messages like this are commonly produced by internet scanners, because those intentionally connect with bad data to test your server's TLS setup.

Unless you're debugging a specific issue, it usually makes sense to turn off the logging of TLS handshake errors server-side: You're just going to get bloated with errors from misbehaving clients.


can you please suggest how to log off TLS handshake errors server-side

IIRC, handshake messages are of info severity, so it should suffice to set your error log level to notice or lower. I personally have it set to warn.

error_log /var/log/nginx/error.log warn;

Also see the nginx docs for more information. You likely have such a directive already defined (in /etc/nginx/nginx.conf, or other places), so you will need to change this existing line to avoid duplicating directives.


Adding on to Nummer378 comment, your log error will show its level in the first part of the error message. If yours looks like this:

2022/04/16 04:40:19 [crit] 809329#809329: *13542487 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client:, server:

it means that message error is level crit. So, you would need to set your error log level to alert or more to avoid seeing crit messages. You'd have to assess whether that would suppress too many errors. I am just providing more details on how this works. See the nginx docs Nummer linked to


Thank you so much for the advice.
My website is working fine.

My doubt is:
When i give the command netstat -anlp | grep LISTEN
my website is running in 6000
I get, why not
can anyone help me in knowing what is the reason

1 Like

What service is running on port 6000?


In same server iam running two applications node.
one at port 5480
and another port 6000

nodejs application

If you want that nodejs application to only run locally (127.0.0.x), then you need to edit the config for it and ensure that it binds only to such an IP.

Note: When binding to local IPs, all external/Internet IPs will be unable to reach them.


Just wanted to provide an update here, because I just saw it in the nginx changelog.

It appears as if there was a mistake, with some handshake error messages (such as bad key share) indeed being set to level crit. This has been corrected as of nginx 1.23.1 (released 19 July 2022, i.e. today), and those handshake messages are now of level info, in line with other handshake errors (I originally stated that the handshake error messages mentioned in this thread were of level info, which was not correct for some nginx versions).


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.