I've got a new Ubuntu 22.04 virtual machine I just setup, and unlike my older virtual machines running older versions of Ubuntu, this server is unable to connect to one of my servers using an https certificate that was obtained using dns validation using winacme (wacs).
On the Windows server itself, I canceled the certificate, updated WACS to the latest version, and re-ran my original command to obtain new certificates. Unfortunately, the problem persists, and I have no idea why. It looks like openssl in newer versions of Ubuntu is configured by default to require CipherString = DEFAULT:@SECLEVEL=2
This is pretty easy to test in Chrome by going to chrome://flags and enabling the #use-sha1-server-handshakes flag.
This isn't a problem with the certificate, but with the software installed on the server. Sha-1 handshake signatures are being phased out by Chrome as mentioned in the above link, but OpenSSL on various linux distributions have also started doing the same.
The server reports it is running "Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.3.20". The bug exists in OpenSSL versions 1.0.1 up to 1.0.1i.
Note that version 1.0.1i was released in 2014, 9 years ago. Apache 2.4.3 is of a similar vintage.
You should seriously consider upgrading Apache and OpenSSL to a version that is newer and supported.
I notice that the certificate chain is different. The example you mention lastly doesn't contain the ISRG Root X1-cross-signed-by-DST Root CA X3. But I doubt that is the issue here, as my OpenSSL 3.0.9 shouldn't have any issue with that.
Hm, not sure what changed the last 5 minutes, but suddenly my OpenSSL doesn't show the error any longer and can connect perfectly to gen.sched.us:21442? Incorrect and long chain still present, so that hasn't changed and thus, as predicted, is/was not the issue.
Definitely seems to be a bug in that version of Apache (maybe), as setting up another virtualhost entry using that same port for a different host causes the verification to fail for any subsequent entry. Really weird...
You're correct. After more troubleshooting, it does indeed happen with server name indication where multiple virtualhost entries are listening on the same port (and using SSL). To work around this issue, you can set your SSL virtualhost entries to listen on a different port, one per port, and then the SSL verification succeeds on each host.
I would upgrade this server if I could, but for what I'm doing and using it for, it's not very feasible at the moment.