A rash of crit errors in error_log

SYSTEM INFORMATION
OS type and version Ubuntu Linux 22.04.4
Webmin version 2.111
Usermin version 2.010
Virtualmin version 7.10.0
Theme version 21.10
Package updates All installed packages are up to date

I am not sure if this is because of or connected to https://forum.virtualmin.com/t/server-admin-gets-an-error-why/127795

History:
This is a (relatively) new VM it only has 4 VS (3 parent domains, 1 sub-server domain)
It is managed by 1 client who wanted to use PHP (that makes it fairly unusual for me). I consider it a development server. So I have not been paying too much attention to the logs. (leaving such matters to the client who regularly logs in as the System Admin.

It is an Nginx webserver.

Today the log has been steadily filling up with the following crit errors (a sample below):
I have not seen this before: Is there a simple way to block them?

2024/07/09 12:04:24 [crit] 596347#596347: *17317 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 74.82.47.2, server: 178.79.131.181:443

2024/07/09 11:50:14 [crit] 596347#596347: *17255 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 188.166.106.51, server: 178.79.131.181:443

2024/07/09 11:30:55 [crit] 596347#596347: *17179 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 2001:470:1:332::42, server: [2a01:7e00::f03c:94ff:fe1a:f5fc]:443

2024/07/09 11:13:33 [crit] 596347#596347: *17102 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 170.64.171.167, server: 178.79.131.181:443

maybe take a look at https://serverfault.com/questions/905011/nginx-ssl-do-handshake-failed-ssl-error1417d18cssl/905019, they seem safe to ignore, but I suppose you could do a fail2ban regex (or a new jail) to ban too many requests like that

Tx, Just love the conclusion from there Ignore Them :slight_smile:

I have not ever bothered with fail2ban - probably should take some time out to look see, they do seem to be from a few very persistent IPs