Obtaining a Let's Encrypt certificate that passes CipherString SECLEVEL=2 in OpenSSL

Help
1

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).

My domain is: https://gen.sched.us:21442/

I ran this command: wget "https://gen.sched.us:21442/"

It produced this output:

wget "https://gen.sched.us:21442/"
--2023-10-30 13:14:04-- https://gen.sched.us:21442/
Resolving gen.sched.us (gen.sched.us)...
Connecting to gen.sched.us (gen.sched.us)||:21442... connected.
OpenSSL: error:0A000172:SSL routines::wrong signature type
Unable to establish SSL connection.

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

However, I can't even get https://gen.sched.us:21442/ to work with SECLEVEL=1. It does work with SECLEVEL=0.

So, my question is, how do I obtain a Let's Encrypt certificate that passes SECLEVEL=2 openssl validation?

Why is the current certificate supposedly having a wrong signature type problem? Can anyone help?

2

It seems you are serving the leaf cert twice:

Certificate chain
 0 s:CN = gen.sched.us
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: rsaEncryption, 3072 (bit); sigalg: RSA-SHA256
   v:NotBefore: Oct 30 18:11:01 2023 GMT; NotAfter: Jan 28 18:11:00 2024 GMT
 1 s:CN = gen.sched.us
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: rsaEncryption, 3072 (bit); sigalg: RSA-SHA256
   v:NotBefore: Oct 30 18:11:01 2023 GMT; NotAfter: Jan 28 18:11:00 2024 GMT
 2 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
 3 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 20 19:14:03 2021 GMT; NotAfter: Sep 30 18:14:03 2024 GMT

And possibly providing incompatible ciphers.
What is the cipher list in use?

2 Likes
3

I'm not sure. How do I find out? Any idea why it would be serving the leaf cert twice? I just configured apache to use the certs out of the box... I didn't modify the certs.

4

What software answers to port 21442?
What does its' config file show?

One example is when serving both cert.pem & fullchain.pem files.

4 Likes
5

I think the server is likely running ancient OpenSSL and has the bug described on Chromium Docs - TLS SHA-1 Server Signatures

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.

6 Likes
6

Thanks, but I have other servers running the same versions of apache / openssl / php that are configured almost exactly the same and yet are passing verification.

For example: genbg.sched.us:21442

openssl s_client -connect genbg.sched.us:21442 -cipher DEFAULT@SECLEVEL=2

The above passes. So, I am not sure what the difference is :frowning: or what is triggering this problem. If it's an apache issue or something else...

7

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.

Edit:
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.

1 Like
8

Yeah, I just fixed it, but I have no idea how what I did fixed it. Isn't that wonderful? :frowning:

All I did was separate the SSL virtualhost entries from the non-SSL virtualhost entries and load the SSL virturalhost entries last in the httpd.conf file... and it's fixed. :expressionless:

I basically mirrored the conf settings from the servers where it was working to the one where it wasn't working, and what I listed above are the only differences that existed between the two...

9

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...

10

The OpenSSL bug also requires SNI, Server Name Indication, which might be why you're only seeing it on some entries. I'm not familiar with the exact situation required to trigger it.

4 Likes
11

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.

1 Like
12

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