On some updated machines there is an ssl error in log that ee key is to small. AH02562: Failed to configure certificate xxxxxxxxxx:444 :0 (with chain), check /etc/httpd/server.crt [Fri Jan 12 23:52:40.051963 2024] [ssl:emerg] [pid 3076:tid 136836598444224] SSL Library Error: error:0A00018F:SSL routines::ee key too small AH00016: Configuration Failed after regeneration of the hostkeys it works. But the updater has to check this and maybee regenerate the key.
Is it possible that your machine was using a very ancient RSA key or something like that? Has that machine been updated for a very long time?
I did some testing with my vm testbed and creating apache rsa certificates of different sizes. 2048 and 4096 bit certificates are fine with the update to CU183. If you have a 1024 bit rsa certificate then it works fine with CU182 with the OpenSSL-3.1.4 but fails to start after upgrade to CU183 with OpenSSL-3.2.0 After some searching I have found the following statement in the 3.2.0 changelog The default SSL/TLS security level has been changed from 1 to 2. RSA, DSA and DH keys of 1024 bits and above and less than 2048 bits and ECC keys of 160 bits and above and less than 224 bits were previously accepted by default but are now no longer allowed. By default TLS compression was already disabled in previous OpenSSL versions. At security level 2 it cannot be enabled. So with OpenSSL-3.2.0 the default security level means certificates need to be a minimum of 2048 bits.
I can confirm this. Old systems installed before core115 has a 1024 bit hostkey
I ran a test on my vm testbed with a CU182 system with a 1024 bit rsa certificate and ran the update to CU183. Everything went well. Apache restarted and checking the rsa cert it was 4096 bit after upgrade. So I can confirm that the fix commits are working.
I will just link this here, because some parts of the conversation have been happening on the list: > https://lists.ipfire.org/hyperkitty/list/development@lists.ipfire.org/thread/ESM2DVKTMQ3MS4TINHRMJMF4VUQFMYUR/
https://www.ipfire.org/blog/ipfire-2-29-core-update-183-is-available-for-testing
Set up a CU182 vm system with 1024 bit server.crt and then ran the Testing CU183 upgrade. Confirm that everything worked as expected with result being a 4096 bit server.crt No impact on the browser as it was using the ECDSA cert anyway.
Core Update 183 with the fix has been released now. https://www.ipfire.org/blog/ipfire-2-29-core-update-183-released