SSL protocol error after today's updates

After today’s install of the following (and maybe since the last core update)

The following 12 packages are going to be upgraded:
  libsystemd0 libsystemd0-32bit libudev1 libudev1-32bit systemd systemd-32bit systemd-container systemd-doc systemd-lang systemd-network systemd-sysvinit
The following NEW patch is going to be installed:
The following patch requires a system reboot:

My Subsonic server throws a SSL protocol error on all browsers except Firefox.
I have made no changes to my Let’s Encrypt certificate or to Subsonic. Firefox says all is OK and the Cert is Valid. Edge says no certificate was presented.

Edge says that no certificate is presented (chrome too, and on 3 platforms). Firefox says all is good and displays the certificate.

Apparently your server rejects anything below TLSv1.2 and it depends on client implementation whether it works. I cannot connect to your server using OpenSSL, but can connect using GnuTLS.

GnuTLS starts with TLS 1.2, server tells to use TLS 1.3 and connection proceeds.

By default OpenSSL tries TLS 1.0 which your server rejects right away. If I force TLS 1.2 only connection seems to work although there is still error “dh key too small” (which points to your server configuration; I can disable DH on client side and do not get this error). If I force TLS 1.3, connection fails right away.

But this is testing using openssl s_client. If I use curl built against OpenSSL it always starts with TLS 1.0 whatever version I say to use so connection fails immediately.

It seems to be more complicated. OpenSSL does (attempt to) use TLS 1.3, but your server rejects initial Client Hello packet. I think that it is due to OpenSSL using legacy version TLS 1.0 (3.1) in initial record packet. This is valid according to TLS 1.3 standard, but this is also the only difference I can see.

GnuTLS is using version TLS 1.2 (3.3) in initial record and it works.

didn’t java blacklist the lower TLS versions? I ran into this in the opposite direction when javamail failed on a corporate smtp that offered only TLS 1.0 on STARTTLS. And since that subsonic server seems to be java, then I would check that first. You can de-blacklist it in some java security properties file. Can’t remember the exact name